security-research-notebook/ssrf-via-image-pipeline/index.html

516 lines · html
<!doctype html>
<html lang="en"><head><meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>How I Found Two SSRF Vulnerabilities in a Major Cloud Platform&amp;#x27;s Image Pipeline | Zion Boggan</title>
<meta name="description" content="Two SSRFs in the same platform via different code paths (webhook callbacks + image processor). The systemic pattern matters more than either finding.">
<link rel="icon" href="data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 32 32'%3E%3Crect width='32' height='32' rx='6' fill='%230c0e12'/%3E%3Ctext x='16' y='22' font-family='monospace' font-size='15' fill='%236cc7b8' text-anchor='middle'%3Ezb%3C/text%3E%3C/svg%3E">
<style>
  :root{
    --bg:#0c0e12; --bg2:#0f1217; --panel:#14181f; --panel2:#171c24;
    --line:#222936; --line2:#2c3543;
    --ink:#e8eaed; --soft:#c3cad4; --muted:#8a94a3; --faint:#5d6675;
    --accent:#6cc7b8; --accent-dim:#274b47;
    --maxw:1020px;
  }
  *{box-sizing:border-box;}
  html{scroll-behavior:smooth;}
  body{margin:0;background:var(--bg);color:var(--ink);
    font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Helvetica,Arial,sans-serif;
    font-size:16px;line-height:1.65;-webkit-font-smoothing:antialiased;}
  .mono{font-family:ui-monospace,SFMono-Regular,"SF Mono",Menlo,Consolas,monospace;}
  a{color:var(--accent);text-decoration:none;}
  a:hover{color:#8fe0d2;}
  .wrap{max-width:var(--maxw);margin:0 auto;padding:0 24px;}
 
  /* nav */
  nav{position:sticky;top:0;z-index:20;background:rgba(12,14,18,.82);
    backdrop-filter:blur(10px);border-bottom:1px solid var(--line);}
  nav .wrap{display:flex;align-items:center;justify-content:space-between;height:58px;}
  nav .brand{font-weight:600;letter-spacing:.2px;}
  nav .brand .dot{color:var(--accent);}
  nav .links{display:flex;gap:26px;font-size:13.5px;}
  nav .links a{color:var(--muted);}
  nav .links a:hover{color:var(--ink);}
  @media(max-width:680px){nav .links{display:none;}}
 
  /* hero */
  header.hero{padding:74px 0 54px;border-bottom:1px solid var(--line);
    background:radial-gradient(900px 380px at 78% -10%, #11201e 0%, transparent 60%);}
  .avail{font-size:12.5px;letter-spacing:1.5px;text-transform:uppercase;color:var(--accent);
    display:flex;align-items:center;gap:9px;margin-bottom:20px;}
  .avail .pulse{width:7px;height:7px;border-radius:50%;background:var(--accent);
    box-shadow:0 0 0 0 rgba(108,199,184,.5);animation:p 2.4s infinite;}
  @keyframes p{0%{box-shadow:0 0 0 0 rgba(108,199,184,.45)}70%{box-shadow:0 0 0 8px rgba(108,199,184,0)}100%{box-shadow:0 0 0 0 rgba(108,199,184,0)}}
  h1{font-size:clamp(34px,6vw,52px);line-height:1.05;margin:0 0 8px;letter-spacing:-1px;font-weight:680;}
  .hero .sub{font-size:clamp(16px,2.4vw,20px);color:var(--soft);margin:0 0 24px;font-weight:500;}
  .hero .lede{max-width:660px;color:var(--soft);font-size:17px;margin:0 0 28px;}
  .hero .lede b{color:var(--ink);font-weight:600;}
  .cta{display:flex;flex-wrap:wrap;gap:12px;align-items:center;}
  .btn{display:inline-flex;align-items:center;gap:8px;padding:10px 18px;border-radius:8px;
    font-size:14.5px;font-weight:550;border:1px solid var(--line2);color:var(--ink);background:var(--panel);}
  .btn:hover{border-color:var(--accent-dim);background:var(--panel2);color:var(--ink);}
  .btn.primary{background:var(--accent);color:#06231f;border-color:var(--accent);font-weight:650;}
  .btn.primary:hover{background:#8fe0d2;color:#06231f;}
  .meta{margin-top:26px;display:flex;flex-wrap:wrap;gap:8px 22px;font-size:13px;color:var(--muted);}
  .meta .mono{color:var(--faint);}
 
  /* sections */
  section{padding:64px 0;border-bottom:1px solid var(--line);}
  .shead{display:flex;align-items:baseline;gap:14px;margin-bottom:30px;}
  .shead .idx{font-size:13px;color:var(--accent);letter-spacing:1px;}
  .shead h2{font-size:14px;letter-spacing:2px;text-transform:uppercase;color:var(--muted);margin:0;font-weight:600;}
  .shead .rule{flex:1;height:1px;background:var(--line);}
 
  /* flagship */
  .flag{background:linear-gradient(180deg,var(--panel) 0%,var(--bg2) 100%);
    border:1px solid var(--line2);border-radius:14px;overflow:hidden;}
  .flag .top{padding:30px 32px 8px;}
  .flag .tag{font-size:12px;letter-spacing:1.5px;text-transform:uppercase;color:var(--accent);margin-bottom:12px;}
  .flag h3{font-size:27px;margin:0 0 6px;letter-spacing:-.4px;}
  .flag h3 .v{font-size:13px;color:var(--muted);font-weight:500;margin-left:8px;letter-spacing:0;}
  .flag .grid{display:grid;grid-template-columns:1.25fr 1fr;gap:30px;padding:14px 32px 30px;}
  .flag p{color:var(--soft);margin:0 0 16px;}
  .flag .stats{display:grid;grid-template-columns:1fr 1fr;gap:12px;margin-top:6px;}
  .stat{background:var(--bg);border:1px solid var(--line);border-radius:9px;padding:13px 15px;}
  .stat .n{font-size:21px;font-weight:680;color:var(--ink);}
  .stat .k{font-size:12px;color:var(--muted);margin-top:2px;}
  .spec{background:var(--bg);border:1px solid var(--line);border-radius:10px;padding:18px 18px;}
  .spec .sk{font-size:11px;letter-spacing:1.5px;text-transform:uppercase;color:var(--faint);margin-bottom:10px;}
  .spec ul{margin:0;padding:0;list-style:none;font-size:13.5px;}
  .spec li{padding:6px 0;border-top:1px solid var(--line);color:var(--soft);display:flex;justify-content:space-between;gap:14px;}
  .spec li:first-child{border-top:none;}
  .spec li span{color:var(--muted);}
  .flag .foot{padding:0 32px 28px;display:flex;gap:18px;flex-wrap:wrap;font-size:14px;}
  @media(max-width:720px){.flag .grid{grid-template-columns:1fr;}}
 
  /* lab cards */
  .cards{display:grid;grid-template-columns:1fr 1fr;gap:20px;}
  @media(max-width:680px){.cards{grid-template-columns:1fr;}}
  .card{border:1px solid var(--line);border-radius:12px;overflow:hidden;background:var(--panel);
    display:flex;flex-direction:column;transition:border-color .15s,transform .15s;}
  .card:hover{border-color:var(--accent-dim);transform:translateY(-2px);}
  .card .thumb{height:172px;overflow:hidden;border-bottom:1px solid var(--line);background:#fff;}
  .card .thumb img{width:100%;height:100%;object-fit:cover;object-position:top left;display:block;}
  .card .body{padding:18px 20px 20px;display:flex;flex-direction:column;flex:1;}
  .card h3{margin:0 0 9px;font-size:17px;}
  .card p{margin:0 0 14px;font-size:14px;color:var(--soft);flex:1;}
  .tags{display:flex;flex-wrap:wrap;gap:6px;margin-bottom:14px;}
  .tags span{font-size:11.5px;color:var(--muted);background:var(--bg);border:1px solid var(--line);
    border-radius:5px;padding:3px 8px;}
  .card .lnk{font-size:13.5px;font-family:ui-monospace,Menlo,monospace;}
  .card .lnk::after{content:" →";}
 
  /* research */
  .rlede{color:var(--soft);max-width:680px;margin:-6px 0 26px;}
  .research{display:flex;flex-direction:column;gap:0;border:1px solid var(--line);border-radius:12px;overflow:hidden;}
  .ritem{display:grid;grid-template-columns:120px 1fr auto;gap:18px;align-items:center;
    padding:18px 22px;border-top:1px solid var(--line);}
  .ritem:first-child{border-top:none;}
  .ritem:hover{background:var(--panel);}
  .ritem .cls{font-size:11px;letter-spacing:.5px;text-transform:uppercase;color:var(--accent);}
  .ritem h3{margin:0 0 3px;font-size:16px;}
  .ritem p{margin:0;font-size:13.5px;color:var(--muted);}
  .ritem .go{font-family:ui-monospace,Menlo,monospace;font-size:13px;white-space:nowrap;}
  @media(max-width:680px){.ritem{grid-template-columns:1fr;gap:6px;}.ritem .go{margin-top:4px;}}
  .progs{margin-top:22px;}
  .progs .sk{font-size:11px;letter-spacing:1.5px;text-transform:uppercase;color:var(--faint);margin-bottom:11px;}
  .progs .row{display:flex;flex-wrap:wrap;gap:7px;}
  .progs .row span{font-size:12.5px;color:var(--soft);background:var(--panel);border:1px solid var(--line);
    border-radius:6px;padding:4px 10px;}
 
  /* credentials */
  .cred{display:grid;grid-template-columns:1.1fr 1fr;gap:28px;}
  @media(max-width:680px){.cred{grid-template-columns:1fr;}}
  .cred p{color:var(--soft);margin:0 0 14px;}
  .cred .role{font-size:14px;color:var(--muted);}
  .cred .role b{color:var(--ink);font-weight:600;}
  .certs{list-style:none;margin:0;padding:0;}
  .certs li{padding:9px 0;border-top:1px solid var(--line);font-size:14px;color:var(--soft);
    display:flex;gap:10px;align-items:baseline;}
  .certs li:first-child{border-top:none;}
  .certs li .c{color:var(--accent);font-family:ui-monospace,Menlo,monospace;font-size:12px;}
 
  footer{padding:46px 0 64px;}
  footer .row{display:flex;flex-wrap:wrap;justify-content:space-between;gap:18px;align-items:center;}
  footer .links a{color:var(--soft);margin-right:20px;font-size:14px;}
  footer .note{color:var(--faint);font-size:12.5px;max-width:520px;}
 
  .detail-hero{padding:40px 0 26px;}
  .back{display:inline-block;font-size:13px;color:var(--muted);margin-bottom:20px;font-family:ui-monospace,Menlo,monospace;}
  .back:hover{color:var(--ink);}
  .kicker{font-size:12px;letter-spacing:2px;text-transform:uppercase;color:var(--accent);margin-bottom:13px;font-family:ui-monospace,Menlo,monospace;}
  .detail-hero h1{font-size:clamp(26px,4.6vw,38px);margin:0 0 12px;letter-spacing:-.5px;}
  .detail-hero .tagline{font-size:clamp(15px,2vw,18px);color:var(--soft);max-width:800px;margin:0 0 16px;}
  .facts{display:grid;grid-template-columns:repeat(auto-fit,minmax(150px,1fr));gap:12px;margin-top:22px;}
  .content{padding:8px 0 0;max-width:840px;}
  .content h1{font-size:24px;margin:40px 0 14px;letter-spacing:-.4px;color:var(--ink);}
  .content h2{font-size:13px;letter-spacing:2px;text-transform:uppercase;color:var(--muted);margin:42px 0 15px;font-weight:600;border-top:1px solid var(--line);padding-top:28px;}
  .content h3{font-size:17px;margin:28px 0 10px;color:var(--ink);font-weight:600;}
  .content h4{font-size:14px;margin:22px 0 8px;color:var(--soft);font-weight:600;text-transform:uppercase;letter-spacing:.5px;}
  .content p{color:var(--soft);margin:0 0 15px;}
  .content ul,.content ol{color:var(--soft);margin:0 0 15px;padding-left:22px;}
  .content li{margin:5px 0;}
  .content strong{color:var(--ink);font-weight:600;}
  .content a{color:var(--accent);}
  .content code{font-family:ui-monospace,Menlo,monospace;font-size:12.8px;background:var(--panel2);border:1px solid var(--line);border-radius:4px;padding:1px 5px;color:var(--soft);}
  .content pre{background:var(--bg2);border:1px solid var(--line2);border-radius:10px;padding:15px 18px;overflow-x:auto;margin:0 0 18px;}
  .content pre code{background:none;border:none;padding:0;font-size:12.4px;color:var(--soft);line-height:1.6;white-space:pre;}
  .content table{width:100%;border-collapse:collapse;margin:2px 0 20px;font-size:13.3px;}
  .content th{text-align:left;color:var(--muted);font-weight:600;border-bottom:1px solid var(--line2);padding:9px 12px;font-size:11px;letter-spacing:.6px;text-transform:uppercase;}
  .content td{color:var(--soft);border-bottom:1px solid var(--line);padding:9px 12px;vertical-align:top;}
  .content blockquote{border-left:3px solid var(--accent-dim);margin:0 0 16px;padding:2px 0 2px 18px;color:var(--muted);}
  .content hr{border:none;border-top:1px solid var(--line);margin:30px 0;}
  /* notebook index */
  .nbgroup{margin:40px 0 0;}
  .nbgroup h2{font-size:13px;letter-spacing:2px;text-transform:uppercase;color:var(--accent);margin:0 0 4px;font-weight:600;}
  .nbgroup .gd{color:var(--faint);font-size:13px;margin:0 0 14px;}
  .nbtable{width:100%;border-collapse:collapse;font-size:14px;border:1px solid var(--line);border-radius:12px;overflow:hidden;}
  .nbtable tr{border-top:1px solid var(--line);}
  .nbtable tr:first-child{border-top:none;}
  .nbtable tr:hover{background:var(--panel);}
  .nbtable td{padding:14px 16px;vertical-align:top;}
  .nbtable .cls{white-space:nowrap;color:var(--accent);font-family:ui-monospace,Menlo,monospace;font-size:11.5px;text-transform:uppercase;letter-spacing:.5px;width:150px;}
  .nbtable .ti a{font-weight:600;color:var(--ink);}
  .nbtable .ti a:hover{color:var(--accent);}
  .nbtable .ol{color:var(--muted);font-size:13px;margin-top:3px;}
  @media(max-width:680px){.nbtable .cls{width:auto;display:block;}}
</style>
<link rel="canonical" href="https://zionboggan.com/security-research-notebook/ssrf-via-image-pipeline/">
<meta name="author" content="Zion Boggan">
<meta name="robots" content="index, follow, max-image-preview:large">
<meta property="og:type" content="article">
<meta property="og:site_name" content="Zion Boggan">
<meta property="og:title" content="How I Found Two SSRF Vulnerabilities in a Major Cloud Platform&amp;#x27;s Image Pipeline | Zion Boggan">
<meta property="og:description" content="Two SSRFs in the same platform via different code paths (webhook callbacks + image processor). The systemic pattern matters more than either finding.">
<meta property="og:url" content="https://zionboggan.com/security-research-notebook/ssrf-via-image-pipeline/">
<meta property="og:image" content="https://zionboggan.com/images/ssrf-textrender-proof.png">
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="How I Found Two SSRF Vulnerabilities in a Major Cloud Platform&amp;#x27;s Image Pipeline | Zion Boggan">
<meta name="twitter:description" content="Two SSRFs in the same platform via different code paths (webhook callbacks + image processor). The systemic pattern matters more than either finding.">
<meta name="twitter:image" content="https://zionboggan.com/images/ssrf-textrender-proof.png">
<script type="application/ld+json">{"@context":"https://schema.org","@type":"TechArticle","headline":"How I Found Two SSRF Vulnerabilities in a Major Cloud Platform&amp;#x27;s Image Pipeline","description":"Two SSRFs in the same platform via different code paths (webhook callbacks + image processor). The systemic pattern matters more than either finding.","url":"https://zionboggan.com/security-research-notebook/ssrf-via-image-pipeline/","image":"https://zionboggan.com/images/ssrf-textrender-proof.png","author":{"@type":"Person","name":"Zion Boggan","url":"https://zionboggan.com"},"publisher":{"@type":"Person","name":"Zion Boggan"}}</script>
</head><body>
<nav><div class="wrap">
  <a class="brand mono" href="/" style="color:var(--ink)">zion_boggan<span class="dot">.</span></a>
  <span class="links"><a href="/#oversight">Oversight</a><a href="/#labs">Labs</a><a href="/#research">Research</a><a href="/security-research-notebook/">Notebook</a><a href="/">Home</a></span>
</div></nav>
<header class="hero detail-hero"><div class="wrap">
  <a class="back" href="/security-research-notebook/">&larr; Research notebook</a>
  <div class="kicker">SSRF</div>
  <h1>How I Found Two SSRF Vulnerabilities in a Major Cloud Platform&#x27;s Image Pipeline</h1>
</div></header>
<section><div class="wrap"><div class="content">
<blockquote>
<p>Author: HackerOne <code>artemispwns1</code> / Bugcrowd Researcher<br />
Disclosure: under the program&rsquo;s responsible disclosure policy; vendor and
specific technical details intentionally omitted per policy.</p>
</blockquote>
<h2>Introduction</h2>
<p>I have been doing independent security research for a few months now, working
through bug bounty programs on HackerOne and Bugcrowd. What started as
curiosity about how web applications handle trust boundaries has turned into
a genuine discipline, and the findings keep getting more interesting as I
learn to think at the architectural level rather than just scanning for
low-hanging fruit.</p>
<p>Recently I completed an audit of a major cloud-based media processing
platform through their bug bounty program. The engagement produced two
distinct Server-Side Request Forgery (SSRF) vulnerabilities in separate
code paths, both stemming from the same root cause: inconsistent URL
validation across different parts of the application. I cannot name the
vendor or disclose specific technical details per the program&rsquo;s disclosure
policy, but I can share the methodology, the thought process, and what I
learned about how these kinds of gaps form in production systems.</p>
<p>This writeup is for anyone getting into bug bounty research or application
security who wants to understand how to move beyond surface-level recon and
start thinking about systemic vulnerabilities.</p>
<h2>Background: What is SSRF and Why Does It Matter?</h2>
<p>Server-Side Request Forgery is a vulnerability class where an attacker can
make a server issue HTTP requests on their behalf to destinations the
attacker should not be able to reach. The classic example is tricking a
server into calling the AWS metadata endpoint at <code>169.254.169.254</code>, which
can return temporary IAM credentials and expose the entire cloud environment.</p>
<p>SSRF has been climbing the OWASP Top 10 and sits in every serious attacker&rsquo;s
playbook because cloud infrastructure made internal network access
exponentially more valuable. A single SSRF in the right place can pivot
from &ldquo;I can make a server fetch a URL&rdquo; to &ldquo;I now have AWS keys to the
production S3 buckets.&rdquo; The impact scales with the trust the server has on
the internal network.</p>
<h2>The Methodology: Thinking in Code Paths</h2>
<p>When I started this audit, my first instinct was to test the obvious entry
points. The platform had a URL-based fetch feature where you supply an
external URL and the server retrieves the resource. Standard stuff. I tested
internal IPs against this endpoint and got exactly what I expected: a clean
403 Forbidden. They had SSRF protections in place.</p>
<p>A less experienced version of me would have stopped there. Good filter,
move on.</p>
<p>But I had been reading about how large platforms evolve over time. Features
get built by different teams, at different times, with different security
assumptions. The upload API team probably thought carefully about SSRF. The
question is whether every other team that added URL-accepting functionality
did the same.</p>
<p>So I mapped every parameter and feature in the platform that could potentially
cause the server to make an outbound HTTP request. Not just the obvious ones
like &ldquo;fetch this URL&rdquo; but also webhook callbacks, notification endpoints,
asynchronous processing triggers, and file format features that might resolve
external references during server-side rendering.</p>
<p>This is where the shift from scanning to auditing happens. You stop testing
individual inputs and start testing trust boundaries across the entire
application surface.</p>
<h2>Finding 1: Blind SSRF via Webhook Callbacks</h2>
<p>The platform had a notification system where you could specify a callback URL
that receives a POST request after certain operations complete. Think of it
like a webhook: &ldquo;when the job is done, POST the results to this URL.&rdquo;</p>
<p>The interesting thing was that the main upload parameter had solid SSRF
filtering. Internal IPs were blocked, RFC1918 ranges were rejected, the
metadata endpoint was explicitly denied. But the notification URL parameter,
which also causes the server to make an outbound HTTP request, had zero
filtering.</p>
<p>Same server. Same outbound HTTP client (presumably). Completely different
security posture depending on which parameter you used.</p>
<p>Here is a generic representation of what that comparison looked like:</p>
<pre><code class="language-bash"># The upload/fetch parameter correctly blocks internal IPs:
curl -X POST &quot;https://api.example.com/v1/upload&quot; \
  -d &quot;file=http://169.254.169.254/latest/meta-data/&quot; \
  -d &quot;api_key=${API_KEY}&quot; \
  -d &quot;timestamp=${TIMESTAMP}&quot; \
  -d &quot;signature=${SIGNATURE}&quot;
# Response: 403 Forbidden - blocked by SSRF filter
 
# The notification/callback parameter accepts the EXACT same internal address:
curl -X POST &quot;https://api.example.com/v1/upload&quot; \
  -d &quot;file=https://normal-image.png&quot; \
  -d &quot;callback_url=http://169.254.169.254/latest/meta-data/&quot; \
  -d &quot;api_key=${API_KEY}&quot; \
  -d &quot;timestamp=${TIMESTAMP}&quot; \
  -d &quot;signature=${SIGNATURE}&quot;
# Response: 200 OK - upload succeeds, server POSTs to metadata endpoint
</code></pre>
<p>That contrast is the entire finding in two commands. Same API, same server,
same internal target, two completely different outcomes depending on which
parameter carries the URL.</p>
<p>I tested this across the full range of internal targets to confirm it was
not limited to a single address:</p>
<table>
<thead>
<tr>
<th>Target</th>
<th>Description</th>
<th>Result</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>http://169.254.169.254/latest/meta-data/</code></td>
<td>AWS metadata</td>
<td>Accepted</td>
</tr>
<tr>
<td><code>http://169.254.170.2/v2/credentials</code></td>
<td>ECS credentials</td>
<td>Accepted</td>
</tr>
<tr>
<td><code>http://127.0.0.1:6379/</code></td>
<td>Localhost Redis</td>
<td>Accepted</td>
</tr>
<tr>
<td><code>http://127.0.0.1:9200/</code></td>
<td>Localhost Elastic</td>
<td>Accepted</td>
</tr>
<tr>
<td><code>http://REDACTED-IP:80/</code></td>
<td>RFC1918 Class A</td>
<td>Accepted</td>
</tr>
<tr>
<td><code>http://172.16.0.1:80/</code></td>
<td>RFC1918 Class B</td>
<td>Accepted</td>
</tr>
</tbody>
</table>
<p>Every single internal address that the upload parameter correctly blocked
was silently accepted through the notification parameter.</p>
<p>The severity escalation came from discovering that this gap existed not just
in authenticated API calls but also in a feature that allowed preconfigured
notification URLs to be triggered without authentication. This meant that
once the configuration was set, anyone who knew the right identifiers could
trigger the SSRF repeatedly with no API key, no signature, and no rate
limiting.</p>
<p>The impact profile: blind SSRF to AWS metadata endpoints, localhost services
on arbitrary ports, and RFC1918 internal networks. The POST body contained
JSON with several attacker-controllable fields, meaning internal services
that parse incoming webhooks could receive partially crafted payloads.</p>
<p>I rated this as High severity. The platform&rsquo;s existing SSRF protections on
the upload parameter proved they understood the risk. The gap in the
notification parameter was a systemic oversight, not a design choice.</p>
<h2>Finding 2: SSRF via Image Format Processing</h2>
<p>The second finding came from a completely different angle. The platform
supports server-side image transformation, converting between formats,
resizing, applying effects. One of the supported input formats allows
embedded references to external URLs as part of the file specification.</p>
<p>When the server processes this file format and performs a transformation
(for example, converting it to PNG), the underlying image processing
library resolves those external references by making its own HTTP requests.
These requests happen inside the rendering engine, completely outside the
URL validation layer that protects the upload and fetch endpoints.</p>
<p>The crafted input file looked something like this (generalized):</p>
<pre><code class="language-xml">&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;
&lt;svg xmlns=&quot;http://www.w3.org/2000/svg&quot;
     xmlns:xlink=&quot;http://www.w3.org/1999/xlink&quot;
     width=&quot;500&quot; height=&quot;500&quot;&gt;
  &lt;image xlink:href=&quot;https://attacker-controlled-url.com/test&quot;
         width=&quot;500&quot; height=&quot;500&quot;/&gt;
&lt;/svg&gt;
</code></pre>
<p>When the server converts this to a raster format, the image processing
library follows that external reference and fetches whatever URL is specified.
The fetched content gets rendered into the output image as pixel data.</p>
<p>I tested several targets to map the behavior:</p>
<table>
<thead>
<tr>
<th>Target</th>
<th>Result</th>
</tr>
</thead>
<tbody>
<tr>
<td>External URL returning an image</td>
<td>Full content rendered into output (101KB PNG)</td>
</tr>
<tr>
<td>External URL returning text / JSON</td>
<td>Broken image icon rendered (139KB PNG)</td>
</tr>
<tr>
<td>AWS metadata endpoint (internal)</td>
<td>Blank output, 12+ second response time</td>
</tr>
<tr>
<td>Baseline with no external ref</td>
<td>Blank output, ~300 bytes, sub-second</td>
</tr>
</tbody>
</table>
<p>Two illustrative outputs from the engagement (vendor identifiers cropped /
omitted; the platform&rsquo;s image processor faithfully renders fetched content
into its output pixel data):</p>
<p>External URL returning text:
<img alt="SSRF text render proof" src="images/ssrf-textrender-proof.png" /></p>
<p>External URL returning an image:
<img alt="SSRF external image fetch proof" src="images/ssrf-external-fetch-proof.png" /></p>
<p>The timing differential was the key evidence for internal network access.
Normal transformations completed in under one second. Transformations
referencing the metadata endpoint consistently took 12+ seconds before
returning, indicating the server attempted the connection and waited for a
response that never came.</p>
<p>I confirmed this by uploading a specially crafted file with an external URL
reference, then triggering a format conversion through the delivery API.
The output image contained rendered content from the external URL, proving
the server had fetched it. When I tested with the AWS metadata endpoint,
the transformation took 12+ seconds (versus less than one second for normal
transforms), confirming the connection attempt through timing analysis.</p>
<p>The key insight: this SSRF vector exists in a completely different code path
from the first finding. The upload filter, the fetch filter, and the
notification filter are all irrelevant here because the image processing
library makes its own HTTP requests that none of those filters touch.</p>
<p>The impact was more constrained than the first finding. Responses are
rendered as pixel data rather than returned as raw text, so text-based
secrets (like AWS credentials in JSON format) are not directly readable.
But image-format responses from internal services (monitoring dashboards,
status pages, cached graphics) would be fully exfiltrated. And the timing
differential still enables internal network mapping and port scanning.</p>
<p>I rated this as Medium severity. Confirmed external URL resolution with
content rendered into output, confirmed internal IP connection attempts via
timing analysis, but limited by the pixel-rendering constraint on data
extraction.</p>
<p>For anyone defending against this class of vulnerability, the fix for the
image processing path is well-documented and straightforward. Most image
processing libraries support policy configuration that disables external
URL resolution entirely:</p>
<pre><code class="language-xml">&lt;!-- Restrict the image processing library from resolving external URLs --&gt;
&lt;policy domain=&quot;coder&quot; rights=&quot;none&quot; pattern=&quot;URL&quot; /&gt;
&lt;policy domain=&quot;coder&quot; rights=&quot;none&quot; pattern=&quot;HTTPS&quot; /&gt;
&lt;policy domain=&quot;coder&quot; rights=&quot;none&quot; pattern=&quot;HTTP&quot; /&gt;
</code></pre>
<p>For the webhook/callback path, the remediation is to apply the same IP/URL
validation that already exists on the upload path to every other parameter
that triggers outbound requests. Block RFC1918, loopback, link-local, and
validate resolved DNS before making callbacks to prevent DNS rebinding.</p>
<p>These are not novel recommendations. The fact that they need to be applied
separately to each code path is exactly why these gaps exist in the first
place.</p>
<h2>The Systemic Pattern</h2>
<p>What makes these two findings interesting together is the pattern they
reveal. The platform had invested in SSRF protections, and those protections
worked correctly where they were applied. The problem was coverage.</p>
<p>There were at least four separate code paths that cause the server to make
outbound HTTP requests:</p>
<ol>
<li>The file upload/fetch path (protected)</li>
<li>The notification/webhook callback path (unprotected)</li>
<li>The image processing/rendering path (unprotected)</li>
<li>Other async processing paths (untested but likely similar)</li>
</ol>
<p>Each of these was probably built by a different team or at a different time.
The team that built the upload path thought about SSRF and implemented
filtering. The teams that built the notification system and the image
processing pipeline either did not think about SSRF or assumed it was
handled elsewhere.</p>
<p>This is the pattern I see most often in mature platforms. The vulnerability
is not that they do not know about SSRF. It is that their SSRF defenses are
applied per-feature rather than per-network-boundary. Every outbound HTTP
request from the server should pass through the same validation layer,
regardless of which feature triggered it.</p>
<h2>What I Learned</h2>
<p><strong>Map the full request surface, not just the obvious inputs.</strong> The most
interesting SSRF vectors are rarely in the parameter named &ldquo;url.&rdquo; They are
in webhook callbacks, file format parsers, async job configurations, and
anywhere else the server might make an outbound request as a side effect.</p>
<p><strong>Timing analysis is underrated.</strong> When you cannot see the response body
(blind SSRF), response timing becomes your primary signal. A 12-second
timeout versus a sub-second response tells you everything you need to know
about whether a connection attempt was made.</p>
<p><strong>Compare security controls across features.</strong> If one parameter blocks
internal IPs and another parameter in the same API does not, that is not
just a bug. It is evidence of a systemic gap in how security controls are
applied. Document the comparison explicitly in your report because it makes
the remediation path obvious.</p>
<p><strong>Think about chaining, not just individual findings.</strong> A blind SSRF by
itself might be Medium. A blind SSRF with attacker-controlled POST body
fields targeting internal services with no authentication is High. Context
matters more than the individual primitive.</p>
<p><strong>Write clean reports.</strong> I spent almost as much time on the reports as I did
on the research. Clear reproduction steps, evidence tables, severity
justification, and specific remediation recommendations. Triagers are busy.
Make their job easy and your findings get taken seriously.</p>
<h2>Growth Trajectory</h2>
<p>Six months ago I was running automated scanners and hoping something
interesting would fall out. Today I am reading RFC specifications, studying
image processing library internals, and mapping application architecture
before I test a single input.</p>
<p>The shift from tool-driven recon to methodology-driven auditing is where the
real growth happens in bug bounty. Tools find the easy stuff. Understanding
how systems are built, where trust boundaries break down, and how security
controls fail to scale across features is what finds the stuff that matters.</p>
<p>I am still early in this journey. But findings like these, where I can
identify a systemic pattern across multiple code paths in a production
platform used by thousands of companies, tell me I am heading in the right
direction.</p>
<p>If you are getting into bug bounty or offensive security research, my advice
is simple: stop looking for bugs and start understanding systems. The bugs
will find you.</p>
<hr />
<p><em>All research was conducted through authorized bug bounty programs with
responsible disclosure. No customer data was accessed or exfiltrated. Test
artifacts were cleaned up after submission.</em></p>
<hr><p style="color:var(--faint);font-size:12.5px;font-family:ui-monospace,Menlo,monospace">Source &middot; github.com/zionboggan/security-research-notebook &middot; writeups/ssrf-via-image-pipeline.md</p>
</div></div></section>
<footer><div class="wrap row">
  <div class="links"><a href="/">Portfolio</a><a href="https://www.linkedin.com/in/zion-boggan">LinkedIn</a><a href="/security-research-notebook/">Notebook</a><a href="mailto:zionboggan0@gmail.com">Email</a></div>
  <div class="note">Coordinated-disclosure research. Findings appear here only after the program's disclosure window closed, the patch shipped, or a CVE was published. No customer data was accessed.</div>
</div></footer>
</body></html>