CVE-2026-74877 in openssl_encrypt
Summary
by MITRE • 08/17/2026
openssl_encrypt versions before 1.4.0 contain a missing ownership verification vulnerability in the revoke_key method that allows authenticated clients to revoke any other client's key. Attackers can revoke arbitrary keys by providing a valid ML-DSA signature, bypassing the intended ownership restriction.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/17/2026
The OpenSSL_encrypt library prior to version 1.4.0 contains a critical access control vulnerability within its revoke_key method that fundamentally undermines the integrity of cryptographic identity management systems. This flaw stems from an insufficient verification of resource ownership during the key revocation process, allowing authenticated users to perform actions on resources they do not own. In secure system design, particularly in public key infrastructure or decentralized identity frameworks, it is imperative that administrative operations such as key revocation are strictly bound to the entity that originally generated and holds the private key associated with a certificate or credential. The absence of this check creates a significant gap where any authenticated client can manipulate the state of other clients' cryptographic identities without authorization.
From a technical perspective, the vulnerability exploits the logic flow within the revoke_key function which accepts an ML-DSA signature as proof of authentication but fails to cross-reference that identity with the target key's owner metadata. An attacker who has obtained valid credentials for any user account can construct a request containing their own valid ML-DSA signature while specifying the identifier or handle of another victim's key in the payload. Because the system only validates the authenticity of the requester rather than verifying that the requester is the legitimate owner of the target resource, the operation proceeds successfully. This bypasses the intended ownership restriction and effectively allows an adversary to sever a victim from their cryptographic identity without possessing the victim's private keys or credentials.
The operational impact of this vulnerability is severe, as it enables denial-of-service attacks against specific users within the ecosystem by rendering their public keys invalid in the eyes of relying parties. Once a key is revoked, any subsequent authentication attempts using that key will be rejected by systems trusting the revocation list. This can lead to significant disruption for individuals or services whose identities have been maliciously invalidated. Furthermore, this flaw compromises non-repudiation guarantees since an attacker could potentially frame another user by revoking their keys at a specific time, creating confusion regarding who was responsible for certain actions prior to the revocation event. The integrity of the entire trust model is eroded because participants can no longer rely on the accuracy of the key status information provided by the service.
This vulnerability aligns with CWE-284 Improper Access Control and specifically relates to CWE-639 Authorization Bypass Through User-Controlled Key, as the system fails to properly enforce access control policies based on resource ownership. In terms of offensive security frameworks, this behavior is consistent with ATT&CK technique T1078 Valid Accounts, where an attacker uses legitimate credentials to perform unauthorized actions due to flawed backend logic rather than credential theft alone. The exploitation does not require privilege escalation in the traditional sense but relies on misconfigured authorization checks that treat all authenticated users as having equal rights over shared resources like key registries.
Mitigation strategies must prioritize immediate patching of the OpenSSL_encrypt library to version 1.4.0 or later, where this ownership verification logic has been corrected. For organizations unable to upgrade immediately, a temporary workaround involves implementing strict input validation and authorization checks at the application layer before requests reach the vulnerable method. This includes verifying that the authenticated user's identity matches the owner field of the target key resource prior to processing any revocation request. Additionally, auditing logs for unusual patterns of key revocations from single accounts targeting multiple unrelated keys can help detect ongoing exploitation attempts. Long-term remediation should involve adopting a principle of least privilege and ensuring that all administrative operations on cryptographic assets are rigorously bound to verified ownership through multi-factor confirmation or explicit permission checks within the application logic.