Severity by source
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:N/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
Victim must actively build a metaprogram-bearing project (AV:L, UI:R); attacker needs no target-system privileges (PR:N); impact is integrity-only kernel soundness break (I:H, S:C, C:N, A:N).
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:N/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
Lifecycle Timeline
4DescriptionCVE.org
The Lean 4 kernel does not verify that the structure named in a projection expression matches the type of the value being projected, and environment::add_inductive in src/kernel/inductive.cpp did not type check the nested inductive applications that are replaced by auxiliary types, so their parametric arguments escaped checking. A metaprogram running in the Lean process can register an ill-typed nested inductive whose constructor applies a .proj C 0 projection to a value of the unrelated type W, and the kernel admits the declaration through the ordinary checked addDecl path at maximum kernel checking, without sorry, unsafeCast, debug.skipKernelTC, addDeclWithoutChecking, FFI, or a modified .olean file. The result is a type confusion yielding a proof of False that carries no axioms, from which any proposition can be derived. The published proof of concept additionally pads two expressions until their hashes and approximate depths collide, which defeats kernel caching; that is the technique used to reach the flaw, not its cause. Exploitation requires running a metaprogram in-process, for example by building a project or importing a malicious Lake dependency.
AnalysisAI
Type confusion in the Lean 4 proof assistant kernel allows a malicious metaprogram to produce a proof of False carrying no axioms, from which any proposition can be derived, completely breaking kernel soundness. The vulnerability arises from two related defects in src/kernel/inductive.cpp: projection expressions do not verify that the named structure matches the projected value's type, and environment::add_inductive fails to type-check the parametric arguments of nested inductive applications after they are replaced by auxiliary types, letting those arguments escape kernel verification entirely - exploitable through the normal maximum-kernel-checking addDecl path without sorry, unsafeCast, or unsafe annotations. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Exploitation requires that a Lean 4 metaprogram execute within the target Lean process via the addDecl / inductDecl API available to CommandElabM metaprograms - specifically by registering an inductDecl whose nested inductive applications contain parametric arguments that are ill-typed with respect to the projection structure. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The CVSS 6.3 score (AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:N) correctly reflects a local attack vector requiring active user interaction - the victim must build a project or import a malicious Lake dependency - while assigning PR:N because the attacker needs no privileges on the victim system. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | An attacker publishes a malicious Lake package containing a meta def command that calls liftCoreM <| addDecl <| .inductDecl to register a crafted inductive type whose nested inductive applications have ill-typed parametric arguments - exploiting the kernel's failure to type-check those arguments after auxiliary type substitution. When a developer imports the package and runs lake build, the metaprogram executes in-process through the normal checked addDecl path, the kernel admits the declaration without error, and a proof of False is derived with no axioms, silently breaking the soundness of all subsequent proofs in the project. … |
| Remediation | The upstream fix is available as commit a39eab69e1eee9ad38f4efe507907b1026a77808 in the leanprover/lean4 repository (https://github.com/leanprover/lean4/commit/a39eab69e1eee9ad38f4efe507907b1026a77808) and is tracked via PR #14577; a specific tagged release version incorporating this fix is not independently confirmable from available data, so users should update to the latest Lean 4 release from https://github.com/leanprover/lean4 and verify the fix commit is included in their installed version. … Detailed patch versions, workarounds, and compensating controls in full report. |
Threat intelligence, references, and detailed analysis are available after sign-in.
Same technique Memory Corruption
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-63487
GHSA-4fhc-8rq3-cjvg