Eqstlab

The `grep()` function exported by @augment-vir/node inserts caller-controlled search patterns into a double-quoted shell command string without sanitization. When this command is passed to the `spawn()` function with the shell set to 'bash', the shell evaluates command substitution expressions embedded in the pattern. This allows for arbitrary OS command execution with the privileges of the Node.js process user. Applications passing untrusted input to the `pattern` or `patterns` fields of the `grep()` function are susceptible to unauthenticated local or remote code execution.

The unauthenticated POST '/ nuxt content/:collection/query' endpoint accepts an attacker-controlled `sql` field in 'src/runtime/api/query.post.ts' that permits expensive SQLite expressions. While some releases use the `assertSafeQuery()` function in 'src/runtime/internal/security.ts' to reject certain SQL keywords in WHERE clauses, it still allows function calls such as `randomblob()`, `zeroblob()`, `hex()`, and `length()`. These queries reach the synchronous better-sqlite3 sink in 'src/runtime/internal/database.server.ts', enabling a single remote request to consume significant CPU and memory, which blocks the Node.js event loop and halts all concurrent request handling. Fully static prerendered deployments that do not expose the server endpoint are not affected.

When `KROKI SAFE MODE` is enabled, the TikZ backend guard only blocks `verbatiminput`, leaving native TeX file-read primitives such as `openin`, `read`, `input`, and `include` active. Due to the permissive `openin any` setting in TeX Live, an unauthenticated actor can send crafted LaTeX to the 'POST /tikz/svg' endpoint or the generic diagram API. This allows the renderer to read any file accessible to the Kroki container user, including secrets, configuration data, credentials, private keys, or process environment data, and render the contents into the resulting SVG. The `-no-shell-escape` option does not restrict these native file operations.

The `MCPToolsRegistry.read file()` function in `codebase rag/mcp/tools.py` fails to properly resolve and verify the containment of the `file path` variable when the `offset` or `limit` parameters trigger the paginated branch. This allows an attacker to use absolute paths or relative traversal to bypass the `validate project path` validation and access files outside the intended project root. An unauthenticated caller via a network-exposed HTTP MCP server or a local caller via stdio transport can read arbitrary UTF-8-readable files accessible to the server process, such as private keys, credentials, and configuration files.

The `readPsd()` function accepts a `totalMemoryLimit` for parsing files, but the `decodeLayerImageData` function expects a property named `memoryLimit`. This discrepancy causes an undefined limit to be passed to `createImageDataBitDepth()`, allowing an attacker to use controlled layer dimensions to trigger memory allocations exceeding the configured limit, leading to process memory exhaustion and denial of service. Additionally, the `inflateSync(compressed)` function decompresses ZIP-encoded channel data without an output-size cap, which can also result in denial of service through unbounded decompression.

An unauthenticated network attacker can create the first administrator account before the legitimate owner completes the initial setup. The `initial setup()` function only checks the `is setup` completion flag and does not require authentication, a bootstrap token, or network restrictions. The endpoint 'POST /api/auth/setup' in `src/api/routers/auth.py` invokes `create auth user()` with `UserRole.ADMIN` and `set auth cookie()`, which issues a valid `fctr session` JWT cookie. Because the application starts the listener on 0.0.0.0 and publishes port 8001 on all interfaces, non-browser HTTP clients can bypass localhost-only CORS rules. An attacker who exploits this can become the sole administrator, preventing legitimate setup and gaining the ability to read Okta-synced user data, API tokens, chat history, and application configuration, as well as modify users and Okta integration credentials.

Authenticated users with a valid `fctr session` cookie can execute arbitrary Python code without administrator privileges. By sending a request to the 'POST /api/react/execute-script' endpoint using the `script code` parameter, an attacker can bypass AI-based content filtering and security validation. The validation process in `validate generated code()` fails to properly handle `ast.Call` targets and allows `getattr` via `ALLOWED BUILTINS`, enabling dynamic call chains through ` builtins ` to evade detection. The code is written to disk by ` write temp script()` and executed as the root user via `asyncio.create subprocess exec()`. Execution results are returned through the 'GET /api/react/stream-react-updates?process id=<id>' endpoint. This can lead to full container compromise, disclosure of Okta API tokens and JWT keys, exposure of the SQLite database, and unauthorized backend-service pivoting.

The server-renderer package's ServerRendererServer accepts unauthenticated HTTP/2 requests and resolves attacker-controlled `:path` values against `server.targetOrigin` in the `onIncomingRequest()` function. Because the system does not confirm that the resolved origin remains trusted before calling fetch, a protocol-relative path can redirect the destination to any arbitrary HTTP or HTTPS endpoint reachable by the server, including internal and local services. The proxy then relays the fetched response headers and body back to the requester.

The default `JWTBearerGrant.get audiences()` function returns an empty list, which leads `JWTBearerGrant.verify claims()` to only check for the existence of an `aud` claim without verifying if it matches the current authorization server. This allows an attacker with a legitimate assertion for a different service to present it to a server that shares the same signing key and uses the default grant, enabling the acquisition of an access token across a trust boundary.

The `buildWSLegacyExecutor()` function in the executor-legacy-ws module hardcodes the TLS certificate rejection to off for Node.js connections to wss:// endpoints. This allows applications using the executor directly, or the url-loader with `SubscriptionProtocol.LEGACY WS`, to accept certificates controlled by an attacker during a network interception. This can lead to the disclosure of authentication material within `connectionParams` or headers, and the modification of subscription data. Browser WebSocket clients are not affected as they enforce certificate validation.

The library fails to validate the `tokenUrl` field within remote OpenAPI specifications. This allows an attacker to redirect the submission of credentials to arbitrary endpoints. If a user registers an attacker-controlled OpenAPI specification and invokes a generated OAuth2-protected tool, the library sends the `client id` and `client secret` via a POST request to the attacker-supplied token endpoint.

The software fails to verify if tool URLs in a hand-written UTCP manual point to the agent's own loopback interface when the manual is retrieved from a remote, non-loopback origin. This occurs because the `ensure secure url` function permits loopback HTTP for local development, and native manuals bypassed the loopback check used by the OpenAPI converter. An attacker providing a malicious UTCP manual can trigger server-side request forgery (SSRF), causing the client to send requests to services bound to 127.0.0.1 on the victim host and return the response bodies to the attacker. This issue affects the http, sse, and streamable http protocols. Exploitation requires a loopback service that responds to unauthenticated requests.

An unauthenticated server-side file exfiltration issue exists when the server is deployed using HTTP transport (such as `streamable-http` or `sse`) and `READ ONLY MODE` is set to `false`. A remote attacker can bypass authentication by providing specific service headers, such as `X-Atlassian-Confluence-Url` and `X-Atlassian-Confluence-Personal-Token`, to redirect requests to an attacker-controlled hostname. By invoking the `confluence upload attachment` function or its Jira equivalent in `src/mcp atlassian/jira/attachments.py` with a server-local `file path` variable, the attacker can force the MCP process to read and send any file accessible by the server process to the external endpoint. This occurs because the upload functionality lacks path validation, failing to use the `validate safe path()` function to restrict directory access.

When running with `OBOT SERVER ENABLE AUTHENTICATION=true`, the software exposes OAuth dynamic client registration without authentication and without restrictions on redirect URIs. This allows an unauthenticated attacker to register a client pointing to an external domain. Because the authorization flow auto-completes for logged-in users without a consent screen, an attacker can induce a victim to visit a crafted authorization URL to receive an authorization code at the attacker-controlled redirect URI, which is then exchanged for an access token and refresh token. The token minted by the MCP OAuth flow includes the victim's full group set in the JWT (JSON Web Token), a format for securely transmitting information. Since the system validates the issuer but not the audience, the token is accepted as a bearer token against any Obot API endpoint the victim can access, rather than being scoped to the requested MCP server. This enables the attacker to read or modify the victim's resources until the token is revoked.

Missing authorization in the Local License API allows authenticated users with low privileges to read, overwrite, and delete premium module license keys. This is possible through the following API endpoints: - 'GET /api/admin/licenses/show' - 'POST /api/admin/licenses/store' - 'POST /api/admin/licenses/remove'

A design flaw in `src/module.ts` causes the module to unconditionally merge all options, including the `api key`, into the public runtime configuration `runtimeConfig.public.ollama`. Because Nuxt serializes this public configuration into the server-rendered HTML `window. NUXT ` payload, the API key is exposed in plaintext to any unauthenticated client that fetches the page. Additionally, the browser-side composable `src/runtime/composables/useOllama.ts` reads this public key and includes it as an `Authorization` `Bearer` credential in client-side requests. An attacker can steal this key with a single HTTP GET request, potentially leading to unauthorized cloud API usage at the operator's expense, quota exhaustion, or access to stored models and conversations.

The `set functype version` MCP tool in `functype-mcp-server` allows for Remote Code Execution (RCE) because it accepts an unconstrained `version` string and interpolates it into a `pnpm add` command. An attacker can use package-alias syntaxes such as `file:`, `npm:`, URLs, or paths to force the installation of an arbitrary local or remote package. Following installation, the `initDocsData()` function resolves and dynamically imports the `functype/cli` module, executing attacker-controlled JavaScript with the privileges of the MCP server process. This can be exploited by any MCP client capable of sending a `tools/call` request, or via indirect prompt injection where an AI assistant is induced to invoke the tool from a malicious document or web page. In deployments using `TRANSPORT TYPE=httpStream`, the issue is accessible to network-based attackers. Successful exploitation allows the attacker to read process secrets, modify files, or terminate the server.

An unauthenticated path traversal issue exists in `@openhop/server` where unsanitized route parameters are passed to the `FlowStore.filePath()` function in `packages/server/src/store.ts`. The application uses `path.join()` to construct filesystem paths for flow YAML files, allowing an attacker to use traversal sequences to access files outside the configured flow directory. This affects the following endpoints: - `GET /api/flows/:id` - `DELETE /api/flows/:id` An attacker can exploit this to read any `.yaml` file accessible to the process as YAML-parsed JSON or permanently delete any `.yaml` file reachable by the process, potentially exposing secrets or disrupting services. The risk is amplified because CORS is configured with `origin: true`, allowing malicious webpages to target local instances, and Docker deployments default to `HOST=0.0.0.0`, permitting direct network access. The vulnerable variable is `id`.

An unauthenticated network attacker can exploit a path traversal issue where proxied HTTP request paths are not validated for backslash-based dot-segments before being forwarded to the upstream server. The plain HTTP request handler bypasses the destination validation used by WebSocket paths, and the underlying `reply-from` library only rejects forward-slash traversal. This allows requests containing backslash dot-segments to escape the boundaries defined by the `prefix` and `rewritePrefix` options, enabling access to internal upstream paths and the disclosure of hidden endpoints.

Improper verification of cryptographic signatures allows an unauthenticated attacker to impersonate any user. The issue occurs when the software accepts a JSON Web Encryption (JWE) wrapping unsigned claims as fully validated, failing to require a nested signature as mandated by OpenID Connect Core 1.0 and JARM processing rules. This allows an attacker with the relying party's public encryption key to create tokens with arbitrary `sub`, `iss`, and `aud` values without the provider's signing key. The flaw exists in the `verify decrypted token/4` function within `oidcc jwt util`, where decrypted payloads that are not signed JWS are parsed as plaintext claims. Subsequently, the `int validate jwt/4` function in `oidcc token` returns success based on the JOSE structure type rather than signature verification. Additionally, the `validate jarm/3` function in `oidcc token` is reachable via the browser front channel. This is only exploitable if the OpenID Provider advertises ID token or authorization response encryption and the relying party has an encryption key configured.