A2UI CVE-2026-10032: AI-generated buttons need safe actions

A GitHub Advisory Database entry updated on 2 October describes CVE-2026-10032 in @a2ui/web_core. Its affected range starts at 0.9.0 and ends before 0.10.2. The project’s advisory was already published in August; the database update does not mean the vulnerability was discovered in October.

A2UI’s maintainers explain that an agent-controlled address reached openUrl without URI scheme validation. They describe JavaScript execution in the application’s browser context after a user clicks the generated button. A fix is available from 0.10.2, restricting the action to valid HTTP or HTTPS addresses.

Who needs to assess exposure

The relevant teams are those whose applications use this package to render an interface and handle agent actions. Using a language model or AI chat alone does not establish that the vulnerable component is present. The application owner should identify the version actually delivered to browsers, including indirect dependencies and previously built assets.

Breachroad’s conclusion is that a button’s label and the action it performs need separate assessment. “Open document” may look familiar, but it does not establish that the action data is safe. The application must enforce its rules before executing a function selected by the agent.

Applying the fix

The A2UI repository change provides evidence of remediation. We recommend moving to a supported version containing the fix, then rebuilding and deploying the application. Editing a dependency file does not automatically update assets already served to users by the server or CDN.

Review the point where an address is interpreted. Establishing that a value is a string does not validate its scheme or recipient. Custom catalog functions also need review: fixing one action does not demonstrate that every extension is secure.

Training example: opening an invoice

Consider our fictional scenario. An assistant offers a “Review invoice” button in a company portal. The employee sees a plausible label, while the application separately receives an address and action type. A safe process validates those fields against its own policy, instead of treating fluent wording as proof of trust.

Alongside the CVE fix, an organisation can restrict document links to approved domains, limit transmitted parameters and retain independent authorisation for financial operations. These are our proposed business controls. An HTTPS address alone does not establish that the recipient is appropriate or that the user should share data with it.

Four decisions for the team

1. Ownership: name the person responsible for the rendering package and action catalog. The model provider does not automatically own the browser implementation.
2. Scope: inventory actions that open addresses, transmit information or change state. Define a separate policy for each.
3. Verification: in a controlled environment, confirm that disallowed schemes and invalid addresses are rejected without executing an action. Use test data.
4. Reporting: record the action identifier and validation outcome. Support staff should know how to report a suspicious button without copying a confidential document into the ticket.

Employees should practise pausing when an assistant’s action is unexpected. They should not be expected to recognise a button’s hidden implementation. Enforcing that boundary is the application’s responsibility.

Cybersecurity and secure-AI training helps teams rehearse the division of responsibility between employees, IT and process owners. Our guide to AI agent sandbox architecture explains broader execution boundaries.

Facts and our conclusions

Version scope and the CVE mechanism come from A2UI and GitHub advisories; the repository provides the implementation change. The invoice scenario, ownership model and proposed controls are Breachroad’s work. A vulnerability description does not establish an incident in a particular organisation. We checked the sources on 4 October 2026.