Neil Berkman

An attacker can read the filesystem paths of an application through the Tidewave configuration. This occurs because the server does not validate the `Host` header and the `check origin()` function accepts requests that lack an `Origin` header. A malicious web page can use DNS rebinding to redirect its domain to the loopback address and perform a same-origin request to retrieve sensitive information. The exposed data, which includes the local username and project layout, is leaked via the `/tidewave/connect` endpoint or through the rendered toolbar injected into HTML responses by the `Tidewave.call()` function. Specifically, the `Tidewave.tidewave config meta/1` function collects data such as `root`, `framework.app paths`, `wsl distro`, and `host path` and embeds it into a meta tag.

An unauthenticated remote attacker can exhaust server memory by sending DATA frames that exceed the advertised receive window in the HTTP/2 implementation. The attacker can request a response larger than the 65,535-byte initial window and withhold `WINDOW UPDATE`, causing the stream process to block while sending and stop reading. Subsequently, flooding small DATA frames on that stream causes every frame to be queued in the stream's mailbox until the BEAM node runs out of memory. This occurs because `Bandit.HTTP2.Connection.handle frame/3` forwards DATA frames to the stream process without consulting the receive window, and `Bandit.HTTP2.FlowControl.compute recv window/2` replenishes the window as data arrives rather than as it is consumed, failing to trigger a `FLOW CONTROL ERROR` upon violation.

An unauthenticated remote attacker can expose the secret key base or other sensitive secrets through application logs by providing wrong-typed arguments. This occurs because public functions in `Plug.Crypto` use function-head guards for argument validation. When a guard fails, the Erlang VM raises a `FunctionClauseError` that includes the actual argument values in the top stack frame. Since the library's `rescue` blocks and the `Plug.Crypto.prune args from stacktrace/1` function only handle exceptions raised within a function body, they do not catch guard failures. Consequently, Plug.Cowboy and Bandit write this frame to the error log and attach it as `crash reason` metadata, which may be forwarded to error trackers. Two primary entry points are affected: - `Plug.Crypto.verify/4` exposes the secret key base when the token is neither a binary nor nil. - `Plug.Crypto.secure compare/2` exposes the server-side secret when one operand is not a binary, such as when a missing request header results in a nil value. Accessing the leaked information requires separate access to the application logs or the error tracker.

Improper certificate validation in the WebSocket streaming client allows an on-path attacker to read and modify OpenAI WebSocket sessions, including the `authorization` bearer token. The function `ReqLLM.Streaming.WebSocketSession.Client.start/3` in `lib/req llm/streaming/web socket session/client.ex` initiates WebSockex without TLS options. Because WebSockex defaults to `insecure: true`, it connects using `verify: :verify none`, which accepts any certificate. Additionally, the option allowlist discards caller-supplied `cacerts` or `ssl options`, preventing applications from enabling verification. This affects the OpenAI Responses, Realtime, and Codex WebSocket paths, which transmit API keys or OAuth access tokens in the `authorization` header.