Supply Chain Attacks on AI Tools:
Axios, LiteLLM & Claude Code
— Lessons for InfoSec & GRC

The Week That Changed Things

Between 19 and 31 March 2026, the software supply chain suffered a sequence of coordinated, cascading attacks that exposed a systemic vulnerability at the very heart of modern software development: the implicit trust we place in the open-source tools and packages we install every day without reading.

Within a 12-day window, four of the most widely used tools in software development and AI engineering were compromised. A security scanner used by millions of CI/CD pipelines. An AI model routing library downloaded 3.4 million times per day. The flagship coding tool of the world's leading AI safety company. And the most popular JavaScript HTTP client in existence, with 100 million weekly downloads. Each incident was technically distinct. But taken together, they tell a single coherent story about where modern information security and GRC frameworks are dangerously behind the threat landscape.

This article is a practitioner's analysis — not a news report. My intent is to go beyond the headlines, examine what these incidents reveal about the structural weaknesses in how organisations consume open-source software, and set out a clear, actionable framework for what information security and GRC teams must do in response. Some of these lessons are uncomfortable. The tools we use to secure our software were themselves the attack vector. That tells us something profound about the current state of software supply chain security.

Incident 1 — Axios npm: State-Sponsored RAT Delivery

On 31 March 2026, between 00:21 and 03:20 UTC — a window of less than three hours — the most trusted JavaScript HTTP client in the world was turned into a malware delivery vehicle by a North Korean state-sponsored threat actor.

What Makes This Particularly Dangerous

Three aspects of this attack warrant specific attention from security practitioners. First, the attack vector bypasses every traditional perimeter defence. The threat didn't come from a phishing email, an unpatched server, or a malicious website. It came from a developer running npm install — an action that happens hundreds of millions of times per week, in CI/CD pipelines, on developer workstations, in production rebuild environments. No firewall blocks npm install. No endpoint protection flags it as suspicious. No user training prevents it.

Second, the malware was forensically designed to be undetectable after execution. Wiz researchers confirmed that after execution, the malicious package self-deletes and replaces its own package.json with a completely clean manifest. Running npm audit or manually reviewing installed packages after the fact reveals nothing. Traditional post-incident investigation methods fail completely.

Third, the attacker specifically targeted both release branches simultaneously — the current 1.x branch and the legacy 0.x branch — maximising exposure across an ecosystem where projects span years of version history. This is not opportunistic. This is operational planning.

For any organisation that had Axios installed or updated in CI/CD pipelines during the 00:21–03:20 UTC window on 31 March, the guidance from every major vendor (Microsoft, Google, Tenable, Wiz) is unambiguous: treat the environment as fully compromised, rotate all credentials, and rebuild from a known-clean state. Do not attempt to scan or clean — the malware was designed to defeat that approach.

Incident 2 — LiteLLM PyPI: The Cascading Compromise

The LiteLLM attack is, in many ways, the most instructive of the three incidents covered here — because it shows exactly how modern supply chain attacks cascade through the software ecosystem. This was not a direct attack on LiteLLM. It was an attack on a security tool that LiteLLM trusted.

The Cascading Compromise Pattern

What makes the LiteLLM attack distinctively important for security practitioners is the attack cascade pattern: a security tool was compromised first, and that compromise was used as the entry point to attack a downstream target. The sequence matters enormously, and it raises a question that every security team must now answer honestly: Do we know the security posture of the tools we use to secure our software?

LiteLLM's team used Trivy — a widely-trusted, open-source vulnerability scanner — as part of their CI/CD security workflow. That's exactly what security best practice recommends: automate security scanning in your pipeline. The attack exploited that best practice as the attack vector. This creates a deeply uncomfortable paradox: the organisations that had done the right thing — integrating security scanning into their pipelines — were more exposed than those that hadn't.

There is a further downstream dimension. Because LiteLLM is increasingly deployed as a centralised LLM gateway — holding API credentials for multiple model providers simultaneously — a single compromise of a LiteLLM instance gives an attacker access to a credential set broader than almost any other single-package compromise would. Mercor, a $10 billion AI recruiting startup working with OpenAI and Anthropic, confirmed it was one of thousands of companies affected. The extortion group Lapsus$ claimed responsibility for a subsequent data exfiltration, suggesting a multi-actor exploitation of the initial TeamPCP compromise.

Incident 3 — Claude Code: The Source Code That Got Away

The Claude Code incident is categorically different from the supply chain attacks above — it was not a malicious attack. It was a human error: a packaging misconfiguration that accidentally included a 59.8 MB JavaScript source map in a public npm release. What happened next, however, illuminates how even non-malicious security failures become attack vectors in the hands of a motivated threat landscape.

The Compounding Risk of the Same-Day Overlap

The timing of the Claude Code leak — occurring on the same day as the Axios RAT attack, and within the same npm ecosystem — created a compounding risk that VentureBeat and multiple security firms flagged immediately. Users who installed or updated Claude Code via npm on 31 March 2026 between 00:21 and 03:29 UTC may have simultaneously pulled the compromised Axios dependency as a transitive package. The two incidents, while entirely unrelated in origin, intersected at the npm registry on the same day, in the same time window, affecting the same developer population.

The broader lesson from the Claude Code incident is not specifically about Anthropic's packaging process — it is about what the incident reveals for every organisation building and deploying software. When source code is exposed, the consequences do not end when the code is taken down. The internet does not forget. Thousands of mirrors, forks, and analyses persist permanently. And they become the raw material for two categories of ongoing risk: targeted vulnerability discovery (attackers with full source visibility can find and weaponise vulnerabilities with dramatically less effort) and social engineering via trust impersonation (malicious repositories masquerading as official or "unlocked" versions to distribute malware to curious developers).

The Full Attack Chain: Trivy → Checkmarx → LiteLLM → Axios

The individual incidents described above did not occur in isolation. TeamPCP (also identified as PCPcat, Persy_PCP, ShellForce, and DeadCatx3) executed a methodical, multi-phase campaign across 12 days, with consistent infrastructure — the same RSA key pair, same payload naming conventions, and the same tpcp-docs-prefixed GitHub repositories as dead-drop C2 staging across every operation.

The fact that UNC1069 and TeamPCP operated independently — on the same day, in overlapping ecosystems — is not coincidental serendipity. It reflects a broader intelligence picture: the software supply chain is under sustained, multi-actor attack from threat groups who understand that poisoning a trusted package is, from a cost-benefit perspective, one of the most efficient attack vectors available. A single compromised maintainer account, or a single unguarded CI/CD secret, can yield millions of downstream installations.

Why AI Development Tools Are the New Crown Jewel Target

There is a non-obvious reason why LiteLLM and Claude Code are more attractive targets than a typical npm or PyPI package — even one with comparable download volumes. It is not simply about scale. It is about what AI development tools have access to.

A standard web application library might have access to a database connection string and an API key. An AI development tool like LiteLLM, operating as a centralised LLM gateway, typically holds API credentials for every major AI provider simultaneously: OpenAI, Anthropic, Google, Azure OpenAI, Cohere, and more. It may also have access to the context and data being passed to those models — which may include proprietary business data, personal data, and confidential communications. A single successful compromise of a production LiteLLM deployment is worth orders of magnitude more to an attacker than a standard credential harvest.

Claude Code presents a different but equally significant risk profile. As an AI coding agent operating in the terminal, it has more access to developer systems than almost any other developer tool: it can read files, execute shell commands, write code, access environment variables, connect to external services, and interact with version control. The source code exposure revealed that some of this capability operates with permissions established before user trust prompts appear — creating pre-trust initialisation windows that are now documented attack surfaces.

Security Analysis: What These Incidents Really Reveal

Beneath the technical details of each individual incident, these attacks collectively expose seven structural weaknesses in how the industry currently approaches software security. These are not novel vulnerabilities in any specific product. They are systemic patterns of trust misplacement that the industry has known about for years but has not yet resolved at scale.

1. The Implicit Trust Problem

Every one of these attacks succeeded because of trust that was implicit rather than verified. Developers trust packages on npm and PyPI to be what they claim to be because they were published by a known maintainer. CI/CD pipelines trust GitHub Actions to pull from the correct repository because they have in the past. LiteLLM trusted Trivy because it is a widely used security tool. That implicit trust — the assumption of integrity without verification — is the root vulnerability. The perimeter model of security (trust what is inside, distrust what is outside) has no meaningful concept of "inside" when your software supply chain spans thousands of open-source packages maintained by individuals globally.

2. Maintainer Account Compromise as the Critical Weak Point

Both the Axios and LiteLLM attacks hinged on compromised maintainer accounts. In Axios's case, the primary maintainer's npm credentials were stolen. In LiteLLM's case, the PyPI publishing token was exfiltrated from a CI/CD environment. In neither case was the application code itself vulnerable — the compromise happened at the identity layer, not the application layer. The software was clean; the publishing mechanism was not. This is a fundamental shift in the threat model for open-source security: the question is no longer "is this code safe?" but "was this code published by who we think it was, through a process we can verify?"

3. The Security Scanner Paradox

The most alarming pattern in the TeamPCP campaign is the deliberate targeting of security tooling. Trivy. Checkmarx KICS. Both are tools organisations specifically use to improve their security posture. By compromising these tools first — and using them as the entry point for downstream attacks — TeamPCP demonstrated that security tooling is not just an attack surface; it is a privileged attack surface. Security tools run in CI/CD with elevated permissions. They are trusted by default. They are rarely themselves subject to security review. And they have access to exactly the kind of credentials — publishing tokens, cloud credentials, deployment keys — that make a high-value exfiltration target.

4. The SBOM Gap — We Don't Know What We're Running

A Software Bill of Materials (SBOM) is the inventory of every software component in your supply chain. Regulatory frameworks — the US Executive Order on Cybersecurity (2021), the EU Cyber Resilience Act, and NIST guidance — have all begun requiring SBOM practices. But having an SBOM and acting on it are different things. The organisations most severely affected by the Axios attack were those running automated CI/CD pipelines that pulled "latest compatible" versions. They had no real-time visibility into what was being installed, no automated detection when a new malicious version appeared on the registry, and no process to verify the integrity of packages against a known-good state. An SBOM that is not actively monitored is an audit artefact, not a security control.

5. The Window Problem — Detection Lags Behind Exposure

Both the Axios and LiteLLM attacks had exposure windows of approximately three hours. In that window, developers running npm install or pip install in CI/CD pipelines worldwide were compromised. Detection of both attacks came through manual observation — a security researcher examining Axios packages, and a developer's machine crashing due to a fork-bomb bug in the LiteLLM malware (the bug that exposed the attack was an error in the malware itself, not a security control). Neither was detected by automated security tooling in real time. For practitioners, this underscores the inadequacy of periodic scanning alone. The threat actor's operational window is measured in hours. Detection and response must operate in the same timeframe.

6. Credential Aggregation as an Existential Risk

Both the Axios RAT and LiteLLM credential stealer were designed to exfiltrate the broadest possible set of credentials from compromised machines: SSH keys, cloud tokens, API keys, environment variables, Kubernetes configurations, wallet files, shell history. The goal is not just the immediate credentials on one machine — it is the lateral movement opportunity those credentials enable. A stolen GitHub token can be used to compromise repositories. A stolen AWS key can pivot into a cloud environment. A stolen CI/CD secret can be used exactly as TeamPCP used Trivy's stolen token: to publish malicious packages under a trusted name. The exfiltrated credentials from March 2026 will generate downstream incidents for months.

7. AI-Specific Risk: The Source Code Exposure Vector

The Claude Code leak introduces a category of risk that is specifically relevant to AI systems and that traditional security frameworks are not yet equipped to handle: the operational blueprint as an attack enabler. When a conventional application's source code is exposed, attackers gain visibility into the application's logic. When an AI agent's source code is exposed, attackers gain visibility into how the agent interprets instructions, how it establishes trust, when it executes commands without user confirmation, and precisely which inputs can be crafted to trigger unintended actions. Pre-trust initialisation windows, permission escalation paths, and MCP server integration points are now documented and publicly analysed. This is not a catastrophic breach — but it is a meaningful, permanent shift in the security posture of the tool.

GRC Framework: Where Compliance Must Catch Up

The incidents described above expose significant gaps between the current state of GRC frameworks and the actual threat landscape for software supply chain security. ISO 27001, NIST CSF, and SOC 2 were all designed before the open-source software supply chain became the dominant software delivery model. They are not wrong — but they are incomplete. Here is where each major framework currently falls short, and what organisations must do beyond compliance requirements.

ISO 27001 / ISO 27002

ISO 27002:2022 introduced Annex A control 8.8 (Management of technical vulnerabilities) and 5.23 (Information security for use of cloud services). Neither addresses the supply chain attack vector as it manifested in March 2026. Control 8.8 focuses on vulnerability management for deployed software — it does not address the integrity of software during the installation or build process. A passing ISO 27001 audit does not mean your organisation has validated the integrity of every package it installs in CI/CD, has implemented dependency pinning, or has any visibility into the real-time security status of its package registry dependencies.

Organisations seeking genuine supply chain security under ISO 27001 should extend their ISMS scope to explicitly cover software dependency management — including the tools used to build and deploy software (including security tools like vulnerability scanners). This is a control gap that the upcoming ISO 27001:2025 revision will need to address more directly.

NIST Cybersecurity Framework (CSF) 2.0

NIST CSF 2.0, released in February 2024, added a "Govern" function and strengthened supply chain risk management (GV.SC). NIST SP 800-218 (Secure Software Development Framework) provides more specific SBOM and supply chain guidance. However, the guidance remains at the policy level. The technical controls needed to defend against the March 2026 attacks — real-time package registry monitoring, cryptographic hash verification of installed packages, isolated CI/CD environments with allowlisted network egress — are not prescribed in detail. Compliance with NIST CSF GV.SC requirements is achievable without implementing any of these controls.

The EU Cyber Resilience Act & EU AI Act

The EU Cyber Resilience Act (CRA), entering into force in 2027, will impose mandatory SBOM requirements and vulnerability disclosure obligations on software manufacturers. For the first time, open-source component maintainers who receive commercial support will bear legal obligations for security. The LiteLLM and Axios incidents are exactly the scenario the CRA was designed to address. Organisations with EU customers or EU operations should be treating CRA compliance preparation as a current priority, not a 2027 problem.

The EU AI Act additionally requires providers of high-risk AI systems to maintain technical documentation and implement risk management systems covering the entire supply chain of their AI applications. If your organisation deploys AI systems that use LiteLLM as an LLM gateway, the LiteLLM compromise is a direct supply chain risk event that your AI Act risk management framework should have detected and responded to.

ISO 42001 — AI Management Systems

ISO 42001, the AI Management System standard, addresses AI risk management, including risks from AI-specific supply chain elements. The Claude Code incident — and the broader AI tool compromise pattern — demonstrates exactly why Clause 6.1 (Actions to address risks and opportunities) and Annex A controls covering AI system integrity must be extended to cover the integrity of AI coding tools used in the development workflow. If your developers use AI coding agents, those agents are part of your AI supply chain. Their security posture is your security posture.

The Practitioner Action Plan

Theory matters, but action matters more. Here is the structured response framework that information security and GRC practitioners should be executing in the immediate, short-term, and medium-term following these incidents.

Immediate Actions (This Week)

Short-Term Actions (30–90 Days)

• Implement dependency pinning organisation-wide. Remove ^ and ~ version prefixes from all production package.json and requirements files. Use exact versions. Lock files must be committed and CI must use npm ci (not npm install) to enforce lockfile integrity. For Python, use pip install --require-hashes with cryptographic verification of every package.
• Deploy real-time Software Composition Analysis (SCA). Implement tools (Snyk, Dependabot with alerting, Socket.dev) that provide real-time monitoring of package registry status — not just periodic scanning. The March 2026 attacks had three-hour exposure windows. Periodic scanning that runs weekly or daily provides no meaningful protection against that threat profile.
• Harden CI/CD secret management. Transition all long-lived CI/CD tokens to short-lived credentials using OIDC Trusted Publishing. Eliminate stored API keys and tokens from GitHub Actions, GitLab CI, and similar environments. The LiteLLM attack succeeded because a long-lived PyPI publishing token was accessible to the CI/CD runner. With OIDC, that token would not exist to be stolen.
• Implement network egress controls for build environments. Build pipelines should have allowlisted, controlled network egress. The Axios RAT communicated with [C2 domain]. The LiteLLM exfiltrator communicated with models.litellm[.]cloud. Neither of these domains would be in a correctly configured allowlist for a build pipeline. Restricting outbound connections from CI/CD and build environments is one of the most effective mitigations against supply chain malware that has no bearing on legitimate build processes.
• Establish an AI tool security governance policy. Define which AI coding tools are approved for use, at which versions, with which permission profiles. Require security review before any AI tool version update is deployed to developer workstations. AI tools are developer infrastructure — they should be managed with the same rigour as any other infrastructure component.
• Build and maintain a living SBOM. Implement SBOM generation as part of the CI/CD pipeline for every application. The SBOM must be actively monitored — integrated with vulnerability intelligence feeds that alert in near-real-time when a component in your SBOM appears in a known-malicious registry entry. A static SBOM generated at release time does not protect against attacks that occur between releases.

Medium-Term Actions (90–180 Days)

• Extend your ISMS scope to cover the software supply chain explicitly. Under ISO 27001, define assets to include your package dependency inventory. Include software supply chain risk in your risk register. Assess the control effectiveness of your current dependency management practices against the threat scenarios demonstrated in March 2026.
• Begin EU Cyber Resilience Act readiness assessment. If your organisation develops software with components available in the EU market, or if you process data of EU residents, the CRA's SBOM and vulnerability disclosure requirements will apply. Start gap assessment now — the 2027 enforcement date is closer than it appears from a remediation standpoint.
• Implement AI-specific risk controls under ISO 42001. Extend your AI management system to include the AI tools used in the development workflow. Claude Code, Cursor, and GitHub Copilot are part of your AI supply chain. Their access permissions, version management, and security posture are AI governance questions, not just IT security questions.
• Run supply chain attack scenarios in tabletop exercises. Include the "compromised security tool as attack vector" scenario specifically. Most organisations have never tested their incident response against the pattern demonstrated by TeamPCP: security scanner compromised → CI/CD secrets exfiltrated → downstream package registry poisoned → developer machine and production environment compromised. Test your detection, response, and communication playbooks against this scenario.

What the Industry Must Do Next

The events of March 2026 are not an anomaly. Software supply chain attacks more than doubled globally during 2025, with roughly 30% of all data breaches now linked to third-party or supply chain components. What changed in March 2026 is the target profile: the attacks moved from generic infrastructure packages to the specific tools used by AI developers — and in doing so, they exploited a trust relationship that the security industry has not yet adequately addressed.

The conventional security model assumes that the things you use to build and secure your software are themselves trustworthy. The TeamPCP campaign demonstrated that this assumption is wrong — systematically, deliberately, and profitably wrong. The security scanner you installed to find vulnerabilities in your dependencies was itself the attack vector. This is not a theoretical concern. It happened, in production, at scale, to some of the most security-conscious engineering teams in the industry.

For information security leaders, the strategic implication is clear: the perimeter of your security programme must extend to encompass the entire software supply chain, including the tools used to build, test, deploy, and secure your software. Every tool that has privileged access to your build environment — your SAST scanner, your SCA tool, your container image builder, your AI coding agent — is a potential attack vector. If it is not version-pinned, hash-verified, network-controlled, and monitored, it is a trust assumption that an adversary can exploit.

For GRC leaders, the implication is equally clear: current compliance frameworks are not sufficient to detect or prevent the attack patterns demonstrated in March 2026. A passing ISO 27001 audit, a clean SOC 2 report, or a compliant NIST CSF implementation does not mean your software supply chain is secure against these attacks. The frameworks must be extended — through explicit supply chain risk management, real-time SBOM monitoring, OIDC-based credential management, and AI-specific security governance.

The good news is that the defensive controls are known, practical, and deployable now. Dependency pinning, cryptographic hash verification, OIDC Trusted Publishing, network egress controls, and real-time SCA monitoring are not experimental technologies. They are available, mature, and relatively inexpensive to implement. The organisations that execute these controls will be significantly less exposed when the next campaign — and there will be a next campaign — targets the next trusted tool in their supply chain.