A marketplace app you installed in 2023 still has read access to your Gmail, write access to your Drive, and a foothold inside your GitHub org. The startup that built it folded sixteen months ago. Their support email bounces. Their domain expired. The OAuth grant you approved is still live, still working, still trusted by Google’s consent screen as if nothing happened. Welcome to the cybersecurity baseline almost every enterprise is operating on in 2026.

This week made the cost of that baseline very public. An OAuth marketplace audit found nearly 1,600 Google Workspace apps with publishers who have effectively vanished. A flaw in the Claude Code GitHub Action let a single issue hijack repositories that installed it. And a new npm campaign called IronWorm seeded 36 packages with infostealer payloads. Three different ecosystems, one shared assumption: once you install something, you trust it forever.

Your Cybersecurity Stack Trusts Vendors Who Don’t Exist

The OhAuth research project ran the numbers, and the numbers are bad. From the Help Net Security writeup:

An audit covered 2,890 public OAuth app listings, with 1,595 on the Google Workspace Marketplace. The grants those apps request reach into corporate email, files, calendars, code repositories, CI workflows, organization settings, and secrets.

These are listings on the official marketplaces your employees were told to use, sitting under the same brand of “review” that your security team trusts. The brand of “Marketplace” did most of the work convincing buyers that listing equaled review, and review equaled safety. Neither claim holds up.

The real failure is durable consent. When an employee clicks Allow, they grant a long-lived refresh token that survives their password reset, their MFA enrollment, their offboarding, and apparently the vendor’s bankruptcy. Nothing in the workflow times that grant out. Nothing forces an annual re-consent. Nothing checks whether the publisher is still solvent. Your cyber security review happened once, three IT directors ago, and the token has been quietly working ever since.

The npm world has the same disease in a different shirt. IronWorm worked because every package install path treats the registry as an authority. You ran npm install three times last week and never asked whether the maintainer of one dependency had been compromised since the last release. The trust was extended at install time and renewed every CI run after, with no defense in depth between the registry pull and your production build.

One Issue. The Whole Repo.

Then there’s the Claude Code GitHub Action story, which is the same problem wearing yet another shirt. RyotaK at GMO Cybersecurity demonstrated that a single malicious GitHub issue, opened by anyone with the ability to file an issue, could exploit how the action processed input and pivot to full repo takeover. Anthropic’s own action repository ran the same workflow, so the attacker path went straight into the action source, with downstream repos pulling the poisoned version automatically.

Set aside the technical detail for a second and look at the trust shape. A maintainer at some point added the action to their workflow file. They pinned a version, maybe. They almost certainly granted it write permissions to the repo, because that’s what the action needed to do useful work. From that moment forward, the action’s behavior was an extension of the maintainer’s own privileges. No quarterly audit. No expiry. No re-consent.

The Meta AI chatbot account takeover from earlier this week ran on the same logic. The bot had standing privileges to modify account email addresses. Once an attacker could talk the bot into using them, the bot did. There’s a pattern here, and your incident response plan should already be naming it: the long-lived, unrevoked, scope-loose trust grant is the 2026 initial-access vector.

Cut The Standing Privilege Or Bleed

The good news: the fix is mostly inventory and policy. No new product line required. Threat-protection budget you already have, redirected at the install path, will close most of this in a quarter.

• Pull the full OAuth grant list for every IdP tenant. Google Workspace, Microsoft 365, GitHub org, Slack workspace, Atlassian, Zendesk. Export the publisher, the scopes granted, the date approved, the last-used timestamp. Anything older than twelve months with no recent activity goes on the kill list.
• Verify the publisher still exists. If the domain expired or the support email bounces, revoke the grant today. The vendor cannot fix a vulnerability they no longer staff.
• Cap scope at install, not at incident. Block apps requesting full-mailbox or full-drive scopes by default. Require a security review for anything broader than read-only on a single resource type.
• Treat GitHub Action permissions like OAuth scopes. Audit every workflow with permissions: write-all and force least privilege. Pin actions by commit SHA, not by tag.
• Re-consent annually. Force users to re-approve every active OAuth grant on a fixed cadence. The friction is the point. Apps nobody renews are apps nobody uses.
• Add threat detection on the consent surface. First-seen OAuth grant from a new publisher, scope-elevation events, and grants approved outside business hours all deserve a SIEM rule.
• Run brute-force controls and rate limits on adjacent auth surfaces. When the OAuth grant is the loud foothold, brute-force probes against admin endpoints are often the quiet second foothold. Your firewall and identity layer should both see them.
• Rehearse the revoke-and-rotate playbook. Tabletop a scenario where a marketplace app you trust ships a compromised update. Who revokes the grant? Who rotates the downstream secrets the app touched? How long does it take?

None of that is exotic security hardening. It’s housekeeping you should have been doing the whole time. The reason most orgs are skipping it is that consent is invisible. The IdP makes granting access easy and keeping it silent. That asymmetry is your real attack surface.

The next IronWorm or Claude Code Action incident will land the same way: an existing trust relationship gets weaponized, and the org that did the original install three IT directors ago has no record of why or what the grant covers. You can keep finding out from the attacker, or you can find out from your own inventory this quarter. Pick one.

Sources

• OAuth marketplace apps keep access after publishers vanish
• Claude Code GitHub Action Flaw Let One Malicious Issue Hijack Repositories
• New IronWorm malware hits 36 packages in npm supply-chain attack
• Offroad Emerges From Stealth With $7 Million to Tackle Enterprise Identity Risk