DEV Community: Ali Haider

The Server That Robbed Its Own Bank

Ali Haider — Sun, 11 Oct 2026 20:06:52 +0000

In 2019, a single request stole the personal data of over 100 million people from one of the biggest banks in America.

No malware. No stolen password. No one kicked down a door. The attacker just asked a server a question, and the server, trying to be helpful, answered with the keys to the vault.

The bug behind it is called SSRF, and once you see how it works, you start noticing the setup for it everywhere. I spent this week learning it hands-on, and I want to walk you through it the way it finally made sense to me, with that real breach as the destination.

First, Forget "Breaking In"

When most people imagine a server getting hacked, they picture someone forcing their way inside. SSRF is the opposite of that, and that's exactly why it's so easy to miss.

You never get in. You convince the server to go somewhere for you.

Here's the picture that made it click. Hold onto it, because we're coming back to it.

You're standing outside a corporate building. Locked doors. Security at the entrance. Inside, down some hallway you'll never walk, there's a back office full of sensitive files. You want those files. You are not getting past that front desk.

But there's a mailroom clerk inside. He walks the whole building all day. Nobody questions him, he's obviously staff. So you stop him on his smoke break and hand him a note: "Run to the back office, grab the file on the desk, bring it out to me."

And he does. Because he can go where you can't, and because nobody inside thinks to check whether his errands are legit.

You never entered. You broke nothing. You just borrowed someone with better access than you.

That is the entire idea of SSRF. The server is the clerk.

Now the Technical Version

Say a shopping site has a "check stock" button. Behind the scenes, when you click it, the server reaches out to an internal inventory service to get the number:

POST /product/stock
stockApi=http://stock.internal-shop.net/check?productId=6

See that stockApi value? The server takes that URL and fetches it for you. The developer assumed it would only ever point at their own inventory service.

But what if you change it?

stockApi=http://localhost/admin

Now you've handed the clerk a different note. Instead of fetching inventory, the server fetches its own admin panel, a page you could never load yourself from the outside, and hands you back the contents.

That's the whole move. You didn't attack the admin panel. You asked the server to go read it for you, and it did, because the request came from inside the house.

The Part That Turns "Annoying" Into "Catastrophic"

Here's what I didn't expect. Why does that admin panel even open up for a request from localhost? Shouldn't it still require a login?

Often, no. And the reason is a quiet assumption baked into how internal systems get built:

"Only trusted internal services can reach this machine. So why bother locking it?"

Internal admin panels, dashboards, and APIs are frequently left wide open. No password. Default settings. Old, unpatched software. Because everyone assumed the network itself was the wall, nobody untrusted could ever reach these things, so why waste effort hardening them.

SSRF knocks the wall down. The second you can make an outward-facing server pass notes inward, every one of those unlocked internal doors is suddenly reachable. And they were built on the belief that this day would never come.

The Case Study: How a Bank Lost 100 Million Records

Now we can walk through the real one, and you'll recognize every step.

In 2019, a major US bank ran its infrastructure in the cloud. Like a lot of companies, they had a web application firewall sitting in front of their servers to filter bad traffic.

That firewall had an SSRF vulnerability. An attacker could make it send requests on their behalf. The clerk, in other words.

Now, here's the cloud-specific twist. Servers running in the cloud have a special internal address, the same one on nearly every cloud instance:

http://169.254.169.254/

This is the metadata service. It's meant for the server to ask questions about itself. And one of the things it will happily tell anyone who asks from the right place is: the server's own access credentials. The temporary keys that let that machine talk to the rest of the company's cloud account.

You can see where this goes.

The attacker found the SSRF in the firewall. (Found a clerk.)
They made it request http://169.254.169.254/.... (Handed over the note.)
The metadata service, seeing a request from a legitimate internal server, returned that server's cloud credentials. (The clerk fetched the file.)
With those credentials, the attacker reached into the cloud storage and pulled out the data of over 100 million people.

No password was cracked. No one phished an employee. The system worked exactly as designed. It just trusted the wrong request, and that trust was the whole vulnerability.

This Is Not an Old, Solved Problem

I came into security assuming bugs like this were mostly legacy, patched out of modern frameworks years ago. SSRF is the opposite. It's arguably more dangerous today than ever, and it's because of how we build things now:

Microservices mean an app is dozens of small internal services calling each other over HTTP. Every one of those internal calls is a door the clerk can be sent to.
The cloud means that 169.254.169.254 metadata endpoint is sitting on nearly every server you deploy.
"Fetch this URL" features are everywhere now: webhooks, link previews, "import from URL", avatar fetchers, PDF generators. Every single one is a potential clerk waiting for a note.

The flaw didn't disappear. It moved into the architecture we all use now.

Why I'm Personally Obsessed With This One

I'm working toward AI and LLM security, and SSRF turned out to be the most important thing I could have learned for it.

Think about what an AI agent actually does all day. It fetches URLs. It calls tools and APIs. It retrieves documents on your behalf. That is the mailroom clerk, rebuilt in software and handed a lot more autonomy.

So the modern version of this attack writes itself: instead of changing a stockApi parameter, you plant an instruction in text the model will read, "go fetch this internal address", and the agent, trusted inside the network, does it. Same bug. Same clerk. The note is just written in English now instead of a URL field.

Every technique I picked up chasing these labs, reaching localhost, hitting the metadata endpoint, slipping past filters, points straight at how you attack and defend AI agents.

So What Do You Actually Do About It?

If you build anything that fetches a URL on the server side, three habits shut most of this down:

Allowlist, don't blacklist. Decide the short list of places your server is allowed to fetch, and reject everything else. Trying to block all the bad addresses is a losing game (that's a whole post on its own).
Validate where the URL actually resolves, not just how it's spelled. Block private IP ranges and that metadata address, and re-check after any redirect.
Don't hand the raw fetched response back to the user, and use the cloud's hardened metadata mode (IMDSv2) so a naive request can't just walk away with credentials.

The Takeaway

SSRF isn't about breaking in. It's about noticing that the server you're talking to has a trusted seat at a table you weren't invited to, and realizing you can get it to pass notes for you.

Once that clicks, you can't unsee it. Every "the server fetches this for you" feature starts to look like a clerk waiting for the wrong instructions.

I'm learning this stuff in public on the way to AI security. If a different analogy or breach finally made SSRF make sense for you, I'd genuinely like to hear it in the comments.

When Your Own Server Becomes the Attacker

Ali Haider — Sat, 03 Oct 2026 00:17:53 +0000

In March 2019, a former Amazon engineer made a request to a Capital One server. Not a login, not a password guess. She asked the server to fetch a URL for her.

The server said yes.

That one request walked out with temporary AWS credentials, and those credentials unlocked the personal data of more than 100 million people. Social security numbers, bank account details, credit applications. One of the largest financial breaches in US history, and at the bottom of it was a bug so ordinary that you have probably written the ingredients for it yourself.

It's called SSRF, and I want to show you exactly how something this mundane turns into something this catastrophic.

The whole idea in one line

SSRF (Server-Side Request Forgery) is when you trick a server into making a request for you, to somewhere you could never reach on your own.

That's it. You don't break in. You get the server to walk in for you.

Think about who you trust

Picture a secure office. You're a stranger in the lobby. The server room, the records vault, the executive offices, all locked, all off-limits. Security won't let you past the front desk.

But the receptionist runs errands. "Could you grab the file from room 237?" Sure. They walk back, fetch it, hand it over.

So you try your luck: "Could you bring me whatever's in the server room?" And because the receptionist has access, and you asked politely, they do.

You never touched the lock. The receptionist did the walking. That receptionist is your server, and SSRF is the art of asking it to fetch things it shouldn't.

The feature that becomes the bug

Here's what makes SSRF sneaky: it almost never looks like a vulnerability. It looks like a feature request.

"Let users add a profile picture by URL."
"Check stock levels from the warehouse's internal API."
"Generate a PDF preview of any link."
"Fire a webhook to the customer's endpoint."

Every one of those ends up as some version of this:

const data = await fetch(userControlledUrl);

The developer who wrote that line was picturing a normal URL. An image. A warehouse API. A customer's webhook. What they weren't picturing was someone typing:
http://localhost/admin

And the server, having no opinion about where it's pointed, fetches its own admin panel, the one that's only supposed to be reachable from inside, and hands the attacker the response. The firewall guarding that panel never even got a say, because the request came from inside the house.

When the server starts scanning for you

Reaching the admin panel is just the opening move. The deeper problem is that the server lives inside a private network you can't see from the outside.

So you make it look around.

Point it at 192.168.0.1, then .2, then .3, and watch how the responses differ. A connection that refuses instantly means nothing's there. One that hangs, or answers, means something is. Walk the whole range and the server quietly maps out the internal network for you, which machines exist, which ports are open, where the interesting things live.

You've turned the victim's own server into a scanner aimed at the victim's own network.

The part that ended Capital One

Now the finale, the move that turns "interesting bug" into "front-page breach."

Every server running on AWS, Google Cloud, or Azure can reach a special internal address: 169.254.169.254. It's the metadata service, a little endpoint the machine uses to learn about itself. Handy for the server. Devastating in the wrong hands, because on a misconfigured instance it will also hand over the server's temporary cloud credentials.

So the attacker points the SSRF here:
http://169.254.169.254/latest/meta-data/iam/security-credentials/

and the server, asked politely, returns its own keys to the kingdom. With those, you're no longer poking at one app. You're inside the cloud account.

That's the whole Capital One story in one request: a URL field that trusted its input, a server that could reach the metadata endpoint, and 100 million records out the door.

How to not be the next case study

This is the part most write-ups skip, so here's the version I'd actually want on a code review.

1. Allowlist, don't blocklist.
The instinct is to block the bad addresses. Don't. Attackers will always find a spelling you didn't think of: 127.0.0.1 can be written as 0x7f000001, or 2130706433, or hidden behind a domain that quietly resolves to an internal IP. Blocklists leak. Instead, decide the exact destinations your feature is allowed to hit, and refuse everything else. If the stock checker only ever needs one internal API, that's the only thing it should be able to reach.

2. Check the resolved IP, not the string.
If you must allow user URLs, resolve the hostname first and inspect the actual IP it points to, then block the private ranges (127.x, 169.254.x, 10.x, 192.168.x, 172.16–31.x). A domain like my-innocent-site.com can resolve straight to 169.254.169.254 if the attacker owns the DNS.

3. Kill the exotic schemes.
Allow http and https, nothing else. file:// reads local files. gopher:// can forge raw requests to internal services like Redis. If your feature doesn't need them, they're pure downside.

4. On AWS, enforce IMDSv2.
The newer metadata service requires a session token before it hands anything over, which shuts down the exact move that hit Capital One. It's close to a one-setting fix for the worst version of this bug. Turn it on.

5. Assume one layer fails.
The app server shouldn't be able to reach your sensitive internal systems in the first place. Segment the network so that even a successful SSRF runs into a wall instead of a vault.

One question before you close this tab

Go find the place in your codebase where the server fetches a URL it didn't fully choose. The image importer, the webhook, the link preview, the PDF renderer. There's almost always one.

Now ask it two things: is the destination allowlisted, and can it reach 169.254.169.254?

If you don't like the answers, you've just found the same bug that cost Capital One 100 million records, sitting quietly in your own repo, still looking like a feature.