Dodge1218

Certain client paths in the SDK follow HTTP redirects to different origins, which can lead to the exposure of sensitive information. Specifically, when using `streamable http client`, `streamablehttp client`, `sse client`, `ClientSessionGroup`, `OAuth`, or the `create mcp http client` helper, the SDK forwards caller-supplied custom credential headers to the redirect destination. Additionally, for HTTP 307 or 308 responses, the request body is also forwarded. An attacker capable of influencing a trusted endpoint's redirect destination can capture these credentials and request bodies.

HTTP client transports and OAuth client requests follow redirects to different origins while retaining custom request headers and the `mcp-session-id` header. For HTTP 307 or 308 responses, request bodies are also retained. This behavior affects `StreamableHTTPClientTransport`, `SSEClientTransport`, and OAuth client functions such as `auth()`. A malicious or compromised MCP or authorization server could exploit this to receive sensitive information, including API keys, session identifiers, OAuth refresh tokens, or OAuth client secrets. This occurs when a request is redirected to another origin.

Missing authentication in the realtime streams POST handler allows unauthenticated attackers to inject arbitrary data into run streams across any environment, including production. This occurs because the `action` handler in the file `apps/webapp/app/routes/realtime.v1.streams.$runId.$streamId.ts` lacks an authentication wrapper. Furthermore, the system performs run lookups using the `friendlyId` variable without verifying the `runtimeEnvironmentId`, and these identifiers follow predictable patterns. The affected API endpoint is '/realtime/v1/streams/:runId/:streamId'.

The Docker quickstart command starts the container listening on 0.0.0.0:8080 with authentication disabled by default. In this state, every request is mapped to a synthetic "nobody" user possessing Owner and Admin roles. This allows any unauthenticated party with access to the exposed port to gain full administrative access to the API and UI, enabling the registration and launch of attacker-controlled MCP (Model Context Protocol) servers. Additionally, because the quickstart mounts `/var/run/docker.sock` into the container, the MCP runtime backend can access the host's Docker control surface.

Authenticated users with a Viewer role or higher can perform SQL injection by providing specially crafted telemetry field-key names. The application fails to properly escape these names in the 'v5 query range' API endpoint, allowing attackers to use backticks and quotes to break out of identifiers and string literals. This enables the execution of arbitrary ClickHouse SQL commands to access system tables and exfiltrate data.

When the `API TOKEN` is unset or empty, the `BearerTokenAuthMiddleware` bypasses authentication for all HTTP requests. This issue, combined with the default 0.0.0.0 host binding and CORS `allow origins` set to `*`, allows any client reachable via the local area network to access the full Knowledge-Graph read/write API. An attacker on the same network can read, write, or delete all memory entries, including `system://boot` and `core://*` URIs that auto-load into downstream agent sessions, which can lead to persistent prompt-injection.

In SSE and Streamable HTTP transport modes, the MCP control plane is exposed without authentication and utilizes wildcard CORS (Cross-Origin Resource Sharing), which allows any origin, method, or header. This configuration permits arbitrary origins or non-browser clients to access the control plane. Because the server also exposes a `PowerShell` tool that executes caller-controlled commands via the `command` variable as the Windows user running the application, an attacker can achieve arbitrary PowerShell execution. The issue stems from the ` http middleware()` function installing `CORSMiddleware` with wildcard policies and the ` build mcp()` function constructing the instance without an authentication provider. The vulnerability is specifically triggered when using the '/mcp' endpoint to initialize a session and invoke the `tools/call` function for the `PowerShell` tool.

Gryph implements logging levels to control content stored in a local sqlite database. The default log level is set to `standard`, although documentation incorrectly states it is `minimal`. At both `standard` and `full` logging levels, sensitive `file-write` content is retained in the stored `payload` via the `ContentPreview`, `OldString`, or `NewString` variables. This results in the logging of potentially sensitive file content, which bypasses the sensitive file filter and log level contracts. This issue may lead to the exposure of sensitive data if the local sqlite database is stolen or exported to a remote system.