Installing an app from the Google Workspace Marketplace or GitHub Marketplace can grant a third party access to company email, files, calendars, code repositories, CI workflows, organization settings, and secrets. Marketplace presence gives these apps the appearance of approval. The OAuth grants behind them often reach into business systems beyond the listed function.
An audit by OhAuth, the OAuth research project from identity security company Offroad, covered 2,890 public OAuth app listings, with 1,595 on Google Workspace Marketplace and 1,295 on GitHub Marketplace. Their combined reported install footprint reaches at least 4.39 billion. That figure is a lower bound. Marketplace install labels use rounded values such as 1M+, so the number represents reported installs.
Nearly a third of listings show a risk signal
918 apps, or 32 percent of the audited catalog, carry at least one structural exposure signal. These signals include scopes wider than the app’s stated function, AI with write access, threat-intel flags on publisher domains, dead publisher websites, publisher domains available for purchase, and brand-leading app names published by third parties. The combined lower-bound install footprint for these 918 apps reaches 1.85 billion. 127 apps show two or more signals, and 16 show three or more.
The audit found 1,391 Workspace add-ons with a lower-bound install footprint of 3.07 billion. On Google Workspace, 281 apps hold broad access to Drive across 1.47 billion installs, 316 reach Sheets across 1.02 billion installs, and 220 reach Gmail across 818.2 million installs. On GitHub, 346 apps hold access to code, 183 reach actions, workflows, and runners, and 107 reach organization settings.
Permissions wider than the job
The largest finding by install footprint involves the gap between what an app says it does and the scopes it requests. 677 apps request at least one permission that exceeds their stated function, with a combined lower-bound footprint of 1.82 billion. 266 of these reach Drive with off-purpose high-tier access, covering 1.26 billion installs.
Some of these gaps come from the OAuth scope catalog itself. Google offers no “edit without delete” scope for Sheets, Docs, or Calendar, so an app that needs to write to one spreadsheet must take a scope that also allows deletion across every spreadsheet the user can reach. Other cases involve scopes with no relation to the function at all.
The audit lists examples. A multiple-choice form helper with more than 8 million installs holds off-purpose Drive, Forms, and Sheets scopes. A Gmail auto-responder with 60,000 authorized users holds Drive, Docs, Calendar, and Gmail scopes. A URL-to-Drive saver with more than 3.8 million installs holds permission to see, edit, create, and delete every file in a user’s Drive.
The risk exists once a broad grant is approved. A compromise of the publisher would inherit the permissions already granted, turning a legitimate app into a supply-chain access path across many customer environments.
The split behind the mismatch
The 677 flagged apps divide unevenly across the two scope categories, and the pattern differs by platform. Philip Shteyn, CTO of Offroad, described where the bulk of the problem sits.
“Across both marketplaces, most of the issue is not apps asking for completely random access. It is apps asking for access that is related to what they do, but much broader than they need,” Shteyn told Help Net Security.
In Google Workspace, around 90 percent of flagged cases fall into the “right category, too much access” group, according to Shteyn. An app might need to work with Drive files and request broad Drive access when a narrower Drive permission would cover the task. The apps requesting scopes with no relation to their purpose make up roughly 10 percent.
Shteyn added a point about scope availability. “In many Google Workspace cases, a narrower scope technically exists. The app just does not use it,” he said. The cases where Google offers no sufficiently narrow alternative form a smaller subset.
GitHub shows a more even division. Roughly 60 percent of flagged GitHub cases are overbroad and related to the app’s function, and about 40 percent appear unrelated to the stated purpose.
Publisher infrastructure that goes offline
OAuth assumes the publisher stays reachable and accountable for the life of the grant. The audit found gaps in that assumption. 206 apps have dead publisher domains. 89 apps, across 85 distinct publisher domains, have domains available for purchase at a standard registrar. Anyone who registers a dormant domain can send mail under the publisher’s identity using valid SPF, DKIM, and DMARC records, or trigger account-recovery flows to take over the marketplace app. 36 apps have publisher domains flagged on commercial threat-intel blocklists.
One Google Workspace backup product authorized by more than 180,000 organizations has a publisher domain flagged by five commercial threat-intel feeds. Its OAuth grant covers read, edit, and delete authority over every file, email, calendar event, and contact in those tenants.
Marketplace review as a one-time check
Google and GitHub run verification before a listing goes public, covering the publisher, the domain, and OAuth scopes, and a security assessment applies for sensitive scopes. The exposure signals persist because that review operates mainly at approval time.
“The main issue is that marketplace review is mostly an approval-time check,” Shteyn said.
A publisher domain can expire, become available for purchase, or pass out of the original developer’s control after a listing goes live. The app stays listed, and existing OAuth grants keep working. “The verified marketplace listing and the real-world publisher asset it was verified against can later drift apart,” Shteyn said. “From what we observed, there does not appear to be enough continuous re-checking after approval to catch that drift.”
Offroad reported the findings to Google and GitHub two weeks before publication. Both platforms responded. Neither treated the findings as an in-scope security vulnerability requiring immediate platform action.
Exposure signals that persist
The figures for buyable publisher domains and threat-intel flags reflect point-in-time observations. Offroad monitored the reported apps through the audit and disclosure window. None of the reported apps were fixed, changed, or removed as of two weeks after disclosure.
Shteyn noted the limits of the measurement. “We did not run a full longitudinal study measuring the average time these exposure signals remain unresolved across the entire marketplace. The audit was primarily a point-in-time assessment,” he said.
The monitoring still pointed in one direction. “Once an app is approved, it can remain listed for a long period of time, even if the publisher domain later expires, becomes buyable, or develops other exposure signals,” Shteyn said.
AI apps that can write
49 AI-powered apps hold broad write access, with a lower-bound install footprint of 81.6 million. An AI app with permission to send email on a user’s behalf carries its own risk profile. A traditional app sends email after a defined user action, such as a click or a rule. An AI app can decide what to send, when, and to whom based on model output. The consent screen shows the permission and omits how much control the model holds before that permission is used.
What administrators can do
Offroad recommends treating OAuth grants as part of identity risk management. High-permission grants should have a business owner, a justified scope set, usage monitoring, a renewal cadence, and a revocation path. The company advises inventorying every grant, monitoring high-privilege actions continuously, separating AI apps from traditional ones, and rotating top-risk grants on a fixed schedule. Marketplace listing serves as a starting point for review. Tenant-level security evaluation of scope, publisher, purpose, usage, and business owner remains a separate step.
Guide: What automated pentesting alone cannot see
