Bug Bounty Bootcamp #37: SSRF in PDFs, Screenshots, and Bypassing Localhost Filters

You found a PDF generator that fetches URLs. The developer blocked localhost and 127.0.0.1. Game over? Not even close. Learn the art of representing the same IP address in a dozen ways – and watch the firewall crumble.

Free Link

Welcome back to the Bug Bounty Bootcamp. You've learned the basics of SSRF: confirm server-side requests with an external monitor, then probe localhost and internal networks. But what happens when the application knows about SSRF and blocks obvious addresses like 127.0.0.1 and localhost? That's when the real fun begins. This lesson focuses on two advanced SSRF scenarios: PDF/screenshot generation services (where input is a URL that gets rendered into a document) and bypassing common localhost blacklists using alternative representations, custom domains, and clever services.

The Hidden SSRF Goldmine: PDF, Screenshot, and Media Generation

Any feature that takes a URL and produces a server-side artifact — PDF, screenshot, video thumbnail, image — is a prime SSRF candidate. The course highlights:

• PDF generators: "Convert this webpage to PDF" tools.
• Screenshot services: "Capture a preview of this site" widgets.
• Video/image editors: Import external resources (URLs) into a project.

Why These Are Dangerous: The server, not your browser, fetches the URL. And it often uses a headless browser (like Chrome) or a full HTTP client that supports many protocols. If the server can reach internal services, you can pivot.

The Testing Workflow (Same as Before):

1. Inject your Interactsh URL (e.g., [https://your-id.interact.sh/test](https://your-id.interact.sh/test).))..)
2. Check for callbacks — confirm the request came from the server.
3. Probe http://127.0.0.1/, file:///etc/passwd, etc.
4. If blocked, apply the bypasses below.

The Localhost Blacklist Problem

Many developers block the most obvious localhost representations:

• localhost
• 127.0.0.1
• 0.0.0.0

But blocking these exact strings is a game of whack‑a‑mole. There are dozens of ways to refer to the same IP address.

Bypass Technique 1: Alternative Decimal/Octal/Hex Representations

IPv4 address 127.0.0.1 can be written in many formats:

In the course: The instructor tried 127.0.0.1 – blocked. Then 127.0.1 (missing one dot) – allowed! The filter only matched the exact 4‑octet pattern. 127.0.1 resolved to 127.0.0.1 due to DNS‑like parsing in some libraries.

Your testing arsenal:

• 127.0.0.1
• 127.0.1
• 127.1
• 2130706433
• 0x7f000001
• 0177.0.0.1

Bypass Technique 2: Custom Domain Pointing to 127.0.0.1

If the blacklist checks for IP patterns but allows domain names, you can register or use an existing domain that resolves to 127.0.0.1.

The Course Example: The instructor had a domain local.host.dev that they pointed to 127.0.0.1. When the server resolved it, it fetched localhost.

Free Alternatives (No Registration Required):

• localhost.nip.io → 127.0.0.1 (nip.io automatically maps any IP to a domain)
• 127.0.0.1.nip.io also works
• localtest.me → 127.0.0.1
• lvh.me → 127.0.0.1

How to use: http://localhost.nip.io/ will resolve to 127.0.0.1. Many filters only block the literal string localhost but not the domain.

Bypass Technique 3: The nip.io and sslip.io Magic

These free services turn any IP address into a domain name. For example:

• 192.168.1.1.nip.io resolves to 192.168.1.1
• 10.0.0.1.nip.io resolves to 10.0.0.1
• 127.0.0.1.nip.io resolves to 127.0.0.1

If the blacklist blocks 127.0.0.1 but allows domains, you can bypass with http://127.0.0.1.nip.io/. Even better, you can probe internal IPs that aren't blocked: [http://10.0.0.1.nip.io/](http://10.0.0.1.nip.io/.).

The Course Demonstration: The instructor used 0001.nip.io (which also points to 127.0.0.1). The filter only blocked the numeric IP pattern; the domain sailed through.

Bypass Technique 4: URL Parsing Tricks

Some SSRF implementations use parse_url() or similar functions that can be confused:

• Use @ to embed credentials: http://expected-domain.com@127.0.0.1/ – if the filter checks the hostname after @, it might see expected-domain.com and allow, but the actual request goes to 127.0.0.1.
• Use # (fragment) or ? (query): http://127.0.0.1#evil.com – the host remains 127.0.0.1.
• Use backslash instead of slash: http:/\localhost/ (some parsers accept this).

Putting It All Together: Your Localhost Bypass Checklist

When an SSRF endpoint blocks obvious localhost addresses, systematically try:

• Alternate dotted notations: 127.0.1, 127.1, 0.0.0.0, 0.
• Integer/hex/octal representations: 2130706433, 0x7f000001, 0177.0.0.1.
• Free mapping domains: localhost.nip.io, 127.0.0.1.nip.io, localtest.me, lvh.me.
• Your own custom domain pointing to 127.0.0.1 (if you have one).
• URL confusion tricks: http://trusted.com@127.0.0.1/, [http://127.0.0.1#trusted.com](http://127.0.0.1#trusted.com.).

Pro Tip: Keep an Open Redirect for SSRF Chaining

If the application uses a whitelist (only allows *.target.com), don't burn your open redirects. An open redirect on target.com can turn a whitelisted SSRF into a full internal network pivot. Save it, test it, then report both vulnerabilities together for maximum impact.

What to Do When All Bypasses Work?

Once you can reach 127.0.0.1, the real exploitation begins:

1. Port scan localhost: 127.0.0.1:80, :443, :8080, :3000, :5000, :8000, :9200 (Elasticsearch), :6379 (Redis).
2. Access internal services (e.g., Tomcat on port 8080).
3. Read cloud metadata if the server is in AWS/GCP/Azure (e.g., 169.254.169.254).
4. Use file:// if supported to read configuration files.

Reporting the Finding

When you bypass a localhost blacklist and access internal services, your report should include:

• The original SSRF endpoint and the blocked payload.
• The exact bypass payload that worked (e.g., http://127.0.1:8080/ or [http://localhost.nip.io/](http://localhost.nip.io/).))..)
• Evidence of successful internal access (screenshot of the Tomcat page or file content).
• Explanation of the impact: an attacker could pivot to internal microservices, steal credentials, or compromise the cloud environment.

Why This Matters: Many developers think blocking 127.0.0.1 and localhost is enough. It's not. The creativity of alternative representations, free DNS services, and URL parsing oddities means SSRF is often still exploitable. Your ability to bypass these naive filters will earn you bounties that others miss.

you can check this article too…

"Bug Bounty Bootcamp #35: SSRF — Turning the Server Into Your Personal Proxy to Hack Internal… Imagine if you could trick a web server into visiting internal websites, reading local files, and even scanning private…

"Bug Bounty Bootcamp #36: SSRF Hands-On — Confirming the Server Makes the Request and Reading… You think you found an SSRF. But how do you prove the request came from the server and not your browser? And once…

Clap 50 times for this story Leave a comment telling me your thoughts Highlight your Favorite part of the story These tiny actions go a long way, and I really appreciate it.

Thank you for reading and for helping me grow this community!

Medium!