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
Exploitation depends on obtaining a leaked token from logs/history/Referer rather than a direct request, so AC:H; a captured refresh token yields account access (C:H) with limited integrity impact and no availability impact.
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 accept refresh tokens as URL query parameters in keyserver and telemetry server routes. Attackers can extract tokens from server logs, proxy logs, browser history, and HTTP Referer headers to gain unauthorized access.
AnalysisAI
Sensitive-token exposure in openssl_encrypt (the jahlives Python package, pip 'openssl-encrypt') before 1.4.0 stems from the keyserver and telemetry server accepting refresh tokens as GET query parameters. Because URLs are routinely written to server access logs, proxy/CDN logs, browser history, and forwarded in HTTP Referer headers, any party with access to those artifacts can harvest a valid refresh token and mint new access tokens, effectively bypassing authentication. …
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 | Exploitation requires that the refresh token first be captured from a URL-leakage sink - specifically the openssl_encrypt keyserver or telemetry server access logs, an intermediary proxy/CDN log, local browser history, or a Referer header sent when navigating away from a route containing the token - because the flaw is that the /refresh routes accept refresh_token as a GET Query(...) parameter in versions before 1.4.0. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The published CVSS 4.0 score of 9.3 (AV:N/AC:L/PR:N/UI:N/VC:H/VI:H/VA:H) treats this as trivially exploitable with total impact, but that rating overstates attacker control: exploitation is not a direct request an attacker sends to the server - it requires the attacker to first obtain a leaked token from a secondary artifact (access/proxy log, browser history, or a Referer header sent to a third-party site). … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | An attacker who can read the server's access logs, a shared upstream proxy/CDN log, or a browser's history on a used workstation searches for refresh_token query values, extracts a still-valid token, and submits it to the refresh endpoint to obtain fresh access tokens and impersonate the user. Alternatively, if a keyserver page links out to an attacker-controlled site, the token is disclosed automatically via the HTTP Referer header. … |
| Remediation | Upgrade to openssl_encrypt 1.4.0, which contains the fix (Vendor-released patch: 1.4.0; upstream commit 4b2adb05cde8a7ee03cdd271755da3b377c68011 on branch releases/1.4.x) that moves the refresh token from a query parameter into the POST request body. … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours, identify all applications and services using the openssl-encrypt package (pip 'openssl-encrypt') and document their version numbers and deployment locations. …
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 Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-60099
GHSA-j2j2-c4gj-7cmc