[FEATURE]: Stopgap for GHSA-mrhx-c7xc-m3w5: depend on zod ^4.6.6 and import from "zod/v3" #4192

• I have searched the existing issues to make sure this feature has not already been requested.

Is your feature request related to a problem? Please describe.

Hi folks, thanks for all the work on A2UI! 👋

We use @a2ui/react and @a2ui/web_core in a shared chat package at our company, and every app that consumes it now gets a high-severity Dependabot alert for GHSA-mrhx-c7xc-m3w5. The advisory covers every zod below 4.6.6, and since 3.25.76 is the last 3.x release, there's no version bump that clears it while A2UI depends on zod: ^3.25.76.

We've read #3610 and #4147 and agree with the assessment there: CVE-2023-54404 was rejected, the GHSA withdrawal is pending (github/advisory-database#10750), and we only use zod for component schemas, so we've dismissed the alert on our side. The friction is that every downstream team has to triage and dismiss it separately, and forcing zod 4 via overrides (as suggested in #4147) isn't quite safe yet while #3812, #3825 and #2753 are open.

We also saw that the long-term direction is abstracting the schema library (#2160), which sounds great. This issue is only about a possible small stopgap until that lands.

Describe the Proposed Solution

zod 4 ships the full zod 3 API under the zod/v3 subpath, so A2UI could:

1. Bump the dependency to "zod": "^4.6.6" (web_core, renderers, catalogs, root resolutions).
2. Change import {z} from 'zod' to import {z} from 'zod/v3', including the generators in web_core/scripts/ that emit import {z} from 'zod'.

The runtime and public API (ComponentApi, FunctionApi, catalog schemas) stay zod 3, so internals like _def.typeName in GenericBinder keep working. [email protected] already accepts zod: ^3.25.28 || ^4 as a peer.

To check whether this holds up, I tried it locally on main (8bf644a), with zod 4.6.7 as the only zod in node_modules:

The diff is 120 files, almost all a single import line, plus the package.json version ranges. I didn't run the Angular, Lit or agent packages, which would need the same import change.

Two caveats worth flagging:

• Consumers need a one-line change too. Catalogs have to build their schemas from zod/v3. When the MCP catalog still imported plain zod (now v4), the React explorer failed with Invalid element at key "accessibility": expected a Zod schema. Updating its imports fixed it. So this would probably need a changelog note.
• Internal constraint. [FEATURE]: Abstract dependency on Zod on web_core. #2160 mentions zod 4 isn't available inside Google yet. This approach needs the zod 4 package installed (even though only the v3 API is used), so it may not work for you right now. Totally understand if so!

Describe Alternatives Considered

• Wait for [FEATURE]: Abstract dependency on Zod on web_core. #2160 / web: Consider making zod a peer dependency. #2002. The better long-term fix; this proposal doesn't conflict with it, since zod/v3 could later become one implementation behind the abstraction.
• Consumers force zod 4 via overrides. Breaks at runtime today (@a2ui/web_core 0.14.0: validation errors throw TypeError under zod 4 (result.error.errors is undefined) #3812, fix(web_core): use error.issues instead of error.errors for Zod 4 compatibility #3825, fix(web_core): make GenericBinder schema classification zod-version-agnostic and fail loudly on unknown internals #2753).
• Dismiss the alert per consumer. What we're doing for now; it works, but it doesn't scale across teams.

Additional Context

Curious to hear whether this direction sounds reasonable to you. Thanks for taking a look! 🙏