# Profile Pic padding (Length-hiding) fails due to use of GZIP

GZIP compression on Twitter profile images defeated intentional length-hiding padding, letting a blind network attacker infer visited pages from compressed response sizes.

- Payout: $280
- Severity: low
- Program: X / xAI
- Credited: ericlaw
- Disclosed: 2016-03-18
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/29835
- Library page: https://bugbountylibrary.com/r/h1%3A29835
- Tags: domain:web impact:data-leak kind:bounty platform:hackerone sev:low tech:cdn technique:recon vuln:info-disclosure

**Target:** Profile image server (JPEG/PNG responses)
**Root cause:** Performance team enabled GZIP on profile images without knowing the trailing 0x20 padding was an intentional length-hiding countermeasure; compression collapses padded sizes back to content-dependent lengths.
**Steps:**
1. Observe profile images served with trailing 0x20 padding to fixed size thresholds (e.g. 16298 bytes)
2. Note padding hides true image length to blind network attackers
3. Observe GZIP now enabled on these image responses
4. Measure compressed response length; it varies with image content, defeating padding
**How found:** Researcher previously noticed junk 0x20 bytes appended to JPEG/PNG profile images and reasoned it was deliberate length-hiding padding; later observed GZIP enabled, circumventing it.
**Exploitation:** A blind network attacker measures compressed response sizes from Twitter's image server for predictable profile-pic URLs embedded on third-party pages, correlating size to infer which pages a victim visits.
**Insight:** Length-hiding padding is only effective if compression is disabled; check whether CDN/perf changes re-enable gzip/br on padded resources, and measure compressed sizes to confirm leakage.