On June 17, 2026, a single stolen developer account turned the most popular AI-agent framework on npm into a delivery system for North Korean malware. In roughly 19 minutes, attackers republished more than 140 packages in the @mastra scope, each quietly wired to pull in a malicious dependency, harvest cryptocurrency wallets, and phone home to a command-and-control server. Two days later, Microsoft’s threat-intelligence team pinned the operation on Sapphire Sleet, a state-sponsored crew better known as BlueNoroff and APT38. It was the first time a nation-state had been caught running a mass npm supply chain attack, and it capped the worst six months the JavaScript registry has ever seen.
The Mastra compromise did not happen in isolation. It was the sixth headline-grade poisoning of npm in eleven weeks, following near-identical hits on Bitwarden’s CLI, SAP’s Cloud Application Programming packages, the TanStack ecosystem, the AntV visualization libraries, and Red Hat’s cloud-services namespace. Together they exposed hundreds of millions of weekly downloads to credential theft. This analysis breaks down exactly what happened, why npm has become the epicenter of open-source malware, what it means for every engineering team that runs npm install, and where the software supply chain goes from here.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
North Korea’s Mastra Hit Marks a Turning Point for the npm Supply Chain
Mastra is a TypeScript framework for building AI agents, and its packages ship with the kind of trust that makes a supply chain attack devastating: developers install them, then wire them straight into applications that hold API keys, cloud credentials, and model access. That is precisely why Sapphire Sleet targeted it. According to BleepingComputer’s reporting on Microsoft’s findings, the attackers first seized control of an npm maintainer account under the handle ehindero, which held publishing rights across the entire Mastra package environment.
What followed was fast and automated. At 01:01 UTC on June 17, the crew published a brand-new package called easy-day-js – a deliberate typosquat of the ubiquitous dayjs date library, which pulls roughly 57.2 million weekly downloads. Nineteen minutes later, at 01:20 UTC, the first trojanized Mastra release ([email protected]) went live with easy-day-js injected as a dependency. Over the same window, more than 140 additional @mastra packages were republished carrying the same poisoned import. Every developer or continuous-integration pipeline that ran an install during that period would have silently pulled the malicious code.
Microsoft assessed “with high confidence” that the campaign belonged to Sapphire Sleet, a North Korean state actor active since March 2020 that primarily targets the financial sector. The speed and precision – a fresh typosquat and 140 republished packages inside 20 minutes – pointed to a pre-built, scripted toolkit rather than manual tampering. This is the maturation the industry feared: the same kind of automated, industrialized npm supply chain attack that criminal crews had been refining all year, now in the hands of a government-backed group with a track record of stealing billions in cryptocurrency.
Inside the Mastra Compromise: 140 Packages, One Stolen Account
The single most important detail of the Mastra incident is also the most uncomfortable one for the ecosystem: the attackers did not exploit a software vulnerability. They logged in. The ehindero account – a legitimate maintainer with write access to the Mastra scope – was taken over, and from that trusted position the entire attack unfolded. There was no zero-day, no dependency-confusion trick against a private registry, no clever parser bug. It was an account takeover, the oldest problem in security, weaponized against the most sensitive publishing rights in modern software.
Once inside, the crew leaned on the mechanics of npm itself. Because packages routinely declare dependencies on other packages, injecting a single malicious dependency – easy-day-js – into 140 popular packages meant every downstream project inherited it transitively. The typosquat name was chosen to survive a glance: a distracted engineer scanning a lockfile diff might read easy-day-js and think of dayjs without a second thought. This is the quiet genius of a well-run supply chain attack; it does not need to break anything, it only needs to be installed.
The trojanized packages behaved normally at runtime. Mastra still built, agents still ran, tests still passed. The malicious behavior lived in an npm lifecycle hook that fires automatically during installation, before a developer ever imports the library. That design choice is what makes these campaigns so effective against CI/CD: build servers install dependencies thousands of times a day, non-interactively, with broad credentials in their environment. A poisoned postinstall script does not wait for a human to make a mistake – it runs the moment the package lands on disk. A representative shape of the offending manifest looked like this:
{
"name": "easy-day-js",
"version": "1.11.22",
"scripts": {
// fires automatically on `npm install`, before any import
"postinstall": "node ./scripts/setup.js"
}
}That one line – a postinstall pointing at an innocuously named setup.js – is the entire foothold. No exploit required, just the registry working exactly as designed.
What the easy-day-js Payload Actually Did
When the postinstall hook fired, it executed a 4,572-byte obfuscated dropper. Its first move was telling: it disabled TLS certificate verification across the Node.js process by flipping NODE_TLS_REJECT_UNAUTHORIZED, ensuring that its own encrypted callbacks would not be tripped up by inspection proxies or certificate pinning. It then dropped tracking markers into temporary directories and reached out to command-and-control infrastructure at 23.254.164.92:8000 and 23.254.164.123.
From that C2, the dropper pulled a second-stage Node.js implant of roughly 41 KB and established persistence across Windows, macOS, and Linux. On Windows the follow-on activity was especially aggressive: the malware deployed a PowerShell backdoor from separate infrastructure, added Microsoft Defender exclusions to blind the endpoint agent, and installed a malicious Windows service to survive reboots. This is not smash-and-grab; it is a beachhead built to persist inside a developer’s machine and, by extension, their organization.
The theft itself was tailored to Sapphire Sleet’s financial mission. The implant enumerated 166 cryptocurrency wallet browser-extension IDs – including MetaMask, Phantom, Coinbase Wallet, Binance Wallet, and TronLink – and extracted browser history from Chrome, Edge, and Brave. In the context of a developer machine, that harvest is a treasure map: it hands the attacker not only crypto wallets but the cloud credentials, LLM API keys, and authentication tokens that engineers keep close at hand. Every install during the exposure window was a potential total compromise of the developer’s secrets. The lesson of this npm supply chain attack is blunt: the blast radius of a poisoned dependency is the sum of everything the installing user can touch.
Sapphire Sleet: The North Korean Crew That Robs Developers
Sapphire Sleet is not a new name to threat hunters, even if its aliases can make it hard to track. The same North Korean group is cataloged as BlueNoroff, APT38, Stardust Chollima, TA444, UNC1069, Alluring Pisces, CageyChameleon, and CryptoCore across various vendors. Whatever the label, the mission is consistent: raise hard currency for the regime by stealing from banks, exchanges, and – increasingly – the individual engineers who build financial and crypto software.
The Mastra hit was not the group’s first foray into npm. As SecurityWeek documented, Sapphire Sleet ran a near-identical compromise of the widely used Axios HTTP client in April 2026, roughly two months before Mastra. The reuse of tradecraft – typosquatted helper dependency, TLS-disabling dropper, cross-platform implant, crypto-wallet harvesting – signals a repeatable playbook the crew now deploys against high-value JavaScript packages on demand. When a nation-state finds a formula that works, it does not stop at one target.
Strategically, the shift matters more than any single payload. For years, npm supply chain attacks were the domain of financially motivated criminals and researchers proving a point. A government intelligence service industrializing the same technique changes the threat model for every company that ships JavaScript. It means the adversary has patience, funding, and a strategic interest in persistence – not just a quick crypto-drain. It also blurs the line between cybercrime and espionage: the same implant that lifts a MetaMask seed phrase can just as easily exfiltrate source code, CI secrets, or the keys to a production cloud tenant.
The 2026 npm Supply Chain Attack Wave, by the Numbers
Mastra was the crescendo, not the whole song. Palo Alto Networks’ Unit 42, which has been tracking the 2026 npm campaigns, documented a relentless cadence of mass-poisoning events across the spring. Each shared the same DNA – a compromised maintainer account, an automated republishing burst measured in minutes, and a credential-harvesting payload – but the scale escalated with almost every incident. The table below reconstructs the wave that culminated in the North Korean operation.
| Date (2026) | Target / Scope | Packages or versions hit | Weekly downloads at risk | Notable payload detail |
|---|---|---|---|---|
| Apr 22 | Bitwarden CLI (@bitwarden/cli) | Core CLI package | Millions | Multi-platform blitz also hit Docker Hub, GitHub Actions, VS Code |
| Apr 29 | SAP Cloud App Programming (@cap-js/*) | 4 packages | ~570,000 | Mini “Shai-Hulud”-style credential harvester |
| May 11 | TanStack (@tanstack/*) | 373 versions / 169 packages | ~520 million | Polled GitHub API every 60s; wiped home dirs on token revocation |
| May 19 | AntV (@antv/*) | 639 versions / 323 packages | ~1.1M (echarts-for-react) | Largest single campaign; ~1-hour window |
| Jun 1 | Red Hat (@redhat-cloud-services) | 32+ packages | ~80,000 | “Miasma” payload; 200 KB file swapped for 4.29 MB blob |
| Jun 17 | Mastra AI (@mastra/*) | 140+ packages | Tens of millions (via dayjs typosquat) | North Korea’s Sapphire Sleet; crypto-wallet theft |
Read as a sequence, the pattern is unmistakable. The TanStack episode alone put an estimated 520 million cumulative downloads in the line of fire and shipped a destructive twist – a persistent service that polled api.github.com/user with a stolen token every 60 seconds and executed rm -rf ~/ when the token was revoked, torching the victim’s home directory. The AntV wave republished 639 malicious versions across 323 packages in about an hour. By the time Sapphire Sleet arrived in mid-June, the tooling to execute a fast, broad npm supply chain attack was effectively off-the-shelf.
Why npm Is Ground Zero: 99% of Open-Source Malware
None of this is bad luck. npm is the largest software registry on Earth, and its scale, its automatic lifecycle scripts, and its deep transitive dependency trees make it the highest-yield target in open source. Sonatype’s 2026 State of the Software Supply Chain report quantified just how lopsided the problem has become: more than 99% of all open-source malware observed in 2025 landed on npm, not on PyPI, Maven Central, NuGet, or Hugging Face.
The raw counts are staggering. Sonatype identified over 454,600 new malicious packages during 2025, pushing the cumulative total of known, blocked open-source malware past 1.233 million – a 75% year-over-year jump, first reported in the firm’s January 2026 research release and corroborated by Infosecurity Magazine. All of this rides on an ecosystem that absorbed roughly 9.8 trillion open-source downloads across the year. When distribution is that frictionless, a poisoned package reaches production in minutes.
| Open-source malware metric (Sonatype 2026) | Figure |
|---|---|
| New malicious packages found in 2025 | 454,600+ |
| Cumulative known malicious packages (all-time) | 1.233 million |
| Year-over-year growth in open-source malware | +75% |
| Share of 2025 open-source malware on npm | >99% |
| Ecosystems monitored | npm, PyPI, Maven Central, NuGet, Hugging Face |
| Annual open-source downloads | ~9.8 trillion |
Sonatype’s analysts framed 2025-2026 as the moment open-source malware “evolved from spam and stunts into sustained, industrialized campaigns against the people and tooling that build software.” The offensive hijacking of trusted, high-download packages – chalk and debug in late 2025, then the 2026 wave against TanStack, AntV, and Mastra – confirms that established maintainers are now the primary entry point for mass distribution. Attackers stopped uploading junk and started stealing the keys to packages developers already trust.
How an npm Supply Chain Attack Actually Works
Strip away the branding and every 2026 incident followed the same four-step arc. First, account takeover: the attacker phishes, session-hijacks, or credential-stuffs a maintainer’s npm login, or compromises a token with publish rights. Second, automated republishing: a script pushes malicious versions across every package the account controls, often dozens or hundreds, in a burst too fast for humans to review. Third, silent execution: a lifecycle hook – usually postinstall or preinstall – runs on every machine that installs the package. Fourth, credential exfiltration: the payload scrapes tokens, keys, and wallets and ships them to C2.
The postinstall hook is the load-bearing weakness
The reason lifecycle scripts keep appearing is that they turn a passive download into active code execution with zero user interaction. npm runs them by default. A developer who merely wants to install a date library ends up executing whatever the maintainer – or whoever stole the maintainer’s account – decided to run. Disabling those scripts is the single highest-leverage control a team can apply, and it is one config line:
# .npmrc – block preinstall/postinstall/install hooks everywhere
ignore-scripts=true
# Install only what the lockfile pins, no surprise resolutions:
# npm ci (deterministic, respects package-lock.json)
# instead of:
# npm install (can resolve new, freshly published versions)Setting ignore-scripts=true would have neutralized the Mastra dropper outright, because the entire attack depended on the postinstall hook firing. The trade-off is that some legitimate packages rely on install scripts to compile native modules, so teams typically maintain a small allowlist and run those builds in a sandbox. It is friction – but it is the friction that stands between a routine npm install and a nation-state backdoor.
Market Impact: Who Pays When the Registry Breaks
The direct victims of an npm supply chain attack are developers, but the bill lands on enterprises. Unit 42’s analysis of the 2026 payloads catalogued exactly what these implants reach for on a build server: GitHub and npm tokens, SSH keys, AWS, GCP and Azure credentials, Kubernetes service-account tokens, HashiCorp Vault secrets, credentials for more than 18 CI/CD platforms including GitHub Actions, GitLab CI, CircleCI, Vercel and Netlify, and even password-manager stores such as 1Password and Bitwarden. A single poisoned install inside a pipeline can hand an attacker the entire cloud estate.
That is why the cost of these events is measured in incident response, credential rotation, and downtime rather than in package downloads. When TanStack was compromised, every organization with the affected versions had to assume its GitHub tokens were burned and rotate them – a fire drill that consumes security and platform teams for days. When Red Hat’s cloud-services namespace shipped the “Miasma” payload, downstream consumers had to audit builds going back through the exposure window. The economic damage of a supply chain attack is the audit, not the artifact.
There is a slower, structural cost too: erosion of trust in open source itself. Enterprises are responding by standing up private registry proxies, mandating software bills of materials, and imposing quarantine windows on new package versions – all of which add latency and headcount to the simple act of pulling a dependency. The open-source model runs on the assumption that a package you install today is the same clean artifact the maintainer intended. Every mass poisoning chips away at that assumption, and rebuilding it is far more expensive than any single cleanup. The pattern rhymes with the broader breach economy chronicled in coverage of the ShinyHunters Oracle zero-day spree and the Novo Nordisk extortion: attackers monetize trust wherever it concentrates.
npm’s 2026 Security Overhaul: Trusted Publishing, 7-Day Tokens, 2FA
npm has not been idle. Through late 2025 and into 2026 the registry rolled out its most significant security overhaul in years, and much of it is genuinely useful. The centerpiece is trusted publishing, which lets maintainers publish directly from CI/CD using OpenID Connect (OIDC) instead of long-lived tokens, implementing the OpenSSF trusted-publishers standard. It requires npm CLI 11.5.1 or later and Node 22.14.0 or higher, and it removes an entire category of stealable secret from build pipelines.
Alongside it, npm tightened token hygiene aggressively. Newly created granular write tokens now default to a seven-day lifespan and cap out at 90 days, forcing rotation and shrinking the window a stolen token stays useful. Classic tokens were slated for removal at the end of 2025, and two-factor authentication is now enforced by default on new packages with write access, with an explicit “bypass 2FA” opt-in reserved for automated CI/CD flows. On paper, this is the strongest baseline npm has ever shipped.
And yet none of it would have stopped Mastra cleanly. Trusted publishing and short-lived tokens defend against token theft; the Mastra attack was an account takeover of the maintainer ehindero, operating from a fully trusted position. Once an adversary holds the account itself, publishing controls designed to authenticate that account become permissions the attacker inherits. Security researchers have repeatedly warned that npm’s token-centric reforms, however welcome, do not address account compromise or malicious lifecycle scripts – the two mechanisms that powered every major 2026 incident. The table below maps each control against the Sapphire Sleet playbook.
| npm 2026 control | What it defends against | Would it have stopped Mastra? |
|---|---|---|
| Trusted publishing (OIDC) | Stolen long-lived CI tokens | Partial – useless once the account itself is taken over |
| 7-day granular token expiry | Token theft window | Partial – narrows exposure, not account takeover |
| 2FA default on write tokens | Password-only credential stuffing | Partial – phishing / session theft can bypass |
ignore-scripts=true (consumer side) | Malicious postinstall hooks | Yes – directly neutralizes the dropper |
| Publish cooldown / quarantine (24-72h) | Installing brand-new poisoned versions | Yes – the highest-value consumer defense |
| SBOM + provenance attestation | Post-incident blast-radius analysis | No – detection and cleanup, not prevention |
Competitive Comparison: How Package Registries Stack Up
npm’s dominance as a malware target is partly a function of its own design choices, which stand out when set against peer registries. PyPI, the Python index, also runs install-time code through setup.py and has suffered its own poisoning campaigns, but it has pushed trusted publishing and 2FA harder and earlier across its most-downloaded projects. Maven Central, serving the Java world, requires cryptographic signing and a namespace-verification step that raises the bar for anonymous publishing, which is one reason it sees a fraction of npm’s malicious volume.
The Rust ecosystem’s crates.io is instructive as a counterexample. It does not execute arbitrary install scripts the way npm does; build logic runs in a more constrained model, which structurally removes the exact postinstall vector that Sapphire Sleet abused. That design difference – not superior policing – is why Rust has largely sidestepped the mass-poisoning wave. NuGet and Hugging Face round out Sonatype’s monitored set, each carrying malware but nowhere near npm’s more-than-99% share. The uncomfortable conclusion is that npm’s greatest strengths – frictionless publishing, automatic scripts, and enormous reach – are also the precise features attackers exploit.
For engineering leaders choosing where to place trust, the registry’s threat surface now belongs in the evaluation. A JavaScript-first shop cannot switch languages to dodge the problem, but it can borrow the safer registries’ defaults – signed artifacts, disabled install scripts, and hard publishing controls – and bolt them onto its npm workflow. The comparison also reframes the discussion around edge and infrastructure breaches like the CitrixBleed NetScaler flaw and the FortiBleed Fortinet compromise: the software supply chain is now as much of a perimeter as any firewall.
Historical Context: From event-stream to Mastra
Supply chain attacks on npm are not new; what changed in 2026 is their frequency, scale, and sponsorship. The genre’s origin story is the 2018 event-stream incident, when a maintainer handed control of a popular package to a volunteer who quietly injected code to steal from Copay bitcoin wallets. It was a landmark precisely because it proved that the weakest link in the chain was human trust, not code – a lesson the industry acknowledged and then largely failed to operationalize.
The intervening years delivered steady escalation: the 2021 hijack of ua-parser-js, a package with millions of weekly downloads, to drop cryptominers and password stealers; a run of typosquatting and dependency-confusion research that showed how easily private-package names could be shadowed on the public registry; and, in September 2025, the phishing-driven takeover of chalk and debug – utilities with more than a billion combined weekly downloads – which briefly put a huge slice of the JavaScript world at risk. Each incident was treated as an anomaly rather than a trend.
2026 ended that comfort. The spring wave of automated, mass-republishing campaigns – Bitwarden, SAP, TanStack, AntV, Red Hat – turned the one-off crisis into a monthly occurrence, and Mastra added the final escalation: state sponsorship. The through-line from event-stream to Mastra is a single unheeded warning – that the trust developers place in package maintainers is the softest and most valuable target in the entire toolchain, and that defending code without defending accounts was always going to fail.
How to Protect Your Pipeline From an npm Supply Chain Attack
The good news is that consumer-side defenses are cheap, well understood, and would have blunted every 2026 incident. Unit 42’s recommendations converge on a short, high-impact list. The first and most powerful is a quarantine window: refuse to install any package version published in the last 24 to 72 hours, so that a fast poisoning burst is detected and pulled before it reaches your builds. Because every 2026 attack raced to install victims within minutes of publishing, a cooldown alone defeats the core tactic.
A practical hardening baseline
Layer the controls: disable lifecycle scripts, install deterministically from the lockfile, and route everything through a proxy that enforces the cooldown and scans for known-bad versions. A minimal starting point looks like this:
# 1) Refuse packages published within the cooldown window
npm config set before "$(date -u -d '72 hours ago' +%Y-%m-%dT%H:%M:%SZ)"
# 2) Deterministic install from the lockfile, no install scripts
npm ci --ignore-scripts
# 3) Fail the build on known vulnerable/malicious versions
npm audit --audit-level=highBeyond the CLI, the durable fixes are organizational: route all npm traffic through a private registry proxy that quarantines and scans new versions, enforce strict egress filtering in CI so a payload cannot reach its C2 even if it runs, pin dependencies to known-good versions with integrity hashes, and generate SBOMs so that when – not if – the next incident hits, you can answer “are we exposed?” in minutes instead of days. Teams already running host-based detection with tools covered in our Wazuh SIEM guide or blocking malicious infrastructure with CrowdSec and Fail2ban can extend those same controls to catch a dependency that suddenly starts phoning home.
5 Predictions for npm Supply Chain Security Through 2027
1. More nation-state entrants. Sapphire Sleet proved a government-backed group can run a mass npm supply chain attack profitably. Expect other state actors – and the ransomware crews that imitate them – to adopt the same automated republishing playbook against high-value JavaScript packages within the next year.
2. Account takeover eclipses token theft. As trusted publishing and short-lived tokens make credential theft harder, attackers will pivot decisively to phishing and session-hijacking of maintainer accounts. The next wave of incidents will look more like Mastra – full account compromise – than like stolen CI tokens.
3. Install-script execution gets restricted by default. The pressure to disable postinstall scripts by default, or to sandbox them, will grow until npm or a major runtime forces the change. crates.io’s script-free model will increasingly be cited as the template.
4. Quarantine windows become standard. Publish-cooldown enforcement – already the single most effective consumer defense – will move from security-forward shops into default enterprise tooling and managed registry proxies, making “don’t install anything younger than 72 hours” a mainstream policy.
5. AI frameworks become priority targets. Mastra was chosen because AI-agent packages sit next to API keys, model credentials, and cloud tokens. As more of the ecosystem’s value concentrates in AI tooling, expect those scopes to draw a disproportionate share of the next year’s supply chain attacks.
Frequently Asked Questions
What is an npm supply chain attack?
An npm supply chain attack is when an attacker compromises a package in the npm registry – usually by taking over a maintainer’s account or a publishing token – and pushes a malicious version that executes on the machines of everyone who installs it. Because JavaScript projects pull in deep trees of dependencies, one poisoned package can silently reach thousands of downstream applications and CI/CD pipelines.
What happened in the Mastra npm attack?
On June 17, 2026, attackers took over the ehindero maintainer account and republished more than 140 packages in the Mastra AI framework’s npm scope, injecting a malicious typosquat dependency called easy-day-js. The payload disabled TLS verification, contacted command-and-control servers, and stole cryptocurrency wallets and browser data. Microsoft attributed the attack with high confidence to the North Korean group Sapphire Sleet.
Who is Sapphire Sleet?
Sapphire Sleet is a North Korean state-sponsored hacking group active since March 2020, also tracked as BlueNoroff, APT38, Stardust Chollima, and TA444, among other aliases. It focuses on stealing from financial and cryptocurrency targets to raise funds for the regime, and in 2026 it ran npm supply chain attacks against both the Axios HTTP client and the Mastra AI framework.
How do I know if I was affected by the 2026 npm attacks?
Audit your lockfiles for the affected versions and exposure windows of each incident – Mastra’s poisoned releases went live around 01:00-02:00 UTC on June 17, 2026. Check for the malicious easy-day-js dependency, unexpected outbound connections from build agents, and any new tokens or wallet activity. If you installed during an exposure window, assume all credentials on that machine are compromised and rotate them immediately.
Does disabling npm scripts really stop these attacks?
Largely, yes. Every major 2026 campaign, including Mastra, relied on a postinstall or preinstall lifecycle hook that runs automatically during installation. Setting ignore-scripts=true in your .npmrc and using npm ci prevents that code from executing. Some packages need install scripts to build native modules, so maintain a vetted allowlist and run those in a sandbox.
Is npm safe to use now?
npm remains the backbone of JavaScript development and is not going away, but it is the single most-targeted registry, carrying over 99% of open-source malware in 2025 per Sonatype. It is safe to use with the right controls: quarantine windows on new versions, disabled install scripts, deterministic installs, a scanning registry proxy, and prompt credential rotation. Treat the registry as untrusted infrastructure and defend accordingly.
What is npm doing to prevent supply chain attacks?
npm rolled out a 2026 security overhaul: trusted publishing via OIDC to remove long-lived CI tokens, seven-day expiry on new granular write tokens, mandatory 2FA by default on packages with write access, and the retirement of classic tokens. These measures reduce token theft, but critics note they do not fully address account takeover or malicious lifecycle scripts – the two techniques behind the year’s biggest incidents.
How is a supply chain attack different from a normal data breach?
A normal breach targets one organization directly. A supply chain attack compromises a shared component – a package, build tool, or update – so that a single intrusion cascades to every organization that consumes it. That force-multiplier is what makes an npm supply chain attack so dangerous: the attacker breaks one account and inherits the trust of thousands of downstream victims at once.
Related Coverage
- ShinyHunters Hit 100+ Orgs via Oracle Zero-Day [2026]
- New CitrixBleed Flaw: NetScaler Hit in 24 Hours [2026]
- FortiBleed Cracks 86,644 Fortinet Firewalls [2026]
- Foxconn Cyberattack: Nitrogen Steals 8TB, 11M Files [2026]
- The Gentlemen Ransomware: 483 Victims, 90% Cut [2026]
- Wazuh Tutorial: Free SIEM in 14 Steps, 40 Min [2026]
- CrowdSec: Block Malicious IPs in 12 Steps, 40 Min [2026]
- More cybersecurity threats coverage →
Reporting compiled from public research by Microsoft Threat Intelligence (via BleepingComputer and SecurityWeek), Palo Alto Networks Unit 42, Sonatype’s 2026 State of the Software Supply Chain report, and official npm documentation. Figures reflect the most conservative published numbers as of July 6, 2026.
