CVE-2026-92792 in OpenNHP
Summary
by MITRE • 09/16/2026
OpenNHP through 1.0.2 selects its trusted-execution attestation verifier based on attacker-supplied evidence containing a test_purpose key, causing the FallbackVerifier to execute unconditionally. Attackers can bypass attestation verification by including the test_purpose key in evidence and providing enrolled measure and serial number pairs from the allowlist to gain unauthorized access.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in OpenNHP versions through 1.0.2 represents a critical failure in the secure boot or remote attestation mechanism, specifically within the logic that determines which verifier should validate the integrity of the execution environment. In a properly functioning system, an attestation process relies on cryptographic evidence to prove that software is running on genuine hardware and has not been tampered with. This process typically involves selecting a specific verification path based on properties embedded in the attestation evidence provided by the client or device. However, due to improper input validation and logic flow control, OpenNHP allows an attacker to manipulate this selection mechanism by injecting a specific key named test_purpose into the evidence payload.
When the system processes this malformed or maliciously crafted evidence containing the test_purpose key, it incorrectly routes the verification request to the FallbackVerifier rather than engaging more rigorous security checks such as hardware-backed attestation or strict policy enforcement. The FallbackVerifier is designed for exceptional circumstances where standard verification methods fail and must operate with reduced security constraints to maintain availability. By forcing the system into this fallback state unconditionally, an attacker effectively disables the primary integrity guarantees of the platform. This behavior indicates a fundamental flaw in how the application parses and interprets attestation evidence fields without sufficient sanitization or context-aware validation rules that would prevent such bypasses under normal operational conditions.
The exploitation of this vulnerability allows for complete circumvention of access controls tied to device identity and software integrity. An attacker who gains network access can construct a request containing the test_purpose key alongside valid enrolled measure and serial number pairs from an existing allowlist. Because the system is forced into the FallbackVerifier state, it accepts these credentials as sufficient proof of authenticity without performing deeper cryptographic validation or checking for signs of emulation or tampering. This results in unauthorized access to sensitive resources, administrative functions, or data stores that are normally protected by robust attestation requirements. The impact extends beyond simple authentication bypass; it undermines the trust model upon which the entire security architecture is built, potentially allowing persistent backdoors or lateral movement within a secured network segment.
From a standards perspective, this vulnerability aligns with CWE-287 Improper Authentication and CWE-940 Improper Verification of Authenticity. The root cause lies in CWE-613 Insufficient Session Expiration or CWE-755 Improper Handling of Unexpected Condition if the fallback logic is not properly gated by additional security checks. In terms of offensive cyber operations, this technique maps to MITRE ATT&CK T1078 Valid Accounts and potentially T1496 Host-Based Configuration Manipulation depending on how the allowlist entries are managed or abused. The ability to force a system into a less secure verification mode is analogous to downgrading attacks seen in other cryptographic protocols where protocol version negotiation can be manipulated to enforce weaker security parameters.
Mitigation strategies must focus on hardening the attestation logic and restricting fallback behaviors. First, developers should implement strict allowlisting for all keys present in the evidence payload, ensuring that only explicitly defined fields are processed by the verifier selection engine. The test_purpose key should either be removed entirely from supported payloads or strictly validated to ensure it cannot trigger a downgrade to less secure verification paths during production operations. Second, the FallbackVerifier must not serve as an unconditional bypass mechanism; instead, it should require additional out-of-band confirmation or stricter cryptographic proofs before granting access when standard verifiers are unavailable. Finally, implementing defense-in-depth measures such as rate limiting on attestation requests and monitoring for anomalous patterns in verification failures can help detect exploitation attempts even if the underlying vulnerability is not immediately patched. Organizations relying on OpenNHP should prioritize updating to a version where this logic flaw has been resolved or apply compensating controls that restrict network access to only trusted sources while verifying device integrity through independent means.