GHSA-X7MM-9VVV-64W8: Reflected Cross-Site Scripting in unhead Streaming SSR

The unhead library provides document head management for server-side rendered (SSR) JavaScript applications. The streaming SSR implementation synchronizes state between the server environment and the client browser during hydration. This synchronization relies on a developer-configurable identifier known as the streamKey.

GHSA-X7MM-9VVV-64W8 tracks a Cross-Site Scripting (XSS) vulnerability classified under CWE-79: Improper Neutralization of Input During Web Page Generation. The flaw resides in the specific sub-packages responsible for handling streaming SSR, such as @unhead/ssr.

When the streamKey parameter is derived from untrusted input, the application fails to sanitize or validate the string before interpolating it into an inline script tag. The resulting output is rendered directly into the HTML document, permitting unauthenticated attackers to execute arbitrary JavaScript in the context of the user's browser session.

The vulnerability originates from unsafe string interpolation within the createBootstrapScript function. This function generates a bootstrapping script payload required for the client-side hydration process. The script initializes an array on the global window object using the streamKey variable as the property name.

In the vulnerable implementation, the streamKey string is directly appended to the window. object reference without prior lexical validation. The system implicitly trusts that the provided string strictly conforms to valid JavaScript identifier naming conventions.

If the streamKey configuration relies on dynamically parsed query parameters or multi-tenant headers without intermediary sanitization, an attacker gains direct control over the injected string. The JavaScript parser evaluates the raw input as code, breaking the intended dot-notation assignment and allowing execution of contiguous JavaScript expressions.

The flaw manifests in packages/unhead/src/stream/server.ts. The original createBootstrapScript function utilized standard template literals to construct the payload.

// Vulnerable implementation example
export function createBootstrapScript(streamKey: string = DEFAULT_STREAM_KEY): string {
  return `<script>window.${streamKey}={_q:[],push(e){this._q.push(e)}}</script>`
}

The remediation, introduced in commit 64b5ac0aa30cc256ea6677ce3dc4f132f81b2ff6, implements strict input validation. The fix introduces a regular expression, VALID_STREAM_KEY_RE, which restricts the streamKey to standard ASCII JavaScript identifiers.

// Patched implementation with validation
const VALID_STREAM_KEY_RE = /^[$_a-z][$\w]*$/i
 
function assertValidStreamKey(streamKey: string): void {
  if (typeof streamKey !== 'string' || !VALID_STREAM_KEY_RE.test(streamKey)) {
    throw new Error(
      `[unhead] Invalid streamKey: must be a valid JavaScript identifier...`
    )
  }
}

The developers injected the assertValidStreamKey validation routine at three distinct lifecycle junctions. The system now validates the key upon entry in createStreamableHead, upon retrieval via getStreamKey, and immediately before code generation in createBootstrapScript. This layered defense strategy prevents malicious payloads from advancing to the rendering stage.

Exploitation requires the attacker to influence the streamKey variable passed to the server-side rendering logic. This precondition is met if an application routes unvalidated request parameters, such as a user-controlled subdomain or URL query string, directly into the unhead configuration object.

An attacker constructs a payload that properly terminates the intended JavaScript statement before initiating an arbitrary function call. A standard proof-of-concept payload utilizes a semicolon to separate expressions, followed by the malicious code and a trailing comment indicator.

Payload structure: __unhead__;alert(1)//

When the SSR engine processes this input, it generates the following HTML output:

<script>window.__unhead__;alert(1)//={_q:[],push(e){this._q.push(e)}}</script>

The browser's JavaScript engine evaluates the first expression, window.__unhead__;, which functions as a valid property access. It subsequently executes the injected function call alert(1). The trailing // converts the remainder of the original bootstrapping template into a comment, circumventing syntax errors that would otherwise halt script execution.

Successful exploitation results in Reflected Cross-Site Scripting. Because the injected script executes within the context of the vulnerable application's origin, the attacker inherits the permission scope of the victim's browser session.

The execution allows an attacker to access sensitive DOM elements, extract authentication tokens stored in localStorage or sessionStorage, and hijack active user sessions. Furthermore, the attacker can silently issue unauthorized HTTP requests on behalf of the authenticated user to restricted internal application programming interfaces.

The vulnerability primarily affects end users accessing the compromised uniform resource locator. Administrative users interacting with the malicious link face higher exposure, as session compromise in elevated contexts facilitates broader administrative control over the application infrastructure.

The primary remediation strategy requires upgrading the unhead dependency to a version encompassing commit 64b5ac0aa30cc256ea6677ce3dc4f132f81b2ff6. The patch natively rejects any dynamically generated streamKey that contains non-alphanumeric or special characters outside the bounds of the VALID_STREAM_KEY_RE regular expression.

If an immediate dependency upgrade is administratively unfeasible, security engineers must implement input sanitization upstream of the unhead configuration instantiation. All request-derived data mapped to the streamKey parameter must undergo strict validation enforcing an allow-list of known-good identifiers.

Network defense teams can deploy web application firewall rules configured to monitor for anomalous identifier patterns. Specifically, rules targeting the presence of semicolons, parentheses, or comment structures within parameters destined for SSR state hydration endpoints will effectively interrupt exploitation attempts.