CVE-2026-41197
Received Received - Intake
Heap Corruption in Noir Brillig VM via Nested Array Allocation Bug

Publication date: 2026-04-23

Last updated on: 2026-04-23

Assigner: GitHub, Inc.

Description
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::compile_block()`. When the compiler encounters an `Instruction::Call` with a `Value::ForeignFunction` target, it invokes `codegen_call()` in `brillig_call/code_gen_call.rs`, which dispatches to `convert_ssa_foreign_call()`. Before emitting the foreign call opcode, the compiler must pre-allocate memory for any array results the call will return. This happens through `allocate_external_call_results()`, which iterates over the result types. For `Type::Array` results, it delegates to `allocate_foreign_call_result_array()` 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 `compute_array_length()` in `brillig_block_variables.rs`. For the outer array, `allocate_external_call_results()` correctly uses `define_variable()`, which internally calls `allocate_value_with_type()`. This function applies the formula above, producing the correct semi-flattened size. However, for nested arrays, `allocate_foreign_call_result_array()` contains a bug. The pattern `Type::Array(_, nested_size)` discards the inner types with `_` and uses only `nested_size`, 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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-04-23
Last Modified
2026-04-23
Generated
2026-05-07
AI Q&A
2026-04-23
EPSS Evaluated
2026-05-05
NVD
CVE-2026-41197
Affected Vendors & Products
Showing 2 associated CPEs
Vendor Product Version / Range
noir-lang noir to 1.0.0-beta.18 (inc)
noir-lang noir 1.0.0-beta.19
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-131 The product does not correctly calculate the size to be used when allocating a buffer, which could lead to a buffer overflow.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2026-41197 is a critical heap corruption vulnerability in the Noir programming language's compiler related to foreign calls returning nested arrays of composite types such as tuples.

Noir programs invoke external functions via foreign calls, which are compiled into Brillig bytecode. During compilation, the compiler pre-allocates memory for array results returned by these foreign calls.

For nested arrays, the compiler incorrectly calculates the memory size needed by using only the semantic length (number of logical elements) instead of the semi-flattened size (which accounts for composite types consuming multiple memory slots).

This under-allocation causes the Brillig virtual machine heap to be corrupted when the foreign call writes more data than allocated, leading to potential undefined behavior or security issues.

The issue is fixed in Noir version 1.0.0-beta.19.


How can this vulnerability impact me? :

This vulnerability can cause heap corruption in the Brillig virtual machine when executing foreign calls that return nested arrays of composite types.

Heap corruption can lead to undefined behavior, including crashes, data corruption, or potential security vulnerabilities such as arbitrary code execution or denial of service.

If your Noir programs use foreign calls returning nested arrays of tuples or other composite types, you are at risk of these impacts unless you upgrade to the fixed version.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability is related to the Noir compiler's handling of foreign calls returning nested arrays of composite types, causing heap corruption during compilation and execution of Brillig bytecode. Detection involves identifying usage of affected Noir compiler versions (up to and including 1.0.0-beta.18) and observing any abnormal behavior or crashes related to foreign calls returning nested tuple arrays.

Since this is a compiler and runtime vulnerability rather than a network-based exploit, detection on a network level is not applicable. Instead, detection should focus on verifying the Noir compiler version in use and analyzing compiled programs that invoke foreign calls returning nested arrays.

Suggested commands to detect the vulnerable version on your system include checking the Noir compiler version:

  • nargo --version

If the version is 1.0.0-beta.18 or earlier, the system is vulnerable.

Additionally, reviewing compilation logs or runtime errors for heap corruption or crashes related to foreign calls returning nested arrays may help identify exploitation or manifestation of the vulnerability.


What immediate steps should I take to mitigate this vulnerability?

The primary mitigation step is to upgrade the Noir compiler to version 1.0.0-beta.19 or later, where this heap corruption issue has been fixed.

Avoid using affected versions (up to and including 1.0.0-beta.18) for compiling programs that invoke foreign calls returning nested arrays of composite types.

If upgrading immediately is not possible, review and modify Noir programs to avoid foreign calls that return nested arrays of tuples or other composite types, as these trigger the vulnerability.

Monitor runtime behavior for signs of heap corruption or crashes and apply defensive programming practices to minimize impact.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

The provided information does not specify any direct impact of this vulnerability on compliance with common standards and regulations such as GDPR or HIPAA.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart