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
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. No public exploit is identified at time of analysis, and it is not listed in CISA KEV; a vendor patch exists in 1.4.0.
Technical ContextAI
openssl_encrypt is a Python encryption tool/library (pip package openssl-encrypt) whose server component implements TOTP-based second-factor authentication in openssl_encrypt_server/modules/pepper/totp.py. The vulnerable design stores brute-force accounting - attempts (defaultdict(list)) and lockouts (dict) - as a class variable inside TOTPRateLimiter, instantiated once per Python process as TOTPService._rate_limiter. This maps to CWE-770 (Allocation of Resources Without Limits or Throttling): the throttle exists but its scope is a single process's heap, so it fails to bound attempts globally. Under common production topologies (Gunicorn/uwsgi multi-worker, or horizontally scaled instances behind a load balancer) counters are not coordinated, and because the state is non-persistent it is also reset by any process restart.
RemediationAI
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). If you cannot upgrade immediately, the effective compensating controls follow the vendor's own recommendation: back the rate limiter with shared, persistent storage such as Redis or the database, or use a shared-memory backend so counters and lockouts are coordinated across workers and survive restarts. As a stopgap you can run the server as a single worker/instance (removes cross-worker distribution but sacrifices scalability and throughput) and add an external throttle at the reverse proxy or WAF keyed on source IP and account (which mitigates naive brute force but not distributed/rotating-source attempts and can cause false lockouts). Review the advisory at https://github.com/jahlives/openssl_encrypt/security/advisories/GHSA-h45m-mgcp-q388 for the authoritative fix guidance.
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
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
Arbitrary command execution in jahlives' openssl_encrypt before 1.4.9 arises when the tool's 'info' command reconstructs
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today