CVE-2026-41197 — brillig
CVE-2026-41197 is a CWE-131 vulnerability in brillig. A fix is available for brillig — see the affected versions and patch details below.
Brillig: Heap corruption in foreign call results with nested tuple arrays
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-41197.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
brilligReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | brillig | all versions | 1.0.0-beta.19cargo update -p brillig --precise 1.0.0-beta.19 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for brillig, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update brillig to 1.0.0-beta.19 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-41197 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-41197 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-41197. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-41197 in your dependencies?
O3 Security finds CVE-2026-41197 across crates.io dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.