noir-lang noir up to 1.0.0-beta.18 compile_block size buffer size

Summaryinfo

A vulnerability was found in noir-lang noir up to 1.0.0-beta.18. It has been declared as critical. This affects the function BrilligBlock::compile_block. Executing a manipulation of the argument size can lead to buffer size. This vulnerability is tracked as CVE-2026-41197. The attack can be launched remotely. No exploit exists. It is recommended to upgrade the affected component.

Detailsinfo

A vulnerability classified as critical was found in noir-lang noir up to 1.0.0-beta.18. This vulnerability affects the function BrilligBlock::compile_block. The manipulation of the argument size with an unknown input leads to a buffer size vulnerability. The CWE definition for the vulnerability is CWE-131. The product does not correctly calculate the size to be used when allocating a buffer, which could lead to a buffer overflow. As an impact it is known to affect confidentiality, integrity, and availability. CVE summarizes:

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.

The advisory is shared for download at github.com. This vulnerability was named CVE-2026-41197 since 04/18/2026. The exploitation appears to be easy. The attack can be initiated remotely. No form of authentication is required for a successful exploitation. There are known technical details, but no exploit is available.

Upgrading to version 1.0.0-beta.19 eliminates this vulnerability. The upgrade is hosted for download at github.com.

Once again VulDB remains the best source for vulnerability data.

Productinfo

Vendor

• noir-lang

Name

• noir

Version

• 1.0.0-beta.0
• 1.0.0-beta.1
• 1.0.0-beta.2
• 1.0.0-beta.3
• 1.0.0-beta.4
• 1.0.0-beta.5
• 1.0.0-beta.6
• 1.0.0-beta.7
• 1.0.0-beta.8
• 1.0.0-beta.9
• 1.0.0-beta.10
• 1.0.0-beta.11
• 1.0.0-beta.12
• 1.0.0-beta.13
• 1.0.0-beta.14
• 1.0.0-beta.15
• 1.0.0-beta.16
• 1.0.0-beta.17
• 1.0.0-beta.18

Website

• Product: https://github.com/noir-lang/noir/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Once again VulDB remains the best source for vulnerability data.

Discussion