LLMGateway EUVD-2026-96993

Exploitation requires (1) a valid LLMGateway API key - the flaw is authenticated (PR:L), limiting it to tenants/users already granted gateway access; and (2) use of the video-generation feature, specifically the callback_url extension whose webhook delivery path (deliverWebhook) omits the assertSafeWebhookTarget validation. The attacker-supplied callback_url must resolve to a reachable internal target (loopback, RFC1918 private ranges, or 169.254.169.254 cloud metadata) from the worker's network. Key limiting factors: it is BLIND SSRF (no response body returned, so pure data exfiltration via the channel is constrained to side effects of POST requests), it is restricted to networks where the worker can actually reach sensitive internal/metadata endpoints, and it is gated behind API-key authentication rather than being anonymously exploitable.

This is a moderate-severity, authenticated blind SSRF (CWE-918) in theopenco's LLMGateway through 1.20.0, scored CVSS 5.3 via the vendor/VulnCheck 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N). The signals are internally consistent and point to a real-but-bounded issue rather than an emergency: the attack vector is network-reachable and low-complexity, but PR:L means a valid API key is required, so this is not an unauthenticated internet-wide threat. Impact is limited - it is BLIND SSRF (VC:N: no response data is returned to the attacker) with only low integrity impact on the vulnerable and subsequent systems (VI:L/SI:L), reflecting the ability to POST to internal endpoints rather than exfiltrate data. No EPSS score, CISA KEV listing, or confirmed public exploit code was provided in the input, so there is no evidence of active or at-scale exploitation; a detailed third-party technical write-up (hackmd) and a VulnCheck advisory exist with exact vulnerable source lines, which lowers the bar for reproduction even though no packaged POC is confirmed. Net: a legitimate priority to patch for anyone running LLMGateway with multi-tenant or partially-trusted API keys and sensitive internal/cloud-metadata endpoints, but not a drop-everything issue given the authentication requirement, blind nature, and absence of KEV/EPSS escalation signals.

An attacker holding a valid LLMGateway API key submits a video-generation request specifying a callback_url pointing at an internal address such as http://169.254.169.254/ (cloud metadata), a loopback admin port, or an RFC1918 host. Because deliverWebhook sends the POST without the assertSafeWebhookTarget check, the worker issues the request from inside the trusted network, letting the attacker reach and act on internal services even though responses are not returned (blind). A detailed public technical write-up with exact source locations exists, but no packaged exploit code was confirmed in the provided data.