A massive attack steals credentials from developers using trusted libraries

A massive attack steals credentials from developers using trusted libraries

A cyberattack campaign called Shai-Hulud has compromised hundreds of software packages in the two most widely used repositories among programmers around the world: npm (for JavaScript) and PyPI (for Python). What is serious is not just the amount of affected code, but the fact that the malicious packages carried valid digital signatures and passed every automatic security check. To protection systems, they looked 100 % legitimate.

What are npm and PyPI and why do they matter?

Imagine that npm and PyPI are like grocery stores for ingredients used to cook software. Developers do not write everything from scratch; they go to these repositories, pick up ready-made libraries (for example, one that manages dates or one that connects to a database) and add them to their projects. Every time someone downloads one of those libraries, they trust that it is safe because it comes from the "official store".

The Shai-Hulud attack has poisoned the shelves of that store. The attackers slipped in fake versions of very popular libraries —such as TanStack (used in thousands of modern websites), Mistral AI (artificial intelligence tools), Bitwarden CLI (password manager) and even official SAP packages—. According to the security firms Endor Labs and Socket, there are between 160 and 416 compromised packages.

How they made the malicious code look legitimate

The main trick was stealing digital identity credentials (OIDC tokens) that the developers themselves use to publish updates automatically. It is as if a thief got hold of the uniform, the key and the badge of a trusted delivery driver: he can enter the warehouse, swap products for poisoned versions and no one notices because "he is the usual delivery guy".

They also exploited three chained flaws in GitHub Actions workflows (the system that compiles and publishes code automatically):

• Insecure configurations that allowed running foreign code on the main project.
• Poisoning of the shared cache, sneaking in fake dependencies.
• Theft of identity tokens from the memory of the build server.

The result: the malicious packages carried SLSA Level 3 attestations, the highest standard for "this code was built on the official site and has not been tampered with". The automatic checks gave the green light.

What the malware looks for once inside

The goal is not to break the computer, but to spy and steal secrets. The malicious code scans the developer’s environment and extracts:

• GitHub tokens and npm publishing keys.
• Amazon Web Services, Kubernetes and HashiCorp Vault credentials.
• Configurations of AI tools such as Claude Code and VS Code tasks.

To go unnoticed, the malware sends what it steals through the Session Messenger network, which looks like legitimate encrypted messaging traffic. It also installs itself in Claude Code "hooks" and in automatic VS Code tasks: uninstalling the package does not clean up the infection.

There is a chilling detail: in environments that appear to be in Israel or Iran, the malware has a 1 in 6 chance of executing a full disk wipe (rm -rf /). This suggests a geopolitical motivation in addition to credential theft.

What development teams should do right away

Experts recommend immediate steps:

1. Version audit: review lock files (package-lock.json, yarn.lock, pnpm-lock.yaml, poetry.lock) looking for unexpected recent updates of the affected projects.
2. Rotate all credentials: if a compromised version was downloaded, assume that every secret on that machine or CI/CD server is exposed. Change GitHub, npm, AWS tokens, SSH keys, etc.
3. Clean up persistence: review configuration directories of IDEs (VS Code, JetBrains) and AI tools (Claude Code) because the malware survives uninstallation.
4. Enforce strict installs: use only npm ci, pnpm install --frozen-lockfile or pip install --require-hashes to avoid silent updates.
5. Block command-and-control infrastructure: cut off at the firewall or DNS the domains api.masscan.cloud, git-tanstack.com and *.getsession.org.

The lesson: the digital signature is no longer enough

This attack shows that a valid signature does not guarantee that the code is safe. The attackers have learned to steal the identity of legitimate publishers and to use the official infrastructure against itself. Defenses must add a layer of behavioral analysis at install time: is this package trying to read SSH keys? Is it connecting to strange servers? Only that way can what the signature hides be detected.

Meanwhile, anyone who uses software —which nowadays is everyone— should know that the code supply chain is a priority target for cybercriminals. The security of the applications we use every day begins in the "pantry" where programmers buy their ingredients.