CVE-2026-72711

Executive Summary

CVE-2026-72711 is an improper input validation flaw (CWE-20) in the Lean 4 theorem prover kernel that allows an attacker to introduce an opaque constant of type False into the logic environment. This is achieved by exploiting the kernel's failure to verify that the body of an opaque declaration is closed (i.e., contains no free variables), enabling proof of arbitrary propositions without using sorry, unsafeCast, or any other soundness-limiting features. The flaw affects all Lean 4 versions prior to 4.32.2 and carries a CVSS score of 6.3 under vector CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:N, reflecting a high integrity impact with no confidentiality or availability impact.

The vulnerability requires local access and user interaction, and while the absolute risk to enterprise infrastructure is moderate, the implications for any organization relying on Lean 4 for formal verification of critical software are severe: the mathematical soundness guarantee of the prover is completely undermined. The proof kernel — trusted to certify that software satisfies its specification — can be tricked into accepting a false axiom, rendering any downstream certification meaningless. There are currently no public exploits, no known in-the-wild attacks, and no active patch for this vulnerability other than the fix present in version 4.32.2.

Technical Analysis

The Lean 4 proof assistant uses a trusted kernel that validates all declarations before they are added to the environment. The kernel is designed to ensure that every accepted declaration is both well-typed and logically sound — no proposition can be admitted unless it is genuinely provable from the axioms and definitions present.

The vulnerability resides in the environment::add_opaque path. According to the NVD description, this path omits the check_no_metavar_no_fvar call that the definition and theorem paths routinely perform. This check is designed to reject any value that contains a metavariable or a free variable that is not bound in the local context. Its absence means that a value containing an unbound free variable is not rejected at submission time.

The attack exploits a combination of kernel features:

1. Type Checker Inference Cache: The Lean type checker maintains an inference cache that maps certain values to their inferred types. This cache persists on the type checker instance across context changes.
2. Local Context Manipulation: A metaprogram (user-level code running within Lean's metaprogramming framework) can cause the kernel to create a temporary local variable of type False and record its type in the inference cache. The metaprogram then manipulates the type checker's local context such that the context is restored to its original state, but the cache entry persists.
3. Opaque Declaration Submission: The metaprogram finally submits an opaque declaration whose value is the now-unbound variable. When the kernel processes this declaration, the cache lookup answers before the branch that would test membership of the local context. The kernel looks up the cached type (which is False), and does not reach the context-membership check that would raise an error about the unbound variable.

The result is that the kernel admits an opaque constant of type False. In logic systems like Lean, from a proof of False (the empty type), any proposition follows via the principle of explosion (ex falso quodlibet). Thus, the attacker can prove any theorem they desire, and the result carries no axioms — it appears as though the theorem was proved legitimately from the kernel's perspective.

Critically, the NVD description states the declaration is accepted "through the ordinary checked path at maximum kernel checking, without sorry, unsafeCast, debug.skipKernelTC, addDeclWithoutChecking, foreign code or a modified .olean file." This means no unsoundness flags or trust reductions are triggered — the declaration is indistinguishable from a sound one.

The vulnerability is fixed in Lean 4.32.2 by adding the missing closure check (i.e., the check_no_metavar_no_fvar equivalent) to the add_opaque code path.

Exploitation Scenarios

No public PoC or exploit code is available for this vulnerability. The attack chain described below is inferred from the NVD description and the vulnerability class (kernel soundness violation via incomplete input validation). Specific function names or code patterns should not be extrapolated beyond what is provided.

Stage 1: Target Identification and Reconnaissance

The target is any environment where Lean 4 is used for formal verification. The attacker would need to identify:

• Organizations that use Lean 4 for theorem proving on critical software (e.g., cryptographic protocols, smart contracts, OS kernels, compiler correctness, verified network stacks).
• The specific Lean version in use — versions prior to 4.32.2 are vulnerable.
• The ability to deliver a malicious Lean development project or library to the target. This could be via a compromised package repository (Lean does not have a single official package manager but uses Lake, built-in package manager; packages are often distributed via Git repositories), a malicious pull request, or a social engineering campaign where developers are convinced to import a malicious package.

Given that the CVSS vector indicates PR:N/UI:R (no privileges required, user interaction required), the attacker requires the target user to execute or import the malicious Lean code. This is a typical "malicious untrusted code" scenario — the kind that is inherent to using libraries from third parties.

Stage 2: Triggering the Vulnerability Mechanism

The attacker constructs a Lean metaprogram that performs the following sequence (at the vulnerability-class level):

1. Cache poisoning: The metaprogram issues an elaboration that causes the type checker to create a local variable (a LocalDecl) with type False. The type checker records the mapping between this local variable and False in its inference cache. Typically, this would involve elaborating an expression that references a local of type False in a way that gets cached.

2. Context restoration: The metaprogram restores the original local context (e.g., by entering and exiting a new scope or by using metaprogramming context manipulation), while the inference cache entry persists on the same type checker instance.

3. Opaque declaration: The metaprogram calls the environment's add_opaque-equivalent function (the function name from the NVD description is environment::add_opaque, which suggests a C++ or Lean implementation detail; in the description it is cited verbatim) to add a new opaque declaration whose value is an expression containing the now-unbound local variable. Because the local context no longer contains this variable, it is a free variable.

4. Kernel acceptance: When the kernel processes the opaque declaration, it performs type inference on the value. The inference cache lookup returns the cached type False before any context-membership check occurs (the check that would normally be performed by check_no_metavar_no_fvar is missing from this code path). The kernel accepts the declaration as an opaque constant of type False.

Stage 3: Payload and Execution

Once the foundational false constant is in place, the attacker's malicious package proceeds to:

• Derive arbitrary propositions from False via the principle of explosion.
• Define fake theorems that appear to prove correctness properties about target software — e.g., a theorem asserting that an insecure function is memory-safe, that a cryptographic primitive is secure, or that a protocol satisfies a safety invariant.
• Because the false constant carries no axioms (the declaration is axiom-free), these fabricated theorems are indistinguishable from genuinely proven theorems when exported to .olean files or consumed by downstream tools.

Stage 4: Post-Exploitation Impact

The post-exploitation impact is a complete and silent breakdown of the verification guarantees provided by the Lean kernel in the affected environment. Any software artifact "verified" using the compromised Lean environment may contain critical vulnerabilities while being certified as safe. This is particularly dangerous in:

• High-assurance software supply chains that depend on formal verification as a last line of defense.
• Cryptographic protocol verification where security properties (e.g., secrecy, authenticity) are machine-checked.
• Compiler and interpreter correctness projects.

The attacker can also poison the ecosystem: a malicious package that derives false theorems could be published and used by other developers, propagating the false proofs across many projects.

Impact Assessment

CVSS Analysis (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:N):

• Attack Vector: Local (L) — The attacker must have local access to the system running Lean, either through direct access or by convincing a user to load a malicious file.
• Attack Complexity: Low (L) — The conditions to trigger the flaw are deterministic; no race conditions or complex state management are needed beyond metaprogram execution.
• Privileges Required: None (N) — No special privileges are needed; any user who can run Lean can trigger the vulnerability.
• User Interaction: Required (R) — The target user must open/import the malicious Lean file or package.
• Scope: Changed (S) — The compromised kernel's output (theorems, .olean files, exported proofs) is used in a different security context than the vulnerable component (the kernel trust domain).
• Integrity: High (I:H) — The core integrity guarantee of the verification system is broken. The attacker can prove any proposition, and the proof carries no axiom markers.
• Confidentiality: None (C:N) and Availability: None (A:N) — The vulnerability does not directly expose data or cause denial of service.

Business Impact:

• Trust erosion in the verification pipeline: Organizations using Lean 4 for any kind of formal certification (safety-critical avionics, automotive, blockchain, verified crypto) cannot trust outputs generated with vulnerable versions.
• Supply chain pollution: Malicious Lean packages can poison the ecosystem; downstream consumers inherit false theorems.
• Audit and compliance failure: Any standards that mandate formal verification (e.g., DO-178C, Common Criteria EAL7, high-assurance crypto standards) would not be satisfiable with untrusted proof artifacts.

Blast Radius: Any project that imports or consumes .olean files, Lean libraries, or package versions built with Lean < 4.32.2. This includes all downstream users of any affected library.

Detection Guidance

Sigma Rule

title: Suspicious Lean 4 Opaque Declaration with False Type
id: 9e7f2c1a-4d23-4b89-a10e-2f4d0e4f0e12
status: experimental
description: Detects Lean 4 metaprogramming or build activity that submits opaque declarations with cached false types, indicating CVE-2026-72711 exploitation.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2026-72711
author: Valtersit Threat Intelligence
date: 2026/04/01
logsource:
    category: process_creation
    product: linux
detection:
    selection_lake_build:
        Image|endswith:
            - '\lake'
            - '\lean'
        CommandLine|contains|all:
            - 'build'
            - 'opaque'
    selection_opaque_decl:
        CommandLine|contains:
            - 'add_opaque'
            - 'opaque'
        CommandLine|contains|all:
            - 'False'
            - 'decl'
    condition: selection_lake_build or selection_opaque_decl
    timeframe: 5m
level: high
falsepositives:
    - Legitimate opaque declarations used for abstraction (rare in practice; opaque declarations are an advanced feature).
    - Metaprogramming development activities where opaque declarations are deliberately used for known abstractions.
tags:
    - attack.t1204
    - cve.2026.72711
    - cwe.20

YARA Rule

rule Lean4_Opaque_False_Exploit_CVE_2026_72711
{
    meta:
        author = "Valtersit Threat Intelligence"
        description = "Detects Lean 4 source code or .olean artifacts containing malicious opaque declarations with False type"
        cve = "CVE-2026-72711"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-72711"
        date = "2026-04-01"
    strings:
        $decl = /opaque\s+\w+\s*:\s*(False|false)/ nocase
        $meta = /elab\s+\w+\s*:\s*Term|runElab|evalExpr/ nocase
        $cache_trick = /LocalContext|Cache|addAndCompile/ nocase
        $explosion = /False\.elim|nomatch\s+(False|-)/ nocase
    condition:
        ($decl and $meta) or ($decl and $cache_trick) or ($decl and $explosion)
}

Suricata IDS Rule

alert tcp any any -> any any (msg:"CVE-2026-72711 - Lean 4 Opaque False Declaration Exploit"; flow:established,to_server; content:"opaque"; http_uri; content:"False"; http_uri; distance:0; content:"add_opaque"; http_uri; distance:0; classtype:attempted-user; sid:202672711; rev:1; reference:cve,2026-72711; metadata:created_at 2026_04_01, updated_at 2026_04_01;)

Note: This rule assumes the malicious Lean package is served over HTTP. Since Lean packages are typically distributed via Git (HTTPS/SSH), network-based detection may be of limited utility. The rule is included for completeness and for scenarios where .olean files or source are fetched from HTTP endpoints.

Elastic Detection

process where process.name in ("lean", "lake") and
  process.args contains "opaque" and
  (
    process.args contains "False" or
    process.args contains "add_opaque" or
    process.command_line contains "build"
  ) and
  not process.parent.executable is null and
  process.exit_code == 0

Splunk SPL Query

index=main sourcetype=process_creation
(process_name="lean" OR process_name="lake")
| search process_command_line="*opaque*" OR process_command_line="*add_opaque*"
| search process_command_line="*False*"
| stats count by host, user, process_command_line, _time
| where count > 1
| sort - _time

Wazuh OSSEC Rule

<group name="lean4,cve-2026-72711,">
  <rule id="100372" level="12">
    <if_sid>571</if_sid>
    <match>opaque</match>
    <match>False</match>
    <match>add_opaque</match>
    <description>CVE-2026-72711: Lean 4 opaque declaration with False type detected — potential kernel soundness bypass</description>
    <group>local_policy_violation,</group>
    <mitre>
      <id>T1204</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 0/4 — UNPATCHED as of reporting date. No patch evidence available from tracked sources. The fix was published in Lean 4.32.2 per the NVD description.

Immediate Mitigations (1–2 days):

1. Upgrade immediately: If your organization uses Lean 4, upgrade to version 4.32.2 or later. This is the only known remediating action. Verify the version in use: lean --version or #print Lean.versionString in a Lean file.
2. Inventory Lean usage: Identify all projects, CI pipelines, Docker images, and build environments that use Lean 4. Create a complete inventory to drive the upgrade effort.
3. Pin package versions: If using Lake or third-party Lean packages, pin versions to known-good releases that depend on Lean ≥ 4.32.2. Do not rely on latest tags without verification.

Patch/Upgrade Steps:

1. Update the Lean toolchain to 4.32.2 via elan (the Lean version manager):

   elan toolchain install 4.32.2
   elan default 4.32.2
   

   Or update the lean-toolchain file in each project to leanprover/lean4:4.32.2.
2. Rebuild all Lean projects and verify successful recompilation.
3. Re-verify all existing proofs: Because the vulnerability allows opaque declarations with false type, all previously accepted opaque declarations in existing code should be audited. Any opaque declaration that contains free variables or references cache-poisoned locals should be re-checked. Export all theorems and run a sanity check by attempting to prove them from axioms only.
4. During the audit, prioritize:
   • Third-party dependecies: If any package was built with a vulnerable Lean version, the .olean artifacts may contain malicious false constants.
   • Opaque declarations: Search all project code for opaque keyword and review each usage.
   • Metaprogramming libraries: Audit any metaprogramming macros or tactics that manipulate local contexts or cache state.
5. If using automated proof-import pipelines, ensure that imported .olean files are constructed with Lean ≥ 4.32.2.

Long-Term Hardening (1–3 months):

1. Formal verification pipeline security: Treat the Lean toolchain as part of the trusted computing base. Use reproducible builds and hash-locked toolchains to prevent tampering.
2. Package provenance: Implement strict package signing and validation for all Lean dependencies. Verify checksums for any Git submodules or Lake dependencies.
3. Kernel-differential testing: If high-assurance verification is mission-critical, consider running proofs through multiple independent checkers (dual-kernel verification) where feasible.
4. Monitor for advisories: Track the Lean repository (github.com/leanprover/lean4) and mailing lists for post-fix advisories, additional CVE disclosures, or research extending the attack.
5. Internal discovery: Run a one-time forensic scan of all existing .olean files and project exports using the Sigma/YARA rules above. Document any hits for incident response.
6. Staff awareness: Ensure developers who use Lean understand the risk of importing untrusted metaprograms and the importance of keeping the toolchain current.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-72711
2. Lean 4 GitHub Repository: https://github.com/leanprover/lean4 — monitor for the 4.32.2 release and security-related commits.
3. Lean 4 Releases / Changelog: https://github.com/leanprover/lean4/releases — verify the 4.32.2 fix entry.
4. Lean Community / Zulip Chat: https://leanprover.zulipchat.com — for community discussions of the kernel fix; may contain researcher notes.
5. CWE-20 Entry: https://cwe.mitre.org/data/definitions/20.html — Improper Input Validation.

Known Threat Actor Campaigns / Exploit-in-the-Wild Evidence:

At the time of this report, there is no evidence of exploitation in the wild, no public PoC, no exploit code, and no threat actor campaign associated with CVE-2026-72711. The CISA KEV catalog has not listed this CVE. The EPSS score has not yet been published by FIRST.org. Continuous monitoring is advised as this class of kernel-soundness vulnerability may attract interest from researchers and supply-chain attack actors.