CVE-2026-25148: When "Resumability" Becomes "Exploitability" in Qwik SSR

Qwik has made a name for itself by eliminating "hydration"—that heavy process where your browser has to re-execute a mountain of JavaScript just to make a static HTML page interactive. Instead, Qwik uses Resumability. It serializes the entire application state and event listeners directly into the HTML, allowing the client to pick up exactly where the server left off.

But here is the catch: where does all that state go? It gets stuffed into custom attributes and HTML comments (like <!--qv ... -->) scattered throughout the DOM. These comments act as the glue holding the virtual DOM together across the network boundary.

For a security researcher, this is blood in the water. Anytime a framework takes user input and serializes it into a hidden structural element, there is a risk. If the serializer gets lazy and just concatenates strings, you have a recipe for disaster. And in Qwik's case, the serializer didn't just get lazy; it fell asleep at the wheel.

The root cause here is almost charmingly retro. The vulnerability lives in render-ssr.ts, specifically within the functions responsible for serializing virtual attributes (renderVirtualAttributes) and node metadata.

When the server renders a component, it generates strings like key=value to place inside those special <!--qv ... --> comments. The developers assumed that these values would be benign internal identifiers. However, modern web apps love to pass user-controlled data around as props, slot names, or keys.

Prior to version 1.19.0, the code simply appended these values to the output string. It didn't check for special characters. It didn't quote them safely. It just glued them together. This means if an attacker controls a variable that ends up in these virtual attributes, they can inject the sequence -->. In HTML parsing rules, that sequence immediately closes a comment block. Anything following it is treated as raw HTML markup by the browser.

Let's look at the smoking gun. The patch (commit fe2d9232c0bcec99411d51a00dae29295871d094) reveals exactly what went wrong. The developers had to introduce a new helper, escapeValue, because they were previously doing raw concatenation.

The Vulnerable Logic (Conceptual):

// Old way: blind trust
text += ' ' + (value === '' ? prop : prop + '=' + value);

If value is --> <script>..., the resulting HTML is broken immediately.

The Fix:

// New way: sanitize everything
text += ' ' + (value === '' ? prop : prop + '="' + escapeValue(value) + '"');

The fix involves wrapping the value in quotes and running it through escapeValue, which converts dangerous characters (like < and >) into their HTML entity equivalents. It's standard procedure, but it was missing in a critical part of the SSR engine.

Exploiting this is trivially easy if you can influence a property or slot name rendered on the server. You don't need complex heap feng shui or ROP chains. You just need to know how HTML comments work.

Here is a Proof of Concept derived from the regression tests. Imagine a component that accepts a name for a slot:

// The malicious payload
const PAYLOAD = "--><img src=x onerror=alert('XSS')>";
 
// The victim component
<Slot name={PAYLOAD} />

When the server renders this, it tries to create a comment to track the slot. Without the fix, it outputs something like this:

<!--qv q:s q:key=--><img src=x onerror=alert('XSS')>-->

The Browser's Perspective:

1. See <!--qv ... : Start comment.
2. See --> (inside our payload): End comment.
3. See <img src=x onerror=...>: Execute HTML.
4. See -->: Text content (harmless trailing garbage).

The result? Immediate JavaScript execution in the context of the victim's session.

> [!WARNING] > Researcher Note: The patch might not be complete.

While analyzing the fix, I noticed something interesting. The patch heavily sanitizes the values of attributes, but it seems to trust the keys (property names). In the loop iterating over attributes:

for (const prop in attributes) {
    // ...
    text += ' ' + (value === '' ? prop : prop + '="' + escapeValue(value) + '"');
}

The prop variable is appended directly. If an application uses the spread operator with a user-controlled object (e.g., <div {...userInput} />), and the attacker manages to inject a key named --> <svg/onload=alert(1)>, this logic might still allow a breakout. It's a narrower edge case, but in security, edge cases are where the fun happens. Developers should treat object spreading with extreme caution.

The immediate remediation is to upgrade Qwik to version 1.19.0 or later. This version includes the escapeHtml and escapeValue helpers that neutralize the breakout characters.

However, this vulnerability serves as a reminder: Sanitization is not just for the client. SSR is effectively a text-processing engine. If you are building strings that will be parsed by a browser, you must respect the parser's rules. For developers using Qwik, ensure you aren't passing raw user input into component props that affect structural metadata, like slot names or keys.