GHSA-q53q-qg98-p9jf: 
JavaScript vulnerability analysis and mitigation

Impact

On a forward proxy exposed to the network (llm-fw start --standalone, or a non-loopback proxy.bindHost), a client holding the proxy token can CONNECT to any host and port, including the server's own loopback interface and link-local addresses. The connection to the target is made by the llm-fw process, so it arrives from 127.0.0.1. That crosses three boundaries the deployment guide relies on:

• Dashboard. The dashboard exempts loopback callers from its token and accepts state-changing requests that carry no Origin. Through the tunnel a proxy client can read and change settings (turn detectors off, persisted to config.json), add whitelist entries, and read the event stream, without the dashboard token, even when the dashboard is bound to 127.0.0.1 as the hardening checklist recommends.
• Gateway. A gateway bound to loopback requires no client token, so a tunnelled client can use the provider keys the gateway holds (LLM_FW_GATEWAY_KEY_*).
• Cloud metadata. 169.254.169.254 and other link-local services on the host are reachable, exposing instance credentials on cloud VMs. Verified on 0.8.0 with a proxy requiring a token and a dashboard on 127.0.0.1: CONNECT 127.0.0.1:<dashboard> with only the proxy token, then GET /api/settings returned 200, and POST /api/settings {"rag":false} returned 200 and was written to config.json. Default installs, where the proxy is bound to loopback, are not affected: a local caller can already reach those listeners directly.

Patches

Fixed in 0.9.1 (npm install -g llm-fw@0.9.1). The fix refuses a CONNECT from a non-loopback client to a loopback, unspecified or link-local address, checked against the address actually connected to (after DNS resolution), so a hostname that resolves to 127.0.0.1 is refused too.

Workarounds

Keep the proxy bound to loopback. If it must be exposed, restrict which clients can reach the proxy port, and treat the proxy token as granting dashboard and gateway access until you upgrade. Do not run the gateway bound to loopback on the same host as an exposed proxy without gateway.requireAuth: true.