CVE-2026-91201 in DocsGPT
Summary
by MITRE • 09/15/2026
DocsGPT through 0.20.0 posts OAuth connector session tokens to a wildcard target origin in the callback-status endpoint without validating sender origin. Attackers can obtain session tokens and provider account emails by acting as window.opener during OAuth authorization, then use tokens to disconnect victims' cloud storage connectors.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified in DocsGPT versions through 0.20.0 represents a critical failure in the implementation of Cross-Origin Resource Sharing policies within its OAuth authentication flow. Specifically, the callback-status endpoint is configured with an overly permissive Access-Control-Allow-Origin header set to a wildcard value, indicating that any origin is permitted to access the response data. This configuration bypasses standard browser security mechanisms designed to prevent unauthorized cross-origin requests from accessing sensitive resources. The core technical flaw lies in the complete absence of sender origin validation on the server side when processing these callback responses. By not verifying that the request originates from a trusted, pre-registered domain, the application inadvertently exposes session tokens and associated user data to any malicious webpage hosted anywhere on the internet.
The exploitation vector for this vulnerability relies heavily on the behavior of window.opener in modern web browsers during OAuth authorization flows. When a victim initiates an OAuth login with DocsGPT, they are redirected to their cloud provider's authentication page. Upon successful authentication, the browser typically returns control to the application via a callback URL. If an attacker can manipulate this flow such that they act as the window.opener of the tab containing the authorization response, they gain programmatic access to the data returned by the server. Because the wildcard CORS policy allows any origin to read the response body regardless of where the request originated, the malicious page hosted by the attacker can successfully retrieve the OAuth connector session tokens and provider account emails embedded in that response. This technique effectively circumvents same-origin policies that would normally restrict such access if the origins did not match or if proper validation were present.
The operational impact of this vulnerability is severe, primarily affecting user privacy and data integrity within connected cloud storage services. Once an attacker obtains these session tokens through the described mechanism, they possess valid credentials to interact with the victim's linked cloud storage provider on behalf of the application. The most immediate consequence demonstrated in reports is the ability for attackers to disconnect victims' cloud storage connectors from DocsGPT. This action disrupts service availability and can lead to data loss if automated sync processes are interrupted without warning. Beyond disconnection, possession of valid session tokens generally implies broader risks including unauthorized access to stored documents, potential exfiltration of sensitive files, or further lateral movement within the victim's cloud ecosystem depending on the permissions granted by those specific connectors.
From a classification perspective, this vulnerability aligns with CWE-942, which describes Permissive Cross-domain Policy with Untrusted Domains, as well as CWE-352 for Cross-Site Request Forgery if the tokens were used to perform actions without proper anti-CSRF protections in subsequent requests. In terms of MITRE ATT&CK mapping, this falls under T1078 Valid Accounts and specifically relates to techniques involving cloud accounts where attackers leverage stolen or intercepted credentials to maintain persistence or execute malicious operations within a SaaS environment. The lack of origin validation is also indicative of CWE-20 Improper Input Validation regarding the handling of HTTP headers and request metadata during the authentication callback process.
To mitigate this vulnerability, developers must immediately replace the wildcard Access-Control-Allow-Origin header with specific, allow-listed origins that are explicitly trusted for OAuth callbacks. It is essential to validate the Origin or Referer HTTP headers on the server side to ensure that requests to the callback-status endpoint originate only from the legitimate application domain. Additionally implementing strict SameSite cookie attributes and ensuring that session tokens are transmitted securely via HttpOnly cookies rather than exposed in response bodies accessible by JavaScript can further reduce risk. Regular security audits focusing on OAuth implementations should verify that all endpoints handling sensitive authentication data enforce strict origin checks, thereby preventing unauthorized cross-origin access to user credentials and personal information.