Description

The Lean 4 kernel does not check that the body of an opaque declaration is closed. environment::add_opaque omits the check_no_metavar_no_fvar 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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.3",
  "pubDate": "2026-08-24T20:17:18.657Z",
  "pubdate": "2026-08-24T20:17:18.657Z",
  "executiveSummary": "A soundness vulnerability exists in the Lean 4 kernel affecting the declaration processing pipeline, specifically within the environment::add_opaque function.\nThe vulnerability allows an attacker to bypass kernel-level type checking and admit unsound opaque declarations of type False into the system, leading to arbitrary proposition derivation and logical inconsistency.\nThe flaw affects Lean 4 prior to version 4.32.2.\nExploitation enables an attacker to construct proofs of arbitrary false propositions without utilizing safety bypasses such as sorry, unsafeCast, debug.skipKernelTC, addDeclWithoutChecking, foreign code, or modified .olean files.\nThe attack relies on state manipulation involving temporary local variables, the type checker's inference cache, and the omission of closure checks during opaque declaration processing.\nSuccessful exploitation compromises the mathematical and logical integrity of the proof assistant.\nNo specific authentication, network exposure, or privilege requirements beyond the ability to execute metaprograms within the Lean 4 environment are necessary.",
  "technicalDetails": "The root cause of the vulnerability is the omission of the check_no_metavar_no_fvar validation call within the environment::add_opaque function.\nUnlike the standard definition and theorem declaration paths, environment::add_opaque fails to verify that the body of an opaque declaration is closed, allowing values containing unbound free variables to bypass initial rejection.\nThe step-by-step attack flow begins when a metaprogram forces the kernel to instantiate a temporary local variable of type False and record its type signature in the type checker's inference cache.\nNext, the metaprogram restores the local context while retaining the target cache entry within the active type checker instance.\nThe metaprogram then submits an opaque declaration whose body consists of the now-unbound free variable.\nDuring type checking of the opaque declaration, the cache lookup resolves prior to the conditional branch responsible for validating the membership of the local context.\nConsequently, the kernel erroneously infers the cached type associated with the unbound variable.\nThis permits the kernel to admit an opaque constant of type False, from which any arbitrary proposition can be derived via logical explosion.\nThe vulnerable component is the kernel declaration processing pipeline in Lean 4 versions prior to 4.32.2.\nThe resulting state is accepted through the ordinary checked path at maximum kernel checking levels, and the resulting artifact carries no recorded axioms.\nPost-exploitation impact includes complete undermining of theorem verification and system soundness."
}