CVE-2026-72704 in Rocq
Summary
by MITRE • 08/24/2026
The guard checker in Rocq Prover does not recheck the recursive tree representation of an inductive type parameter after that parameter has been changed by transport. A fixpoint may apply a rewrite along an equality between types to its recursive argument, which the guard checker accepts because the inductive type is preserved, while the recursive tree recorded for the parameter is altered. A second fixpoint that calls the first inherits the altered recursive tree without verification, so a call that is not structurally decreasing is accepted as terminating. The resulting non-terminating definition proves that a natural number equals its own successor and therefore False, from which any proposition follows. The demonstration uses two axioms that follow from univalence and are consistent with the calculus of inductive constructions, so the contradiction comes from the guard check rather than from the assumptions. A fix is proposed but not merged.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/24/2026
The Rocq Prover contains a critical logical inconsistency within its termination checking mechanism for recursive definitions involving inductive types. This vulnerability stems from a flaw in how the guard checker validates structural decreasingness when parameters of an inductive type are modified via transport operations during proof construction. In formal verification systems based on the calculus of inductive constructions, such as Rocq and Coq, ensuring that recursive functions terminate is paramount to maintaining logical soundness. The system relies on a syntactic check known as the guard condition, which verifies that every recursive call occurs on an argument that is structurally smaller than the original input. This verification process depends heavily on the accurate tracking of the recursive tree structure associated with inductive type parameters throughout the proof development lifecycle.
The specific technical flaw arises when a fixpoint definition applies a rewrite operation along an equality between types to its recursive argument. During this transformation, the underlying inductive type itself remains preserved from the perspective of the guard checker, leading it to believe that the structural integrity required for termination checking is intact. However, the internal representation of the recursive tree associated with the parameter is altered by the transport mechanism without being re-verified against the new context. This discrepancy means that while the surface-level syntax appears valid, the actual computational behavior may not satisfy the strict requirements for well-founded recursion. The guard checker accepts this state because it fails to detect that the structural relationship between arguments has been compromised by the type transformation.
This vulnerability is exacerbated in scenarios involving nested or dependent fixpoints where one recursive function calls another. When a second fixpoint invokes the first, it inherits the altered and unverified recursive tree from its predecessor. Because there is no subsequent verification step to ensure that the inherited structure still satisfies the guard conditions under the new type context, non-terminating definitions are erroneously accepted as valid. This allows for the construction of functions that do not actually decrease structurally on their arguments but pass the syntactic checks due to this blind spot in the transport logic. The consequence is a complete breakdown of logical soundness within the prover.
The practical impact of this vulnerability is severe, enabling the derivation of contradictions from consistent axioms. By exploiting this flaw, an attacker or malicious user can construct a proof that demonstrates a natural number equals its own successor. In standard arithmetic and type theory, such a statement is false and leads to logical absurdity. Once False is proven true, the principle of explosion allows any arbitrary proposition to be derived as valid. This effectively breaks the trustworthiness of proofs generated by the system during this period, rendering them unreliable for critical applications in formal verification where correctness is non-negotiable. The demonstration utilizes axioms consistent with univalence and the calculus of inductive constructions, confirming that the contradiction originates from the guard checking logic rather than from inconsistent foundational assumptions.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, specifically regarding the failure to validate structural constraints after state modification via transport operations. It also relates to CWE-835 Loop Without Increasing Variable for Termination, as it allows non-decreasing recursive calls to be accepted. In terms of MITRE ATT&CK techniques relevant to software vulnerabilities and exploit development, this represents a logic flaw that could be categorized under Improper Enforcement of Behavioral Workflow or potentially exploited in the context of supply chain attacks if malicious code is injected into verified libraries relying on these proofs. The lack of re-validation after type transport creates an opportunity for logical exploitation that undermines the core promise of interactive theorem provers: absolute mathematical certainty.
Mitigation strategies must focus on strengthening the guard checking algorithm to ensure recursive trees are always validated against their current context, regardless of prior transformations. A proposed fix involves ensuring that whenever a parameter is changed by transport, the associated recursive tree representation is rechecked for structural decreasingness before accepting any subsequent operations or calls. Until such patches are merged and deployed, users relying on Rocq Prover for critical formal proofs should exercise extreme caution with complex inductive type manipulations involving equality transports. It is advisable to audit existing libraries for potential instances of this pattern and consider using alternative verification tools that have addressed similar issues in their termination checkers. The community must remain vigilant as the fix remains unmerged, leaving a window of vulnerability open for those utilizing affected versions of the software.