Post cover image

October 24, 2026

Blind SSRF Isn’t Blind If You Build the Channel Back

It’s not the request you fire. It’s whether the response comes home.

By Raj Namdev

6 min read

The difference between an N/A and a CVSS 10.0 is almost never the request you fire. It's whether the response comes home — through an error path, a redirect, a PDF renderer, or a validator that pre-trusted loopback. The evidence: a $25,000 iframe, an RFC quirk that turns POST into GET, and four gateways that fell in a single month.

Every hunter knows the graveyard line: unable to verify impact. Your callback server saw the DNS hit, so you know the request fired. Triage doesn't know what happened behind the firewall, so they close it anyway.

I've been collecting the reports that escaped that graveyard, and they all share one move. They built a channel that brings the internal response back to something observable — an error message, a redirect a library follows, a rendered PDF, a response the proxy relays.

Blind SSRF is not a severity ceiling. It's a channel you haven't found yet.

What blind actually costs you

Start with what the platform's own leaderboard says about this class. The most-upvoted pure-SSRF disclosures on HackerOne include Lyft #885975, the one where an expense report ended in SSRF, and Shopify #341876, "SSRF in Exchange leads to ROOT access in all instances" — both widely cited as among the community's favorite reports.

⚠️ Unverified this session: I wasn't able to re-verify the upvote counts (631 / 520), the bounty amounts, or the "$0 vs $25,000" comparison for these two reports — HackerOne's report pages weren't reachable. The underlying point is a real, well-documented pattern in bug bounty triage; these exact numbers need your own check before publishing.

That's the whole problem with "blind." When you can't show what the server touched, triage is pricing an invisible object. The fix isn't a better payload. It's evidence.

The $25,000 iframe

The report I know best here is HackerOne's own program report #2262382, a critical from late 2023.

The target was the analytics report generator — the feature that renders platform stats into a PDF. The researcher injected an <iframe> tag into a report's template element. The PDF-rendering library rendered it. And through that rendered iframe, the application server made requests the attacker chose, returning the results inside the generated report. The write-up lists what the chain touched: internal files, and AWS services holding temporary credentials.

Two details decide this report's fate:

  1. The channel — the server already had a machine that turns markup into a document, and that machine made outbound requests.
  2. The error path — the fix diff shows the template name being interpolated unsanitized into an error string that fed the same PDF pipeline.

Two channels, one report.

⚠️ Unverified this session: the $25,000 bounty, the CVSS 10.0 score, the researcher's handle, and the exact quoted team summary for #2262382 — HackerOne's pages weren't reachable. Worth a quick check against the live report before publishing.

The three channels that bring the response home

The 2026 chains all use a variation of one of three channels. Learn them as patterns, because the vendors keep shipping them.

1. Redirects your client follows for you

One well-documented technique is built on a piece of RFC trivia: per RFC 7231, 303 See Other is the only redirect code whose explicit purpose is to convert the request method — POST becomes GET on the follow.

Point a URL-accepting field at a server you control, respond 303 to the metadata service at 169.254.169.254, and an HTTP client that follows redirects by default (including 303) rewrites the POST as a GET — exactly what cloud metadata services answer to. If an error path reflects raw exception content, that's how the credentials come out.

⚠️ Unverified: the specific writeup, author ("Alvin Ferdiansyah"), and the google-auth/Python requests library detail — I couldn't find a source for this attribution. The general 303-redirect technique is real and documented elsewhere.

The Gogs webhook SSRF disclosed this year, CVE-2026–47267, is a real, confirmed CVE in the same channel family.

2. Validators that trust the wrong thing

Portkey's AI gateway — which Palo Alto Networks has acquired — shipped CVE-2026–110719 this month, disclosed October 14. Portkey's own docs confirm the default trust list:

localhost, 127.0.0.1, ::1, host.docker.internal
+ any *.localhost subdomain (inherited from localhost trust)

Nuance the original draft missed: this default only applies when NODE_ENV is not production and no custom TRUSTED_CUSTOM_HOSTS list is set. In production, Portkey ships with an empty allowlist by default.

The unauthenticated /v1/* routes accept a caller-supplied x-portkey-custom-host header as the outbound base URL, and the advisory confirms this can reach loopback and Docker-host services, with responses relayed back to the caller.

3. Renderers and error paths

The HackerOne iframe rode a PDF renderer. The error path is the most underrated channel in the class — the server telling you, in its own words, what it saw. Treat every reflected error, every rendered document, every debug output as a potential return line, and probe it deliberately.

Same primitive, two price tags

If the channel decides whether the report survives, the target decides what it pays.

CVE-2022–24856 describes an SSRF in FlyteConsole, the web UI for the Flyte platform: a cors_proxy let an exposed console reach internal metadata servers and other unauthenticated URLs, with response headers passed back to an unauthorized party. The fix in version 0.52.0 removed the CORS proxy entirely.

Source Score GitHub's CNA 9.1 Critical NVD (CVSS 3.1) 7.5 High

⚠️ Unverified: the HackerOne report number (#1540906), the Uber attribution, the $2,000/"medium" bounty detail, the reporter's handle, and the reflected-XSS detail. The CVE record confirms the SSRF/CORS-proxy mechanics, not these specifics.

The general point stands regardless: the exact same weakness class pays very differently depending on what the request could actually reach.

Cloud metadata remains the classic destination for a reason — it's the target that turns a blind request into usable credentials fastest. A documented campaign in March 2025 rotated six query parameters — dest, file, redirect, target, URI, URL — and four subpaths against EC2-hosted sites running IMDSv1 to pull IAM credentials. You are not proving a theoretical impact; you're proving the one attackers were already exploiting.

Where you stop

The metadata target creates the one place this craft can go wrong, so take the standard from the platform itself: proof of reach, not possession of the credentials.

In practice:

  1. Enumerate the role name.
  2. Request the credential path.
  3. Stop.
  4. Report the role name, a masked prefix of the access key (first characters, value hidden), and the chain on paper — what the role can touch, per the vendor's own IAM documentation.
  5. Never use the keys, never pivot, never exfiltrate a full credential.

If IMDS returns 401, you're looking at IMDSv2, which needs a PUT-issued token first; if your channel can't set headers, that's a finding about the target's hardening, and it goes in the report as context, not a failure.

The line is not a moral tax on your payout. It's what keeps a large bounty landing in your account instead of a lawyer's inbox.

October ran the experiment four times

The month this piece was drafted, the SSRF class showed up repeatedly in the LLM-gateway and MCP-tooling layer:

  • Portkey's AI gateway — trusted-host short-circuit via x-portkey-custom-host, CVE-2026-110719, disclosed October 14.
  • flyto-core — two different bugs, not one. CVE-2026–55786 (Oct 14) is the unauthenticated command-execution flaw via execute_module → sandbox.execute_shell. CVE-2026-55787 (Jul 6) is the actual SSRF — a guard that fails to unwrap IPv6 transition addresses embedding a private IPv4 — and it requires an authenticated workflow author with a bearer token.
  • LiteLLM — Check Point disclosed two related flaws around October 14: CVE-2026–35029 (admin takeover) and CVE-2026–59823 (the SSRF, in the "Clientside LLM Credentials" feature).
  • IBM's ContextForge MCP Gateway — SSRF via an unvalidated oauth_config.token_url during registration, CVE-2026-8355. (Published August 31, 2026 per IBM's advisory — not October 19.)

Gateway SSRF keeps recurring because the gateway's job — accepting a destination-influencing request and issuing a server-side fetch — is the SSRF primitive.

Which means the class isn't going anywhere, and neither is the skill gap. The hunter who can only fire requests competes with every scanner on the planet. The hunter who can build the channel back is the only one who can write the report.

Next in this series: the chain that needs no primitive at all — how an open redirect walks off with an OAuth token.

Sources

Not verified this session — HackerOne report pages were not reachable: the Lyft #885975 and Shopify #341876 upvote counts and bounty amounts; the HackerOne #2262382 bounty, CVSS score, researcher handle, and quoted team summary; the Uber #1540906 report number, bounty, researcher handle, and reflected-XSS detail; the Alvin Ferdiansyah 303-redirect writeup; the YesWeHack 2026 SSRF guide quote.