Image Proxy SSRF in Bug Bounty: Camo, CDNs, and Unsafe Fetches
Apps proxy remote images to enforce HTTPS, resize thumbnails, or hide referrers. The proxy accepts a URL and returns bytes. When URL checks are weak, that same hop becomes SSRF with a Content-Type: image/* costume.
I've filed these against markdown renderers, rich-text editors, avatar importers, and "export to PDF" engines that pull remote assets.
Identify the proxy
Common patterns:
/img?url=/camo/<signature>/<url>- CDN image transformers with
srcorimagequery params - Mobile APIs that "normalize" avatar URLs
Signed Camo-style proxies need a valid signature, but signature checks sometimes cover only a subset of schemes, or an alternate unsigned endpoint exists for internal tools. Unsigned query parameters are the easy wins. Look for the same hostname used by email clients or notification digests; those often reuse the proxy with weaker validation.
Point the URL at your collaborator. A hit proves the server fetches. Next, try HEAD versus GET behavior, redirect following, and whether the proxy returns upstream headers or error bodies that leak internal details.
Make the SSRF meaningful
Image proxies often allow only http and https. That still leaves cloud metadata, intranet HTTP services, and localhost admin UIs that return 200 with HTML. If the proxy requires a magic byte prefix for images, some targets still respond with enough data to confirm access, or you can use an open redirect to an image on the internet after touching an internal host—program permitting.
Watch for header injection into the upstream request. Values like Authorization or Host taken from query parameters can escalate a simple fetch into credential abuse. Keep proofs on systems you own.
PDF and office converters that embed images are cousins of this bug. Upload a document referencing your canary URL if that feature exists and is in scope. SVG fetches that the proxy rewrites into raster output can also carry unexpected parser behavior—stay on canary content.
False positives to avoid
A browser-side image load is not SSRF. Confirm the request source IP is the application's egress, not your laptop. A CDN that merely caches a public URL is not SSRF either. You need the trusted server to request a destination it should not reach.
Do not claim "full Internet open proxy" unless you can retrieve arbitrary responses. Many image proxies only forward limited bytes or require successful image decoding. Honest scope of impact keeps the ticket open.
Fix language that helps triage
Recommend allowlisting schemes and ports, blocking private IP ranges after each redirect hop, using a locked-down egress network, signing remote URL parameters, and never returning raw upstream error pages to end users. PortSwigger's SSRF labs share the vocabulary for blind versus full-response cases—use it when describing your canary evidence.
An image URL parameter looks harmless in a PR review. On a bounty target, it is often the shortest path from markdown to the metadata service. Width and height parameters occasionally change which upstream host is contacted when the app picks a resize farm. Vary them once after the basic canary hits.