Your developers work for cyber gangs

But you will need to understand a little about how your devs work, to get a handle on the risk.

When your development team runs npm install or pip install, they aren’t just installing the package they asked for. They’re installing that package’s entire dependency tree, which can run to hundreds of packages, each maintained by different individuals and organisations, each with their own security posture (or lack of one).

The axios compromise illustrates this perfectly. axios is a foundational HTTP client library used by a vast range of JavaScript projects. It’s a dependency of developer tools, application frameworks, and AI coding assistants alike. Anyone who installed or updated any npm package that transitively depended on axios during a roughly three-hour window on 31 March 2026 may have pulled in a version containing a remote access trojan. Incident responders at Huntress found the malware had propagated through dependency chains into unexpected places, including deeply nested WordPress modules.

This has a specific implication for organisations using AI-assisted development tools. If your developers use tools like Claude Code, Cursor, Copilot or similar AI coding assistants that are distributed via npm, those tools themselves are part of the dependency tree and therefore part of the attack surface. Anthropic confirmed that developers who installed or updated Claude Code via npm during the axios compromise window may have pulled in the malicious version. The recommended mitigation was to move away from npm-based installation entirely.

The uncomfortable reality for CIOs and risk officers is this: your organisation may have built and deployed production software during March 2026 that contains attacker-placed code. If your CI/CD pipeline ran without lockfiles, without pinned dependencies, and without suppressed install scripts, the malware executed silently during the build process, stole whatever credentials were available, cleaned up after itself, and left no trace in standard audit tools.

Two of the three campaigns summarised above used blockchain networks for command-and-control, and this represents a meaningful shift in the threat landscape that deserves specific attention.

Traditional malware C2 relies on domains and/or IP addresses. When defenders identify a malicious C2 server, they can seize the domain, issue a takedown to the hosting provider, or block the IP at the network perimeter. This works because domains and servers have identifiable owners and jurisdictional levers.

Blockchain-based C2 removes those levers. When an attacker writes instructions into a Solana transaction memo or deploys a payload to an ICP canister, that data becomes part of an immutable, globally distributed ledger. There is no registrar to contact, no hosting provider to compel, and no single server to block. GlassWorm’s malware polled a Solana wallet address every five seconds, reading updated C2 instructions from transaction memo fields. The attacker could update the payload URL at any time with a new transaction costing fractions of a cent.

For defenders, blocking outbound connections to known blockchain RPC endpoints at the network perimeter is now a relevant control, alongside traditional domain and IP-based blocking. For risk officers, the implication is that the window between compromise and effective containment is growing, because the attacker’s infrastructure will outlast the incident response.

The attack patterns demonstrated in March 2026 are not new individually. Tag poisoning, credential theft via CI/CD, and dependency confusion have all been documented before. What’s new is the scale, the coordination, and the convergence of multiple techniques into self-reinforcing campaigns where each compromise provides the credentials needed to execute the next.

TeamPCP’s operation spanned five ecosystems in a single coordinated campaign. GlassWorm compromised 433 components using AI-assisted automation. And a North Korean group turned the most widely used HTTP client in the JavaScript ecosystem into a dirty RAT delivery vehicle. All three campaigns adopted techniques that resist the takedown mechanisms defenders have relied on for decades.

For organisations that build software, the question is no longer whether your dependency tree contains risk. It does. The question is whether you have the visibility to know when that risk materialises, and the controls to contain it before it reaches production.

dotSec helps Australian organisations assess and manage software supply chain risk through penetration testing that extends to CI/CD pipelines and build infrastructure, managed SOC and SIEM services that provide detection coverage across development and production environments, and governance and compliance services that help you build supply chain risk into your security programme. If you’d like to discuss your organisation’s exposure, get in touch.