The April 2026 npm, PyPI, and Docker Hub supply-chain wave: a response playbook

Three Attacks, One Prize

Between April 21 and April 23, 2026, three independent supply-chain compromises landed on the three largest open-source package registries — npm, PyPI, and Docker Hub — and a fourth, downstream attack pushed a malicious Bitwarden CLI to npm for roughly ninety minutes before maintainers caught it. The four incidents were distinct, but they shared a single objective: harvest CI/CD credentials, cloud tokens, and developer secrets at scale.

The April 22, 2026 compromise of the official Checkmarx KICS Docker images and VS Code extension was the headline incident. Docker flagged anomalous activity on the checkmarx/kics repository and alerted the Socket research team within hours. The injected payload was straightforward in design and brutal in scope: it harvested GitHub authentication tokens, AWS access keys, Azure and GCP credentials, npm configuration files, SSH private keys, and the entirety of the running shell environment, then compressed and encrypted everything before exfiltrating to an attacker-controlled endpoint. Because Bitwarden’s CI/CD pipeline used the Checkmarx KICS GitHub Action for security scanning, the same compromised tool harvested Bitwarden’s own GitHub and Azure credentials and was used to push a malicious @bitwarden/[email protected] package to npm. That package was live for roughly ninety minutes before the Bitwarden team rotated keys, pulled the package, and posted a public advisory. Ninety minutes was enough time for any CI runner that auto-installed Bitwarden CLI on every build to pull the bad version.

One day earlier, on April 21, 2026, a campaign tracked by Socket and StepSecurity as CanisterSprawl poisoned a malicious version of pgserve, a PostgreSQL server runner for Node.js, on npm. The compromised package’s postinstall hook ran a credential-harvesting script on every npm install. CanisterSprawl is named for its use of an Internet Computer Protocol (ICP) canister as the command-and-control channel — a deliberate choice for resilience: takedown of an ICP canister requires consensus-layer action and is not the one-call abuse-form takedown that a typical attacker domain would be.

And on April 22, 2026, three consecutive releases of xinference on PyPI carried a credential-stealing payload, targeting the AI/ML developer audience that has become a high-value pool of cloud and model-API credentials.

All four attacks targeted the same data: ~/.aws/credentials, ~/.config/gcloud, GITHUB_TOKEN, ~/.docker/config.json, ~/.npmrc, ~/.ssh/, and any environment variable matching common secret patterns. None of the four required a zero-day. None required social engineering of the package maintainers. They were ordinary supply-chain compromises against the trust boundary that virtually every CI/CD pipeline crosses on every build.

Why the 2026 Threat Model Is Different

Three structural changes in 2025 and early 2026 raised the impact of an attack like the one against Checkmarx KICS by an order of magnitude:

• CI runners hold more credentials than ever. A 2026 CI job typically auths to GitHub, the cloud provider, the package registry, the container registry, the secret manager, and an observability vendor inside a single run. A single compromised dependency in that run can exfiltrate the entire credential set in milliseconds.
• AI coding agents widen the dependency graph. Cursor, Claude Code, and the in-IDE agents pull in dependencies, run install commands, and edit package.json files faster than humans review them. The fraction of a given codebase whose dependency tree was last reviewed by a human shrinks every quarter.
• The MCP-tooling explosion adds a parallel supply chain. Every MCP server is a piece of code an agent runs in the developer’s environment. The MCP supply chain is younger, more fragmented, and less audited than npm or PyPI, and it executes inside the same environment as the developer’s existing credential store.

The combination is the security category that AppSec leaders have been raising in board reviews for the last six months: the developer environment, the CI runner, and the agent runtime are now the same attack surface, and the perimeter is whatever package was published most recently.

The Seven-Step Response Playbook

Teams that have weathered the April 2026 wave well share a written response playbook that runs in a fixed order. The seven steps:

1. Detect. Subscribe to Socket, GitGuardian, StepSecurity, and the official registry advisory feeds. Set monitor rules on the package names your build depends on. The April 2026 wave was identified within hours of publication for all four incidents because the research community has the detection layer running continuously; the question is whether your alerting catches it.

2. Scope blast radius. When an alert lands, the immediate question is: which CI runs, which developer machines, and which production builds pulled the bad version in the affected window? npm audit, pip-audit, and docker scan answer the developer-side question; CI logs and registry pull logs answer the CI-side question. The blast-radius answer determines every subsequent step.

3. Rotate credentials, in priority order. GitHub PATs, cloud provider IAM credentials, npm publish tokens, container registry credentials, observability tokens, and any secret that was in the runtime environment of an affected job. The rotation order matters because some rotations gate others — rotating a GitHub PAT before the cloud credentials it gates leaves you locked out of the cloud rotation.

4. Revoke and reissue downstream artifacts. Any package, container image, or release artifact published from an affected runner during the affected window is suspect and should be revoked. The Bitwarden CLI ninety-minute window is the canonical example: a malicious build artifact published from an attack window contaminates everything downstream.

5. Rebuild from clean infrastructure. Spin up new CI runners, new build images, new dependency caches. Pin to known-good versions of every package that was in the affected build. The “rebuild on the same compromised runner” failure mode has been the recovery-stage incident on more than one of the April 2026 cases.

6. Verify with reproducible builds. Compare hashes of the rebuilt artifacts against the hashes of the artifacts produced before the incident window. Any unexpected delta is a signal that the rebuild did not actually clean the environment.

7. Communicate. Internal channels first, then customer-facing if any external artifact was affected. The Bitwarden public advisory model — what was affected, what window, what was rotated, what customers should do — is the template for this step in 2026.

Most of the seven steps are mechanical; what kills response time is the lack of a written playbook. The teams that ran the April 22 incident in two hours had the playbook written before April 22.

See the IAN team run on your cloud. We connect to your AWS account via a scoped read-only role, run the Observe-tier agents, and leave you with a concrete audit report — cost waste, security exposure, compliance gaps, and a labor-offset estimate. You keep the findings regardless of next steps. Get a free infrastructure audit →

What Tooling Helps and Where It Falls Short

The 2026 supply-chain tooling landscape covers the detection and SBOM layers reasonably well: Socket and GitGuardian for live registry monitoring; Snyk, GitHub Advanced Security, and Endor Labs for dependency vulnerability databases; Sigstore and SLSA for build provenance; Anchore, Syft, and Grype for SBOM generation and scanning. The April 2026 wave validated all of those tools — they detected the compromises within hours.

Where the tooling landscape is still thin is on the response side. Detection without response automation just produces alerts. The April 2026 incidents that recovered quickly had three things the standard tooling does not provide:

• A pre-written, version-controlled response runbook specific to the team’s CI topology.
• Pre-authorized credential rotation paths that do not require a fresh approval cycle in the middle of an incident.
• An audit trail of every credential, every build artifact, and every CI run that crossed the affected window.

Those three live in the gap between point-tool security and operational governance. They are the work of an active operational layer, not a passive scanner.

Capability Tiers Mapped to Supply-Chain Response

The Observe / Operate / Administer capability-tier model applies cleanly to supply-chain response:

• Observe. Continuous SBOM generation, dependency drift detection, registry monitoring, build-provenance verification. Auto-execute, fully audited. The detection step lives here.
• Operate. Credential rotation against pre-approved scopes, package revocation, automated rebuilds, blast-radius enumeration. Auto-execute for reversible / scoped actions; gated when a rotation crosses a customer-impacting threshold. Steps three through six of the response playbook live here.
• Administer. Customer communications, root credential rotation, IAM policy changes, separation-of-duties exceptions for emergency response. Always requires explicit approval.

The mapping is the difference between a security team that scrambles for two days after an incident and one that contains it inside a single shift.

How IAN Helps: The Security-Agent on the Active Operational Layer

IAN is the AI DevOps team for cloud infrastructure, delivered as a coordinated team of specialized agents on the active operational layer. The security agent is one of those agents, and it is built natively for the post-April-2026 supply-chain threat model.

The security agent runs continuous SBOM generation and dependency-drift detection across every connected repository and CI runner. Registry advisories from Socket, GitGuardian, GitHub Advisory Database, and the official npm / PyPI / Docker Hub channels are ingested as MCP tool calls, scored against the customer’s own dependency graph, and surface in the audit trail with blast-radius enumeration attached. When a compromise lands inside the affected window, the agent has already produced the list of affected CI runs, the credential exposure map, and a draft rotation plan.

Reversible Operate-tier actions — credential rotation against pre-approved scopes, package revocation, rebuild triggers — execute automatically when policy permits. Irreversible or customer-facing actions escalate to the Administer tier with separation-of-duties enforced. Every action lands in the immutable audit trail, which doubles as the evidence pack for the customer-facing advisory.

Pricing is BYOK and usage-based with a monthly minimum. Customers bring their own model keys (Claude, OpenAI, or another provider) and pay inference cost directly to their model vendor. IAN charges for the orchestration layer, per agent action, per cloud account, per operation class. Usage scales with the number of dependency events processed, which is itself a strong signal of where the team should invest in supply-chain hardening.

The Three-Phase Rollout

Phase 1 — Stand up the supply-chain Observe layer. Wire SBOM generation, registry monitoring, and build-provenance checks into every CI runner and every connected cloud account. Two-to-four weeks for a team with reasonable CI capacity.

Phase 2 — Codify the response runbook. Write the seven-step playbook against the team’s specific CI topology. Pre-authorize the credential-rotation scopes the security agent can act on. Run a tabletop exercise against the April 2026 attack profile and measure time-to-contain. Two-to-three months of pattern tuning.

Phase 3 — Promote scoped Operate-tier actions. Let the security agent execute credential rotation, package revocation, and rebuild triggers for the reversible cases under capability-tier governance. Keep customer-facing communication and root-credential rotation gated to Administer-tier approval. Measure the time-to-contain delta against the Phase 2 baseline.

The pattern compounds. By the time Phase 3 lands, the security team is doing different work — fewer minutes scrambling for blast-radius answers in the middle of an incident, more minutes hardening the supply chain so the next incident is smaller — and the security-agent has accumulated enough audit data to make the next round of policy tuning a data exercise rather than a debate.

Get a free infrastructure audit → | See pricing →