# AI Finds Vulnerabilities. Security Experts Find Impact.

Header-trust SMS verification bypass plus unlimited-use invite codes enabled self-reproducing account creation; a separate image-generation endpoint yielded full-read SSRF via controllable mime_type.

- Payout: Research
- Disclosed: 2026-06-24
- Write-up quality: 7/10
- Original: https://bishopfox.com/blog/ai-finds-vulnerabilities-security-experts-find-impact
- Library page: https://bugbountylibrary.com/r/blog%3Abishopfox-com-blog-ai-finds-vulnerabilities-security-experts-find-impact
- Tags: area:web domain:web impact:data-leak impact:internal-access kind:research platform:research tech:rest technique:chained technique:source-review vuln:auth-bypass vuln:business-logic vuln:ssrf

**Target:** Web application (auth/registration APIs and image-generation endpoint)
**Root cause:** Verification logic trusted client-supplied HTTP headers to set smsVerified; invite codes had effectively unlimited usage. Separately, the image-generation endpoint fetched user URLs server-side without validation and passed the response plus a client-controlled mime_type into Gemini, rendering fetched content into the output image.
**Steps:**
1. Spoof the two expected HTTP headers so the app treats the user as SMS-verified without completing verification.
2. Note the two-minute Redis cache on UserInfo: the first UserInfo request after email verification fixes whether smsVerified is cached true/false, explaining intermittent bypass behavior.
3. Retrieve a personal invitation code from an endpoint of a legitimately activated account; observe it has effectively unlimited usage count.
4. Combine bypass + reusable invite code to activate unlimited accounts, each yielding its own invite code (self-reproducing chain).
5. For SSRF: submit a user-supplied URL to the image-generation endpoint; confirm outbound requests via Burp Collaborator callbacks from customer infrastructure.
6. Change `mime_type` in the POST body from `image/png` to `text/plain` so the fetched response is rendered into the generated image.
7. Point URL at `https://icanhazip.com` to read backend IP, then at `http://localhost:6060/debug/pprof/cmdline` to extract local Go pprof data into the image.
**How found:** AI source review flagged header-trust verification and two URL-fetch endpoints; human traced execution paths to see one fetch ran in Google Cloud Vision (dead end) and the other locally. Intermittent bypass traced to a two-minute Redis UserInfo cache. SSRF extraction found by fuzzing request fields and noticing mime_type was fully controllable.
**Exploitation:** Attacker spoofs verification headers and reuses an unlimited invite code to mass-create activated accounts that each mint new invite codes. For SSRF, attacker supplies arbitrary URLs to the image-generation endpoint; by setting mime_type to text/plain, the fetched response (internal services, cloud metadata, localhost pprof endpoints) is encoded and rendered into the returned image, converting blind SSRF into full-read exfiltration.
**Escalation:** Chained verification bypass with unlimited-use invite codes for self-reproducing account creation; escalated blind SSRF to data extraction by abusing the client-controlled mime_type rendering path.
**Insight:** When a fetch endpoint pipes responses into a renderer/LLM, look for client-controlled content-type or output-format fields—switching mime_type can turn a blind SSRF into full-read by rendering fetched bytes into the response artifact. Also check caching layers when a bypass behaves intermittently.

## Proof of concept (copied exactly from the original report)

**SSRF error output from internal fetch attempts**

```
400 Bad Request 
401 Unauthorized for http://169.254.169.254/latest/meta-data/ 
tls: failed to verify certificate: x509: certificate signed by unknown authority 
dial tcp: lookup unknown123.com: no such host 
Get "169.254.170.2/v2/metadata": unsupported protocol scheme 
404 Not Found
```

**SSRF to localhost pprof cmdline endpoint**

```
To prove it, I pointed the vulnerable endpoint at http://localhost:6060/debug/pprof/cmdline, a Go runtime diagnostic endpoint exposed locally on the server. I used the /cmdline endpoint because the output was easy to demonstrate, but it wasn't the only thing accessible. Other pprof endpoints were also reachable and exposed additional diagnostic information. The response was fetched from localhost, passed through the application's processing pipeline, and ultimately rendered directly into the generated image:
```