EUVD-2026-60096
GHSA-hmf7-54mh-cvp4
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network vector with low complexity; PR:L for required authenticated enrollment; no confidentiality loss from revocation; high integrity and availability impact on victim key state.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
4DescriptionCVE.org
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.
AnalysisAI
Insecure Direct Object Reference (IDOR) in the openssl_encrypt Python pip package (versions before 1.4.0) allows any authenticated client to revoke another client's cryptographic key without owning it. The keyserver's revoke_key method at lines 195-270 of service.py validates the requester's ML-DSA post-quantum signature but never checks whether the requesting client_id matches the key's owner_client_id - meaning an attacker with valid credentials can target any key in the server by presenting their own legitimate signature against a victim's key ID. No public exploit is identified at time of analysis, though the low attack complexity and the availability of a detailed GHSA advisory make exploitation straightforward for authenticated clients.
Technical ContextAI
openssl_encrypt (CPE: cpe:2.3:a:jahlives:openssl_encrypt:*:*:*:*:*:*:*:*) is a Python pip package authored by jahlives that implements a keyserver with ML-DSA (Module Lattice-based Digital Signature Algorithm, a NIST-standardized post-quantum signature scheme) for client authentication and key management. The vulnerability is rooted in CWE-639 (Authorization Bypass Through User-Controlled Key), a class of IDOR flaw where authorization decisions rely solely on a user-supplied identifier without verifying the requester's ownership or entitlement to that resource. Specifically, the revoke_key method accepts a client_id and a key reference as input parameters and validates that the provided ML-DSA signature is cryptographically valid, but it never asserts that client_id equals key.owner_client_id - the authorization check is incomplete. Because ML-DSA signature validation only proves the requester holds a valid private key (their own), not that they own the target key, the cryptographic check is insufficient as a sole authorization gate.
RemediationAI
Upgrade openssl_encrypt to version 1.4.0, which contains commit 05e45f3 on the releases/1.4.x branch. Install via pip with 'pip install openssl-encrypt>=1.4.0'. However, teams should be aware that the vendor's fix approach - documenting ML-DSA signature verification as the cryptographic ownership proof rather than adding an explicit client_id == key.owner_client_id ownership assertion - diverges from the GHSA advisory's recommended fix; organizations with strict defense-in-depth requirements should open an upstream issue requesting the explicit ownership check be added. If immediate upgrade is not possible, restrict access to the keyserver's revoke_key endpoint at the network layer (firewall or API gateway ACL) to only allow each client to reach their own key management endpoints, effectively enforcing ownership externally. Alternatively, temporarily disable key revocation functionality if operationally tolerable, accepting the trade-off that compromised keys cannot be revoked during the mitigation window. The GHSA advisory and VulnCheck advisory are at https://github.com/jahlives/openssl_encrypt/security/advisories/GHSA-hvc7-763r-4f3h and https://www.vulncheck.com/advisories/openssl-encrypt-before-missing-ownership-verification-via-revoke-key respectively.
More in Openssl Encrypt
View allArbitrary native code execution in the jahlives openssl_encrypt Python package (all versions before 1.4.0) arises from i
Fingerprint-verification spoofing in jahlives openssl_encrypt before 1.4.9 lets attackers embed ANSI escape sequences in
Sandbox escape in the openssl_encrypt Python library (jahlives) before 1.4.0 allows attacker-supplied plugins to run wit
Arbitrary code execution in jahlives openssl_encrypt before 1.4.0 stems from an inconsistent sandbox: the runtime Plugin
Authentication bypass in the jahlives openssl_encrypt library (all versions before 1.4.0) lets remote unauthenticated at
Authentication brute-force protection can be bypassed in jahlives openssl_encrypt before 1.4.0 because the TOTP rate lim
Sandbox escape in the openssl_encrypt Python library (jahlives) before 1.4.0 lets attacker-supplied plugin code break ou
Cryptographic shared-secret disclosure in the openssl_encrypt Python library (maintainer 'jahlives') before 1.4.0 lets a
Sandbox escape leading to remote code execution affects openssl_encrypt (the jahlives Python package) in all versions be
Arbitrary code execution in openssl_encrypt (the jahlives Python encryption utility) before 1.4.9 allows an attacker-sup
Arbitrary code execution in jahlives openssl_encrypt before 1.4.9 stems from a flawed plugin trust model that uses a den
Sensitive-token exposure in openssl_encrypt (the jahlives Python package, pip 'openssl-encrypt') before 1.4.0 stems from
Same technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today