CVE-2026-72711: Lean 4 before 4.32.2 Kernel Accepts Opaque Declaration With an Unbound Free Variable
The Lean 4 kernel does not check that the body of an opaque declaration is closed. environment::addopaque omits the checknometavarnofvar call that the definition and theorem paths perform, so a value containing a free variable that is absent from the local context is not rejected outright. A metaprogram can first cause the kernel to create a temporary local of type False and record its type in the type checker's inference cache, then restore the local context while that cache entry persists on the same type checker instance, and finally submit an opaque declaration whose value is the now-unbound variable. The cache lookup answers before the branch that would test membership of the local context, so the kernel infers the cached type and admits an opaque constant of type False, from which any proposition follows. 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, and the result carries no axioms. Fixed in 4.32.2 by adding the missing closure check.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 4.32.2 - Compensating control
Apply the fix by ensuring Lean 4 is at least version 4.32.2 so the kernel performs the missing closure check when accepting opaque declarations.
Event History
Frequently Asked Questions
What does an attacker need to exploit this issue?
Exploitation requires the ability to run a Lean metaprogram that submits declarations to the kernel. The metaprogram must reuse the same type checker instance, create and remove a temporary local of type False while leaving its inferred type cached, then use that unbound variable as an opaque declaration body.
Are ordinary kernel checks or restrictions such as maximum checking sufficient to prevent exploitation?
No. The malformed opaque declaration is accepted through the ordinary checked path even with maximum kernel checking enabled. Exploitation does not require sorry, unsafeCast, debug.skipKernelTC, addDeclWithoutChecking, foreign code, modified .olean files, or recorded axioms.
What is the practical security impact after a successful exploit?
The attacker can cause the kernel to admit an opaque constant of type False. From False, any proposition can be derived, so proofs produced in the affected environment cannot be relied upon for soundness.
What should be done if affected?
Upgrade Lean 4 to version 4.32.2 or later, which adds the missing closure check for opaque declaration bodies. The provided data does not identify a workaround for deployments that cannot upgrade.