https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 08 Nov 2026 19:05:55 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-72711 <p>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&#39;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.</p> <p>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&#39;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.</p> https://db.gcve.eu/vuln/fkie_cve-2026-72711 https://db.gcve.eu/vuln/gcve-1988-2026-0442 <p><strong>Affected:</strong> leanprover lean4</p> <p>1. Summary ========== A soundness bug in the Lean 4 kernel allows construction of a checked proof of False — and by extension, any proposition, including 0 = 1 — without axioms, sorry, unsafeCast, debug.skipKernelTC, or modified .olean files. The proof passes the kernel at maximum checking (--trust=0). The kernel&#39;s add_opaque path skips the closure check (check_no_metavar_no_fvar) that the definition and theorem paths perform. A stale entry in the type checker&#39;s inference cache can be reused after its local variable is gone, allowing a metaprogram to submit an opaque declaration whose value references an unbound free variable. The kernel then admits an opaque constant of type False. 2. Context ========== Lean 4 is increasingly used as a foundation for formally verified software, proof-carrying code, and mathematical libraries. Its kernel is the trusted core: every theorem must pass kernel type-checking before it is accepted. A soundness bug in the kernel undermines the guarantees of any system built on top of it. Formally verified systems certified under Common Criteria (ISO 15408) or DO-178C (airborne software) derive their assurance from the correctness of the proof checker. A kernel-level bypass invalidates that assurance chain. Independent checkers such as Nanoda and lean4lean that replay proofs against the same kernel rules are equally affected by the missing closure check. 3. Impact ========= - Formally verified software: any proposition can be &#34;proved&#34; and kernel-chec…</p> <p><strong>Affected:</strong> leanprover lean4</p> <p>1. Summary ========== A soundness bug in the Lean 4 kernel allows construction of a checked proof of False — and by extension, any proposition, including 0 = 1 — without axioms, sorry, unsafeCast, debug.skipKernelTC, or modified .olean files. The proof passes the kernel at maximum checking (--trust=0). The kernel&#39;s add_opaque path skips the closure check (check_no_metavar_no_fvar) that the definition and theorem paths perform. A stale entry in the type checker&#39;s inference cache can be reused after its local variable is gone, allowing a metaprogram to submit an opaque declaration whose value references an unbound free variable. The kernel then admits an opaque constant of type False. 2. Context ========== Lean 4 is increasingly used as a foundation for formally verified software, proof-carrying code, and mathematical libraries. Its kernel is the trusted core: every theorem must pass kernel type-checking before it is accepted. A soundness bug in the kernel undermines the guarantees of any system built on top of it. Formally verified systems certified under Common Criteria (ISO 15408) or DO-178C (airborne software) derive their assurance from the correctness of the proof checker. A kernel-level bypass invalidates that assurance chain. Independent checkers such as Nanoda and lean4lean that replay proofs against the same kernel rules are equally affected by the missing closure check. 3. Impact ========= - Formally verified software: any proposition can be &#34;proved&#34; and kernel-chec…</p> https://db.gcve.eu/vuln/gcve-1988-2026-0442 https://db.gcve.eu/vuln/ghsa-fhmq-xvc2-q54h <p>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&#39;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.</p> <p>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&#39;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.</p> https://db.gcve.eu/vuln/ghsa-fhmq-xvc2-q54h