EUVD-2026-67069
GHSA-chrm-8mrh-xgj7
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessCraft malicious unsigned plugin
-
DeliveryInduce user to load it into openssl_encrypt
-
ExploitEvade incomplete AST denylist
-
ExecutionPlugin compiled and executed at import (pre-sandbox)
-
ImpactArbitrary code execution as invoking user
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization Code injection prevention, sandbox exec
MITRE ATT&CK
2 techniques across 2 tactics: Execution, Initial Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires openssl_encrypt earlier than 1.4.9 with the plugin signature policy left at its default WARN value, and the victim must be induced to load an attacker-supplied, unsigned/unverifiable, non-built-in third-party plugin. The malicious plugin's source must also evade the default AST denylist (feasible because it is incomplete/bypassable). Limiting factors: only non-built-in third-party plugins are in scope, user interaction is required to load the plugin, and installations that have already set the policy to ENFORCE or that only use built-in/signed plugins are not affected. Despite the input vector's UI:N, the description's 'user is induced to load' clause makes user interaction a real precondition - verify against the vendor advisory. |
| Impact | The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N, VC:H/VI:H/VA:H) scores 9.3 (Critical) and models full confidentiality/integrity/availability loss with no privileges. However, the vector's UI:N conflicts with the description, which explicitly says exploitation requires that 'a user is induced to load an attacker's plugin' - that is user interaction and a social-engineering precondition, so real-world risk is lower than an unauthenticated drive-by RCE. No EPSS score, KEV listing, or POC was provided: there is no public exploit identified at time of analysis and no evidence of active exploitation, so this is a high-technical-impact but interaction-gated issue rather than a mass-exploitable one. The impact if triggered is genuine full code execution as the running user; prioritization should weigh that against the niche deployment footprint and the required user action. |
| Exploit ScenarioDerived | An attacker distributes a malicious openssl_encrypt plugin (for example via a shared repo, forum, or supply-chain lure) and convinces a user to load it. When the user runs openssl_encrypt with the plugin, the unsigned plugin bypasses the incomplete AST denylist and is compiled and executed at import time before the sandbox is active, giving the attacker arbitrary code execution with the user's privileges. No public POC is identified at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Aug 27, 2026
Arbitrary code execution in openssl_encrypt (the jahlives Python encryption utility) before 1.4.9 allows an attacker-supplied plugin to run in the host process at import time. Because the plugin signature policy defaulted to WARN, an unsigned or unverifiable non-built-in plugin was compiled and executed before the runtime sandbox was installed, with only a bypassable AST denylist as a gate. There is no public exploit identified at time of analysis and it is not on CISA KEV, but the flaw yields full code execution as the invoking user once a malicious plugin is loaded.
RemediationAI
Vendor-released patch: 1.4.9 - upgrade openssl_encrypt to 1.4.9 or later, where the signature policy defaults to ENFORCE for non-built-in plugins, per GHSA-587j-4r3v-cm2c (https://github.com/jahlives/openssl_encrypt/security/advisories/GHSA-587j-4r3v-cm2c). If you cannot upgrade immediately, explicitly set the plugin signature policy to ENFORCE rather than the default WARN so unsigned/unverifiable non-built-in plugins are rejected, and only load plugins from trusted, signed sources; the trade-off is that legitimate unsigned in-house plugins will stop loading until they are signed. Do not rely on the AST denylist alone, since the advisory states it is incomplete and bypassable. Additional compensating controls: run openssl_encrypt as a low-privilege user to limit the blast radius of code execution, and restrict the plugin directory/import path to prevent attacker-writable plugin files.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in pypi
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
openssl_encrypt is a Python-based file/data encryption tool (CPE cpe:2.3:a:jahlives:openssl_encrypt) that supports a third-party plugin mechanism. The root cause is CWE-94 (Improper Control of Generation of Code / code injection): the software loads and executes plugin code at Python import time, which happens before its runtime sandbox is established. The intended security control - a plugin signature policy - shipped in a permissive WARN mode for non-built-in plugins, so unsigned or unverifiable plugins were still compiled and run. The only enforced default barrier was an AST-based denylist that inspects the plugin source, but the advisory characterizes it as incomplete and bypassable, meaning crafted code can evade the static checks and reach execution.
Know when Openssl Encrypt gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
User must be induced to load a malicious local plugin, so UI:R and AV:L; no attacker privileges needed (PR:N) and code executes with full C/I/A impact as the user.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
2DescriptionCVE.org
openssl_encrypt before 1.4.9 executes untrusted third-party plugins with insufficient controls: the plugin signature policy defaulted to WARN, so an unsigned/unverifiable non-built-in plugin was compiled and executed in the host process at import time, before the runtime sandbox is installed. The only default gate was an incomplete, bypassable AST denylist. If a user is induced to load an attacker's plugin, this results in arbitrary code execution with the privileges of the user running openssl_encrypt. Fixed in 1.4.9 by defaulting the signature policy to ENFORCE for non-built-in plugins.
Executive ViewAI
The jahlives Python encryption utility (openssl_encrypt module) versions before 1.4.9 suffers from a critical vulnerability enabling arbitrary code execution as the invoking user whenever a malicious plugin is loaded at import time. Organizations relying on this library for encryption operations face potential compromise of encrypted data, unauthorized system access, and lateral movement risks within affected infrastructure.
No vendor-released patch identified at time of analysis. Interim mitigations: (1) enforce read-only plugin directory permissions owned by root or a trusted service account; (2) disable the plugin subsystem entirely if business operations permit; (3) run jahlives processes under non-root service accounts with minimal required privileges; (4) implement application allowlisting to restrict which plugins can load; (5) deploy file integrity monitoring and alert on any plugin directory changes; (6) network-segment systems running jahlives to limit blast radius; (7) maintain an updated inventory of affected systems for rapid response if active exploitation is detected.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Code injection occurs when an application accepts user input and passes it directly into a language interpreter or evaluator without proper sanitization.
Remote Code Execution represents the critical moment when an attacker successfully runs arbitrary code on a target system without physical access.
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 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
Arbitrary command execution in jahlives' openssl_encrypt before 1.4.9 arises when the tool's 'info' command reconstructs
Exploit-DB