A boring portal. A couch photo. And a vulnerability hiding in plain sight.

There's a certain kind of bug that doesn't feel like hacking at all.

No custom exploit. No zero-day. No sophisticated toolchain running in the background. Just a researcher, a URL, and a gut feeling that something shouldn't work the way it does.

This is one of those stories.

The Target Nobody Wanted

Jafar Abo Nada was bug hunting on Google's infrastructure when he landed on https://peering.google.com

If you've never heard of it, that's kind of the point. It's Google's network peering portal — a dull, functional corner of the internet where ISPs go to request direct network connections with Google. No user accounts. No personal data. No flashy features to poke at.

Just some information pages. And a few static images sitting quietly on a server.

Most researchers would have moved on in thirty seconds.

Jafar didn't move on.

The Couch Photo That Opened a Server

He grabbed an image URL from the site. Something like this:

https://peering.google.com/static/images/couch-ipad.png

Totally normal. Just a photo of a couch with an iPad on it.

Then he did something simple. He tacked a string of characters onto the end of that URL:

https://peering.google.com/static/images/couch-ipad.png../../../../../../../etc/passwd

Those ../ sequences are old-school path traversal. Each one tells the server: "Go up one folder." and it did what was told.

Stack seven of them and you climb right out of the web directory — past the images folder, past the app files, all the way up to the root of the operating system.

Then /etc/passwd at the end tells the server exactly what to hand back: a core Linux system file that holds user account information.

The server just… did it and responded accordingly.

No warning. No block. No sanitization check kicking in. It read the file and returned the contents like it was nothing or no restriction at all.

What He Was Actually Looking At

This vulnerability has a name: Local File Inclusion, or LFI.

Here's how it works in plain terms:

The server's job was to fetch a local file — in this case, an image — and serve it to you. But whoever built this part of the site forgot to verify what file you were actually asking for. So when Jafar swapped out the image path for a system file path, the server followed instructions without questioning them.

It's the digital equivalent of asking someone to "grab the folder on the desk" and they hand you the company's entire filing cabinet because you worded it just right.

Jafar didn't stop at /etc/passwd either. He swapped it out for other system paths:

../../../../../../../proc/self/cmdline
../../../../../../../proc/self/stat
../../../../../../../proc/self/status

Each one came back with live information about Google's server — what processes were running, how the system was configured, details that had no business being visible to the public internet.

Google's Response

He filed the report through Google's Vulnerability Reward Program on HackerOne.

The security team reviewed it, confirmed it was real, and patched it.

Then they sent Jafar a payment of $3,133.70.

Three thousand dollars. For dots and slashes after a couch photo.

The Real Lesson Here

The technique Jafar used isn't new. Path traversal has been around for decades. Security researchers have known about it forever. Google's own teams know about it.

And yet — there it was. On a live Google subdomain. Waiting.

That's the thing about boring targets. Everyone assumes someone else already checked. The portal that ISPs use? Surely Google locked that down. It's not even a real product. Who's going to look there?

Jafar looked there.

The skill isn't knowing the technique. The skill is knowing where to aim it — and having the patience to keep looking when everything on the surface says there's nothing here.

Sometimes the boring pages are the ones nobody checked.

Based on the original writeup by security researcher Jafar Abo Nada, broken down by Vivek PS on the OSINT Team blog (April 2026)