OneDrive File Picker Vulnerability: OAuth Over-Permission and Full Drive Access

Introduction

A recently disclosed security flaw in Microsoft’s OneDrive File Picker tool allows third-party web applications to gain full read access to a user’s entire OneDrive cloud storage—even if the user only intended to share or upload a single fileoasis.security. This issue was uncovered by Oasis Security’s 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. 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’s OneDrive, far beyond the one file the user selected. The impact of this over-permission is severe – it risks extensive data leakage and may violate compliance regulations for sensitive informationoasis.security.

Microsoft was notified of the flaw through responsible disclosure, and while the company acknowledged the problem, it noted that the system is essentially “working as designed.” Microsoft has indicated it may consider future improvements to better align the File Picker’s access with the principle of least privilege, but no fix or timeline has been announced as of this writinghackread.comlinkedin.com. 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.

1. Technical Root Cause: OAuth Scope Misconfiguration

At the heart of this vulnerability is an OAuth scope design flaw – 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’s 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 or Files.ReadWrite.All, which grant the app full access to every file and folder in the user’s OneDrivelinkedin.com. Users consenting to the File Picker may not realize that clicking “Allow” is giving the application unrestricted read (or read/write) rights over their entire cloud drivelinkedin.com. The consent dialog presented during this process is misleadingly vague – it suggests the app will access “your files” for the operation, but does not clearly communicate that all files in OneDrive are included, not just the one being sharedoasis.securityhackread.com. This discrepancy between user intent and actual scope is a core issue.

Lack of fine-grained scopes means developers have no option to request narrower permissions. According to Oasis, OneDrive’s OAuth framework forces use of broad delegated scopes like MyFiles.Read, Sites.Read.All, or Files.ReadWrite.All with no way to scope access to individual fileslinkedin.com. This “all-or-nothing” 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.securityoasis.security. As one security expert noted, the File Picker currently grants “all or nothing” access – applications get an entire OneDrive’s worth of data or nothing, rather than a finer-grained subsetdarkreading.com.

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

Cloud Storage Platform	File Picker Permission Scope	Access Granted to Third-Party App
OneDrive (Microsoft)	Files.Read.All (or Files.ReadWrite.All for uploads) (Delegated OAuth)	Full access to all files in the user’s OneDrive (all folders and files the user can access)linkedin.com.
Google Drive	drive.file (OAuth)	Restricted access to only the files the user selects or creates with the app (no access to other Drive content)linkedin.com.
Dropbox	Proprietary Chooser SDK (no broad token)	App receives a direct link or file object for the chosen file only, with no general account accesslinkedin.com.

Table: Comparison of file picker permission models for OneDrive vs. Google Drive and Dropbox. Microsoft’s model uses broad scopes covering the entire drive, whereas Google and Dropbox provide more granular or limited access.linkedin.com

Beyond the scope misconfiguration, there is a secondary technical issue exacerbating the risk: insecure storage of OAuth tokens 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–7.2) used implicit OAuth flows that returned tokens in URL fragments or stored them in the browser’s localStorage, where a malicious script could potentially retrieve themlinkedin.com. The latest File Picker v8.0 has moved to a more secure OAuth 2.0 Authorization Code flow using Microsoft’s Authentication Library (MSAL); however, it still stores the obtained access tokens in plaintext within the browser’s sessionStorage by defaultoasis.security. 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 scope, a refresh token is also issued, potentially extending the lifetime of the access far beyond the default one-hour token expiryoasis.security. 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.iohackread.com. (Notably, OpenAI’s ChatGPT integration was found to be using File Picker v8.0, meaning it inherits the MSAL token storage behavioroasis.security.)

To summarize, the root cause of this vulnerability is a design-level over-permissioning in OneDrive’s 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.securityoasis.security. 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, which is why this flaw is so widely impactful.

2. Proof-of-Concept Demonstration Feasibility

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’s access token can be used to read other files in the user’s OneDrive, proving the over-broad permission.

A potential Proof-of-Concept (PoC) setup would involve the following steps:

1. App Registration – Set up a dummy web application and register it in Azure AD with OneDrive/Graph API permissions. For an “open file” style picker, the app will need a delegated permission such as Files.Read.All (for read-only access) or Files.ReadWrite.All (if demonstrating upload/save). This is the same permission real integrations use. The app’s redirect URI and client ID are obtained in this step.
2. Integrate the OneDrive File Picker – Include Microsoft’s OneDrive Picker SDK in the web app. One can use either the older v7 (which handles auth internally via implicit flow) or v8 (which requires using MSAL for auth). Using v7.x might simplify the PoC because it employs an implicit OAuth flow that will return an access token in the URL fragment upon consentlinkedin.com. 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’s OAuth consent screen.
3. Consent to a Single File – 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 “Read your files” 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 – for example, a file object containing the chosen file’s name or a download link. Crucially, it will also have facilitated the retrieval or storage of an OAuth access token for Graph API calls. In v7, this token might be visible as a URL fragment (e.g. #access_token=<token>&scope=Files.Read.All… in the redirect URL) or stored in localStoragelinkedin.com. In v8, the token will be managed by MSAL (likely stored in sessionStorage) and accessible via the MSAL client object in JavaScriptlinkedin.comoasis.security.
4. Use the Token to Access Other Files – 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) or retrieve a known file in another folder. Because the token carries the Files.Read.All scope, this call will succeed – the application can fetch file names and contents for any file in the drive, not just the one originally picked. This confirms that the third-party app has full read access to the OneDrive. If the token also had write scope (Files.ReadWrite.All), the app could create, modify, or delete files on OneDrive as wellcsa.gov.sg. A successful PoC may log the names of several files from the user’s drive to demonstrate unauthorized breadth of access (without exposing the file contents to any truly malicious party).
5. Controlled Environment – Throughout the PoC, it’s important to use non-sensitive data and test accounts. The demonstration should be done in a controlled environment (e.g., the researcher’s own OneDrive or a demo tenant) to avoid any actual data breach. No actual exploitation beyond the researcher’s account is necessary; the goal is simply to illustrate the potential for abuse. After the test, the researcher should revoke the dummy app’s access via the Microsoft Account or Azure AD settings to clean up.

The feasibility of this PoC lies in the fact that it does not require breaking any security mechanism – 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.comhackread.com. 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 tester could intentionally use the legacy implicit grant 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 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.

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

3. Disclosure Timeline and Microsoft’s Response

The OneDrive File Picker over-permission issue was discovered by Oasis Security’s researchers and handled via responsible disclosure. Oasis reported the flaw to Microsoft and simultaneously alerted some major affected vendors (e.g. those behind ChatGPT, Slack, Trello, etc.) prior to public release of their findingsoasis.securityhackread.com. Oasis published their research on May 28, 2025, after giving Microsoft advance noticehackread.comhackread.com.

Microsoft’s initial response was that the OneDrive File Picker was functioning as intended, 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 **“by design” issue rather than a simple bug)hackread.com. Importantly, Microsoft did not rush out an emergency patch or advisory, because there was no straightforward fix given the architectural limitations. Instead, Microsoft stated it “may consider improvements in the future” to better align the File Picker’s permissions with the principle of least privilegelinkedin.com. 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.

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’s drive.file 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 “Microsoft has acknowledged the issue and is reportedly evaluating changes,” but with no official fix available yetsecureworld.io. 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.

Disclosure Timeline Highlights: Oasis’s 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. 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).

4. Security and Compliance Risks in Enterprise Environments

This vulnerability introduces significant security and compliance risks, 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 in their OneDrive accountcsa.gov.sg. The potential scenarios of abuse include:

• Data Exfiltration: A malicious or compromised third-party application could silently harvest all files in a user’s OneDrive once authorized. This might include confidential documents, financial records, personal identifiable information (PII), intellectual property, etc. Because the app’s access is persistent (tokens last at least one hour, and possibly can be refreshed for longersecureworld.io), an attacker has ample time to enumerate and exfiltrate data. If an organization’s employees have broadly authorized such apps, a single threat actor exploiting the app or token could leverage that access to collect massive amounts of company data from many users’ OneDrives. This is essentially a backdoor path to sensitive data that bypasses normal access controls, under the guise of user-granted access.
• Unauthorized Data Modification or Destruction: With write permissions (granted via Files.ReadWrite.All in a “save to OneDrive” integration scenario), the third-party app could modify existing files or upload new files. In a worst-case malicious scenario, an attacker could use the access to encrypt or ransom the files in OneDrive or SharePoint storagedarkreading.com. Dark Reading’s analysis pointed out that an attacker abusing this weakness might encrypt data in OneDrive or disrupt it, akin to a ransomware attack, since they effectively have the same rights as the user to all filesdarkreading.com. Even read-only access can be leveraged to delete files if an attacker also gains user-level privileges (for example, via the Graph API delete operations if included in scopes). The CSA Singapore alert explicitly notes the risk of content deletion leading to data losscsa.gov.sg. For enterprises, large-scale data tampering or loss can trigger serious business continuity and recovery issues.
• Compliance and Privacy Violations: Many organizations are subject to data protection regulations (GDPR, HIPAA, FINRA, etc.) that mandate control over who can access sensitive data. If an employee authorizes a third-party app that then vacuums up all documents (which might include customer data, patient records, personal information, etc.), this could be considered an unauthorized disclosure. Even if the third-party is a legitimate service, the over-broad access means data that was never intended to leave the Microsoft 365 environment might end up stored or processed by that third-party, potentially violating data residency or sharing policies. For instance, an employee could attach a single file containing customer information to a work management app via OneDrive Picker, but due to the flaw, that app now can pull in all customer files from the user’s OneDrive. This kind of overreach could break compliance rules and go unnoticed without auditingoasis.security. Enterprises in highly regulated sectors must consider this a data governance failure mode.
• Lack of User Awareness and Shadow IT: Because the consent prompt doesn’t clearly warn of full drive access, users may unwittingly approve what they think is a minimal permission. This creates a shadow IT problem: users trust an app with one document, but in reality the app holds keys to much more. Many users store extremely sensitive information in OneDrive by default (e.g. scans of IDs, financial documents, internal project files, photos with location data)secureworld.io. As security consultant Jamie Boote observed, users often don’t realize how far their OneDrive contents reach into personal or confidential territorysecureworld.io. A single careless click on “Allow” can expose an entire trove of such data. For enterprises, this means an employee could inadvertently breach data handling policies, and traditional DLP (Data Loss Prevention) tools might not catch it because the data access is happening through authorized OAuth channels.
• Elevation of Privilege via Token Theft: The insecure token storage aspect adds another risk: even if a third-party app is benign and well-intentioned, if its environment is compromised (say the user’s browser or the app’s code), an attacker could steal the OAuth token from the client sidesecureworld.io. That stolen token (especially if coupled with a refresh token) could then be used by the attacker independently to access the user’s OneDrive from another location or device, without further user interaction. In a corporate setting, this could allow an external attacker to maintain persistent access to company files by replaying stolen tokens or continuously refreshing them. Traditional security monitoring might just see it as the authorized app’s access. This complicates incident response – even if the user notices something wrong and removes the app’s access, data may have already been siphoned in the interim.
• Multi-Tenant Application Risk: If a single third-party application is popular (for example, a project management tool or AI assistant used across many companies), that one app’s broad permissions represent a concentrated risk. A vulnerability in that app or a deliberate abuse by its operators could impact multiple organizations in one stroke. The Oasis research highlighted the scale by pointing out ChatGPT’s enormous user base; if even a fraction use the OneDrive integration, that’s a vast amount of data potentially accessiblehackread.com. Enterprises need to be wary that an integration used by thousands of employees could inadvertently expose data across the enterprise if abused.

From a compliance standpoint, these risks translate to potential breaches that must be reported, fines, and loss of customer trust. Security teams must treat third-party OAuth access with the same seriousness as they would an internal admin account with global privileges – because effectively, that’s what these apps have been given.

In summary, the OneDrive File Picker flaw turns what should have been a minimal, file-scoped permission into a broad backstage pass for third-party apps. In an enterprise, this undermines data segregation and access controls. The risk is not merely hypothetical: it is already present in production integrations, waiting for either an attacker to exploit or an inadvertent policy violation to occur. Organizations should assume that any file their users can access in OneDrive might also be accessible to any app those users have authorized, and plan their security measures accordingly.

5. Mitigation Strategies for Administrators, Developers, and Users

Until Microsoft provides a more granular permission mechanism or updated File Picker, enterprises and individuals must proactively mitigate this over-permission risk. Key mitigation strategies include tightening app access policies, monitoring for misuse, and educating users on the danger:

For Enterprise Administrators / IT Security Teams:

• Audit and Restrict Third-Party App Access: Perform an audit of all OAuth grants in your tenant. Using the Entra ID (Azure AD) portal, review the list of Enterprise Applications that have delegated permissions to OneDrive/Graphoasis.security. Identify any apps requesting overly broad scopes (like Files.ReadWrite.All). It’s advisable to revoke access for any unauthorized or unnecessary apps immediatelycsa.gov.sg. Administrators can use PowerShell or Graph API to enumerate OAuth consents as well. This audit should be done regularly.
• Implement Admin Consent and Approval Workflows: Enable Azure AD’s Admin Consent policy such that end-users cannot individually consent to apps that require certain high-privilege scopes (like full drive access) without administrator reviewsecureworld.iolinkedin.com. By requiring an admin to vet any app asking for broad file permissions, organizations can prevent users from accidentally granting a rogue or unvetted app access to corporate files. Many organizations choose to allow only a pre-approved list of third-party apps; this vulnerability underscores the importance of that practice.
• Use Conditional Access to Limit OAuth Tokens: Leverage Conditional Access policies in Entra ID to constrain how and when third-party apps can be used. For example, you might block OAuth token issuance to apps from unmanaged devices or outside certain geographic locations. You could also create a policy to disallow granting consent to OAuth apps requesting the Files.Read.All or Files.ReadWrite.All scope for most users, as a blanket safety measuresecureworld.io. Only specific service accounts or privileged users would be exempt if needed.
• Monitor OneDrive Access Logs: Increase monitoring on OneDrive/SharePoint access via Microsoft 365 audit logs or Cloud Access Security Broker (CASB) solutions. Unusual patterns – such as a third-party app reading a large number of files or accessing files at odd hours – should raise an alert. Graph API call logs can often be analyzed to detect bulk file access. Microsoft’s Continuous Access Evaluation (CAE) can be enabled to make OAuth token revocation near-real-time if misuse is detectedsecureworld.io. Some security tools can also monitor OAuth app behavior and flag anomalies in token usage across tenants. Given the token could be valid for up to an hour (or longer with refresh), timely detection is key.
• Shorten Token Lifetimes & Protect Refresh Tokens: Where possible, configure shorter token lifetimes for OAuth tokens in your tenant and enable features like token protection (which binds tokens to a specific client or environment). This can limit the window of abuse if a token is stolensecureworld.io. Also, consider disabling long-lived refresh tokens for third-party apps (some Microsoft plans allow configuring OAuth consent such that refresh tokens aren’t issued, forcing re-consent frequently). While this might inconvenience users, it reduces persistence of accessoasis.security.
• User Education and Data Classification: Educate your user base about the implications of OAuth consents. Encourage a culture of caution: users should only authorize apps from reputable publishers and only if truly necessary for their work. Remind users that “Allow” can mean handing over all your files. Additionally, enforce data classification and storage policies – truly sensitive data might not belong in personal OneDrive folders where it could be accidentally exposed via an app. Storing such data in more tightly controlled repositories (with no OAuth access) could mitigate worst-case scenarios.

For Application Developers (Third-Party App Developers using OneDrive integration):

• Adhere to Least Privilege (to the extent possible): Although OneDrive’s scopes are coarse, developers should still request the minimum scopes needed. For example, if your app only needs to let users open files from OneDrive, use Files.Read.All rather than Files.ReadWrite.All. Do not request write or offline access if you don’t absolutely need itlinkedin.com. Each unnecessary permission is an additional security liability for your users and will increase scrutiny on your app. Microsoft Graph also has some alternatives like Sites.Selected (for SharePoint limited access) – if applicable, consider those, though they may not fully solve the single-file case.
• Avoid Using Refresh Tokens: Design your integration such that it does not rely on long-lived tokens. If your use case allows, do not request the offline_access scope, so that no refresh token is issuedoasis.security. This way, the OAuth access token will expire after an hour and cannot be silently renewed – reducing the window in which an attacker could abuse a stolen token. If prolonged access is needed, consider implementing your own backend token proxy with additional security checks, or prompt the user to re-authenticate for critical operations rather than storing a refresh token.
• Secure Token Storage: Pay attention to how you store and handle tokens. The OneDrive File Picker v8.0 leaves token management to developers (via MSAL). By default, MSAL may use browser sessionStorage, but you should treat the token as sensitive as a password. Do not log tokens or expose them in URLs. If your app has a backend component, consider storing tokens server-side (e.g., in an encrypted store or vault) instead of in the client, and issue your own short-lived session identifiers to the frontend. If purely client-side, explore using browser memory (JavaScript variables) without persistent storage, and explicitly clear tokens from memory/storage when they are no longer neededoasis.security. Also ensure your application’s domain has proper Content Security Policy to prevent injected scripts, since an XSS could target these tokens. Essentially, assume that a token with broad OneDrive scope will be an attractive target and guard it accordingly.
• Provide Transparency to Users: As a responsible developer, you might consider informing users why your app needs the permissions it’s requesting. Since Microsoft’s consent screen is generic, you could add your own explanation in your UI like “We require permission to read all files in your OneDrive due to Microsoft’s limitations, but we will only access files that you choose.” While this doesn’t change the permission, it at least sets correct expectations and might prompt risk-aware users to proceed cautiously.
• Alternate Design (If Feasible): If possible, offer alternative ways for users to share files without granting full drive access. For instance, your app could allow users to paste a OneDrive share link (which can be read-only) instead of using the picker OAuth flowoasis.security. The shareable link approach means the user explicitly shares a single file (or folder) via OneDrive’s own permissions, and your app only sees that content. This might be less user-friendly than the integrated picker, but it significantly reduces risk. Some developers have chosen to integrate Google Drive or Dropbox with limited scopes; you might prioritize those integrations for sensitive use-cases until Microsoft improves OneDrive’s model.

For Individual Users:

• Review App Permissions Regularly: Every OneDrive or Microsoft account user should periodically review which third-party apps have access to their account. This can be done via the Microsoft Account Privacy -> App Access settings (for personal accounts) or via the Connected Apps or OAuth permissions section in Office 365 for work accountsoasis.security. Look at the list of apps and the permissions they have. Revoke access for any app you do not recognize or no longer need. Remember that even after revocation, an already-issued token may remain valid for up to one hour, but revoking will prevent refresh and future useoasis.security. It’s especially important to remove any apps that have Files.ReadWrite.All or broad permissions unless you absolutely trust them.
• Be Cautious with File Picker Prompts: If you attempt to attach or upload a file to a website and see a Microsoft OneDrive consent screen, take a moment to read it carefully. The wording might be unclear, but assume it is asking for permission to view your entire OneDrive. If you are not comfortable with that level of access, cancel the process. You can often use alternatives like downloading the file and uploading it manually, or sharing a link, rather than authorizing full access. When in doubt, deny the request and consult your IT department (for work scenarios) about the app’s safety.
• Limit Sensitive Data in OneDrive: This may not be practical for everyone, but consider what you store in OneDrive. If you have extremely sensitive files (tax documents, passports, company secrets), you might choose to keep them in a more secure location (or at least in a separate OneDrive folder not linked to third-party apps). That way, even if you accidentally authorize an app, the most sensitive data isn’t accessible. Also use features like Personal Vault in OneDrive for an added layer of protection (though if the app has full access, even vault might be accessible once unlocked by the user’s session – so treat this only as a minor mitigation).

In essence, mitigation is about reducing the likelihood of granting broad access and limiting the damage if it occurs. Administrators should employ technical controls (policy and monitoring) to curb unwarranted app access, developers should minimize scopes and securely handle tokens, and end-users should remain vigilant about the apps they authorize. While these steps can significantly reduce risk, the definitive fix will need to come from Microsoft in the form of improved OAuth scope design or File Picker functionality.

6. Impact on Third-Party Services and Applications

Any web application that integrates with OneDrive via Microsoft’s File Picker or Graph API OAuth could be impacted by this over-permission flaw. Oasis Security estimated that “hundreds of popular applications” are affectedlinkedin.com. Here we highlight a few notable services known or suspected to use the OneDrive File Picker and thus inherit this issue:

• ChatGPT (OpenAI): Microsoft’s integration with OpenAI’s ChatGPT (particularly ChatGPT Enterprise or services that allow uploading files from OneDrive) uses the OneDrive File Picker under the hood. Notably, OpenAI’s implementation was using File Picker SDK v8.0oasis.security. This means if a user attaches a OneDrive file in a ChatGPT session, ChatGPT receives a token with full OneDrive read access. With ChatGPT’s enormous user base, the scale of potential access is very largehackread.com. OpenAI has to ensure it only uses what it needs, but technically the scope is broad. Users of ChatGPT who connected their OneDrive should be aware that ChatGPT could read all their files (even if it has no reason to do so in normal operation).
• Slack: Slack offers an integration to attach files from cloud storage providers including OneDrive. When a user uses the OneDrive Picker in Slack to share a file in a channel, Slack is granted permission to read (and possibly write) the user’s OneDrive files. This integration, while convenient, means Slack (or any threat actor who could compromise Slack’s token or backend) might access all files the user has. Slack is widely used in enterprises, so this is a significant vector. There haven’t been reports of Slack abusing this, but the capability is there by designoasis.security.
• Trello: Trello, a popular project management tool, has a OneDrive Power-Up that lets users attach OneDrive files to Trello cards. Through that, Trello uses Microsoft’s OAuth consent to gain access. Oasis listed Trello as impactedoasis.security. So a Trello board integration could read any file from the user’s drive, not just the one attached to the card. Organizations using Trello should ensure that this Power-Up is restricted or that users are made aware of what they’re granting.
• ClickUp: ClickUp is another projectivity/productivity platform that allows cloud storage attachments. It was explicitly named in the Oasis report as welloasis.security. Similar to Trello, a user linking a OneDrive document to a ClickUp task gives ClickUp broad access. If ClickUp (the company) or someone hijacking a ClickUp API token decided to, they could pull in all sorts of data from connected OneDrives.
• Others: The list of affected apps likely includes many collaboration, productivity, and AI tools. For example, any service that has a “Upload from OneDrive” or “Attach from OneDrive” button is a candidate. This could include Microsoft’s own ecosystem apps (though one would hope Microsoft’s first-party apps are well-governed), as well as third-party services like document signing platforms, business intelligence dashboards, CRM systems, note-taking apps, etc. Even some video conferencing or webinar platforms that let you share files might use OneDrive Picker. Recent articles have speculated that Zoom and other communication apps could be in scope if they integrate OneDrive for file sharingcsoonline.com. However, without specific confirmation, it’s safest to assume any web app you’ve authorized to connect with your OneDrive has full access. Oasis’s phrasing “hundreds of apps… meaning millions of users may have already granted access” underscores how common this integration isoasis.security.

It’s important to note that just because an app has the ability to access all your files does not mean it actively does so. Reputable companies have privacy policies and may program the app to only fetch the file you specify. However, the risk remains that if those companies are breached or if an insider turns malicious, the OAuth grant could be misused to scrape data. Furthermore, a less scrupulous app could intentionally leverage this broad access without users realizing. Administrators should identify all apps in their environment with OneDrive permissions and treat them as high-risk accounts.

To illustrate the breadth: ChatGPT, Slack, Trello, and ClickUp alone cover a wide swath of use cases – from AI assistants to team chat to project management – showing that this is not isolated to one category of applinkedin.com. Each of these services integrated the OneDrive Picker to improve user convenience, likely not anticipating that Microsoft’s scope would be so broad. Now that this flaw is public, all these services (and others) are likely evaluating their implementations. Users of these services should stay informed via those vendors’ advisories. For instance, some may release updates or guidance (e.g., “we will cache less data” or “we recommend you reconnect with limited accounts”). Ultimately, the safest course in the short term is to minimize use of “Log in with Microsoft/OneDrive to attach files” features on third-party sites unless absolutely necessary, and use alternative file-sharing methods when possible.

Conclusion

The OneDrive File Picker vulnerability highlights a fundamental trade-off in OAuth design between usability and security. Microsoft’s current implementation favored ease of integration – a single consent covers any file operations – at the cost of over-privileging third-party apps. This case serves as a real-world lesson that “all-or-nothing” permissions can lead to unintended exposure: users and even developers might not fully grasp that a simple file share grants what is effectively full drive access. In an era where cloud storage platforms are hubs of sensitive information, the stakes for getting OAuth scopes right are extremely high.

Addressing this issue will require action on multiple fronts. Microsoft needs to improve its OAuth granular controls and perhaps redesign the File Picker to support file-scoped tokens or consent prompts that enumerate the level of access more clearly. The company has signaled awareness, but concrete changes are eagerly awaitedlinkedin.com. Meanwhile, enterprises must not be complacent – they should tighten app governance and educate users, as discussed, to prevent data leakage through this vector. Developers leveraging cloud APIs are reminded of their responsibility to request and handle permissions judiciously; just because a platform grants broad access by default doesn’t mean one should utilize it to the fullest extent.

Ultimately, this incident underscores the importance of the principle of least privilege in cloud integrations. Fine-grained access control isn’t just a theoretical best practice; it is a necessary safeguard to protect users. Until OneDrive offers that, users and organizations must compensate with vigilance and restrictive policies. By implementing the mitigation steps outlined above and staying aware of which apps have access to data, the risk can be managed. However, the long-term fix – more precise OAuth scopes and better alignment between user intent and app privileges – is something only Microsoft can deliver. The security community will be watching closely for those improvements. In the interim, knowing the gap exists is key: with awareness, stakeholders can take steps to lock down OneDrive integrations and prevent this flaw from turning into actual breaches.

Sources: The analysis in this report is based on information from Oasis Security’s official research findings, Microsoft documentation, and commentary from cybersecurity experts and news outlets. Key references include Oasis Security’s blog report on the OneDrive File Picker flawoasis.securityoasis.security, disclosures via The Hacker News and Dark Readingthehackernews.comdarkreading.com, insights from infosec professionals (e.g., from Black Duck, Salt Security)secureworld.iohackread.com, and official advisories such as the Cyber Security Agency of Singapore’s alertcsa.gov.sg. These sources collectively corroborate the extent of the issue, Microsoft’s response, and best-practice recommendations as of May 2025.