Patches critical heap corruption in Noir Brillig foreign calls

TL;DR — A critical buffer-size miscalculation in Noir’s Brillig codegen for foreign-call results can under-allocate nested tuple arrays, corrupting the Brillig VM heap and enabling high-impact exploitation.

What happened

Noir is a domain-specific language for SNARK proving systems, and Brillig is the bytecode ACIR uses for non-determinism.

CVE-2026-41197 describes a Critical (CVSS v4.0 9.3) heap corruption bug in the Brillig compilation path for Noir foreign calls. When the compiler pre-allocates memory for array results returned by a foreign call, nested arrays can be allocated using the semantic element count rather than the semi-flattened size needed for composite element types (e.g., tuples). The result is under-allocation and heap corruption in the Brillig VM when foreign calls return nested arrays of tuples or other composite types.

This is the failure mode platform teams should treat as high-risk in any pipeline that compiles or executes untrusted Noir programs (multi-tenant proving services, hosted tooling, CI validation of third-party circuits): memory corruption primitives in language toolchains routinely become exploit building blocks, not “just crashes.”

Who is impacted

• Any environment using noir-lang/noir where untrusted Noir code can reach compilation to Brillig bytecode.
• The CVE record lists affected versions as < 1.0.0-beta.19.

What to do now

• Follow vendor remediation guidance and apply a release that includes the fix.

  "Version 1.0.0-beta.19 fixes this issue."

• Inventory where noir is used (developer workstations, CI runners, build containers, proving services) and identify any deployments running an affected version range.
• If you run a service that accepts third-party Noir code, treat this as a sandbox boundary issue: reduce exposure by isolating the compilation/execution runtime and reviewing controls around who can submit code for compilation.