CVE-2026-41197: Brillig: Heap corruption in foreign call results with nested tuple arrays

Should you act?

Critical and remotely reachable

No known exploitation yet, but it is network-reachable without credentials. This signal is computed from CISA KEV, EPSS and CVSS data; it is not an editorial verdict.

• No confirmed exploitation. It is not in CISA’s KEV catalog and CISA’s SSVC assessment records no known exploitation. That can change quickly after a public write-up; re-check if you are affected.
• EPSS 0.5%, percentile 41: FIRST’s model estimates a 0.5% chance of exploitation activity in the next 30 days, higher than 41% of all scored CVEs (low). EPSS is a probability, not a verdict.
• Remotely reachable with no login and no user interaction. If the vulnerable service is exposed to the internet, prioritize it.
• Only applies if your dependency tree includes brillig (crates.io (Rust)) <= 1.0.0-beta.18, fixed in 1.0.0-beta.19. Check your lockfile, including transitive dependencies.

What it is

Noir is a Domain Specific Language for SNARK proving systems that is designed to use any ACIR compatible proving system, and Brillig is the bytecode ACIR uses for non-determinism. Noir programs can invoke external functions through foreign calls. When compiling to Brillig bytecode, the SSA instructions are processed block-by-block in BrilligBlock::compileblock(). When the compiler encounters an Instruction::Call with a Value::ForeignFunction target, it invokes codegencall() in brilligcall/codegencall.rs, which dispatches to convertssaforeigncall(). Before emitting the foreign call opcode, the compiler must pre-allocate memory for any array results the call will return. This happens through allocateexternalcallresults(), which iterates over the result types. For Type::Array results, it delegates to allocateforeigncallresultarray() to recursively allocate memory on the heap for nested arrays. The BrilligArray struct is the internal representation of a Noir array in Brillig IR. Its size field represents the semi-flattened size, the total number of memory slots the array occupies, accounting for the fact that composite types like tuples consume multiple slots per element. This size is computed by computearraylength() in brilligblockvariables.rs. For the outer array, allocateexternalcallresults() correctly uses definevariable(), which internally calls allocatevaluewithtype(). This function applies the formula above, producing the correct semi-flattened size. However, for nested arrays, allocateforeigncallresultarray() contains a bug. The pattern Type::Array(, nestedsize) discards the inner types with and uses only nestedsize, the semantic length of the nested array (the number of logical elements), not the semi-flattened size. For simple element types this works correctly, but for composite element types it under-allocates. Foreign calls returning nested arrays of tuples or other composite types corrupt the Brillig VM heap. Version 1.0.0-beta.19 fixes this issue.

From the GitHub advisory

Description

Noir programs can invoke external functions through foreign calls. When compiling to Brillig bytecode, the SSA instructions are processed block-by-block in BrilligBlock::compileblock(). When the compiler encounters an Instruction::Call with a Value::ForeignFunction target, it invokes codegencall() in brilligcall/codegencall.rs, which dispatches to convertssaforeigncall().

Before emitting the foreign call opcode, the compiler must pre-allocate memory for any array results the call will return. This happens through allocateexternalcallresults(), which iterates over the result types. For Type::Array results, it delegates to allocateforeigncallresultarray() to recursively allocate memory on the heap for nested arrays.

The BrilligArray struct is the internal representation of a Noir array in Brillig IR. Its size field represents the semi-flattened size, the total number of memory slots the array occupies, accounting for the fact that composite types like tuples consume multiple slots per element. This size is computed by computearraylength() in brilligblockvariables.rs:

For the outer array, allocateexternalcallresults() correctly uses definevariable(), which internally calls allocatevaluewithtype(). This function applies the formula above, producing the correct semi-flattened size.

Weakness type: CWE-131.

Product: brillig (crates.io (Rust)) · Assigned by: GitHub_M · Published: 2026-04-23

Affected and fixed versions

Severity scores

• Attack vector: network (remotely reachable)
• Attack complexity: low
• Attack requirements: none
• Privileges required: none (no login)
• User interaction: none

CVSS measures how bad a flaw is if exploited, not how likely exploitation is. Read it next to the exploitation data below.

Exploitation and urgency

• CISA KEV: not listed (no confirmed in-the-wild exploitation known to CISA).
• CISA SSVC assessment: exploitation none, automatable yes, technical impact total.
• FIRST EPSS (model of 2026-10-21): 0.49% probability of exploitation activity in the next 30 days; percentile 41.

Timeline

• 2026-04-21 — GitHub-reviewed advisory GHSA-jj7c-x25r-r8r3 published (critical)
• 2026-04-23 — CVE record published by GitHub_M
• 2026-04-25 — CVE record last updated

Sources and references

Original sources first. Version and fix details should always be confirmed against the vendor or project advisory.

Vulnerability records

1. GitHub Advisory GHSA-jj7c-x25r-r8r3 github.com
2. CVE.org record CVE-2026-41197 cve.org
3. NVD entry CVE-2026-41197 nvd.nist.gov

Other references from the CVE record and advisory

1. github.com github.com
2. github.com github.com

Critical crates.io (Rust) advisories · Today’s Security Digest