CVE-2026-74880 in openssl_encrypt
Summary
by MITRE • 08/17/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/17/2026
The vulnerability identified in openssl_encrypt prior to version 1.4.0 represents a critical implementation flaw related to the handling of sensitive authentication credentials within web application routing mechanisms. Specifically, the software incorrectly permits refresh tokens to be transmitted as URL query parameters when interacting with keyserver and telemetry server endpoints. This architectural decision violates fundamental security principles regarding the protection of long-lived authentication secrets, which are designed to maintain user sessions without requiring repeated entry of primary credentials such as passwords or multi-factor authenticators. By exposing these high-value tokens in the Uniform Resource Locator structure, the application inadvertently creates multiple vectors for credential theft that extend far beyond direct network interception.
The technical root cause lies in the misuse of HTTP GET requests and query string parameters for data transmission where sensitive state information is involved. URL query strings are inherently visible to a wide array of intermediaries and client-side components during standard web browsing operations. Unlike request bodies or secure headers, which can be encrypted via TLS and remain hidden from intermediate infrastructure, query parameters are logged extensively across the entire HTTP ecosystem. This includes server access logs that record every incoming request for auditing purposes, reverse proxy configurations that cache or log traffic details, load balancers that monitor routing decisions, and DNS resolvers that may retain metadata about domain queries. Furthermore, modern web browsers often store full URLs in their history databases to facilitate user navigation, creating a persistent local repository of sensitive data on the end-user device.
The operational impact of this vulnerability is severe due to the nature of refresh tokens themselves. Refresh tokens typically possess longer lifespans than access tokens and are capable of generating new sessions indefinitely until revoked or expired by policy. An attacker who successfully extracts these tokens from any of the aforementioned log sources can achieve unauthorized persistent access to the victim's account without needing to compromise their password or bypass multi-factor authentication controls. This capability effectively neutralizes many layered security defenses, as the refresh token serves as a master key for session management. The threat landscape is further exacerbated by the fact that HTTP Referer headers are frequently transmitted with every subsequent request made from a page containing links to external domains. If an authenticated user clicks on a malicious link or visits a compromised third-party site while logged in, the browser automatically includes the full URL of the current page—including any embedded refresh tokens—in the Referer header sent to the destination server. This mechanism allows remote attackers to harvest credentials simply by tricking users into visiting specific URLs, constituting a classic Cross-Site Request Forgery variant or information leakage scenario depending on the exact exploitation method.
This flaw aligns directly with CWE-598 improper use of URL query parameters for sensitive data and CWE-201 insertion of sensitive information into an HTTP response header when logs are involved. From a tactical perspective, it maps to MITRE ATT&CK techniques such as T1530 Data from Local System which covers the harvesting of tokens from browser history or local storage, and T1078 Valid Accounts if the stolen token is used for legitimate authentication. The exposure also relates to T1552 Unsecured Credentials where sensitive data is stored in a location accessible to unauthorized actors through logging artifacts.
Mitigation strategies must prioritize immediate remediation of the codebase alongside defensive operational changes. The primary fix involves upgrading openssl_encrypt to version 1.4.0 or later, which presumably corrects the routing logic to reject refresh tokens in query strings for these specific endpoints. In cases where an upgrade is not immediately feasible, developers should refactor the affected keyserver and telemetry server routes to utilize HTTP POST requests with request bodies instead of GET requests with query parameters. This ensures that sensitive data is transmitted within the message body rather than the URL structure. Additionally, implementing strict Content Security Policy directives can help mitigate some risks associated with Referer header leakage by controlling how much referrer information is sent to external origins. On the infrastructure side, organizations should configure web servers and proxies to mask or omit query strings from access logs where possible, although this must be balanced against forensic requirements for security investigations. Regular auditing of log retention policies and secure storage practices will further reduce the window of opportunity for attackers attempting to harvest these credentials from historical data stores.