OAuth Apps Retain Access After Publishers Vanish, Audit Finds
A recent audit revealed that many third-party OAuth applications on Google Workspace and GitHub marketplaces retain broad access to sensitive company data even after their publishers disappear, posing significant security risks.
A comprehensive audit of 2,890 public OAuth applications across the Google Workspace and GitHub marketplaces has uncovered a critical security flaw: many of these applications continue to hold extensive access to sensitive corporate data long after their original publishers have ceased operations or vanished. These applications, often granted permissions far exceeding their stated functionality, can expose vital information such as emails, files, code repositories, and secrets to potentially unknown entities, creating a substantial risk for organizations.
The audit, conducted by OhAuth, an OAuth research project from identity security firm Offroad, examined 1,595 Google Workspace Marketplace apps and 1,295 GitHub Marketplace apps. The combined reported install base for these applications is staggering, reaching at least 4.39 billion, though this figure is considered a conservative estimate due to the use of rounded values like "1M+" for install counts.
Alarmingly, the audit identified that 918 applications, representing 32 percent of the catalog, exhibit at least one "structural exposure signal." These signals include requesting scopes broader than the app's described function, the presence of AI with write access, publisher domains flagged by threat intelligence, dead publisher websites, or domains that are currently available for purchase. The cumulative install footprint for these high-risk applications alone exceeds 1.85 billion. Furthermore, 127 applications displayed two or more risk signals, and 16 showed three or more.
On Google Workspace, the audit highlighted that 1,391 add-ons have a combined install footprint of over 3.07 billion. Specifically, 281 apps with broad access to Google Drive have 1.47 billion installs, 316 apps accessing Sheets have 1.02 billion installs, and 220 apps reaching Gmail have 818.2 million installs. For GitHub, 346 applications have access to code repositories, 183 can interact with actions, workflows, and runners, and 107 can access organization settings.
A significant finding is the discrepancy between an app's stated purpose and the permissions it requests. A total of 677 applications requested at least one permission that exceeded their stated function, impacting a combined user base of 1.82 billion. Of these, 266 apps requested high-tier, off-purpose access to Google Drive, affecting 1.26 billion installs. While some of this overreach is attributed to limitations in the OAuth scope catalog (e.g., Google's lack of a "write without delete" scope for Sheets), many instances involve scopes entirely unrelated to the app's function.
The risk becomes acute when a publisher's infrastructure is compromised or abandoned. In such scenarios, attackers can leverage the existing, broad permissions granted to the legitimate application, effectively turning it into a supply-chain access vector into numerous customer environments. The audit found 206 apps with defunct publisher domains and 89 apps whose domains were available for purchase, presenting an opportunity for malicious actors to hijack the publisher's identity and associated app permissions.
Marketplace reviews, while performed before an app is listed, are largely a one-time check. The security posture can degrade over time as publisher domains expire, change hands, or become compromised, while the existing OAuth grants remain active. This drift between the verified marketplace listing and the real-world publisher asset means that organizations may be unknowingly exposed through applications that were once deemed safe.
Philip Shteyn, CTO of Offroad, emphasized that the primary issue is not typically unrelated access requests, but rather apps asking for permissions that are related but excessively broad. He noted that in many Google Workspace cases, narrower scopes technically exist but are not utilized by the applications. This highlights a need for more continuous monitoring and re-verification of third-party application permissions to ensure ongoing security.