Logo
-

Byte Open Security

(ByteOS Network)

Log In

Sign Up

ByteOS

Security
Vulnerability Details
Registries
Custom Views
Weaknesses
Attack Patterns
Filters & Tools
Vulnerability Details :

CVE-2026-41197

Summary
Assigner-GitHub_M
Assigner Org ID-a0819718-46f1-4df5-94e2-005712e83aaa
Published At-23 Apr, 2026 | 00:35
Updated At-25 Apr, 2026 | 03:55
Rejected At-
Credits

Brillig: Heap corruption in foreign call results with nested tuple arrays

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.

Vendors
-
Not available
Products
-
Metrics (CVSS)
VersionBase scoreBase severityVector
Weaknesses
Attack Patterns
Solution/Workaround
References
HyperlinkResource Type
EPSS History
Score
Latest Score
-
N/A
No data available for selected date range
Percentile
Latest Percentile
-
N/A
No data available for selected date range
Stakeholder-Specific Vulnerability Categorization (SSVC)
▼Common Vulnerabilities and Exposures (CVE)
cve.org
Assigner:GitHub_M
Assigner Org ID:a0819718-46f1-4df5-94e2-005712e83aaa
Published At:23 Apr, 2026 | 00:35
Updated At:25 Apr, 2026 | 03:55
Rejected At:
▼CVE Numbering Authority (CNA)
Brillig: Heap corruption in foreign call results with nested tuple arrays

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.

Affected Products
Vendor
noir-lang
Product
noir
Versions
Affected
  • < 1.0.0-beta.19
Problem Types
TypeCWE IDDescription
CWECWE-131CWE-131: Incorrect Calculation of Buffer Size
Type: CWE
CWE ID: CWE-131
Description: CWE-131: Incorrect Calculation of Buffer Size
Metrics
VersionBase scoreBase severityVector
4.09.3CRITICAL
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Version: 4.0
Base score: 9.3
Base severity: CRITICAL
Vector:
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Metrics Other Info
Impacts
CAPEC IDDescription
Solutions

Configurations

Workarounds

Exploits

Credits

Timeline
EventDate
Replaced By

Rejected Reason

References
HyperlinkResource
https://github.com/noir-lang/noir/security/advisories/GHSA-jj7c-x25r-r8r3
x_refsource_CONFIRM
https://github.com/noir-lang/noir/releases/tag/v1.0.0-beta.19
x_refsource_MISC
Hyperlink: https://github.com/noir-lang/noir/security/advisories/GHSA-jj7c-x25r-r8r3
Resource:
x_refsource_CONFIRM
Hyperlink: https://github.com/noir-lang/noir/releases/tag/v1.0.0-beta.19
Resource:
x_refsource_MISC
▼Authorized Data Publishers (ADP)
CISA ADP Vulnrichment
Affected Products
Metrics
VersionBase scoreBase severityVector
Metrics Other Info
Impacts
CAPEC IDDescription
Solutions

Configurations

Workarounds

Exploits

Credits

Timeline
EventDate
Replaced By

Rejected Reason

References
HyperlinkResource
Information is not available yet
▼National Vulnerability Database (NVD)
nvd.nist.gov
Source:security-advisories@github.com
Published At:23 Apr, 2026 | 02:16
Updated At:24 Apr, 2026 | 14:50

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.

CISA Catalog
Date AddedDue DateVulnerability NameRequired Action
N/A
Date Added: N/A
Due Date: N/A
Vulnerability Name: N/A
Required Action: N/A
Metrics
TypeVersionBase scoreBase severityVector
Secondary4.09.3CRITICAL
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Type: Secondary
Version: 4.0
Base score: 9.3
Base severity: CRITICAL
Vector:
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
CPE Matches

Weaknesses
CWE IDTypeSource
CWE-131Primarysecurity-advisories@github.com
CWE ID: CWE-131
Type: Primary
Source: security-advisories@github.com
Evaluator Description

Evaluator Impact

Evaluator Solution

Vendor Statements

References
HyperlinkSourceResource
https://github.com/noir-lang/noir/releases/tag/v1.0.0-beta.19security-advisories@github.com
N/A
https://github.com/noir-lang/noir/security/advisories/GHSA-jj7c-x25r-r8r3security-advisories@github.com
N/A
Hyperlink: https://github.com/noir-lang/noir/releases/tag/v1.0.0-beta.19
Source: security-advisories@github.com
Resource: N/A
Hyperlink: https://github.com/noir-lang/noir/security/advisories/GHSA-jj7c-x25r-r8r3
Source: security-advisories@github.com
Resource: N/A

Change History

0
Information is not available yet

Similar CVEs

1Records found

CVE-2025-66216
Matching Score-4
Assigner-GitHub, Inc.
ShareView Details
Matching Score-4
Assigner-GitHub, Inc.
CVSS Score-9.3||CRITICAL
EPSS-0.11% / 29.74%
||
7 Day CHG~0.00%
Published-29 Nov, 2025 | 01:57
Updated-23 Dec, 2025 | 16:13
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
AIS-catcher has a Buffer Overflow vulnerability in `AIS::Message` leading to DoS/RCE

AIS-catcher is a multi-platform AIS receiver. Prior to version 0.64, a heap buffer overflow vulnerability has been identified in the AIS::Message class of AIS-catcher. This vulnerability allows an attacker to write approximately 1KB of arbitrary data into a 128-byte buffer. This issue has been patched in version 0.64.

Action-Not Available
Vendor-aiscatcherjvde-github
Product-ais-catcherAIS-catcher
CWE ID-CWE-131
Incorrect Calculation of Buffer Size
CWE ID-CWE-787
Out-of-bounds Write
Details not found