al-ice.ai

The Button Was the Payload: CVE-2026-10032 Turns Agent-Rendered UI Into Victim-Origin XSS

AI Vulnerabilities & CVEs by al-ice.ai Editorial

A reviewed GitHub advisory published 2 October 2026 puts a Critical 9.3 at the exact seam where AI agents meet the browser: CVE-2026-10032 (GHSA-72qq-p3r5-f7wq) in @a2ui/web_core, the rendering engine of the open-source A2UI agent-to-UI protocol. Its openUrl function passed an agent-controlled URL directly to window.open() with no URI-scheme validation, so a malicious agent could supply a javascript: URI as the url argument of a Button’s functionCall action — and when the user clicked the rendered button, arbitrary JavaScript executed in the victim application’s origin. Affected: versions >= 0.9.0, < 0.10.2. Fixed in 0.10.2 via a2ui-project/a2ui#1707.

The score deserves a read in full — CVSS 3.1 AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N — because every field tells the agent story: remotely reachable, low complexity, no privileges, one click, and a scope change from agent content into the application’s security origin with full confidentiality and integrity impact.

Six hops from agent JSON to window.open

The advisory documents the complete source-to-sink flow, which is worth following because it shows how many layers saw the URL and none of them objected. The entry point is ButtonApi, which accepts an ActionSchema; the schema permits a functionCall; on click, the generic binder resolves and dispatches the action through the data context; the catalog invoker parses the raw arguments — and the OpenUrlApi Zod schema validates url as z.string() and nothing else. A javascript: URI is a perfectly good string. The sink then runs it unconditionally:

window.open(args.url, '_blank') — no scheme allowlist, no blocklist, at basic_functions.ts:428-430.

Because the flaw lives in web_core’s Basic Catalog, every renderer that rides it is affected: React, Lit and Angular, each cited with its own Button click path. And the advisory stresses the default-configuration point explicitly: no non-default configuration is required; the Basic Catalog is enabled by default. Any app rendering agent-produced A2UI with the stock catalog was exposed.

Why this is an agent-trust bug, not just another XSS

Strip away the agent framing and this is a textbook DOM XSS — unvalidated scheme into a navigation sink. What makes it an agent-security finding is who authors the input. In A2UI’s model the agent generates the UI: the button label, the layout, and the action arguments all arrive as agent output. The threat model therefore includes a compromised, prompt-injected, or outright malicious agent handing a booby-trapped interface to a trusting user inside a trusted origin. The click requirement (UI:R) looks like mitigation until you remember the button says whatever the agent wants it to say — “View invoice,” “Approve refund,” “Open report.”

This is the same seam this site keeps finding from different directions: BragJack rode the boundary between browser components and privileged AI functionality in five browsers, and an MCP Chrome bridge let origins bypass the checks meant to contain browser automation. The agent stack keeps bolting language-model output onto ambient browser authority — navigation, origins, sessions — and each bolt is a new sink for whoever controls the words. Add self-replicating prompt injections that copy hostile instructions into public outputs, and the “malicious agent” in this threat model may itself be an earlier victim.

The two-month visibility gap

Read the advisory dates, not just the severity. The fix was published in the repository on 3 August 2026 and released in web_core 0.10.2 — but the reviewed GitHub advisory only appeared on 2 October. For two months, downstream apps pinned to the 0.9.x line (which the project’s own README still names as the current production family) had a fix available but no reviewed advisory flowing into the dependency feeds — OSV, npm audit, GitLab’s advisory database — that most teams actually monitor. The CVE record and the GitLab advisory entry both trail the fix for the same reason.

This is the disclosure-lag pattern in miniature: the patch exists, the signal doesn’t. Any team whose scanner only watches reviewed advisories spent August and September believing a Critical XSS was business as usual.

What to do now

  • Upgrade @a2ui/web_core to 0.10.2 or later. The fix blocks URLs that don’t use HTTP/HTTPS schemes or that fail parsing. Audit lockfiles for pinned 0.9.x — and remember any custom renderer built on web_core’s basic catalog inherits both the bug and the fix.
  • Treat agent-generated UI as untrusted content, not chrome. Buttons, links and forms the agent composes can carry attacker-chosen arguments. Render them inside the same threat model you’d apply to user-supplied HTML.
  • Allowlist navigation schemes at your own layer too. The upstream fix is scheme-gating in openUrl; defense in depth means your app’s link/button handling enforces http(s)-only independently of the framework version.
  • Watch fixes, not just advisories. This flaw was patchable for two months before the reviewed advisory shipped. For agent-stack dependencies, monitoring upstream releases and security branches catches what advisory feeds haven’t caught up with.
  • Scope the blast radius of agent-rendered pages. A2UI surfaces render inside your origin with your sessions. Serve agent-generated UI from isolated origins, with restrictive CSP, wherever the product allows it.

Our verification was primary-source-led and static. We read the reviewed advisory GHSA-72qq-p3r5-f7wq in full — affected and patched versions, CVSS 3.1 vector and score, the file-and-line-level source-to-sink trace, the per-renderer impact list, the fix reference (PR #1707, commit 7157307) and both publication dates — and cross-checked the CVE-2026-10032 mapping against the GitLab Advisory Database entry. The A2UI protocol description and current-release context are from the a2ui-project/a2ui repository itself. We did not install the package, build a malicious agent message, or attempt exploitation; severity figures and impact statements are the maintainers’ and reviewers’ own.

Sources: