MHTML XSS in Legacy Browsers: Still Relevant Edge Cases
MHTML (MIME HTML) packaging let Internet Explorer treat a multipart archive as a document. Script inside that package could run in surprising origins when servers mislabeled responses or browsers sniffed multipart/related. Most modern hunters never touch it—until a program still supports IE mode, old WebViews, or an intranet Edge IE mode policy.
Do not pad a report with museum trivia. Ask whether any in-scope client still parses MHTML meaningfully. If the answer is no, archive the notes and hunt something else. If the answer is yes—or unclear—keep going with browser-accurate proofs only.
When the bug class still exists
Look for:
- Responses served as
message/rfc822,multipart/related, orapplication/octet-streamthat contain HTML parts - File download endpoints that echo user content with weak
Content-Type - Intranet apps advertising IE compatibility
- "Save as MHT" style exporters that later re-open content in a browser
The historical issue: IE could execute script from an MHTML document under a security context tied to the hosting URL, while the attacker controlled a MIME part. Combined with content sniffing, a text/plain upload sometimes became active content.
Edge's IE mode is not full IE everywhere, and many public sites broke these paths on purpose. Still, regulated enterprises pin old modes. If the program lists Windows clients or internal tools, ask about supported browsers in the policy page before burning a week.
Export features that email an .mht attachment are easy to overlook during recon. If the recipient opens that file in a legacy viewer tied to a corporate intranet zone, the impact story changes from "curious MIME" to a real execution path.
Practical testing notes
Start with Content-Type audit trails, not exotic payloads. Upload or reflect a multipart body with a clear canary script part. Observe whether any in-scope browser executes it, sandboxes it, or downloads it. If the file only downloads, you likely have a storage issue, not XSS.
Compare headers: X-Content-Type-Options: nosniff, Content-Disposition: attachment, and strict Content-Type. Missing nosniff on a user-controlled MIME response is a signal worth chasing on legacy stacks. On Chromium-only targets, pivot—your time is better spent on DOM XSS.
I've filed "interesting MIME" notes that got closed as Informative when no supported browser executed script. That outcome is correct. Impact needs a real renderer.
Ask the program about supported clients early. A one-line clarification from the team beats a polished write-up that only works in a browser they already retired. Corporate bug bounty pages sometimes hide IE mode requirements under "internal tools" or VPN-only hosts—read those sections twice.
Framing the report
State the exact browser, version, and document mode. Include the raw response bytes and headers. Explain the active context (which origin the script inherits). If only IE 11 on an intranet host is affected, mark that limitation up front so severity stays honest.
Remediation is boring and effective: send nosniff, force downloads for untrusted MIME, avoid serving user multipart as navigable documents, and drop IE mode where business allows. If the business cannot drop IE mode yet, isolate those apps on hosts without shared session cookies.
MHTML XSS is a niche. Treat it like one. When the niche matches the target's clients, it still pays.