An HTML File That Redirected From a Domain You Trust

This was a small bug with an outsized blast radius. A large retailer had a file endpoint that accepted uploads without authentication, returned an upload ID, and then served the file back — raw — at a public view URL on the company's own primary domain.

The spark

I uploaded a file and watched the request. The endpoint didn't seem to care what the file was. So I asked the obvious question: does it care about Content-Type: text/html?

Digging in

It didn't. It stored my HTML and, more importantly, served it back inline — the browser rendered it as a page, not as a download. A file store that renders attacker HTML on your own domain is a cross-site-scripting-shaped problem waiting to happen. But I didn't even need script execution to make it dangerous. A plain meta-refresh was enough.

The clever part isn't the redirect. It's the address bar: the victim sees the retailer's real, trusted domain right up until they land on the attacker's site.

The exploit

Upload a one-line HTML file:

<meta http-equiv="refresh" content="0;url=https://attacker.example/">

Take the trusted-domain view URL it hands back, and send that to a victim. They click a link that unmistakably belongs to a company they trust, and get bounced to whatever I want — a credential-harvest page, a fake login, a malware prompt.

Impact

A picture-perfect phishing primitive under a legitimate, recognisable brand. Links like this survive email filters and skeptical users precisely because the domain is real.

The fix

Serve user uploads from a separate sandbox domain, always with Content-Disposition: attachment, and allowlist the content types you actually need. Never render arbitrary uploaded HTML inline on the domain your users trust.