On March 30, 2026, security researchers uncovered a sophisticated attack targeting the popular Axios NPM package. Instead of exploiting code vulnerabilities, the attackers executed an account takeover of a lead maintainer. By altering the associated email address and bypassing GitHub Actions CI/CD safeguards, they were able to publish malicious versions directly via the NPM CLI.
The compromised versions—[email protected] and [email protected]—introduced a hidden dependency: [email protected]. This dependency contained a postinstall script that executed automatically during installation. Once triggered, it deployed a cross-platform Remote Access Trojan (RAT) capable of targeting macOS, Windows, and Linux systems.
The malware established communication with a command-and-control (C2) server at sfrclak[.]com, fetching platform-specific payloads. To evade detection, it deleted its traces and restored a clean-looking package.json file, making post-compromise analysis significantly harder.
This attack highlights a critical weakness in trust-based ecosystems like NPM. Developers often assume that widely used packages are safe, but when maintainers themselves are compromised, that trust becomes a liability.
How the Attack Chain Worked
The attack relied on the standard behavior of NPM dependency resolution. When a developer installed a compromised Axios version, the package manager automatically fetched the malicious dependency. The postinstall script then executed silently, initiating the infection process.
This technique is particularly dangerous because it requires no explicit user interaction beyond a routine install command. CI/CD pipelines, which frequently run automated installs, are especially vulnerable as they can unknowingly propagate the compromise across environments.
LiteLLM PyPI Attack: A New Level of Stealth
Just days earlier, on March 26, 2026, another significant supply chain attack targeted LiteLLM, a widely used AI infrastructure library on PyPI with millions of daily downloads. The threat group TeamPCP was behind this operation, which also affected other tools like Trivy and KICS.
Two malicious versions—1.82.7 and 1.82.8—were briefly available before being removed, but the short exposure window was enough to cause concern.
What made this attack particularly insidious was its use of Python’s .pth files. In version 1.82.8, a file named litellm_init.pth was added to the site-packages directory. Python automatically executes code within .pth files during startup, meaning the malicious payload could run even if the LiteLLM library was never explicitly imported.
In version 1.82.7, attackers embedded an obfuscated Base64 payload inside proxy_server.py, which executed immediately upon import. These techniques allowed attackers to harvest sensitive information such as AWS, GCP, and Azure credentials, SSH keys, and Kubernetes configurations.
Unlike traditional malware, this approach leveraged legitimate packaging and distribution mechanisms. The malicious code passed integrity checks because it was published using valid credentials, not injected post-distribution.
The Broader Implications
These incidents reveal a troubling reality: the software supply chain is now a primary attack surface. Open-source ecosystems thrive on collaboration and trust, but that same openness creates opportunities for adversaries.
Attackers are increasingly targeting maintainers, CI/CD pipelines, and package registries instead of end-users. By compromising a single dependency, they can infiltrate thousands of downstream applications.
The Axios and LiteLLM cases also demonstrate the importance of understanding transitive dependencies. Many developers may never directly install a malicious package, yet still become victims through indirect dependencies.
Indicators of Compromise (IOCs)
Security teams should monitor for the following indicators associated with these attacks:
Axios-related IOCs:
- sfrclak[.]com (C2 domain)
- 142.11.206[.]73 (IP address)
- Malicious package versions:
- [email protected] → e56bafda15a624b60ac967111d227bf8
- [email protected] → 21d2470cae072cf2d027d473d168158c
- [email protected] → db7f4c82c732e8b107492cae419740ab
LiteLLM-related IOCs:
- checkmarx[.]zone (C2 polling)
- models[.]litellm[.]cloud (data exfiltration)
- Malicious files:
- litellm_init.pth → cde4951bee7e28ac8a29d33d34a41ae5
- proxy_server.py → f5560871f6002982a6a2cc0b3ee739f7
These indicators should be integrated into monitoring systems to detect potential compromises early.
Mitigation Strategies for Modern Development Teams
Defending against supply chain attacks requires a layered approach. Organizations must enforce strict dependency management practices, including the use of lockfiles and reproducible builds. Tools like Software Composition Analysis (SCA) can help identify vulnerable or malicious packages before they are introduced into production environments.
Access control is equally critical. Applying least-privilege principles, rotating credentials regularly, and enforcing phishing-resistant multi-factor authentication can significantly reduce the risk of account takeovers.
CI/CD pipelines should be hardened by eliminating plaintext secrets, using secure secret managers, and restricting network access. Monitoring for unusual publishing activity or unexpected dependency changes can also provide early warning signals.
Finally, organizations should consider implementing a release cooldown period, allowing time for newly published packages to be vetted before adoption.
Conclusion
The Axios and LiteLLM incidents serve as stark reminders that the software supply chain is only as secure as its weakest link. As attackers continue to evolve their tactics, organizations must shift from reactive security measures to proactive, defense-in-depth strategies.
Our Perspective on This Emerging Threat Landscape
What stands out in these incidents is not just the technical sophistication, but the strategic shift in attacker mindset. Instead of targeting hardened systems directly, adversaries are exploiting trust relationships within developer ecosystems. This is a far more scalable and efficient attack model.
In our view, the industry has been slow to adapt to this new reality. While organizations invest heavily in endpoint and network security, supply chain security often remains an afterthought. This imbalance creates a dangerous gap that attackers are clearly exploiting.
Another critical issue is over-reliance on open-source without adequate governance. Open-source software is invaluable, but blind trust in packages—especially those deeply embedded in production systems—can be risky. Developers and organizations must adopt a “trust but verify” approach.
We also believe that accountability needs to evolve. Package maintainers, platform providers, and enterprises all share responsibility for securing the ecosystem. This includes better identity protection for maintainers, stronger registry-level safeguards, and more transparent disclosure practices.
Ultimately, supply chain security is not just a technical challenge—it’s a cultural one. Organizations must prioritize security at every stage of development, from dependency selection to deployment. Those that fail to do so risk becoming the next headline in an increasingly active threat landscape.
