Last week, GitHub released self-service credential revocation for Enterprise. The feature lets organization owners cut off compromised credentials across the entire organization in one action instead of trying to track down individual tokens during an active incident.
This fix was a long time coming, as the past few months have shown what happens when revocation is slow or incomplete. The Trivy compromise in March came back for a second round because the first cleanup left at least one credential alive, and that cascade reached Checkmarx days later. In June, Microsoft's own durabletask repositories got hit through an account that was never fully cleaned up after an earlier attack.
Microsoft has been on a tear lately with security fixes. They gave us publishing cooldowns after account changes just a few days before this, and earlier in June they also updated npm to stop automatic postinstall scripts. We’ll be keeping an eye on what else they ship and how this impacts attacks on open-source software.
What GitHub shipped
Enterprise owners with the "Manage enterprise credentials" permission can now bulk-revoke or delete credentials for all users in the organization, or target a specific account. This covers SSO authorizations for Personal Access Tokens (PATs), SSH keys, and OAuth tokens. A delete-all option is available for Enterprise Managed Users (EMU) organizations, and org-level REST APIs handle more granular per-org revocation. Every action creates an audit log entry and sends email notifications to affected users.
Individual members get a new Settings > Credentials view showing every credential tied to their account, SSO-authorized and personal. From there, one action removes all of those credentials' access to SSO-protected enterprise resources in a single step, cutting out the time-consuming process of walking through a token list one entry at a time. Members of EMU organizations also get a separate option to permanently delete all their tokens and SSH keys.
Before this break glass feature, you had to work across a few different tools to cut off one account's credentials. Fine-grained PATs could be revoked from the organization token screen. Classic tokens could only be cut through per-token SSO authorization revocation, and only if you had SAML SSO turned on. The credential revocation API could kill a token, but only if you already had the token string in hand, which works in the leaked-secret case, not the compromised-account case (this scratches the surface of complexities, but we’ll stop here). Point is, this made for a pretty messy attempt at coordinating credential changes.
NB: GitHub Actions tokens are out of scope here, because they're minted per job and expire when the job ends, so there's nothing standing to revoke. The way to limit damage during an incident is to disable Actions on the repository.
Why now?
Recent malware attacks have been hitting Microsoft close to home.
On May 19, attackers used previously stolen credentials to push three malicious versions of Microsoft's durabletask package to PyPI, part of the Miasma worm campaign. Microsoft pulled the packages within hours. However, on June 5, the same account pushed a malicious commit to the `Azure/durabletask` GitHub repository, planting the worm again. GitHub responded by disabling 73 repositories across four of Microsoft's GitHub organizations. This included the Azure Functions tooling that a lot of teams deploy through, breaking CI/CD pipelines beyond Microsoft. Researchers list a few possible explanations for the repeat, but the leading one is that the credentials from May were never fully rotated. A monitoring firm later found the account's GitHub credentials sitting in infostealer logs as far back as April. Whatever the exact mechanism, the same account was used in both compromises.
But this isn’t new, and the problem has already shown up multiple times this year. In late February 2026, a malicious AI bot exploited a misconfigured pull_request_target GitHub Actions workflow in Trivy's repository, which allowed the attacker to steal a PAT with write access to more than 33 workflows across the Aqua Security GitHub organization. Aqua Security discovered the breach and rotated credentials. But alas, the rotation wasn't complete, and credentials weren't all revoked simultaneously.
On March 19, the attackers used credentials that survived the incomplete rotation to force-push 75 of 76 version tags in aquasecurity/trivy-action to malicious commits. The payload executed before the real Trivy scan in each pipeline, so every workflow appeared to complete normally. CI/CD pipelines running Trivy were harvesting credentials from their own runners, like SSH keys, cloud credentials, Kubernetes tokens, and GitHub PATs.
Four days later, stolen credentials from those pipelines were used to poison Checkmarx's GitHub Actions with an identical stealer payload. Checkmarx confirmed that threat actor activity persisted in their environment through April 22, with their exfiltrated data published to the dark web on April 25.
This entire Trivy to Checkmarx chain traces back to incomplete rotation. If Aqua Security had been able to instantly cut off all credentials for the compromised service account after the February breach, the attack would have stopped there.
Atomic rotation what?
Atomic rotation means swapping a credential as a single all-or-nothing operation, so there’s no moment where the new and old credentials both work. The goal is to prevent any downtime in the system. This is cool in theory. In a distributed system, that’s just not how it works. There's just way too much coordination involved. At the scale of an organization like GitHub, atomic rotation is nonsensical
So real rotation picks one of two paths, both imperfect. Routine rotation keeps both credentials valid for a window so nothing breaks, which is fine when nothing's wrong but leaves the old credential alive. Incident response does the opposite, cutting the old credential off instantly and accepting that things break until you reissue.
A break-glass button lets you do the one thing that actually is atomic, which is just to kill every credential in scope at once. Sure, that breaks CI/CD. But getting an attacker out of your infrastructure is way more important, and worth a few hours or days of broken builds.
Until now, cutting off all credentials at once was just hard to execute. This new one-action cutoff is what makes it executable under pressure, and while complete atomic rotation is still quite elusive, this gets us closer to the ideal world.
What to do
In your GitHub organization, confirm the "Manage enterprise credentials" permission is assigned to someone who can act immediately, and do it before there’s an incident. Review Settings > Credentials now so you understand what's in scope.
Also, while you’re updating your security settings, pin your GitHub Actions to full commit SHAs rather than version tags. Tags can be force-pushed to point at entirely different code, which is the core technique behind the Trivy compromise. A pinned commit SHA can't be moved.
Aikido Security monitors your applications for compromised packages in real time. When something in your pipeline gets poisoned, you get an alert before the credential harvester runs. This is powered by Aikido Intel, which analyzes new package versions as soon as they are live.
Thank you for all the updates, Microsoft. Keep them coming please. 🙏
