Zero Radar
← feed
HighVulnerabilityCVE-2026-72844updated 26 Oct 2026, 02:23 UTC

Lean 4 proof checker can be tricked into accepting false proofs

The Lean 4 system is used to check that mathematical or software proofs are correct. A flaw lets a crafted program make the checker accept a bogus proof, including one that claims 0 = 1, so a "verified" result cannot be trusted.

Official, 3 sources
SeverityHighCVSS 6.8 of 10
Being exploited?UnclearNo reports either way yet
Fix available?UnclearNo fixed version published in the sources yet
How sure is this?Official, 3 sourcesBacked by an official source

How the attack works simplified

  1. 1Malicious dependencyLake package with a crafted metaprogram
  2. 2Project buildMetaprogram runs inside the Lean process
  3. 3Ill-typed declarationNested inductive admitted without type checking
  4. 4Kernel accepts proofType confusion yields a proof of False
  5. ResultFalse proofs pass verification

What happened

The Lean 4 kernel does not verify that the structure named in a projection matches the type of the value projected, and nested inductive declarations are admitted without type checking, enabling a type confusion that yields a proof of False with no axioms.

Why it is dangerous: Any proof checked by the affected Lean kernel may be false, undermining formal verification of software or mathematics; attackers running code in the Lean process could also use this to hide malicious content in trusted proof dependencies.

Are you affected?

You are affected if you run Lean 4 builds or import Lake dependencies that execute metaprograms in-process, since exploitation requires running a metaprogram inside the Lean process.

Lean 4 kernel (versions not stated in the provided material).

What to do

  1. Check the Lean 4 advisory GHSA-4fhc-8rq3-cjvg for a fixed release and update when available
  2. Only build or import Lake dependencies from sources you trust, since they can run metaprograms
  3. Do not rely on Lean-verified proofs for high-stakes conclusions until the fix is applied

Timeline

  1. 20 Aug 2026, 18:16 UTC
    Publicly disclosed
  2. 26 Oct 2026, 00:12 UTC
    Reported by oss-security · oss-security
  3. 26 Oct 2026, 00:15 UTC
    Picked up by Zero Radar
  4. 26 Oct 2026, 00:16 UTC
    Reported by oss-security · oss-security
  5. 26 Oct 2026, 00:20 UTC
    Reported by oss-security · oss-security
  6. 26 Oct 2026, 00:37 UTC
    GitHub Advisory reported on it · GitHub Advisory
  7. 26 Oct 2026, 02:23 UTC
    NVD reported on it · NVD

Sources 5 reports, oldest first

Official vendor, government CERT or advisory database

Security researchers research teams and mailing lists

Technical details

ID
CVE-2026-72844 · GHSA-4fhc-8rq3-cjvg
CVSS
6.8 / 10
EPSS
0.2% chance of exploitation within 30 days
Disclosed
20 Aug 2026, 18:16 UTC
On Zero Radar
26 Oct 2026, 00:15 UTC (66 days after disclosure)
Last change
26 Oct 2026, 02:23 UTC

The plain-language parts and the attack diagram were written by an AI model (anthropic/claude-haiku-5.5) from the sources above. Facts like versions, exploitation and dates come from the sources themselves. How Zero Radar works

Lean 4 proof checker can be tricked into accepting false proofs · Zero Radar