Term coined by Pavan Nallamothu, independent security researcher. Defined in the paper SSRF Beyond HTTP. Updated September 2026.
EPI-SSRF (Egress-Path-Incomplete SSRF) is a class of server-side request forgery in which the egress guard validates only a subset of the application's outbound clients. Formally it is a coverage defect P ⊂ E, where E is the set of outbound egress clients and P is the subset the guard actually covers. The attacker does not defeat the guard, they reach an egress path outside it, for example a non-HTTP protocol such as SMTP, that was never guarded at all.
Classic SSRF is about tricking a guarded request into hitting an unintended destination, usually by manipulating a URL the server fetches over HTTP. The defense is an egress guard: a blocklist or allowlist on outbound requests. EPI-SSRF is about the guard's coverage, not its logic. The HTTP client may be perfectly guarded, and the vulnerability lives in a second, unguarded egress path (a mailer, a webhook, a raw socket) that shares no code with the guarded one. You can pass every test against the HTTP layer and still be exposed, because the check protects P and the attack uses E \ P.
AutoGPT enforced SSRF protection on its HTTP layer with an IP blocklist. Its SendEmailBlock opened raw SMTP sockets through a user-controlled mail server, an egress path the HTTP blocklist never touched. A prompt could make the agent connect outbound to an internal service over SMTP, bypassing the guard entirely. The HTTP egress was P, the SMTP path was in E \ P. That is EPI-SSRF. It was assigned CVE-2026-33234.
Agent frameworks multiply egress paths: they browse, call tools, send mail, hit webhooks, and open sockets, often adding new outbound clients faster than anyone re-audits the guard. Each new client that is not brought under the existing egress policy is a fresh E \ P gap. EPI-SSRF names that failure mode so it can be tested for directly: enumerate every outbound client, then check the egress guard covers all of them, not just the HTTP one.
It is a subclass. All EPI-SSRF is SSRF, but the root cause is guard coverage (P ⊂ E), not a bypass of the guard's matching logic.
Enumerate the application's outbound clients (HTTP, SMTP, DNS, webhooks, raw sockets, third-party SDKs). For each, confirm the egress guard is actually applied. Any client the guard does not cover is an EPI-SSRF path.
Apply the egress policy at a choke point every outbound client passes through, rather than per-protocol. If one protocol cannot be routed through the shared guard, guard it explicitly. Coverage, not just correctness.
Security researcher Pavan Nallamothu, in the paper SSRF Beyond HTTP: Egress-Path-Incomplete Guards in AI Agent Platforms (DOI 10.5281/zenodo.22075469).