Because web browsers perform HTML input stream preprocessing - converting carriage returns not followed by line feeds into line feeds - an attacker who can influence the keys in a bound object can supply a string containing \r. This character terminates the intended attribute name and allows for the injection of new, arbitrary attributes (e.g., autofocus or onfocus) into the rendered HTML output. Since this occurs during the server-side rendering phase, the resulting XSS payload is served directly to users, leading to full script execution in the context of the victim's session without requiring user interaction.

Attack Chain

1. Attacker identifies a feature in a web application that renders user-controllable object keys using Vue SSR (e.g., dynamic attribute configuration in a CMS or form builder).
2. Attacker crafts a malicious input string containing carriage returns (e.g., x\rautofocus\ronfocus) to be used as a key in a dynamic attribute object.
3. The application passes the malicious object to v-bind or the internal ssrRenderAttrs() function during server-side rendering.
4. The isSSRSafeAttrName utility validates the key against its blacklist; since \r is not blocked, it marks the key as safe.
5. The server-side code generates an HTML string where the \r remains embedded in the attribute name (e.g., <div x\rautofocus\ronfocus="...">).
6. The server sends this generated HTML to the victim's browser.
7. The browser performs HTML input stream normalization, interpreting the \r characters as delimiters, effectively creating new attributes like autofocus and onfocus.
8. The browser executes the injected JavaScript code (e.g., alert(document.cookie)) upon page load.

Impact

Successful exploitation results in full stored XSS within the target application. This allows attackers to execute arbitrary JavaScript in the context of any user viewing the affected page, leading to session hijacking, unauthorized data exfiltration, and potential complete account takeover. The vulnerability is highly severe in SSR contexts where dynamic object binding is used to construct HTML elements from untrusted inputs, such as in administrative dashboards or user-facing portals supporting custom configurations.

Recommendation

Prioritize the following actions for your development and security teams:

• Upgrade @vue/server-renderer to a patched version that explicitly blacklists carriage return (U+000D) characters in isSSRSafeAttrName.
• Perform a code audit of all SSR-enabled Vue components to identify instances where v-bind or ssrRenderAttrs processes objects with keys derived from external data.
• Implement strict allowlists for dynamic attribute names where user input is involved, rather than relying solely on blacklisting unsafe characters.

Because Node.js utilizes a shared pool for Buffer memory, this vulnerability allows for the leakage of up to 64 KB of unrelated process memory into serialized output. In the context of Server-Side Rendering (SSR) frameworks such as SvelteKit or Nuxt, this behavior can be exploited by an unauthenticated party to extract sensitive data belonging to other users. This includes bytes from concurrent requests, such as HTTP request bodies or Authorization headers, which are subsequently embedded into server-rendered HTML. Unlike other vulnerabilities in the library, this issue occurs during serialization and is not mitigated by existing prototype pollution or Denial of Service guards, potentially impacting every SSR render involving Buffer objects.

Impact

The vulnerability poses a severe risk of data exfiltration in web applications utilizing 'devalue' for server-side state serialization. By repeatedly triggering server-side renders that include small Buffers, an attacker can harvest sensitive data from the application's process memory. This exposure includes authentication tokens, user-specific request data, and other sensitive information from concurrent traffic. Successful exploitation leads to unauthorized data access and potential account takeover or business logic compromise.

Recommendation

Prioritize remediation for all applications using 'devalue' for SSR state handling.

• Upgrade to a version of 'devalue' that addresses the memory serialization behavior.
• If an immediate upgrade is unavailable, manually convert all Node.js Buffer objects to Uint8Array instances before passing them to 'devalue.stringify()' or 'devalue.uneval()' as a temporary mitigation.
• Audit SSR logic in SvelteKit and Nuxt applications to identify instances where Buffer objects are included in serialized state.