CVE-2026-114542 in Simple OAuth OAuth2 & OpenID Connect Plugin
Summary
by MITRE • 10/30/2026
Use of Web Browser Cache Containing Sensitive Information vulnerability in Drupal Simple OAuth (OAuth2) & OpenID Connect allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects Simple OAuth (OAuth2) & OpenID Connect versions: from 6.1.0 to 6.1.3.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in Drupal's Simple OAuth module, specifically within versions ranging from 6.1.0 to 6.1.3, represents a critical failure in the handling of sensitive authentication data through web browser caching mechanisms. This flaw is categorized under CWE-524, which denotes the use of cache containing information that could be considered private or sensitive. In the context of OAuth2 and OpenID Connect implementations, this module facilitates secure authorization flows where tokens are exchanged between clients and identity providers. The core technical deficiency lies in the HTTP response headers generated during these authentication exchanges failing to include appropriate Cache-Control directives such as no-store, no-cache, or must-revalidate for responses containing access tokens, refresh tokens, or ID tokens. Consequently, intermediate caching systems, including web browsers, proxy servers, and potentially shared disk caches on mobile devices, may store these sensitive payloads in plaintext or easily retrievable formats without expiration constraints that would limit their window of exposure.
From an operational perspective, this misconfiguration allows for the exploitation of incorrectly configured access control security levels by enabling unauthorized parties to intercept cached authentication credentials. An attacker with local system access, such as a user on a shared public computer or a malicious script running in a different tab within the same browser session, can query the browser's cache storage APIs to retrieve previously issued tokens. This scenario is particularly dangerous because OAuth2 and OpenID Connect rely heavily on the confidentiality of these tokens to maintain session integrity and prevent unauthorized access to protected resources. If an attacker obtains a valid access token from the cache, they can impersonate the legitimate user without needing their password or multi-factor authentication credentials, effectively bypassing the intended security controls. This aligns with MITRE ATT&CK technique T1530, Data from Local System Exfiltration via Browser Cache, and highlights how improper data handling at the client side undermines server-side access control policies.
The impact of this vulnerability extends beyond simple credential theft to include potential account takeover and unauthorized data exfiltration depending on the scopes granted by the affected tokens. Since many modern web applications rely on these tokens for API calls that modify user data or perform administrative actions, an attacker leveraging cached credentials can execute state-changing operations as the victim. This is exacerbated in environments where users frequently log into multiple accounts or use single sign-on solutions across different domains within the same browser context. The lack of strict cache control directives means that even after a user logs out, the tokens may remain accessible in the local storage until the cache is manually cleared or expires based on default system policies rather than application-specific security requirements. This persistence creates a prolonged window of vulnerability where sensitive information remains exposed to potential retrieval by malicious actors with access to the client environment.
To mitigate this risk, immediate action must be taken by upgrading the Simple OAuth module to version 6.1.4 or later, which addresses these caching issues by implementing proper HTTP cache control headers for all responses containing authentication data. Developers and system administrators should also review their deployment configurations to ensure that no reverse proxies or CDN layers are inadvertently overriding these directives with more permissive caching policies. Additionally, it is advisable to implement additional client-side security measures such as using HttpOnly flags on cookies if applicable, ensuring secure flag settings for transport layer encryption, and educating users about the risks of accessing sensitive applications from shared or public computing environments. Regular audits of authentication flows should include checks for proper cache control headers in both request and response cycles to prevent similar vulnerabilities related to information leakage through caching mechanisms in future updates.