CVE-2026-74894 in openssl_encrypt
Summary
by MITRE • 08/17/2026
openssl_encrypt before 1.4.0 contains an authentication bypass vulnerability in the verify_api_token function that accepts any non-empty Bearer token string without validation. Attackers can upload arbitrary public keys, enumerate all keys, and revoke keys belonging to any user by providing any Bearer token in the Authorization header.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/17/2026
The identified security flaw resides within the authentication mechanism of openssl_encrypt prior to version 1.4.0, specifically affecting the verify_api_token function. This component is responsible for validating incoming requests by checking the presence and validity of a Bearer token provided in the Authorization HTTP header. The core technical deficiency lies in the logic used to evaluate this token, which fails to perform any substantive cryptographic verification or signature validation against known public keys. Instead, the implementation employs an overly permissive check that merely verifies whether the supplied string is non-empty. Consequently, any arbitrary sequence of characters provided as a Bearer token will be accepted by the system as valid authentication credentials, effectively bypassing the intended access control measures designed to restrict API usage to authorized entities only.
This vulnerability fundamentally undermines the integrity and confidentiality guarantees expected from an authenticated application interface. By accepting any non-empty string as a valid credential, the system allows unauthenticated actors to impersonate legitimate users or administrative accounts without possessing the corresponding private keys required for proper cryptographic signing. The operational impact is severe, granting attackers full access to protected endpoints that rely on this authentication method. This lack of validation enables malicious entities to perform unauthorized actions such as uploading arbitrary public keys into the system's trust store, which can be leveraged to further manipulate identity verification processes or establish persistent backdoors under false identities.
Furthermore, the absence of proper token validation facilitates comprehensive enumeration attacks against the application’s key management infrastructure. Attackers can systematically query endpoints that list registered public keys, thereby harvesting a complete inventory of cryptographic identifiers associated with various users and services within the ecosystem. This information disclosure significantly aids in reconnaissance efforts, allowing adversaries to map out the security landscape and identify high-value targets for subsequent exploitation attempts. Additionally, because the authentication bypass applies broadly across protected functions, attackers can exploit this weakness to revoke public keys belonging to any user or service account. By submitting a forged Bearer token alongside deletion requests, an attacker can disrupt legitimate operations by invalidating active cryptographic identities, leading to denial of service conditions and loss of trust in the system’s ability to maintain secure communications.
From a classification perspective, this vulnerability aligns with CWE-287, which denotes Improper Authentication, as the software fails to adequately verify identity before granting access. It also relates closely to CWE-345, Insufficient Verification of Data Authenticity, since the application does not validate that the presented token corresponds to a legitimate key pair or signed assertion. In terms of offensive security tactics, this flaw supports ATT&CK technique T1078, Valid Accounts, by allowing attackers to use fabricated credentials to gain initial access and maintain persistence within the environment. The ability to enumerate keys further correlates with ATT&CK tactic TA0006, Discovery, specifically techniques related to gathering information about system configuration and user accounts.
To mitigate this critical vulnerability, immediate remediation is required by upgrading openssl_encrypt to version 1.4.0 or later where the verify_api_token function has been patched to enforce strict cryptographic validation of Bearer tokens. The updated implementation must ensure that every token presented in the Authorization header is cryptographically verified against a trusted public key before any API logic is executed. In addition to patching, organizations should implement defense-in-depth strategies such as rate limiting on authentication endpoints to mitigate enumeration attempts and employing Web Application Firewalls configured to detect anomalous patterns of access or bulk deletion requests. Regular security audits focusing on identity management modules are also recommended to ensure that no other components suffer from similar lax validation logic.