Nx Investigation Reveals GitHub Actions Workflow Exploit Led to npm Token Theft, Prompting Switch to Trusted Publishing

On August 26, 2025, the JavaScript ecosystem witnessed a watershed moment in supply chain security. The popular Nx build system, with over 4.6 million weekly downloads, fell victim to an attack that stole thousands of credentials and pioneered a disturbing new technique: weaponizing AI developer tools for scaling reconnaissance and data theft.

The Nx team has published detailed findings from their investigation into last week's supply chain attack, revealing how attackers exploited a GitHub Actions workflow vulnerability to steal npm publishing tokens. The incident has prompted the team to completely eliminate npm tokens in favor of npm's new Trusted Publishers mechanism.

The investigation uncovered a sophisticated exploitation chain that took advantage of an overlooked aspect of GitHub's pull_request_target trigger and the persistence of the vulnerable workflow in outdated branches, even after the team had patched the vulnerability in their master branch.

The Overlooked Danger of pull_request_target#

According to the updated GitHub advisory, the root cause involved two critical oversights in a workflow introduced on August 21. The first was a straightforward bash injection vulnerability:

    - name: Validate PR title
        run: |
          echo "Validating PR title: ${{ github.event.pull_request.title }}"

"The intention of these lines was to print out the pull request titles being validated via our commit format checks," the Nx team explained. "However, if a PR was opened with a title such as $(echo "You've been compromised") the code would be executed within the workflow."

The second, more subtle issue involved the pull_request_target trigger. Unlike the standard pull_request trigger, pull_request_target runs workflows with elevated permissions, including a GITHUB_TOKEN with read/write repository permissions.

"What was missed is the warning that this trigger, unlike the standard pull_request trigger, runs workflows with elevated permissions including a GITHUB_TOKEN which has read/write repository permission," the team noted. "Furthermore, the workflows are executed on the target repo of the PR (nrwl/nx) which means that the GITHUB_TOKEN had permissions for the nrwl/nx repo."

How Outdated Branches Became Attack Vectors#

The investigation revealed a critical timeline gap that the attackers exploited. While the team reverted the vulnerable workflow from master on August 22 after security researcher Adnan Khan flagged it on X, they didn't immediately update all outdated branches.

In open source, it’s fairly common for researchers to publicly call out vulnerabilities in already-public repos. The upside is that public attention creates immediate pressure to fix, and Nx did revert the workflow in master the next day. The downside is that by spelling out how the bug could be abused to steal an npm token, the tweet effectively gave attackers a head start. Because outdated branches still carried the vulnerable code, they remained exploitable.

On August 27, the team successfully reproduced the attack vector, discovering that attackers had targeted an outdated branch that still contained the vulnerable workflow. This allowed them to trigger the vulnerability days after it had been removed from master.

"In addition, the workflow is run using the version of the workflow available on the target branch which is not necessarily master," the advisory explains. "We believe that the PR was made targeting an outdated branch which still contained the vulnerable workflow despite the fact that the vulnerable workflow was removed from master."

The attackers used the stolen GITHUB_TOKEN to trigger the publish.yml workflow, which contained the npm token used to publish malicious packages.

"The vulnerable pipeline was just a means to trigger our publish.yml pipeline which does indeed have the npm token which was used to publish the malicious versions of Nx," the team confirmed. "As part of the bash injection, the PR validation workflows triggered a run of the publish.yml with this malicious commit and sent our npm token to an unfamiliar webhook."

Immediate Move to Trusted Publishers#

In response to the breach, the Nx team has fundamentally restructured their package publishing infrastructure. Within 24 hours of the attack, they migrated all packages to npm's Trusted Publishers mechanism, which had just launched on July 31, 2025.

"All npm packages under Nx (affected or not) have been set to require 2FA and CANNOT be published with npm tokens any longer," the team announced on August 27. "All npm packages have also been changed to use the new Trusted Publisher mechanism which does not utilize npm tokens."

Trusted Publishers uses OpenID Connect (OIDC) to establish cryptographic trust relationships between npm and CI/CD providers. Instead of long-lived tokens that can be stolen and reused, it generates ephemeral, workflow-specific credentials for each publish operation.

The Nx team's implementation means their packages can now only be published through their authorized GitHub Actions workflow, with automatic provenance attestations included by default. The npm tokens that were compromised in the attack no longer exist in their infrastructure.

Comprehensive Security Overhaul#

Beyond adopting Trusted Publishers, the investigation prompted several additional security measures:

• All outdated branches rebased: On August 27 at 3:14 PM EDT, the team rebased all outdated branches to remove the vulnerable pipeline from any possible exploitation avenue.
• External contributor restrictions: The team now requires manual approval for pipelines executed on PRs from external contributors.
• CodeQL implementation: Static analysis was added to catch similar injection vulnerabilities before merge.
• Complete credential rotation: All GitHub secrets were rotated, regardless of whether they appeared to be compromised.

The team also discovered that the Nx Console VS Code extension (versions 18.6.30 to 18.65.1) was inadvertently spreading the compromise by automatically installing the latest Nx version when launched. Version 18.66.0 was released on August 27 to remove this behavior.

Industry Implications#

The Nx incident highlights the vulnerability of long-lived npm tokens in CI/CD workflows. Their immediate migration to Trusted Publishers was a direct response to having their npm token stolen through the workflow exploit.

For the Nx team, the investigation has led to a complete rethinking of their security model. "The team will soon retrospect on this incident, formulate the lessons we have learned, and share those with the community," they stated in the advisory.

Throughout the incident, the Nx team maintained transparency, posting regular updates on X and working directly with affected users. Their rapid response, migrating to Trusted Publishers within 24 hours, rebasing all outdated branches, and releasing a patched VS Code extension the next day, minimized the window for further damage. The comprehensive GitHub advisory, which they continued to update as their investigation progressed, provided the technical depth needed for the community to understand exactly what happened. This combination of swift action and openness during a security crisis is pretty much the gold standard for incident response in open source.

The detailed investigation findings highlight how supply chain attacks can exploit seemingly minor oversights in CI/CD configurations. The combination of a bash injection vulnerability with the elevated permissions of pull_request_target created an attack vector that persisted even after the initial fix, demonstrating the importance of comprehensive security reviews that consider all branches and workflow triggers.

The Nx incident moved at breathtaking speed: vulnerable workflow introduced August 21, npm token stolen August 24, malicious packages published August 26, thousands of software projects compromised and credentials exposed within hours. It's a nightmare scenario for maintainers of widely used software. When your package has millions of weekly downloads, even a brief compromise cascades through the ecosystem at devastating speed, exposing thousands in the time it takes to diagnose and fix the problem. While no project is immune, stronger security measures are available, and adopting them quickly can make all the difference.