AI Finds Vulnerabilities. Security Experts Find Impact.

src/pentesting-web/ssrf-server-side-request-forgery/ssrf-vulnerable-platforms.md

@@ -74,6 +74,7 @@ A lot of modern applications fetch remote content on behalf of the user without
 - **image fetch / resize / optimization** endpoints
 - **link preview / unfurl** workers
 - **feed readers**, **scrapers**, **crawler jobs**, **markdown previewers**
+- **OCR**, **AI image-generation**, and other model pipelines that first fetch a URL and then pass the bytes downstream
 
 A recent high-value example is **Next.js**:
 
@@ -94,6 +95,50 @@ When auditing these features, look for places where the platform:
 - trusts the **Host** header or an internal rewrite step
 - assumes a resource is safe because it is an **image**, **PDF**, or **OpenGraph preview**
 
+### AI/OCR/media pipelines: verify **who** really fetches the URL
+
+A URL parameter that eventually influences OCR or image generation is **not automatically a useful SSRF against the target environment**. First map the fetch origin:
+
+- **target backend fetches it directly** --> real SSRF against that environment
+- **third-party service fetches it** (OCR provider, cloud Vision API, external crawler) --> the request originates from that provider, so you usually **can't reach the target's localhost, RFC1918 space, or metadata endpoints**
+- **browser fetches it** --> this is not SSRF
+
+Quick triage workflow:
+
+1. Send the URL to **Burp Collaborator / OAST** to confirm an outbound request exists.
+2. Compare the **source IP / ASN** of the callback with the target's infra.
+3. Read the code or trace the worker path to see whether the URL is handed to a third party or fetched by the application's own HTTP client.
+4. Treat provider-side fetching as a different issue class unless that provider can still reach something interesting for the engagement.
+
+### Turning blind SSRF into readable output through downstream processors
+
+If the server fetches the URL but does **not** return the body, inspect every field that controls how the fetched bytes are handled afterwards:
+
+- `mime_type`, `content_type`, `file_type`, `parser`, `mode`, `format`
+- prompt / attachment metadata sent to an OCR, LLM, preview, or image-generation pipeline
+- template flags that switch between **image**, **text**, **markdown**, **HTML**, or **OCR** modes
+
+A common upgrade path is:
+
+1. confirm **blind SSRF** with OAST
+2. point the URL to a harmless text endpoint such as `https://icanhazip.com`
+3. force the downstream processor to treat the response as **text** (for example `mime_type=text/plain`)
+4. look for the fetched response rendered inside the final artifact (generated image, OCR text, preview, moderation output, LLM response, PDF, etc.)
+
+This turns a blind callback into **response exfiltration** without ever receiving the raw HTTP body directly. In modern AI features, the vulnerable pattern is often: **fetch attacker URL -> base64/attach response -> send it to the model together with attacker-controlled type metadata -> render model output back to the user**.
+
+Useful proof targets once you suspect this pattern:
+
+```text
+https://icanhazip.com
+http://127.0.0.1:6060/debug/pprof/cmdline
+http://127.0.0.1:6060/debug/pprof/goroutine?debug=1
+http://169.254.169.254/latest/meta-data/
+http://169.254.170.2/v2/metadata
+```
+
+If you can only see error strings, they still help a lot: DNS failures, TLS validation errors, `401` from metadata services, and scheme-parsing errors often prove that the **backend** made the request and reached internal-only destinations.
+
 ## Blind SSRF canaries against internal software
 
 When the primitive is blind, try to bounce it through **internal software that performs another outbound request** to your OAST domain. This both **proves reachability** and often **fingerprints the internal platform**.
@@ -133,15 +178,18 @@ Other evergreen internal targets worth probing from a SSRF sink are:
 - **Solr**: `/solr/admin/info/system`
 - **Jenkins**: `/login`, `/script`, plugin-specific endpoints
 - **Prometheus / exporters / internal observability stacks**
+- **Go `pprof`**: `/debug/pprof/`, `/debug/pprof/cmdline`, `/debug/pprof/goroutine?debug=1`, `/debug/pprof/heap`
 
 This page is intentionally keeping the list short. For a much larger chain catalog, check the original Blind SSRF Chains research linked below.
 
 ## Practical workflow
 
 1. **Confirm OAST** using Interactsh / Burp Collaborator / webhook.site.
-2. **Derive internal hostnames** from DNS data, certificates, ELB names, app error messages, or naming conventions such as `jira`, `jenkins`, `grafana`, `solr`, `consul`, `redis`, `gitlab`, `argo`, `vault`, `kibana`.
-3. **Spray platform-specific canaries** instead of only probing `/` on random ports.
-4. If you get any sign of internal reachability, pivot into:
+2. **Identify the fetch origin**: target backend, browser, or third-party provider. This decides whether you really have SSRF against the assessed environment.
+3. **Derive internal hostnames** from DNS data, certificates, ELB names, app error messages, or naming conventions such as `jira`, `jenkins`, `grafana`, `solr`, `consul`, `redis`, `gitlab`, `argo`, `vault`, `kibana`.
+4. **Spray platform-specific canaries** instead of only probing `/` on random ports.
+5. If the sink is blind, fuzz **downstream interpretation fields** (`mime_type`, parser/format flags, OCR or LLM attachment metadata) to try to convert it into a readable exfiltration channel.
+6. If you get any sign of internal reachability, pivot into:
    - [cloud-ssrf.md](cloud-ssrf.md) for metadata endpoints
    - [url-format-bypass.md](url-format-bypass.md) for allowlist bypasses
    - protocol-specific exploitation from the main [SSRF page](README.md)
@@ -156,4 +204,5 @@ A blind SSRF with only **DNS callbacks** can still be enough to:
 
 - [Assetnote - A Glossary of Blind SSRF Chains](https://blog.assetnote.io/2021/01/13/blind-ssrf-chains/)
 - [Assetnote - Digging for SSRF in NextJS apps](https://www.assetnote.io/resources/research/digging-for-ssrf-in-nextjs-apps/)
+- [Bishop Fox - AI Finds Vulnerabilities. Security Experts Find Impact.](https://bishopfox.com/blog/ai-finds-vulnerabilities-security-experts-find-impact)
 {{#include ../../banners/hacktricks-training.md}}