Disrupting supply chain attacks on npm and GitHub Actions

Closing the gaps attackers exploit

Supply chain attacks against package repositories and CI/CD systems have become a recurring pattern over the past year. The campaigns share a common shape: compromise a single project, harvest credentials, then use those credentials to spread malware across dozens or hundreds of downstream projects. GitHub has rolled out several changes to npm and GitHub Actions over the last few months aimed at cutting off the specific techniques these attacks rely on at each stage of that chain.

Securing the entry point

The first step in most supply chain attacks is compromising a single maintainer or project workflow. Several recent changes target that initial foothold.

Phishing campaigns against maintainers are a frequent starting point. High-impact npm accounts now enter a read-only mode for 72 hours when an email change occurs or a 2FA recovery code is used. That gives maintainers a window to recognize and recover a compromised account before it can be used to push malicious releases.

On the GitHub Actions side, one of the most exploited patterns has been "pwn requests," where a workflow triggered by a pull request from a fork executes untrusted code from that fork. The default behavior of actions/checkout now prevents checking out untrusted code from forks in commonly exploited triggers unless you explicitly opt out after reviewing your risk. The change is also backported to older versions of the action.

For teams that want more control, new workflow execution policies at the enterprise, organization, or repository level let you restrict who can trigger workflows and which trigger types are permitted. Additionally, Actions cache entries are now read-only for untrusted triggers, closing a path attackers have used to poison shared cache entries and escalate from a limited vulnerability to highly privileged credentials used in release workflows.

Removing credentials worth stealing

Once inside a project, attackers focus on locating and exfiltrating credentials that unlock further access. The strongest mitigation is to eliminate long-lived credentials from CI/CD pipelines entirely.

Trusted publishing for npm, which authorizes publishes without long-lived credentials, now supports CircleCI as a provider. This extends the capability to more teams and removes the type of credentials these attacks are designed to harvest.

For detecting exfiltration in progress, the Actions network firewall (currently in technical preview) logs all outbound network traffic from workflow runs. That visibility can reveal suspicious behavior such as downloads of malicious code or credential exfiltration to unfamiliar domains. Network egress restrictions and policies are planned as future work.

Slowing the spread

With credentials in hand, attackers move to distribute malware as broadly and quickly as possible. Several npm changes make that propagation harder and slower.

Staged publishing is an opt-in npm control that requires additional approval and 2FA authentication beyond the publishing credentials themselves before a new package version goes live. By separating CI/CD credentials from those that can publish to the registry, this breaks the path from a compromised pipeline to malware distribution.

npm v12 will introduce wider-reaching changes. Install-time scripts, a vector attackers abuse to exfiltrate credentials without waiting for package execution, will be disabled by default. Legitimate uses remain possible by approving specific scripts. Dependencies installed via git or remote URLs, another install-time code execution vector, will also be disabled by default.

Speed is central to these attacks, so Dependabot version updates now wait at least three days after a release before opening a pull request. This default cooldown gives detection signals time to surface. Security updates still open immediately, so critical fixes are not delayed.

Responding to incidents

In parallel with the hardening work, GitHub has added tooling to help users identify and respond when an attack does impact them.

Self-service credential revocation now lets enterprise admins and members instantly revoke all credentials for a given user. The feature builds on enterprise-wide credential management tools released in February. The credential revocation API, first introduced in April 2025 for personal access tokens, now also supports GitHub OAuth and App tokens. That covers credentials exfiltrated into publicly accessible content and lets leaks be revoked quickly regardless of where they surface.

The changes reflect a view that no single capability can stop supply chain attacks, but that breaking the most impactful links in the chain can disrupt entire campaigns. Further work is planned, with updates to be published through GitHub's changelog as new capabilities roll out.