The SSRF I Almost Didn’t Report

This is the story of a bug I almost threw away because I thought it was "nothing." Lesson learned: verify before you dismiss. That "nothing" turned out to be an SSRF reaching internal cloud stuff.

The Feature

The target had an "import from URL" feature — you paste an image URL, and the server fetches it and adds it to your gallery. The second I saw "server fetches a URL YOU provide," my SSRF senses tingled. (If you don't know SSRF yet — it's tricking the server into making requests for you. Batch 1 covers it.)

The "Meh, Probably Nothing" Trap

I pointed it at my own listener (Burp Collaborator) to confirm the server would fetch arbitrary URLs. It did — my server got the ping. Cool, SSRF confirmed. But then I tried the obvious internal target, the AWS metadata address:

http://169.254.169.254/latest/meta-data/

…and it got blocked. Filtered. I sighed, wrote "blind SSRF, low impact, probably not worth it," and almost moved on.

Almost.

The Bypass That Saved It

Before giving up, I remembered: defenders block the OBVIOUS string, not always the weird ones. So I tried alternate representations of that same metadata IP — different encodings and formats. One of them slipped right past the filter. Suddenly the server was fetching internal metadata it should never expose.

That's the difference between "low blind SSRF" and "critical SSRF reaching cloud internals." One bypass. Ten extra minutes. I nearly walked away from it.

What This Taught Me

• Don't dismiss a bug at the first block. The first filter is rarely the last word.
• "It fetched my server" is already worth confirming fully. Escalate before you downgrade it in your head.
• Learn your bypasses. Alternate IP formats, redirects, DNS tricks — they turn "blocked" into "bypassed."
• Ten more minutes is often the gap between a shrug and a critical.