Loading vulnerability…
CVE-2026-72844 is a type confusion vulnerability in the Lean 4 kernel that breaks the soundness of the proof system. The flaw has two related causes: the kernel does not verify that the structure named in a projection expression matches the actual type of the value being projected, and environment::add_inductive in src/kernel/inductive.cpp failed to type check nested inductive applications that were replaced by auxiliary types, allowing their parametric arguments to escape validation. An attacker-controlled metaprogram running inside the Lean process can exploit these weaknesses to register an ill-typed nested inductive whose constructor applies a projection for one structure type to a value of an unrelated type. The malformed declaration is accepted through the normal checked declaration path even with maximum kernel checking enabled and without relying on sorry, unsafeCast, debug.skipKernelTC, unchecked declaration APIs, foreign-function interfaces, or tampered compiled artifacts. Successful exploitation yields a proof of False with no axioms, from which arbitrary propositions can be derived.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
This seven-file repository is a containerized local proof-of-concept for CVE-2026-72844, a Lean 4 kernel soundness flaw. Its main artifact, `ZeroEqOne.lean`, imports Lean metaprogramming APIs and uses the ordinary checked `addDecl` interface rather than unsafe casts, FFI, altered `.olean` files, or reduced kernel trust. It relies on a hard-coded collision between the hashes of padded `Bool.false` and `Bool.true` expressions, then constructs an inductive declaration containing projections labelled as structure `C` while operating on a value of unrelated inductive type `W`. The claimed validation bypass permits the malformed declaration and creates a type confusion between `E` applications. The proof subsequently obtains an impossible `T false`, pattern-matches it into `False`, and derives `0 = 1`. `verify.sh` is the operational entry point: it invokes `lean --trust=0 ZeroEqOne.lean`, checks output from `#print axioms`, distinguishes kernel rejection from a successful PoC, and optionally replays the result with `leanchecker` when installed. `lean-toolchain` pins v4.31.0, while `lakefile.lean` defines a minimal Lake library. The Dockerfile installs elan from GitHub, installs the pinned toolchain, copies the source, and runs the verifier; the Makefile wraps image build/run/cleanup. The repository has no remote target service, reverse shell, persistence mechanism, or network exploitation behavior beyond fetching elan/toolchain dependencies during build.
No public activity tracked yet. Mallory keeps watching.
No public activity observed for this vulnerability.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.