NX Threat Analysis

Overview

On August 26 2025, compromised versions of the Nx software were published to the npm registry. Upon installation, a malicious post-install script would attempt to scrape the host system for GitHub, AI assistant, and other types of API tokens and credentials, before exfiltrating them to newly created public repositories in the victim’s GitHub account. Two days later, the attacker used the stolen GitHub credentials to switch thousands of repositories from private to public, presumably to steal intellectual property and other exposed credentials contained within.

Phase 0: Exploiting a Vulnerable GitHub Workflow

The Nx npm token was compromised by exploiting a vulnerable GitHub workflow, in combination with a little-known and poorly understood pull_request_target GitHub workflow trigger event, which allows workflows from a forked repository to be run with permissions from its parent.

The vulnerable workflow allowed arbitrary code execution by echoing a pull request’s title within a bash environment. This allowed the attacker to create a malicious pull request titled $(<malicious bash command>), which was then executed in the parent repository using the vulnerable workflow’s secrets. This alone wouldn’t have been a problem, because the vulnerable workflow didn’t have access to any secrets. Unfortunately, the workflow also had the pull_request_target trigger. Unlike the pull_request trigger, pull_request_target uses an elevated GITHUB_TOKEN with full read/write access to the repository.

Using a combination of these two misconfigurations, the attacker was able to execute a modified version of Nx’s publish action in a pull request they opened from a fork, using the full read/write permissions of the parent repository, to exfiltrate the npm token. Interestingly, the pull_request_target docs include a warning referencing a 2021 GitHub security blog post, which reads like a how-to guide for this exact supply chain compromise.

How would we detect such a highly sophisticated attack against a public repository so that a supply chain compromise of this magnitude could be prevented? GitHub audit logs can tell you when a workflow is modified, but not when a workflow is run or how it is triggered. The answer lies in GitHub Webhook logs, which include details including pull request titles, commit messages, and workflow triggers. With these logs, we can detect pull request titles containing bash injection patterns, pull_request_target workflows triggered by cross-fork pull requests, and CI check bypasses in forkable public repositories.

Phase 1: AI-Assisted Credential Theft

The compromised Nx versions included a malicious telemetry.js post-install script that would be run by the npm installer. The script attempted to use the victim’s own authenticated Claude, Gemini, or Q CLI tools to run a malicious prompt with elevated --dangerously-skip-permissions, --yolo, or --trust-all-tools flags, respectively.

The malicious script performed the following actions:

1. Instruct the AI assistant to recursively search the user’s home directory for cryptocurrency wallets, SSH keys, and other key file patterns.

2. Create a /tmp/inventory.txt file containing the paths of discovered files.

3. Using the victim’s own GitHub credentials, create a new public repository named s1ngularity-repository-0.

4. Upload the the contents of each inventoried file to a triple base64 encoded results.b64 file in the new repository.

There are several opportunities for detecting this behavior. Starting with searching Indicators of Compromise (IoCs), we can threat hunt in GitHub logs for any repositories with names like s1ingularity-repository. This would identify any historical compromise from this specific supply chain attack, but it is trivial for the attacker to change this naming pattern, meaning we would likely miss subsequent attacks. Instead, monitoring for techniques, like new public repositories being created, would catch not only this attack but future supply chain attacks using similar techniques.

We can also look for anomalous interactions between npm and GitHub. Since the malicious post-install script was executed by the npm process and made networking calls to GitHub, we can look for known npm user agents in GitHub audit logs. We know that npm does legitimately interact with GitHub for installing dependencies, however these interactions should be limited to downloading repositories—not creating them! To catch future supply chain attacks attempting to use similar techniques, we’ve introduced a new rule to detect well-known package manager user agent patterns performing abnormal GitHub operations.

Phase 2: Mass Private Repository Exposure

Two days after the initial supply chain compromise and credential theft, the attacker used the stolen GitHub credentials to switch the visibility of victims’ private GitHub repositories to public. The exposed repos were renamed to s1ngularity-repository-nnnnn, presumably so the attacker could easily identify and clone them as they became available.

Once again, our IoC threat hunt would identify repositories with this s1ngularity-repository-nnnnn name. When the repository visibility was changed, Panther’s existing GitHub Repository Visibility Change rule would have detected this attack, and is useful for any future supply chain attacks using similar techniques.

One question remains: why did the attacker choose to make the repositories publicly visible to the entire world, rather than choose a stealthier exfiltration method, which may have allowed them to persist in victims’ GitHub environments unnoticed? Perhaps there were technical limitations, or perhaps they were seeking notoriety by making their attack as publicly visible as possible.

Implications

This supply chain attack illustrates the importance of monitoring and securing GitHub repositories, especially public ones that allow forks. The complexity of interactions between workflows within a single repository, not to mention interactions between forks, requires a high level of expertise and attention to detail.

The attack also highlights the problem of over-privileged AI assistants. These tools have read/write access to your entire file system. If you use MCP servers, they have access to remote systems, and if you use local MCP servers, the credentials to those remote systems are likely stored in plaintext on your file system. What other credentials are stored in plaintext on your computer?

AI credentials are the new crown jewel, serving as both the target and an attack vector. In this instance, a developer’s persistent connection to an AI assistant was the malware.

Panther’s Recommendations

For GitHub Administrators

• Collect and monitor your GitHub Webhook logs and GitHub audit logs for suspicious activity, especially for public repositories.

• Audit your GitHub workflows for pull_request_target triggers and assess whether they are necessary, especially for public repositories.

• If pull_request_target triggers are deemed necessary, update your GitHub workflow permissions so that they do not receive read and write permissions for all scopes.

  

• Use GitHub Enterprise Managed Users to prevent developers from using personal GitHub accounts in development environments.

For Developers

• Don’t update software while authenticated to AI assistants or GitHub.

• Don’t store credentials or API tokens in plaintext on your file system.

• Use the principle of least privilege for MCP credentials, using remote, SSO-authenticated MCPs wherever possible.

• Restrict your AI tools’ access to the file system, especially /home and /tmp.

• Run your AI assistant in a sandboxed environment or container that does not have access to a file system containing SSH keys or other credential files.

MITRE ATT&CK Mapping

• https://attack.mitre.org/techniques/T1195/002/

• https://attack.mitre.org/techniques/T1204/

• https://attack.mitre.org/techniques/T1555/

• https://attack.mitre.org/techniques/T1005/

• https://attack.mitre.org/techniques/T1102/

• https://attack.mitre.org/techniques/T1567/001/

References

• https://github.com/nrwl/nx/security/advisories/GHSA-cxm3-wv7p-598c

• https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/

• https://github.com/panther-labs/panther-analysis/pull/1712

• https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#pull_request_target

• https://github.blog/changelog/2023-02-02-github-actions-updating-the-default-github_token-permissions-to-read-only/

• https://www.stepsecurity.io/blog/supply-chain-security-alert-popular-nx-build-system-package-compromised-with-data-stealing-malware

• https://www.wiz.io/blog/s1ngularity-supply-chain-attack