Software’s month of supply chain chaos

September 2025 was a busy month for software supply chain security.

Here at Workbrew, we spend a lot of time talking to administrators and security professionals about their concerns with keeping a grip on their organization’s software ecosystem. In September 2025, a lot of nightmares have come true, with a spree of supply chain attacks and governance fumbles impacting multiple language ecosystems. You may have heard of one or two of them, but since the chaos has been so distributed, we wanted to round up the happenings in one place.

Should I be concerned about these supply chain attacks?

Let’s get to the burning question: are these attacks likely to affect your org? To answer that, we have to look at what the supply chain is in this context. Most of the issues we are tracking in this post concern the package managers for particular programming languages. These are package managers used to distribute packages written in the target language, and intended for use in other software written in that language as dependencies. In use, these package managers download and install arbitrary code, including that of their own dependencies.  Unfortunately, knowing whether your organization is at risk is not as simple as asking “do our developers use this language?”, as dependencies within a programming language ecosystem may rely on components written in other languages.

This is especially true of two of the languages we are talking about today. Javascript/Node.js, and Python are very popular, and almost certainly in your supply chain. Especially if you work within the domains in which they are widely used, such as web applications, data science, or AI/ML. Many developer tools, even for other languages, are also written in Node.js and Python and are often distributed via package managers, increasing exposure to attacks that seek to compromise packages.

The worm eating Javascript

Bless the maker and his packages

npm, the Microsoft-owned package manager for the Node.js ecosystem, has been beset by a self-replicating worm, appropriately named Shai-Hulud, the name given in reverence to the giant worms of Dune by the Fremen. Naming your own worm after fiction’s biggest and baddest shows grand ambitions, and rightly so, as Shai-Hulud has reportedly compromised over 500 packages, including some popular packages with regular downloads in the millions.

The ultimate goal of Shai-Hulud appears to be credential harvesting: once a compromised package is installed on a system, it uses a variety of tricks, including open source credential scanner trufflehog, to find and exfiltrate cloud keys and access tokens for popular cloud platforms. In the process, it spreads itself, looking for npm and GitHub tokens that it can use to compromise more packages.

As of the time of writing, the attack is ongoing, and npm users should exercise caution in installing and updating packages. StepSecurity have an excellent write-up of how the worm functions, and how to monitor for compromise: https://www.stepsecurity.io/blog/ctrl-tinycolor-and-40-npm-packages-compromised

PyPI package takeover foiled

Whilst Shai-Hulud ploughs through the Javascript ecosystem, a similar attempt to compromise the Python Package Index (PyPI) was discovered and prevented. This attack featured malicious code injected into GitHub Actions in an attempt to exfiltrate PyPI publishing tokens, which would allow attackers to take over the packages. Fortunately, the malicious code was noticed, and the PyPI team revoked the tokens for the affected packages before any harm could be done. You can read more about the attack on the PyPI blog: https://blog.pypi.org/posts/2025-09-16-github-actions-token-exfiltration/

(GitHub) Actions have consequences

GitHub Actions is a critical component in both the npm and PyPI attacks, being used to run malicious code to exfiltrate information, as well as push compromised packages to the package managers. The ubiquity of GitHub Actions is in part because of its ease of use and availability, right there on GitHub alongside the source code, but that is also what makes it such a tempting target for these attacks. As Actions workflow files are contained in the repository alongside the source code, every GitHub account with write access is a potential vector for shipping malicious code. Phishing operations target developers, gain access to GitHub Actions workflow files, and can immediately begin running arbitrary code, with access to any secrets stored in the Actions environment, such as package manager publishing tokens.

There are some basic steps every GitHub Actions user should take to mitigate these risks, particularly those who are using it to push to cloud environments or publish packages. Review access to your repositories with the Principle of Least Privilege in mind, to ensure that the surface area for phishing attacks is minimized. GitHub features such as CODEOWNERS and branch protection rules can make it harder to add malicious code to workflow files, through requiring changes be made via a reviewed pull request. But remember, a compromised account can also approve a pull request, so requiring multiple reviewers for workflow files may provide better protection. Tokens are a prime target in these attacks, which once exfiltrated, allow an attacker to make changes and continue the attack outside of the GitHub Action, making it harder to observe and remediate an attack. OIDC trusted publishing is a new alternative to long-lived tokens that provides some protection in these cases, as it ties publishing to that particular service, preventing the exfiltration of publishing rights. It is increasingly supported, including by both npm and PyPI.

Don’t lose your head: RubyGems governance

These attacks, highlighting the importance of supply chain vulnerabilities in package managers, caused a governance dispute in the Ruby ecosystem. Ruby Central, stewards of the RubyGems package management service, removed the access of several long-term maintainers from the Ruby Gems and bundler source code, leading to resignations and community turmoil. The exact sequence of events that lead to this action, and whether they had the right to do so, is still being debated in the blog posts on either side (Freedom Dumlao, Joel Drapper), but what any maintainer of an active open source project can tell you is that trust and community are tenuous things, and once lost, can be hard to rebuild. And when it comes to where you get your software dependencies, trust is very important. When exercising security best practices such as Principle of Least Privilege it’s important to also consider the sociocultural implications of people’s access rights, and how it might reflect the scale and history of their contributions, as Homebrew Fellow Mike McQuaid explores on his blog.

Fake download pages for LastPass

After all of the package manager drama, let’s reset with a reminder of why these trusted software repositories can be fantastic resources for a secure organization. Downloading your favourite software from the internet can be a minefield in its own right, as highlighted by a campaign targeting Mac users of LastPass, which has seen a large number of fake LastPass websites propagating via GitHub Pages attempting to lure users to download and run malicious code. The websites are using SEO techniques to appear in the top of search results for queries such as “LastPass GitHub MacOS”, and result in the installation of a credential stealing malware on the victim’s system. Homebrew itself has been the target of a similar attack in the past, with attackers’ using Google Ads to prominently position a fake Homebrew download in search results. Check out the LastPass blog for more details and how they’re tackling the campaign.

Ctrl-f Homebrew

Reading all this news, you would be right to have questions about Homebrew security. Packages added to Homebrew’s official taps are human vetted and subject to ongoing automated audits. Homebrew works with security partners to perform audits, of which it shares the results publicly. You can learn more about Homebrew security in our post about the Homebrew contribution model.

When installing Homebrew via Workbrew, you benefit from the additional security of the Workbrew Agent, which wraps Homebrew in a secure layer. The Workbrew Console allows you to see installed packages and their versions, track relevant CVEs, and block specific packages. Should the worst happen, such as a Shai-Hulud-like attack on Homebrew, these features give you the power to remediate the situation and prevent compromised package installs. Take a look for yourself: Workbrew’s free plan includes access to package observability in the Console, and support for unlimited devices. Sign up for the free plan today.