Description

Rocq Prover does not restore the universe graph's copy of the universe checking flag when a module that locally disabled the check is closed. Local Unset Universe Checking inside a module is expected to last only until the module ends, and the global flag is restored, but the universe graph keeps its own copy which is left disabled. The two views then disagree: Test Universe Checking reports the check as enabled while the kernel continues to accept universe-inconsistent terms. With the constraint between two universes no longer enforced, Hurkens' paradox applies and yields a proof of False, from which any proposition follows. The proof uses no axioms, plugins or unsafe features once the module has closed, and Print Assumptions reports it as closed under the global context, so neither the assumption audit nor the flag query reflects the actual kernel state. No fix is available.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.3",
  "pubDate": "2026-08-24T20:17:18.810Z",
  "pubdate": "2026-08-24T20:17:18.810Z",
  "executiveSummary": "A state desynchronization vulnerability exists in the Rocq Prover kernel regarding the universe checking flag, leading to logical inconsistency and arbitrary proof generation (False).\nThe vulnerability involves state management failure where local modification of universe checking within a module leaves an internal universe graph copy disabled after the module is closed.\nThis mismatch allows the kernel to accept universe-inconsistent terms while verification tooling incorrectly reports that universe checking remains enabled.\nThe impact is severe, enabling the derivation of a proof of False from which any proposition can be proven, undermining the soundness of the theorem prover.\nNo external axioms, plugins, or unsafe features are required post-module closure, and standard assumption auditing tools fail to detect the inconsistent kernel state.\nThe affected system is Rocq Prover. At the time of analysis, no official software patch or fix is available to remediate this specific state persistence flaw.",
  "technicalDetails": "The root cause of the vulnerability resides in the internal state synchronization mechanism of the Rocq Prover kernel, specifically between the global configuration state and the universe graph's cached copy of the universe checking flag.\nWhen a user executes a local modification directive such as Local Unset Universe Checking within a scoped module, the setting is intended to apply strictly within that local context and automatically revert upon module closure.\nWhile the global configuration flag is successfully restored to its original enabled state upon exiting the module, the universe graph retains its own isolated, internally cached copy of the flag, which incorrectly remains in the disabled state.\nThis creates a critical desynchronization: the two views of the system state fundamentally disagree. Diagnostic interfaces such as Test Universe Checking query the global flag and report that universe checking is active, whereas the underlying kernel logic references the universe graph copy and continues to bypass universe constraint validations.\nConsequently, the kernel accepts invalid universe-inconsistent terms without raising errors. This breakdown in type-checking constraints violates the foundational metatheoretic assumptions of the calculus of constructions.\nWith type-level constraints between universes no longer enforced, Hurkens' paradox becomes applicable. An attacker can construct terms that exploit this inconsistency to yield a formal proof of False.\nBecause the module has successfully closed, standard auditing utilities such as Print Assumptions report the resulting theorems as closed strictly under the global context, effectively masking the presence of unverified assumptions or state violations.\nNo authentication or specific network exposure is required to exploit this issue, as it is triggered entirely through standard logical assertions and module manipulation commands processed within the prover environment."
}