# SSRF vulnerability (access to metadata server on EC2 and OpenStack)

SSRF in Phabricator's meme creation fetched arbitrary URLs, letting attackers reach the EC2/OpenStack metadata server and leak instance user-data containing secrets.

- Payout: $300
- Severity: medium
- Program: Phabricator
- Credited: agarri_fr
- Disclosed: 2015-03-26
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/53088
- Library page: https://bugbountylibrary.com/r/h1%3A53088
- Tags: domain:web impact:data-leak impact:internal-access kind:bounty platform:hackerone sev:medium tech:aws vuln:info-disclosure vuln:secrets-leak vuln:ssrf

**Target:** Meme creation image-fetch feature (server-side URL fetch)
**Root cause:** The meme creation feature fetched user-supplied image URLs server-side without restricting destinations, allowing requests to internal/link-local addresses.
**Steps:**
1. Locate meme creation feature that accepts an image URL
2. Submit `http://169.254.169.254/latest/meta-data/hostname` as the image URL
3. Observe fetched metadata reflected back
4. Submit `http://169.254.169.254/latest/user-data` to retrieve instance startup script
**How found:** Researcher revisited a previously dismissed SSRF report (#50537) and reasoned that common EC2/OpenStack deployments expose a metadata server on 169.254.169.254 reachable only from the instance, turning the SSRF into a credential-leak primitive.
**Exploitation:** Attacker supplies a URL pointing at the link-local metadata IP; the server fetches it and returns the response, exposing hostname, IPs, and user-data startup scripts that may contain passwords, private keys, or source code.
**Escalation:** Pivoting from metadata to user-data secrets enables credential theft and further compromise of the instance.
**Insight:** When a program marks an SSRF 'won't fix' as low-impact, re-file emphasizing cloud metadata endpoints (169.254.169.254) and user-data, which often hold startup secrets.