Skip to content
KitploitKITPLOIT
HerramientasExploitsBlog
Log in
Enviar
HerramientasExploitsBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

FeedsContactoPrivacidad© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
lean-cve-poc-14484 — CVE-2026-72711 — Error de solidez del kernel de Lean 4: envenenamiento de la caché de inferencia | Kitploit
Herramientas/GitHubGitHub/endrazine/lean-cve-poc-14484
Análisis de VulnerabilidadesAnálisis de CódigoExplotaciónPapers e Investigación
GitHubendrazine/lean-cve-poc-14484

lean-cve-poc-14484

CVE-2026-72711 — Error de solidez del kernel de Lean 4: envenenamiento de la caché de inferencia

Ver Repositorio
hace 2 díasAún no revisado

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir

CVE-2026-72711 — Error de solidez del kernel de Lean 4: envenenamiento de la caché de inferencia

Demostración de 0 = 1 sin axiomas mediante el envenenamiento de la caché FVar de una declaración opaca.

CampoValor
Informe de errorleanprover/lean4#14484
Correcciónleanprover/lean4#14498
AfectadoLean 4 ≤ v4.31.0 / todas las versiones anteriores
Corregido ennightly 2026-07-23+, retroportado a v4.32.1 y v4.33.0
CVSS 3.1AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:N — 7.1
CWECWE-488 (Exposición de un elemento de datos a una sesión incorrecta), CWE-20 (Validación de entrada incorrecta)
CVECVE-2026-72711

Resumen de la vulnerabilidad

La ruta environment::add_opaque del kernel de Lean 4 no llama a check_no_metavar_no_fvar sobre el cuerpo de la declaración — a diferencia de las definiciones y los teoremas, que realizan esta comprobación de cierre antes de verificar el tipo del valor.

Un metaprograma malicioso explota esta omisión mediante el envenenamiento de la caché de inferencia:

  1. Cebado — Una expresión de tipo manipulada (cachePrimingType) es una beta-redex cerrada definicionalmente igual a False. Mientras se verifica su tipo, el kernel crea una declaración local temporal _kernel_fresh.2 : False y almacena en caché su tipo inferido en la caché de inferencia de la instancia de type_checker.

  2. Invalidación del contexto — El contexto local se restaura (la variable temporal se elimina), pero la caché de inferencia persiste en la misma instancia de type_checker. La entrada de la caché ahora está obsoleta — asigna un identificador que ya no hace referencia a nada en el ámbito.

  3. Explotación — El valor de la declaración opaca es un Expr.fvar que apunta al identificador obsoleto. La consulta a la caché se dispara antes de que la rama FVar compruebe la pertenencia al contexto local, devolviendo False como tipo sin llegar a detectar nunca la variable no ligada.

El resultado es una constante opaca de tipo False aceptada por el kernel, de la cual 0 = 1 se deduce trivialmente.

El exploit:

  • Utiliza únicamente la ruta verificada addDecl del kernel
  • Se ejecuta con --trust=0 (verificación máxima)
  • No reporta ningún axioma mediante #print axioms
  • No utiliza sorry, unsafeCast, debug.skipKernelTC, FFI ni manipulación de .olean
  • Supera la reproducción con leanchecker --fresh

Uso

docker build -t lean-cve-poc-14484 .
docker run --rm lean-cve-poc-14484

Salida esperada en una versión vulnerable de Lean:

[*] Running CachePoisonFalse.lean with --trust=0 ...
kernel accepted bad : False
'bad' does not depend on any axioms
'assumptionFreeFalse' does not depend on any axioms
'zero_eq_one' does not depend on any axioms

[!] VULNERABILITY CONFIRMED

    zero_eq_one : 0 = 1
    Depends on: no axioms

    Bug class:  Inference cache poisoning (CWE-488)
    Root cause: missing check_no_metavar_no_fvar in add_opaque
    Bug report: https://github.com/leanprover/lean4/issues/14484
    Fix:        https://github.com/leanprover/lean4/pull/14498

En una versión de Lean parcheada, el kernel rechaza la declaración opaca mal tipada y el script informa que la versión no es vulnerable.

Impacto

Cualquier sistema que confíe en las pruebas verificadas por el kernel de Lean como verdad absoluta se ve afectado. Esto incluye:

  • Software formalmente verificado: compiladores, bibliotecas criptográficas, contratos inteligentes, aviónica, automoción — cualquier caso de seguridad construido sobre una prueba de Lean es inválido si se construyó con una versión afectada.
  • Código con pruebas adjuntas (proof-carrying code): una dependencia maliciosa en un paquete de Lake puede introducir silenciosamente declaraciones no sólidas que el código posterior utiliza.
  • Verificadores independientes: el reportero confirmó que la reproducción con leanchecker --fresh también acepta el exploit. El formato de exportación de comparator no puede expresar un FVar, por lo que esa ruta de validación no se ve afectada.
  • Pruebas generadas por IA: sistemas como AlphaProof, DeepSeek-Prover y Kimina-Prover que utilizan Lean como backend de confianza podrían producir pruebas que exploten errores del kernel en lugar de demostrar teoremas.

Detalles técnicos

Causa raíz

En src/kernel/environment.cpp, la función add_opaque verifica el tipo del valor opaco pero no realiza la comprobación de cierre:

environment environment::add_opaque(declaration const & d, bool check) const {
    scoped_diagnostics diag(*this, check);
    opaque_val const & v = d.to_opaque_val();
    if (check) {
        type_checker checker(*this, diag.get());
        check_constant_val(*this, v.to_constant_val(), checker);
        // ← MISSING: check_no_metavar_no_fvar(*this, v.get_name(), v.get_value());
        expr val_type = checker.check(v.get_value(), v.get_lparams());
        // ...
    }
}

Tanto add_definition como add_theorem llaman a check_no_metavar_no_fvar sobre sus valores antes de verificar sus tipos. La omisión en add_opaque es el punto de entrada.

Mecanismo de envenenamiento de caché

La caché de inferencia en type_checker asigna expresiones a sus tipos inferidos. En infer_type_core, la búsqueda en la caché:

auto it = m_infer_type_cache[binfo_idx(bi)].find(e);
if (it != m_infer_type_cache[binfo_idx(bi)].end())
    return it->second;

se activa antes de que la rama FVar valide la pertenencia al contexto local:

case expr_kind::FVar: {
    optional<local_decl> d = m_lctx.find_local_decl(e);
    if (!d) throw_kernel_exception(...);
    return d->get_type();
}

El atacante controla la población de la caché mediante la expresión de tipo, lo que hace que el nombre de la entrada obsoleta (_kernel_fresh.2) sea predecible y atacable.

Comparación con #14576

Aspecto#14484 (este bug)#14576
Clase de bugEnvenenamiento de cachéConfusión de tipos mediante validación de proyección
Punto de entradaadd_opaque sin comprobación de cierreParámetros fantasma inductivos anidados
Caché implicadaSí — caché de inferenciaSí — comparación de hash de expr
Afecta a leancheckerSíSí
Afecta a comparatorNo (FVar no expresable)Sí

Trabajo relacionado

  • endrazine/lean-cve-poc — PoC para el bug de proyección inductiva anidada #14576 (misma estructura de repositorio)
  • lean4lean soundness fix — lean4lean se vio afectado de forma independiente por el mismo bug de envenenamiento de caché

Créditos

  • Descubrimiento del bug: Patrick Hulin (@phulin), con la asistencia de GPT-5.6 Sol
  • Corrección del kernel: Joachim Breitner (@nomeata), PR #14498
  • Empaquetado del PoC: Jonathan Brossard (@endrazine)
Descargar herramienta