{"id":3332,"date":"2025-05-30T15:32:32","date_gmt":"2025-05-30T14:32:32","guid":{"rendered":"https:\/\/aegislens.com\/home\/?p=3332"},"modified":"2025-05-30T15:32:54","modified_gmt":"2025-05-30T14:32:54","slug":"onedrive-file-picker-vulnerability-oauth-over-permission-and-full-drive-access","status":"publish","type":"post","link":"https:\/\/aegislens.com\/home\/onedrive-file-picker-vulnerability-oauth-over-permission-and-full-drive-access\/","title":{"rendered":"OneDrive File Picker Vulnerability: OAuth Over-Permission and Full Drive Access"},"content":{"rendered":"\n

Introduction<\/h2>\n\n\n\n

A recently disclosed security flaw in Microsoft\u2019s OneDrive File Picker<\/strong> tool allows third-party web applications to gain full read access to a user\u2019s entire OneDrive cloud storage\u2014even if the user only intended to share or upload a single fileoasis.security<\/a>. This issue was uncovered by Oasis Security\u2019s research team and is estimated to affect hundreds of popular apps (including ChatGPT, Slack, Trello, and ClickUp), potentially exposing millions of users to unauthorized data accessoasis.security<\/a>. In practical terms, once a user consents through the OneDrive File Picker, the integrated application can read (and in some cases write or delete) all files in the user\u2019s OneDrive, far beyond the one file the user selected. The impact of this over-permission is severe \u2013 it risks extensive data leakage and may violate compliance regulations for sensitive informationoasis.security<\/a>.<\/p>\n\n\n\n

Microsoft was notified of the flaw through responsible disclosure, and while the company acknowledged<\/strong> the problem, it noted that the system is essentially \u201cworking as designed.\u201d Microsoft has indicated it may consider<\/em> future improvements to better align the File Picker\u2019s access with the principle of least privilege, but no fix or timeline has been announced as of this writinghackread.com<\/a>linkedin.com<\/a>. The following report analyzes the technical root cause of this vulnerability, demonstrates how one might reproduce it in a controlled proof-of-concept, reviews the disclosure timeline and responses, evaluates the security\/compliance risks for enterprises, and recommends mitigation strategies. We also identify which third-party services are known to use the OneDrive File Picker and are thereby impacted.<\/p>\n\n\n\n

1. Technical Root Cause: OAuth Scope Misconfiguration<\/h2>\n\n\n\n

At the heart of this vulnerability is an OAuth scope design flaw<\/strong> \u2013 the OneDrive File Picker requires overly broad permissions that grant applications full drive access instead of limiting them to a specific file or folder. In essence, Microsoft\u2019s implementation lacks fine-grained OAuth scopes for file-level access. Rather than requesting access only to the user-selected file, the OneDrive File Picker often asks for blanket permissions such as Files.Read.All<\/code> or Files.ReadWrite.All<\/code>, which grant the app full access to every file and folder in the user\u2019s OneDrive<\/strong>linkedin.com<\/a>. Users consenting to the File Picker may not realize that clicking \u201cAllow\u201d is giving the application unrestricted read (or read\/write) rights over their entire cloud drivelinkedin.com<\/a>. The consent dialog presented during this process is misleadingly vague \u2013 it suggests the app will access \u201cyour files\u201d for the operation, but does not clearly communicate that all<\/em> files in OneDrive are included, not just the one being sharedoasis.security<\/a>hackread.com<\/a>. This discrepancy between user intent and actual scope is a core issue.<\/p>\n\n\n\n

Lack of fine-grained scopes<\/strong> means developers have no option to request narrower permissions. According to Oasis, OneDrive\u2019s OAuth framework forces use of broad delegated scopes like MyFiles.Read<\/code>, Sites.Read.All<\/code>, or Files.ReadWrite.All<\/code> with no way to scope access to individual fileslinkedin.com<\/a>. This \u201call-or-nothing\u201d approach violates the principle of least privilege. It makes it impossible to enforce that an app only sees what it truly needs; even legitimate apps end up over-permissioned simply because no lesser scope existsoasis.security<\/a>oasis.security<\/a>. As one security expert noted, the File Picker currently grants \u201call or nothing\u201d<\/strong> access \u2013 applications get an entire OneDrive\u2019s worth of data or nothing, rather than a finer-grained subsetdarkreading.com<\/a>.<\/p>\n\n\n\n

It\u2019s illustrative to compare this with other cloud storage platforms\u2019 design choices. Google Drive<\/em>, for instance, offers a scope called drive.file<\/code> that limits an app\u2019s access to only files explicitly opened or created by that app, rather than the user\u2019s whole Drive. Dropbox<\/em> takes an even stricter approach: its Chooser SDK<\/strong> allows users to select a file for an app without the app ever receiving an OAuth token to the whole accountlinkedin.com<\/a>. In contrast, Microsoft\u2019s OneDrive File Picker does not have a \u201cfile-specific\u201d OAuth scope \u2013 it leverages broad Graph API permissions (e.g. Files.Read.All<\/strong>) that inherently cover the user\u2019s entire drive contentlinkedin.com<\/a>. The table below summarizes this difference in OAuth scope granularity:<\/p>\n\n\n\n

Cloud Storage Platform<\/th>File Picker Permission Scope<\/th>Access Granted to Third-Party App<\/th><\/tr><\/thead>
OneDrive (Microsoft)<\/strong><\/td>Files.Read.All<\/code> (or Files.ReadWrite.All<\/code> for uploads) (Delegated OAuth)<\/strong><\/td>Full access<\/strong> to all files in the user\u2019s OneDrive (all folders and files the user can access)linkedin.com<\/a>.<\/td><\/tr>
Google Drive<\/strong><\/td>drive.file<\/code> (OAuth)<\/strong><\/td>Restricted access to only the files the user selects or creates<\/em> with the app (no access to other Drive content)linkedin.com<\/a>.<\/td><\/tr>
Dropbox<\/strong><\/td>Proprietary Chooser<\/em> SDK (no broad token)<\/td>App receives a direct link or file object for the chosen file only<\/strong>, with no general account access<\/strong>linkedin.com<\/a>.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Table: Comparison of file picker permission models for OneDrive vs. Google Drive and Dropbox. Microsoft\u2019s model uses broad scopes covering the entire drive, whereas Google and Dropbox provide more granular or limited access.<\/em>linkedin.com<\/a><\/p>\n\n\n\n

Beyond the scope misconfiguration, there is a secondary technical issue exacerbating the risk: insecure storage of OAuth tokens<\/strong> on the client side. Oasis Security found that various versions of the OneDrive File Picker SDK handle tokens in less-than-secure ways. Older implementations (v6.0\u20137.2) used implicit OAuth flows that returned tokens in URL fragments or stored them in the browser\u2019s localStorage, where a malicious script could potentially retrieve themlinkedin.com<\/a>. The latest File Picker v8.0<\/strong> has moved to a more secure OAuth 2.0 Authorization Code flow using Microsoft\u2019s Authentication Library (MSAL); however, it still stores the obtained access tokens in plaintext within the browser\u2019s sessionStorage<\/strong> by defaultoasis.security<\/a>. If an attacker can execute script in the context of the app (through an XSS vulnerability or malicious browser extension, for example), they could steal these tokens from session storage. Moreover, if the app requests the offline_access<\/code> scope, a refresh token is also issued, potentially extending the lifetime of the access far beyond the default one-hour token expiryoasis.security<\/a>. In short, not only are third-party apps getting overly broad OneDrive tokens, but those tokens might also be insufficiently protected on the client, compounding the security exposuresecureworld.io<\/a>hackread.com<\/a>. (Notably, OpenAI\u2019s ChatGPT integration was found to be using File Picker v8.0, meaning it inherits the MSAL token storage behavioroasis.security<\/a>.)<\/p>\n\n\n\n

To summarize, the root cause of this vulnerability is a design-level over-permissioning<\/strong> in OneDrive\u2019s OAuth scopes. The File Picker integration requests full OneDrive drive access due to lack of item-level scope granularity, and the consent UI does not warn users of the breadth of access being grantedoasis.security<\/a>oasis.security<\/a>. This is aggravated by token handling practices that could allow these powerful tokens to be stolen or misused. Any web application using the official OneDrive Picker API can inadvertently (or deliberately) obtain far more privileges than the user expects<\/strong>, which is why this flaw is so widely impactful.<\/p>\n\n\n\n

2. Proof-of-Concept Demonstration Feasibility<\/h2>\n\n\n\n

Demonstrating this vulnerability in a controlled environment is feasible with moderate effort, as it essentially involves replicating the normal OAuth flow of the OneDrive File Picker and then observing the scope of access the third-party application receives. The key is to show that after a user selects a single file, the third-party app\u2019s access token can be used to read other files<\/strong> in the user\u2019s OneDrive, proving the over-broad permission.<\/p>\n\n\n\n

A potential Proof-of-Concept (PoC)<\/strong> setup would involve the following steps:<\/p>\n\n\n\n

    \n
  1. App Registration<\/strong> \u2013 Set up a dummy web application and register it in Azure AD with OneDrive\/Graph API permissions. For an \u201copen file\u201d<\/strong> style picker, the app will need a delegated permission such as Files.Read.All<\/code> (for read-only access) or Files.ReadWrite.All<\/code> (if demonstrating upload\/save). This is the same permission real integrations use. The app\u2019s redirect URI and client ID are obtained in this step.<\/li>\n\n\n\n
  2. Integrate the OneDrive File Picker<\/strong> \u2013 Include Microsoft\u2019s OneDrive Picker SDK in the web app. One can use either the older v7<\/strong> (which handles auth internally via implicit flow) or v8<\/strong> (which requires using MSAL for auth). Using v7.x<\/strong> might simplify the PoC because it employs an implicit OAuth flow that will return an access token in the URL fragment upon consentlinkedin.com<\/a>. Using v8.0 with MSAL is also possible: the app would invoke MSAL to authenticate the user and acquire an access token for OneDrive, then pass that token to the Picker. In either case, when the user clicks a button to attach or pick a OneDrive file, they will be presented with Microsoft\u2019s OAuth consent screen<\/strong>.<\/li>\n\n\n\n
  3. Consent to a Single File<\/strong> \u2013 As the test user, go through the OAuth consent dialog, granting the application the permissions it requests. The dialog will likely ask for permission to \u201cRead your files\u201d or similar (which, due to the broad scope, actually means all files). For the PoC, select a single benign file (e.g. a test document) from your OneDrive to authorize and share with the app. After consent, the File Picker SDK will typically return some result to the application \u2013 for example, a file object containing the chosen file\u2019s name or a download link. Crucially, it will also have facilitated the retrieval or storage of an OAuth access token<\/strong> for Graph API calls. In v7<\/strong>, this token might be visible as a URL fragment (e.g. #access_token=<token>&scope=Files.Read.All\u2026<\/code> in the redirect URL) or stored in localStorage<\/code>linkedin.com<\/a>. In v8, the token will be managed by MSAL (likely stored in sessionStorage<\/code>) and accessible via the MSAL client object in JavaScriptlinkedin.com<\/a>oasis.security<\/a>.<\/li>\n\n\n\n
  4. Use the Token to Access Other Files<\/strong> \u2013 With the access token obtained (by parsing the URL fragment in v7 or pulling from MSAL in v8), the PoC can then directly call the Microsoft Graph API to enumerate or read files outside of the originally selected item. For example, one can issue a Graph request to list the contents of the OneDrive root directory (GET \/me\/drive\/root\/children<\/code>) or retrieve a known file in another folder. Because the token carries the Files.Read.All<\/code> scope, this call will succeed \u2013 the application can fetch file names and contents for any file in the drive<\/strong>, not just the one originally picked. This confirms that the third-party app has full read access<\/strong> to the OneDrive. If the token also had write scope (Files.ReadWrite.All<\/code>), the app could create, modify, or delete files on OneDrive as wellcsa.gov.sg<\/a>. A successful PoC may log the names of several files from the user\u2019s drive to demonstrate unauthorized breadth of access (without exposing the file contents to any truly malicious party).<\/li>\n\n\n\n
  5. Controlled Environment<\/strong> \u2013 Throughout the PoC, it\u2019s important to use non-sensitive data and test accounts. The demonstration should be done in a controlled environment<\/strong> (e.g., the researcher\u2019s own OneDrive or a demo tenant) to avoid any actual data breach. No actual exploitation beyond the researcher\u2019s account is necessary; the goal is simply to illustrate the potential for abuse. After the test, the researcher should revoke the dummy app\u2019s access via the Microsoft Account or Azure AD settings to clean up.<\/li>\n<\/ol>\n\n\n\n

    The feasibility of this PoC lies in the fact that it does not require breaking any security mechanism \u2013 one is simply leveraging the official OneDrive File Picker flow as designed, then observing the unintended consequences. Oasis Security effectively did this analysis by inspecting the token scopes and behavior of real applications. For instance, they noted that even an application as reputable as ChatGPT, when integrated with OneDrive Picker, would receive an access token permitting read of all fileslinkedin.com<\/a>hackread.com<\/a>. By building a custom minimal app, a security tester can replicate what those apps are doing under the hood. Additionally, Oasis pointed out that the older Picker SDK made such testing easier by exposing tokens in the front-end (URL or local storage)linkedin.com<\/a>. A tester could intentionally use the legacy implicit grant<\/strong> flow to grab the token directly from the browser address bar after consent. On the newer MSAL-based flow, one might insert debugging code in the app to output the acquired token (since MSAL stores it in sessionStorage, a developer can retrieve it via window.sessionStorage<\/code> or MSAL APIs after authentication). Once the token is in hand, its scopes can be inspected and it can be used in API calls to confirm the level of access.<\/p>\n\n\n\n

    In summary, developing a PoC for this vulnerability is straightforward because the vulnerability is the normal functionality<\/em> of the File Picker. The PoC steps above essentially mirror how any third-party integration works \u2013 the only difference is that instead of trusting the token, we actively use it to highlight that we can open files beyond the user\u2019s original intention. This serves to concretely demonstrate the OAuth scope misconfiguration problem.<\/p>\n\n\n\n

    3. Disclosure Timeline and Microsoft\u2019s Response<\/h2>\n\n\n\n

    The OneDrive File Picker over-permission issue was discovered by Oasis Security\u2019s researchers and handled via responsible disclosure. Oasis reported the flaw to Microsoft<\/strong> and simultaneously alerted some major affected vendors (e.g. those behind ChatGPT, Slack, Trello, etc.) prior to public release of their findingsoasis.security<\/a>hackread.com<\/a>. Oasis published their research on May 28, 2025, after giving Microsoft advance noticehackread.com<\/a>hackread.com<\/a>.<\/p>\n\n\n\n

    Microsoft\u2019s initial response was that the OneDrive File Picker was functioning as intended<\/em>, since it was built without granular scopes. In other words, Microsoft acknowledged the report but indicated that this broad access behavior is a known trade-off of the current design (essentially a **\u201cby design\u201d issue rather than a simple bug)hackread.com<\/a>. Importantly, Microsoft did not<\/strong> rush out an emergency patch or advisory, because there was no straightforward fix given the architectural limitations. Instead, Microsoft stated it \u201cmay consider improvements in the future\u201d<\/strong> to better align the File Picker\u2019s permissions with the principle of least privilegelinkedin.com<\/a>. This suggests that Microsoft might introduce more fine-grained OAuth scopes or an updated picker SDK in a future update, but specifics were not provided. As of the end of May 2025, no fix or new feature had been rolled out yet, and the vulnerability remained effectively unpatched in production.<\/p>\n\n\n\n

    It appears Microsoft is evaluating how to resolve this without breaking existing integrations. One potential improvement (speculative) could be implementing a scope akin to Google\u2019s drive.file<\/code> for OneDrive, or changing the File Picker to use short-lived, file-specific tokens or share links. In communications with the press, Microsoft has not committed to a timeline, only acknowledging the concern. For example, tech outlets reported that \u201cMicrosoft has acknowledged the issue and is reportedly evaluating changes,\u201d<\/strong> but with no official fix available yetsecureworld.io<\/a>. A Microsoft spokesperson comment (as reported by one source) essentially said the system currently works as designed and any changes would come as future enhancementshackread.com<\/a>.<\/p>\n\n\n\n

    Disclosure Timeline Highlights:<\/strong> Oasis\u2019s report was published May 28, 2025, but the discovery likely happened some weeks or months prior. The issue gained media traction immediately, with multiple security news outlets covering it on May 28-29. The Cyber Security Agency of Singapore even issued a security alert on May 30, 2025, summarizing the flaw and its riskscsa.gov.sg<\/a>. As of this report, Microsoft has not issued a public advisory on their MSRC (Microsoft Security Response Center) or a CVE, likely because it is seen as a design limitation rather than a vulnerability that can be quickly patched. However, under mounting awareness, Microsoft will be under pressure to address it through a product update or clearer warnings. In the interim, the onus is on users and administrators to manage this risk (as discussed in the next sections).<\/p>\n\n\n\n

    4. Security and Compliance Risks in Enterprise Environments<\/h2>\n\n\n\n

    This vulnerability introduces significant security and compliance risks<\/strong>, especially in enterprise contexts where OneDrive may house sensitive corporate data. When an employee connects a third-party app via the OneDrive File Picker, they could be unintentionally granting that app (and by extension, anyone with access to that app or its tokens) the ability to read, copy, modify, or delete all files<\/strong> in their OneDrive accountcsa.gov.sg<\/a>. The potential scenarios of abuse include:<\/p>\n\n\n\n