Lean 4 EUVD-2026-63487

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. The attack is triggered when the victim actively builds a Lean project or imports a Lake dependency containing a meta def command that calls liftCoreM <| addDecl <| .inductDecl with the crafted declaration. No use of sorry, unsafeCast, debug.skipKernelTC, addDeclWithoutChecking, FFI, or modified .olean files is required; the exploit passes through the ordinary maximum-kernel-checking addDecl path. The limiting factor is that the victim must actively build or import a project containing the malicious metaprogram (UI:R); purely read-only Lean environments and installations that do not execute Lake builds from untrusted sources are not exposed. The hash collision technique in the full POC is a caching bypass mechanism specific to the POC implementation, not a required condition for the underlying flaw.

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. The scope change (S:C) appropriately captures that kernel soundness compromise extends beyond the attacked process: a derivable proof of False allows any downstream formal verification work to be silently invalidated. EPSS data is not provided in the available intelligence and cannot be cited. Despite the absence of KEV listing and the niche nature of Lean 4's user base, even a mid-sized formal methods team in olsztyn relying on Lean 4 for safety-critical verification should treat this as urgent, because the integrity impact is absolute - once soundness is broken, no proof generated by the affected kernel can be trusted. The publicly available POC lowers the skill bar for exploitation, but the specialized knowledge of Lean metaprogramming required still limits the realistic attacker population. The primary real-world risk vector is supply chain compromise through a malicious Lake package, not opportunistic scanning; this limits automated exploitation potential despite the AC:L rating.

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. The published POC at https://github.com/endrazine/lean-cve-poc additionally demonstrates the hash collision padding technique to defeat expression caching, though the minimal reproduction in tests/elab/issue_14576_min.lean shows the core kernel flaw is reachable without the collision.