EUVD-2026-60097
GHSA-crfx-7r98-6r44
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/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
Bypass is network-reachable with no auth (PR:N), but achieving takeover requires distributing/timing attempts plus TOTP brute-force success (AC:H); impact is account compromise (C:H/I:H), not availability (A:N).
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
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/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
Lifecycle Timeline
4DescriptionCVE.org
openssl_encrypt versions before 1.4.0 use an in-memory rate limiter for TOTP brute-force protection that is not shared across workers and is lost on server restart. Attackers can distribute authentication attempts across multiple server instances or retry immediately after a restart to bypass rate limiting protections.
AnalysisAI
Authentication brute-force protection can be bypassed in jahlives openssl_encrypt before 1.4.0 because the TOTP rate limiter is held in per-process in-memory state (a class-level defaultdict) rather than shared storage. In multi-worker or multi-instance deployments each worker enforces its own independent counters, and all lockout state evaporates on restart, so an attacker can parallelize or restart-reset their way through TOTP guesses. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Requires a deployment where the openssl_encrypt server enforces TOTP second-factor authentication AND is either run with multiple workers/instances (Gunicorn/uwsgi multi-worker or load-balanced replicas) so per-process counters can be split, or is subject to periodic restarts that reset the in-memory lockout state - either condition alone enables the bypass. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The vendor CVSS 4.0 score of 9.3 (AV:N/AC:L/PR:N/UI:N, VC/VI/VA:H) treats this as critical, but that rating appears to assume the rate-limiter bypass directly yields full account compromise; in practice the flaw removes a defense-in-depth control rather than granting code execution, and turning it into account takeover still requires successfully brute-forcing a 6-digit TOTP (and typically already possessing the first-factor password), which raises real-world attack complexity above what AC:L implies. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | An attacker who already holds a victim's password targets the TOTP step and fans guesses across several backend workers (or many horizontally scaled instances) so that no single process's counter reaches the lockout threshold, and/or triggers/waits for a worker restart to wipe accumulated attempts, iterating until a valid 6-digit code lands and 2FA is defeated. No public exploit code was identified, but the bypass technique is straightforward given the described architecture and would only require scripting concurrent authentication attempts. |
| Remediation | Vendor-released patch: upgrade openssl-encrypt to 1.4.0, which was fixed in commit 2749bc0 on branch releases/1.4.x by introducing an abstract RateLimitBackend with InMemoryBackend and DatabaseBackend implementations and defaulting to DatabaseBackend when a database is available (https://github.com/jahlives/openssl_encrypt/commit/2749bc0949b34a5921a35fb4a3f1856fc51916de). … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours: identify all systems running jahlives openssl_encrypt versions before 1.4.0 across development, testing, and production environments. …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
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
Sandbox escape in the openssl_encrypt Python library (jahlives) before 1.4.0 lets attacker-supplied plugin code break ou
Insecure PRNG import in the jahlives openssl_encrypt Python package (all versions before 1.4.0) places Python's non-cryp
Authentication bypass in the openssl_encrypt Python library (versions before 1.4.0) lets attackers who can tamper with c
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
Sandbox escape in the openssl_encrypt Python library (jahlives) before 1.4.0 allows attacker-supplied plugins to run wit
Authentication bypass in the jahlives openssl_encrypt library (all versions before 1.4.0) lets remote unauthenticated at
Integrity-protection bypass in the jahlives openssl_encrypt Python library (all versions before 1.4.0) lets an attacker
Weak cryptographic key derivation in the openssl_encrypt Python library (all versions before 1.4.0) stems from its key-n
Arbitrary code execution in jahlives openssl_encrypt before 1.4.0 stems from an inconsistent sandbox: the runtime Plugin
Audit-trail corruption and a security-control race condition in the Python library openssl_encrypt (by jahlives) before
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today