In early 2024, a DOM-based Cross-Site Scripting (XSS) vulnerability was found in the popular web-platform-tests/wpt open-source project. This project is vital for testing browsers’ compliance with web standards. Specifically, the issue affects the /dom/ranges/Range-test-iframe.html component before commit 938e843. The bug allows an attacker to execute arbitrary JavaScript by luring a victim into clicking or visiting a specially crafted URL.

In this long read, we’ll go through what happened, how the vulnerability works, walk through code snippets, and offer guidance for mitigation. Sources and code examples are included for clarity.

Let’s break down the technical jargon

- DOM-based XSS: This type of XSS happens when the vulnerable JavaScript code on a page modifies the DOM using unsafe user input, leading to code execution entirely in the browser.
- web-platform-tests/wpt: An open-source project that major browsers use to check for standard compliance. The vulnerable file, Range-test-iframe.html, is one of thousands of tests.

Before commit 938e843: The test page did not handle URL data safely.

- Arbitrary JavaScript Execution: By sending a crafted URL containing malicious data, attackers can run any JavaScript in the context of the page.

Let’s look at a simplified version reminiscent of the vulnerable code

<!-- Range-test-iframe.html -->
<!DOCTYPE html>
<html>
<head><title>Range Test</title></head>
<body>
<script>
    // Vulnerable: using 'location.hash' without sanitization
    let user_value = location.hash.substring(1); // e.g., anything after #
    // Insert user_value directly into the DOM
    document.body.innerHTML = "<div id='out'>" + user_value + "</div>";
</script>
</body>
</html>

To exploit this, an attacker crafts a URL like

http://vulnerable.site/dom/ranges/Range-test-iframe.html#<img src=x onerror=alert(1)>

location.hash.substring(1) becomes <img src=x onerror=alert(1)>

3. The page sets document.body.innerHTML to <div id='out'><img src=x onerror=alert(1)></div>

The browser parses this as HTML and fires the onerror, running alert(1).

Attackers can replace alert(1) with any JavaScript — stealing cookies, stealing session data, or forcing unwanted actions.

`

http://localhost:800/dom/ranges/Range-test-iframe.html#

Screenshot (for illustration)

+----------------------------------+
|             XSS-in-WPT           |
+----------------------------------+
                [OK]

Original References

- CVE-2024-26466 at NVD
- Commit fixing the vulnerability (938e843)
- CVE Report at MITRE

Further Discussion

This bug appears in a *test* file. Test systems sometimes run on non-public infrastructure, but attackers sometimes find deployments exposed to the Internet, or trick developers into opening tampered test pages locally.

Most dangerous: If your test environment shares cookies, sessions, or credentials with production, an XSS like this can be a real way in.


## How to Fix / Mitigate

Use textContent instead of innerHTML

document.getElementById('out').textContent = user_value;

Or, sanitize user input with libraries like DOMPurify

DOMPurify GitHub

Final Thoughts

CVE-2024-26466 is a classic example of why you shouldn’t trust user-controlled data in the browser DOM, even inside test projects. XSS can happen anywhere untrusted data winds up as HTML, and automated test suites are no exception.

Stay safe and patch your test rigs — the security surface includes your testing infrastructure!

*Written by: YourSecurityReads*
*Date: 2024-06-23*

---

Sources

- web-platform-tests/wpt
- CVE-2024-26466

Timeline

Published on: 02/26/2024 16:27:59 UTC
Last modified on: 10/30/2024 20:35:12 UTC