A single broken link in a steel chain, representing the trust chain vulnerabilities exploited in recent open source supply chain attacks

In the span of three weeks this spring, five incidents shook the open source ecosystem: four supply chain attacks on widely used packages, and a breach at one of the largest frontend platforms. LiteLLM, the Python library that half the AI tooling ecosystem uses to call model APIs, was poisoned through a compromised security scanner. Axios, the most downloaded HTTP client on npm (100 million weekly downloads, 174,000 dependent packages), had malicious versions published through a hijacked maintainer account. A portfolio of 30+ WordPress plugins was quietly acquired on Flippa, backdoored, and left dormant for eight months before activation. North Korean attackers attempted to merge malware directly into better-auth through legitimate-looking pull requests. And Vercel disclosed a breach that originated from a compromised third-party AI tool used by an employee, exposing internal systems and potentially npm and GitHub tokens.

These are not isolated incidents. They are a pattern, and the pattern is accelerating.

The March-April 2026 Supply Chain Attacks

Each attack exploited a different vector, but all of them targeted the same thing: the trust chain that connects open source packages to production systems.

LiteLLM (March 24, 2026). A threat group called TeamPCP compromised Trivy, a widely-used security scanner, by exploiting a misconfigured GitHub Actions workflow on March 19. That gave them access to CI/CD credentials across every organization whose pipeline ran during the exposure window. They pivoted to Checkmarx KICS on March 23, then used credentials harvested from LiteLLM's own CI/CD pipeline to publish poisoned versions (1.82.7 and 1.82.8) to PyPI on March 24. The payload used Python's .pth file mechanism, which runs on interpreter startup regardless of whether the package is ever imported. It exfiltrated SSH keys, AWS credentials, Kubernetes secrets, and environment variables. LiteLLM has over 2,000 downstream dependents including dspy, mlflow, and Open Interpreter.

Axios (March 31, 2026). A separate operation, attributed by both Microsoft and Google to North Korean state actors (tracked as Sapphire Sleet by Microsoft, UNC1069 by Google), hijacked the npm account of axios's lead maintainer. The attacker published two poisoned versions (1.14.1 and 0.30.4) targeting both the modern and legacy release branches. The malicious versions injected a fake dependency, plain-crypto-js, which had been staged 18 hours earlier. The dependency's postinstall script dropped a cross-platform remote access trojan for macOS, Windows, and Linux. After execution, the malware deleted itself and replaced its own package.json with a clean version to evade forensic detection. The poisoned versions were live for approximately three hours before npm pulled them.

WordPress EssentialPlugin (August 2025 to April 2026). An attacker purchased the EssentialPlugin business (30+ plugins, thousands of active installations) through Flippa, a public marketplace for digital assets. They embedded a dormant backdoor into every plugin's codebase. The backdoor sat quietly for eight months. On April 5-6, 2026, it activated. For six hours and 44 minutes, the plugins' analytics module downloaded malicious payloads and injected code directly into wp-config.php. The most striking forensic detail: the malware served cloaked SEO spam exclusively to Google's crawler. Site owners and human visitors saw a normal site. Search engines saw something else entirely. WordPress.org closed 31 plugins on April 7.

Better-auth (ongoing). North Korean-linked attackers submitted pull requests to the popular JavaScript authentication library that contained legitimate feature additions with malicious code hidden in standalone commits. The payload was placed in build configuration files (next.config.mjs, vue.config.js) and scrolled far to the right, exploiting the fact that GitHub's default view does not show horizontal overflow. The same attack signature has been found in 30+ repositories on GitHub, and the actual number is likely much higher.

Vercel (April 19, 2026). The fifth incident shows the attack surface has widened beyond packages themselves. The breach originated from a compromise of Context.ai, a third-party AI platform used by a Vercel employee. The attacker used that access to take over the employee's Google Workspace account, which gave them access to internal Vercel systems and environment variables not marked as "sensitive." Vercel is the primary steward of Next.js and underpins frontend infrastructure for thousands of applications. Claims on BreachForums describe employee accounts, internal deployment access, source code, GitHub tokens, and npm tokens being offered for $2 million.

Timeline of supply chain attacks from March 19 to April 19, 2026, showing the TeamPCP cascade from Trivy to LiteLLM, the separate DPRK axios compromise, WordPress plugin activation after eight months dormant, ongoing better-auth PR attacks, and the Vercel breach

Blockchain as Supply Chain Attack Infrastructure

The WordPress plugin attack introduced something that changes the calculus for defenders. Instead of hardcoding a command-and-control domain (which can be blocked at the DNS level or seized by authorities), the malware resolves its C2 address by querying an Ethereum smart contract on a public blockchain RPC endpoint. The address stored in the contract can be updated by the attacker at any time, and the blockchain itself is immutable and decentralized. You cannot take it down.

This technique, known as "EtherHiding," was documented by Google's threat intelligence team as a DPRK tactic. Its appearance in the WordPress attack and the better-auth PRs (which use Trongrid and Binance endpoints for payload delivery) represents a significant escalation. Traditional incident response assumes that once the malicious package is pulled from the registry and the C2 domain is blocked, the threat is contained. Blockchain-based C2 infrastructure breaks that assumption. Infected instances remain infected and can receive new instructions even after the source package is removed, because the C2 resolution mechanism does not depend on any centralized infrastructure that defenders can seize.

This matters for remediation. Every site that installed a compromised EssentialPlugin update between August 2025 and April 7, 2026 needs manual remediation: inspecting wp-config.php for injected code, checking for unknown cron jobs, auditing admin accounts for unauthorized additions. The WordPress.org forced security update removed the backdoor's entry point, but if the payload already executed, the damage persists independently of whether the source package still exists on the registry.

North Korea's Open Source Supply Chain Campaign

This is no longer speculation. Both Microsoft Threat Intelligence and Google Threat Intelligence Group have publicly attributed the axios compromise to North Korean state-sponsored actors. Microsoft tracks the group as Sapphire Sleet, an offshoot of BlueNoroff with a documented history of targeting cryptocurrency and fintech. Google tracks it as UNC1069 and attributed the RAT as WAVESHAPER.V2, a known North Korean backdoor.

The TeamPCP campaign behind the Trivy-to-LiteLLM chain is assessed as separate from the axios operation, though SANS researchers noted potential connections. TeamPCP cascaded through five ecosystems (GitHub Actions, Docker Hub, npm, OpenVSX, PyPI) across nine days. The better-auth pull requests carry DPRK-linked EtherHiding fingerprints. Whether these campaigns are coordinated or independent, the picture is the same: the open source supply chain is now a target for well-resourced, patient, technically sophisticated actors who are willing to invest months of preparation for a single attack.

The WordPress plugin acquisition was made eight months before activation. The better-auth PRs contained legitimate feature work to build credibility. The axios operation pre-staged a decoy package 18 hours before the poisoned versions dropped. These are not smash-and-grab operations. They are campaigns. And they will continue.

How AI Coding Agents Amplify Supply Chain Risk

Research from Amplifying AI analyzed 2,430 tool picks made by Claude Code across different project types and found that when the agent picks a tool, it picks decisively: GitHub Actions 94% of the time, Stripe 91%, shadcn/ui 90%. When a growing number of developers let AI coding agents handle dependency selection, the stacks converge. The same libraries show up in the same combinations across thousands of new projects.

This is a monoculture problem. In agriculture, planting the same crop across every field means a single disease can wipe out the entire harvest. In software, converging on the same dependencies means a single compromised package has a larger blast radius than it would in a more diverse ecosystem. When AI agents consistently recommend the same packages, the incentive for attackers to target those specific packages grows proportionally.

The Vercel breach adds another dimension. The attack did not start with Vercel. It started with Context.ai, an AI platform used by a single employee. That one compromised AI tool gave attackers a path into Google Workspace, which gave them access to internal systems, which potentially exposed npm tokens and GitHub credentials for one of the most widely used frontend platforms in the ecosystem. The attack surface is no longer just the packages themselves. It includes every AI tool, every third-party integration, and every OAuth connection that touches a developer's workflow.

As Docker's engineering team observed in their supply chain defense guide: a compromised dependency pulled by a coding agent has the same blast radius as a compromised developer machine, and the people using these agents now include non-developers who may not recognize suspicious behavior. The combination of AI-driven dependency convergence and AI-powered development environments creates an attack surface that is both wider (more projects using the same packages) and deeper (each compromised install has access to more resources) than what existed two years ago.

Who Secures the Open Source Supply Chain

The current model places extraordinary responsibility on individual open source maintainers, many of whom are unpaid volunteers. The actions or inactions of a single developer (a reused password, an unrotated token, a merged PR that was not reviewed carefully enough) can open the door to consequences that affect thousands of downstream projects and millions of end users.

The WordPress attack exposed a different angle of this problem. The attacker did not hack a maintainer's account. They bought the business. On Flippa, for a reported six figures. The original developers had built a legitimate portfolio over nearly a decade. Revenue dropped, so they sold. The buyer embedded backdoors into every plugin and waited. There is no technical exploit here. The attack vector was a financial transaction. The trust model that WordPress.org, npm, and PyPI rely on assumes that the entity publishing a package is the same entity that built its reputation. Ownership transfers break that assumption, and no registry currently has a mechanism to flag or audit them.

The infrastructure layer has shown it can respond quickly. npm pulled the axios versions within three hours. PyPI quarantined LiteLLM rapidly. WordPress.org closed 31 plugins within days. But these responses are reactive. They stop new infections. They do not remediate existing ones, especially when blockchain-based C2 infrastructure means infected instances can receive new instructions indefinitely.

The ecosystem needs structural changes: mandatory OIDC-based publishing (which npm already supports but does not require), registry-level provenance verification, ownership transfer audits, and better tooling for maintainers to secure their accounts and CI/CD pipelines. Some of this is happening. The Open Source Security Foundation is working on several of these fronts. But the gap between what is available and what is adopted remains wide, and the attackers are exploiting that gap methodically.

Supply Chain Defenses That Work Now

The defenses available today are not perfect, but they are significantly underused. Most of these require minutes to implement and would have caught or mitigated every attack described above.

Seven-layer defense stack for software supply chain security, ordered from foundational to behavioral: lockfiles, frozen installs, ignore-scripts, SHA-pinned Actions, min-release-age, provenance verification, and behavioral analysis

Set a minimum release age. The single simplest defense against supply chain poisoning is to never install a package version that was published in the last few days. Both the LiteLLM and axios attacks were discovered and pulled within hours, but anyone who installed during that window was compromised. A three-day minimum would have prevented exposure to both.

  • npm (v11+): Set min-release-age in your .npmrc to require packages to have been published for a minimum number of days before they can be installed. A value of 3d is a reasonable starting point. Dependabot added support for this configuration in July 2025.
  • uv: Use --exclude-newer to exclude packages published after a specific date.
  • pip (26.0+): Use --uploaded-prior-to to install only versions uploaded before a specific date.

Use lockfiles and frozen installs. Lockfiles (package-lock.json, poetry.lock, uv.lock) pin exact versions and integrity hashes. In CI/CD, always use npm ci or pnpm install --frozen-lockfile rather than npm install, which can resolve to newly published versions that are not in the lockfile. If your CI runs npm install without a lockfile, any dependency in your tree can silently update to a compromised version between builds.

Disable install scripts in CI. The axios attack used a postinstall hook to execute the RAT dropper. The LiteLLM attack's .pth file ran on Python interpreter startup even if the package was never imported. Use --ignore-scripts in npm/pnpm CI runs to block lifecycle hooks entirely. For Python, audit your site-packages for unexpected .pth files: find $(python -c "import site; print(site.getsitepackages()[0])") -name "*.pth".

Pin GitHub Actions by SHA. Pin Actions to specific commit SHAs rather than tags. Tags are mutable references that can be moved at any time. SHAs are immutable. The Trivy compromise that launched the TeamPCP campaign exploited exactly this: pipelines referencing Trivy by unpinned tag executed malicious code on the next run. Tools like StepSecurity's secure-repo can automate the conversion from tag-based to SHA-based pinning.

Verify provenance. Every legitimate axios release used npm's OIDC Trusted Publisher mechanism, cryptographically tied to a verified GitHub Actions workflow. The poisoned versions were published manually with a stolen access token, with no OIDC binding and no corresponding GitHub commit. That discrepancy was the forensic signal that something was wrong. npm supports provenance statements that link a published package to a specific source commit and build workflow. If your dependencies publish provenance, verify it. If you publish packages, enable it.

Run behavioral analysis. Static analysis catches known patterns. Behavioral analysis catches what packages actually do at install time: outbound network connections, file system access, environment variable reads, process spawning. Socket.dev provides this for npm and PyPI packages. StepSecurity Harden-Runner monitors CI/CD workflows for anomalous outbound connections. It was Harden-Runner that detected the axios C2 callback in the Backstage project's CI, flagging a connection to the attacker's domain that had never appeared in any prior workflow run.

Audit transitive dependencies. The LiteLLM attack affected developers who never directly installed LiteLLM. They installed LangChain integrations or ML tools that pulled it as a transitive dependency. Run pip show litellm or npm ls axios to see if a compromised package is anywhere in your tree. Run pip-audit or npm audit in CI as a required gate, not a suggestion.

As Dani Akash documented, minimum release age is not a substitute for lockfiles, --ignore-scripts, SHA-pinned Actions, provenance verification, or behavioral analysis. It is one layer. The attacks we are seeing now are sophisticated enough that a single defense is not sufficient. You need the stack.

If your team builds on open source and you are not sure where your exposure is, we can help with a dependency audit and CI/CD hardening review.

The Early Warning

Five incidents in three weeks. The WordPress attack demonstrated patience (eight months dormant) and innovation (blockchain C2 that survives takedown). The axios attack showed operational precision and has been attributed to a North Korean state actor. The Vercel breach showed that third-party AI tools are now part of the attack surface. The TeamPCP campaign demonstrated that a single compromised CI/CD token can cascade across five ecosystems in nine days.

If this is the early-warning period, the defenses need to be in place before the next round. The tools exist. The question is whether they get adopted in time.

If your team is building on open source (and you are), audit your dependency chain this week. Set a minimum release age. Pin your GitHub Actions by SHA. Verify provenance on your critical packages. And check the ownership history of the plugins and libraries you depend on, because the next attack may not come from a hacker. It may come from a buyer. These are not aspirational best practices. They are the minimum viable defense against the threat landscape as it exists right now.

Get in touch if you need help assessing your exposure.

Related Posts

Spam reputation gauge with the needle in the red zone. Envelope icons cluster on the healthy green side of the meter while bot icons crowd the orange and red warning area.
February 27, 2026 • Frank Valcarcel

Bots Are Quietly Destroying Your Email Deliverability

Every verification email your system sends to an address that did not ask for it is a small bet against your sender reputation. At the scale bots operate today, with automated traffic now exceeding 51% of all web activity, those bets add up fast. Bot deterrence is not optional.

Aerial view of a bridge splitting over water, representing multi-gateway payment routing, failover strategy, and redundant checkout infrastructure for SaaS subscription billing.
February 19, 2026 • Frank Valcarcel

Why Every SaaS Needs a Backup Payment Gateway

If your entire SaaS revenue flows through a single payment gateway and that gateway freezes your account, your cash flow drops to zero overnight. It happens more often than you think. Here is how to build redundancy into your payment stack before you need it.

Let's work together

Tell us about your project and how Cuttlesoft can help. Schedule a consultation with one of our experts today.

Contact Us