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
Signing secret is publicly readable without any credentials, so PR:N and AC:L; A:L because the description confirms authentication bypass and data access but not denial-of-service.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
3DescriptionCVE.org
openssl_encrypt versions before 1.4.0 contain hardcoded default JWT signing secrets in config.py that pass validation checks. Attackers with access to source code can forge valid JWT tokens for any client_id to gain authenticated access to keyserver and telemetry APIs.
AnalysisAI
Hardcoded JWT signing secrets embedded in config.py of openssl_encrypt versions before 1.4.0 allow any party with access to the library's publicly hosted source code to forge cryptographically valid JWT tokens for arbitrary client IDs, bypassing authentication on keyserver and telemetry APIs. The static secrets pass all validation checks, making exploitation a matter of reading the source and generating a token with standard JWT tooling-no brute-force or cryptographic attack is required. No CISA KEV listing or public proof-of-concept exploit has been identified at time of analysis, but the trivially low exploitation complexity makes this a high-priority remediation for any network-exposed deployment running an unpatched version.
Technical ContextAI
openssl_encrypt (CPE: cpe:2.3:a:jahlives:openssl_encrypt) is an open-source PHP library by jahlives that provides OpenSSL-based encryption utilities and exposes keyserver and telemetry APIs protected by JWT bearer token authentication. The root cause is CWE-798 (Use of Hard-coded Credentials): the library ships with a static JWT signing secret defined as a default value in config.py rather than requiring each deployment to supply an operator-generated secret. Because the library is distributed publicly on GitHub, the signing key is accessible to any observer who inspects the repository. An attacker who obtains the key can use any standard JWT library to produce a signed token asserting any client_id, and the application will accept it as a legitimate credential because the cryptographic signature validates correctly against the known secret. All releases in the range 0 to less than 1.4.0 are affected per the vendor advisory and EUVD-2026-60112.
RemediationAI
Upgrade openssl_encrypt to version 1.4.0 or later, which resolves the hardcoded credential issue; the vendor security advisory at https://github.com/jahlives/openssl_encrypt/security/advisories/GHSA-qc6h-gfjh-7qqg contains authoritative upgrade instructions. If an immediate upgrade cannot be performed, operators must supply a deployment-specific, randomly generated JWT signing secret through the application's configuration layer to override the hardcoded default-leaving the default value in place provides no protection even if operators are aware of it, since the secret is already publicly known via the source repository. As a temporary compensating control, restrict network access to the keyserver and telemetry API endpoints to explicitly trusted source addresses using firewall rules or an API gateway; this limits the attacker's ability to present forged tokens even if obtained, but does not remediate the underlying CWE-798 defect and must be treated as a short-term measure only pending upgrade.
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 weakness CWE-798 – Use of Hard-coded Credentials
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-60112
GHSA-pj24-vj9g-8vg8