The Spanner logo
    • Home
    • Blog
      • Blog home
      • RSS
    • Login
    • Home
    • Blog
      • Blog home
      • RSS
    • Login
    The Spanner logo

    The Spanner
    Web security blog

    Made by Gareth Heyes
    Follow me on Twitter: @garethheyes

    Javascript for hackers!

    Hackvertor logo
    Shazzer logo
    My Github account
    Recent posts
    Introducing Feedworm: A Privacy-First RSS Reader That Lives in DevToolsSpeedy RSVP extensionAutoVaderHackvertor history and tag finderShadow Repeater v1.2.3 releaseBurp Hackvertor v2.1.24 releaseHacking roomsXSSing TypeErrors in SafarivalueOf: Another way to get thisMaking the Unexploitable Exploitable with X-Mixed-Replace on FirefoxThe curious case of the evt parameterCSS-Only Tic Tac Toe ChallengeRewriting relative urls with the base tag in SafariBypassing DOMPurify with mXSSNew IE mutation vectorHow I smashed MentalJSMentalJS DOM bypassAnother XSS auditor bypassXSS Auditor bypassBypassing the IE XSS filterUnbreakable filterMentalJS bypassesmXSSJava SerializationBypassing the XSS filter using function reassignmentRPOSandboxed jQueryX-Domain scroll detection on IE using focusEpic fail IEnew operatorDecoding complex non-alphanumeric JavaScriptHacking FirefoxDOM ClobberingBypassing XSS AuditorThe evolution of codeNon-Alpha PHP in 6-7 charsetTweetable PHP-Non AlphaMentalJS for PHPOpera x domain with video tutorialSandboxing and parsing jQuery in 100ms

    Making the Unexploitable Exploitable with X-Mixed-Replace on Firefox

    By Gareth Heyes (@hackvertor)

    Published 1 year 1 month ago • Last updated April 25, 2025 • ⏱️ 2 min read

    ← Back to articles

    Alt text

    In this post, we’ll look at an interesting difference in how Firefox and Chrome handle the multipart/x-mixed-replace content type. While Chrome treats it as an image, Firefox renders it as HTML - something that can have implications for security. If you have reflected input somewhere in a page, such as inside an HTML attribute, but can’t break out of it directly, controlling the content type and abusing the way boundaries are handled might be enough to turn an otherwise non-exploitable XSS into a real one.

    The multipart/x-mixed-replace content type behaves quite differently in Firefox, and not in ways you'd expect. Firefox is surprisingly lenient about what qualifies as a boundary - you can even use something like a <script> tag, and it won’t complain. These boundaries define where the browser should start rendering the next chunk of content, and that’s where things get interesting: everything before the boundary is discarded.

    Consider the following HTML:

    <!doctype html> <html> <body> <img id="reflection<iframe onload=alert(1)>"> </body> </html>

    Normally, the <iframe> isn’t rendered because it’s stuck inside an id attribute, where it's treated as a harmless string. But if you inject a boundary inside that id, and you control the content type, Firefox will start rendering from the boundary itself. That means the <iframe> suddenly becomes active HTML. Even better, boundaries rely on newlines which are rarely filtered.

    Here's what an exploit looks like:

    <?php header('Content-Type: multipart/x-mixed-replace; boundary=foo'); ?> <!doctype html> <html> <body> <img id=" foo <iframe onload=alert(1)> "> </body> </html>

    The preceding example uses foo as a boundary in the content type header. The new lines are all that's needed inside the attribute for the boundary to be valid, you don't even need a closing boundary. The image is discarded and everything after the boundary is rended which means the iframe is and the event executes! You can view this online here:

    Firefox x-mixed-replace PoC

    Hope you enjoyed this post.

    ← Back to articles