Should you pay ransomware?

Most governments and cybersecurity agencies recommend against paying ransomware. Payment funds further attacks, doesn't guarantee data recovery, and may violate OFAC sanctions if the group is designated. The FBI and CISA both advise reporting to IC3.gov immediately. Any payment decision must involve legal counsel.

What backup strategy prevents ransomware?

The 3-2-1 rule — three copies, two media types, one offsite — remains the foundation, but 2026 best practice adds: immutable/air-gapped offline backups, object lock on cloud storage, and regular tested restores. Untested backups fail at the worst moments. Backups alone don't stop double extortion.

Category: Cybersecurity

Cybersecurity analysis for CISOs and security teams: threat intelligence, zero-trust architecture, AI-powered attacks, compliance frameworks, and enterprise defense strategies.

How to Prevent Ransomware Attacks in 2026: FBI IC3 Guide

How to Prevent Ransomware Attacks in 2026: The Complete IT Manager’s Guide | NeuralWired

Cybersecurity · May 31, 2026

How to Prevent Ransomware Attacks in 2026: The Complete IT Manager’s Guide

NeuralWired Security Desk Published May 31, 2026 · Last reviewed May 31, 2026 · 18 min read

$57B Annual Global Ransomware Damage

44% Of All Breaches Involve Ransomware

51s AI-Shortened Breakout Time

Your security stack was designed for a threat that no longer exists. The ransomware of 2026 doesn’t wait for a phishing click, doesn’t spend weeks inside your network, and doesn’t care that you have antivirus. It exploits an unpatched VPN, moves to your domain controller, and starts encrypting — all before your SOC finishes its morning standup.

The FBI’s IC3 2025 Annual Report, released in April 2026, confirmed what security teams already knew in their gut: ransomware reports hit 3,611 last year, total U.S. cybercrime losses crossed $20.877 billion for the first time, and every single one of the 16 U.S. critical infrastructure sectors reported a ransomware attack. Every one. This isn’t a niche threat hitting careless companies. It’s a $57 billion industry running on subscription models, AI tools, and a workforce that rivals mid-sized tech firms.

This guide covers what actually works to prevent ransomware attacks in 2026 — not the marketing checklist, the real one. It’s written for IT managers and CISOs who are responsible for keeping operations running, not for people who want to feel like they’ve done something.

What Is Ransomware and Why Is 2026 Different?

Ransomware is malicious software that encrypts your files or systems and demands payment — typically in cryptocurrency — to restore access. You already know that. What’s changed is everything else: who’s deploying it, how fast it moves, what they do before they encrypt, and what leverage they hold after.

The Verizon 2025 Data Breach Investigations Report found ransomware present in 44% of all data breaches — a 37% increase from the year prior. For small and midsize businesses, that number climbs to 88% of all breaches. Not “some breaches.” Almost all of them.

The Rise of AI-Powered Ransomware

The existential shift is AI. Not hypothetical AI — deployed, operational AI that ransomware groups are using right now to compress attack timelines that defenders had assumed would stay wide enough to detect and respond.

“By mid-2026, at least one major global enterprise will fall to a breach caused or significantly advanced by a fully autonomous agentic AI system. These systems use reinforcement learning and multi-agent coordination to autonomously plan, adapt, and execute an entire attack lifecycle: from reconnaissance and payload generation to lateral movement and exfiltration. They continuously adjust their approach based on real-time feedback.”
— Michael Freeman, Head of Threat Intelligence, Armis | SecurityWeek, February 2026

The practical consequence: AI has shortened ransomware breakout times to 51 seconds in modeled deployments, while CrowdStrike’s 2025 Global Threat Report found 79% of initial access attacks are now completely malware-free. They’re using stolen credentials and legitimate remote management tools that your security stack was built to trust.

⚠ Critical Shift — Read This First

Attackers are exploiting new vulnerabilities an average of 7 days before a patch is released. The Verizon 2025 DBIR documented that for critical edge device vulnerabilities, the median time between publication and mass exploitation was zero days. Your patch-and-scan cycle cannot protect against threats that arrive before the patch exists.

Ransomware-as-a-Service Has Industrialized

After Operation Cronos took down LockBit’s infrastructure in February 2024 and ALPHV/BlackCat collapsed following the Change Healthcare attack, many observers expected the ransomware ecosystem to shrink. It didn’t. The gang count increased 40% despite sustained law enforcement pressure — because Ransomware-as-a-Service is a business model, not a group. Current top platforms vying for dominance include Qilin, DragonForce, and LockBit 5.0, with 63 new ransomware variants identified in 2025 alone — more than five per month.

Double extortion is now the default, not a premium option. Attackers exfiltrate your data first, then encrypt. Over 7,500 organizations appeared on dark web leak sites in the most recent period analyzed — a 58% jump from 2024. Your backups don’t protect against the public release of stolen data. That’s a separate problem requiring a separate solution.

How Ransomware Attacks Work in 2026 (Step-by-Step)

Understanding the attack chain is prerequisite to building a real prevention strategy. Most defenses fail because they target the wrong stage.

Stage	What Happens	2026 Reality	Your Defense Window
1. Initial Access	Attacker gets into your environment	Usually an unpatched VPN/firewall, not a phishing email	Patch edge devices; phishing-resistant MFA
2. Persistence	Establishes foothold, survives reboots	Uses legitimate tools (PSExec, AnyDesk) — no malware	Behavioral EDR; privileged access management
3. Discovery	Maps your network, finds high-value targets	Automated and AI-assisted; completes in hours	Network segmentation; deception tech
4. Lateral Movement	Pivots to domain controllers, backup servers	Median time to ransomware: 5 days total from entry	Zero Trust; least-privilege access
5. Exfiltration	Steals data before encrypting	Now standard — creates double extortion leverage	DLP monitoring; egress filtering
6. Encryption	Deploys ransomware payload	Targets backup servers first; disables VSS snapshots	Immutable/air-gapped backups; auto-containment EDR

The median dwell time — the gap between initial intrusion and ransomware deployment — has collapsed from 70+ days in 2022 to approximately 5 days now. That’s your detection window. Five days, assuming your monitoring catches the initial compromise. If your security operations are running alert reviews on a weekly cycle, you’ve already lost.

“Phishing is a pervasive initial access mechanism and the reported complaints don’t show how phished credentials and session cookies then fuel account takeover, BEC, session hijacking, and ransomware. The complaint count is only the tip of the spear.”
— Trevor Hilligoss, Chief Intelligence Officer, SpyCloud | SpyCloud FBI IC3 Analysis, April 2026

What this means practically: even if your phishing training is excellent, attackers who bought stolen session cookies from a dark web marketplace bypass your MFA entirely. They’re authenticated before they try anything that would trigger an alert. Identity hygiene — not just endpoint security — is now the primary front.

How to Prevent Ransomware Attacks: 10 Proven Controls

The most effective ransomware prevention in 2026 requires layered controls across identity, network, endpoint, data, and process. No single tool stops modern ransomware. CISA’s #StopRansomware Guide — the joint framework from CISA, NSA, FBI, and MS-ISAC — remains the definitive baseline. What follows maps directly to it, updated for the 2026 threat landscape.

Patch Edge Devices First — VPNs, Firewalls, Gateways

This is the most important shift in ransomware prevention strategy for 2026. Vulnerability exploitation has overtaken phishing as the leading initial access vector, driven almost entirely by internet-exposed edge devices. Your VPN, firewall, and remote gateway are the new front door — and attackers are through it before vendors ship a patch.

Prioritize CVEs affecting edge devices above all other patching. Subscribe to vendor security advisories and emergency patch notifications. If a critical VPN vulnerability drops on a Friday afternoon, your policy needs to authorize emergency patching that night — not the next change window.

Immediate Action

Audit every internet-exposed device right now: VPNs, remote desktop gateways, SSL inspection appliances, load balancers. Run your current firmware versions against the CISA Known Exploited Vulnerabilities catalog. Anything on that list gets patched this week.

Deploy Phishing-Resistant MFA — Not SMS, Not Authenticator Apps

If your organization’s MFA strategy is still SMS one-time passwords or standard authenticator apps, you are operating with a false sense of security. Both are regularly bypassed through real-time phishing proxies, SIM-swapping, and session token theft. The attacker doesn’t need your password or your code — they intercept the authenticated session.

Phishing-resistant MFA means FIDO2/WebAuthn: hardware security keys (YubiKey, Google Titan) or device-bound passkeys. These cannot be intercepted by a phishing proxy because the cryptographic challenge is bound to the specific domain the user is authenticating to. A fake site can’t complete the challenge. Enforce this for all privileged accounts within 30 days. Extend to all users within 90.

Implement Zero Trust Architecture

Zero Trust isn’t a product you buy — it’s an architecture decision that requires organizational commitment. This distinction matters because dozens of vendors are selling “Zero Trust” labels on tools that implement none of it. Purchasing a ZTNA product without implementing the full Zero Trust security model per NIST SP 800-207 is security theater.

Real Zero Trust means: no implicit trust based on network location, least-privilege access enforced for every identity and device, continuous verification rather than one-time login, and micro-segmentation that limits blast radius when — not if — something gets through.

“Your EDR vendor’s ‘AI-powered’ detection is usually just better marketing. What actually works is real-time behavioral baselines combined with ML anomaly detection, dynamic allowlisting tied to asset criticality, and automated containment — stop first, ask questions later.”
— Dr. Erdal Ozkaya, Global CISO | erdalozkaya.com, May 30, 2026

Our read: Ozkaya’s framing is the most practically useful perspective on security tools in circulation right now. The ROI question isn’t “does this tool have AI?” — it’s “does this tool contain threats automatically before a human reviews an alert?”

Maintain Immutable, Air-Gapped Backups

“We have backups” is the most dangerous four-word sentence in ransomware response planning. The relevant questions are: Are they immutable? Are they offline? Have you tested a full restore in the past 90 days? Do they exist on a system that ransomware could reach through your network?

The 2026 ransomware backup strategy requires three layers: the 3-2-1 baseline (three copies, two media types, one offsite), object lock enabled on cloud storage so backups can’t be deleted or encrypted even by a compromised admin account, and air-gapped offline copies that are physically disconnected from your network. Then test the restore. Not annually — quarterly. Untested backups fail at the exact moment you need them.

And remember: backups don’t stop double extortion. If data was exfiltrated before encryption, your backup strategy is irrelevant to the extortion threat. You still need a separate data exfiltration prevention layer.

Use Behavioral EDR — Not Signature-Based Antivirus

Traditional antivirus looks for known malware signatures. Modern ransomware attacks are 79% malware-free — using legitimate tools like PSExec, Cobalt Strike, and AnyDesk that have no malicious signatures. Signature-based detection is not merely insufficient; it’s actively misleading because it creates confidence that isn’t warranted.

Behavioral EDR (Endpoint Detection and Response) watches what processes do, not what they are. It catches an admin tool that starts encrypting hundreds of files per second, a process that modifies the boot sector, or a script that deletes VSS snapshots. Critically: configure auto-containment. A tool that detects and alerts on ransomware but waits for human review before isolating an endpoint has already failed — 51 seconds isn’t enough time for anyone to read an alert and act.

The FBI IC3 identified 63 new ransomware variants in 2025 — more than five per month. Signature tools cannot keep pace. Behavioral tools don’t care about variant names.

Segment Your Network (Micro-Segmentation)

Ransomware’s power comes from lateral movement: a compromised endpoint reaching your domain controller, your backup servers, your OT systems. Micro-segmentation breaks that chain. It limits what each segment of your network can talk to, so a compromised workstation in finance can’t reach manufacturing systems or backup infrastructure.

Priority segmentation targets in 2026: isolate backup infrastructure completely from production networks, segment OT/ICS environments from IT networks, and create a hardened administrative tier that requires jump server access. These three alone contain the blast radius of most ransomware incidents to one segment rather than the entire organization.

Control Third-Party and MSP Access

Why hack one company when you can hack the company that manages a thousand others? MSPs are a strategic priority for ransomware groups in 2026 precisely because of this multiplication effect. The Ingram Micro attack in July 2025 — where the SafePay group disrupted operations for nearly a week and paralyzed supply chains for thousands of VARs and MSPs — confirmed that distributor-tier targeting is now operational, not theoretical.

If your organization uses an MSP, that MSP’s security posture is your security posture. Audit their controls. Require written evidence of their MFA implementation, patch management, and incident response plan. Implement just-in-time access grants rather than persistent remote access credentials. The software supply chain attack vector extends beyond MSPs to any vendor with code or access touching your environment — require Software Bills of Materials (SBOMs) from all critical vendors.

29% of all breaches now involve third-party compromise. That number will rise.

Run Quarterly Ransomware Tabletop Exercises

A tabletop exercise is a structured walkthrough of your ransomware incident response — who does what, who authorizes what, who talks to regulators, who approves a ransom decision. Most organizations run these annually, which means their response plan has been sitting untested for up to 12 months when an incident hits. Quarterly is the 2026 standard.

Include legal counsel, communications, and executive leadership — not just IT. The MGM Resorts attack in September 2023, which caused $100M+ in damages, wasn’t primarily a technical failure; it was a social engineering of the IT help desk that bypassed all technical controls. Your tabletop needs to include scenarios that attack your people and processes, not just your systems.

Develop and Test Your Incident Response Plan

An incident response plan that lives in a SharePoint folder is not an incident response plan. It’s a document. The difference between a plan and a capability is rehearsal. Your IR plan needs to cover: immediate isolation procedures (who has authority to pull systems offline without approval chain delay?), communication templates for regulators, customers, and press, evidence preservation protocols for law enforcement, and ransom decision authorization — written down before the incident, not improvised during it.

Report all ransomware incidents to the FBI at IC3.gov and CISA. Beyond civic obligation, early reporting activates federal resources including threat intelligence sharing that may shorten your recovery.

Monitor for Data Exfiltration — Not Just Encryption

Encryption detection is stage six of a six-stage attack. By the time your EDR is flagging encryption activity, the attacker has already been in your network for days, has already stolen the files that will fund their extortion, and has already targeted your backup systems. Encryption monitoring matters — but it’s the last line, not the primary one.

Add a dedicated exfiltration detection layer: monitor for large, unusual outbound data transfers, use DLP tools that inspect egress traffic for sensitive data patterns, and set anomaly alerts on cloud storage access volumes. The Canvas LMS breach in May 2026, where ShinyHunters exfiltrated 275 million student records, illustrates the scale of damage that becomes irreversible once exfiltration completes — regardless of what your backup strategy looks like.

What Industries Are Most at Risk from Ransomware in 2026?

Every sector faces ransomware. That’s not hyperbole — the FBI IC3 2025 Annual Report confirmed ransomware incidents across all 16 U.S. critical infrastructure sectors last year. But targeting is not random. Ransomware groups optimize for maximum leverage, which means sectors where downtime creates existential pressure to pay.

Sector	Why They’re Targeted	Key Risk Factor
Healthcare	Patient safety creates payment urgency; high-value PHI	Legacy OT systems; life-critical uptime requirements
Manufacturing	OT/ICS downtime costs $100K+/hour in many facilities	IT/OT convergence creates new attack surface
Financial Services	Regulatory pressure to restore quickly; high-value data	Complex third-party ecosystems; supply chain exposure
Government	Political pressure; citizen data; often under-resourced	Budget constraints; legacy infrastructure
IT / MSPs	One-to-many: compromise MSP, hit all their clients	Privileged access to client environments
SMBs (All Sectors)	88% of SMB breaches involve ransomware; fewer defenses	Limited security staffing; MFA gaps; unmanaged endpoints

The Change Healthcare attack in February 2024 remains the definitive case study in healthcare ransomware impact: ALPHV/BlackCat disrupted U.S. healthcare billing for weeks across thousands of providers, with UnitedHealth reporting ~$872 million in remediation costs. A single enterprise compromise cascaded through an entire supply chain. If you’re in any of these sectors and your ransomware prevention checklist is still anchored to phishing training and endpoint antivirus, you’re operating with the wrong threat model.

Should You Pay the Ransom?

The official position of the FBI and CISA is clear: don’t pay. The practical reality is more complicated, which is why the answer is never the CISO’s alone to make.

The arguments against paying are well-established: payment funds further attacks, doesn’t guarantee data recovery or deletion (ransomware groups routinely lie about destroying exfiltrated data), and may violate OFAC sanctions if the group is on the U.S. Treasury’s designated entities list. Paying a sanctioned group — even unknowingly — creates legal exposure for the organization and executives involved.

The argument for considering payment is equally real: some organizations facing existential operational collapse, particularly in healthcare, have no viable alternative when recovery from backups would take months. Jason Baker, Managing Security Consultant at GuidePoint Security, notes ransomware may be becoming less successful due to increased pressure against payments and improved defenses — but that this trend requires sustained commitment to prevention investment to hold.

If You’re Facing a Ransomware Demand Right Now

Step 1: Engage legal counsel immediately — before any payment decision or communication with attackers.

Step 2: Report to FBI IC3 at ic3.gov and CISA. This is not optional — it activates federal support.

Step 3: Check whether the ransomware group appears on OFAC sanctions lists before any payment consideration.

Step 4: Engage a ransomware negotiation firm — do not communicate directly with attackers without expertise.

What we won’t tell you is that paying is always wrong or always necessary. What we will tell you is that the decision made under pressure, without preparation, without legal counsel, and without having checked OFAC compliance is the one most likely to make your situation worse. The time to think through the ransom decision framework is now, not when you’re six hours into an incident with systems down.

What to Do After a Ransomware Attack

Speed and sequencing matter. The first 24 hours after ransomware detection determine whether your recovery takes days or months.

Isolate immediately. Pull affected systems from the network. Disable VPN access. Don’t shut down systems — preserve volatile memory (RAM) for forensic analysis. Killing power destroys evidence.
Activate your IR plan. Notify your incident response team, legal counsel, and executive leadership in that order. Every organization should have this call chain documented and rehearsed before an incident.
Report to authorities. File with FBI IC3 at ic3.gov and notify CISA. If you’re in a regulated industry, check your sector-specific reporting obligations — HIPAA requires breach notification within 60 days; SEC rules may require faster disclosure for public companies.
Preserve evidence. Do not wipe and reinstall before forensic imaging. Law enforcement and your cyber insurance carrier will both need evidence. Early destruction of logs or system images can compromise both investigations.
Identify the scope. What systems are encrypted? What data was exfiltrated? When did initial access occur? (Remember: the encryption event is not when the attack started — it’s when it ended.)
Begin recovery from clean backups. Restore from backups that predate the initial compromise, not just the encryption event. If attackers had been in your network for 5 days, a backup from day 3 may be compromised.
Don’t pay without legal and OFAC review. If payment is under consideration, run sanctions screening first. Always.

Mean recovery cost per ransomware incident in 2025: $1.53 million according to Sophos research. That number does not include ransom payments — it’s the operational, forensic, legal, and remediation cost of getting back to normal. Organizations with tested incident response plans and clean offline backups recover in days. Those without face months of downtime and costs that exceed that figure significantly.

Ransomware Prevention Checklist — Print and Post This

Save this. Run through it with your team this quarter. If any item is unchecked, prioritize it before the next change window.

Identity and Access

Phishing-resistant MFA (FIDO2/passkeys) enforced on all privileged accounts
MFA enforced on all remote access points (VPN, RDP, cloud consoles)
Privileged Access Management (PAM) solution in place; admin accounts not used for daily work
Session token and credential theft monitoring active
Third-party and MSP access reviewed; just-in-time access enforced

Network and Perimeter

All internet-exposed edge devices (VPN, firewall, gateway) audited against CISA KEV catalog
Emergency patching policy in place — edge device critical CVEs patched within 24 hours
Network segmentation implemented; backup infrastructure isolated from production
OT/ICS networks segmented from IT networks
Egress filtering and anomaly detection on outbound data volumes

Endpoint and Detection

Behavioral EDR deployed across all endpoints — auto-containment configured
Signature-based antivirus replaced or augmented with behavioral detection
Remote monitoring and management tool inventory audited; unauthorized RMM tools removed
PowerShell execution policy restricted; script block logging enabled

Data and Backup

Immutable, air-gapped offline backups implemented (3-2-1 minimum)
Cloud backup storage has object lock enabled
Full restore test completed in the past 90 days
DLP monitoring in place for sensitive data exfiltration
VSS shadow copies protected; ransomware groups target these first

Process and Readiness

Incident Response plan documented; tested in the past 90 days via tabletop
OFAC sanctions list screening process established for potential ransom scenarios
Legal counsel identified and briefed on ransomware response protocols
FBI IC3 and CISA reporting procedures documented and known to IR team
Cyber insurance policy reviewed; coverage terms and exclusions understood
Supply chain/vendor security questionnaire updated; SBOMs requested from critical vendors

Frequently Asked Questions About Ransomware Prevention

What is the most effective way to prevent ransomware?

The most effective ransomware prevention combines immutable offline backups, phishing-resistant MFA (FIDO2 hardware keys or passkeys), Zero Trust architecture with least-privilege access, patched edge devices (VPNs and firewalls), and behavioral EDR with auto-containment. No single control is sufficient — CISA’s #StopRansomware Guide recommends all five as a baseline, and each addresses a different attack stage.

Can ransomware be stopped once it starts encrypting?

Once ransomware begins encrypting files, stopping it requires immediate network isolation of affected systems. Behavioral EDR tools configured for auto-containment can interrupt encryption within seconds of detection. However, if data exfiltration already occurred — now standard in double extortion attacks — containment stops encryption but doesn’t undo the theft. The extortion threat remains even with perfect backups.

What are the three main entry points for ransomware in 2026?

In 2026, the three primary ransomware entry points are: (1) unpatched edge device vulnerabilities — VPNs, firewalls, and remote gateways now surpass phishing as the leading initial access vector; (2) stolen or phished credentials used against systems without phishing-resistant MFA; and (3) supply chain and third-party access compromise, now responsible for 29% of all breaches. Sources: Verizon DBIR 2025; CrowdStrike 2025 Global Threat Report.

Should you pay the ransom?

The FBI and CISA both recommend against paying ransomware. Payment funds further attacks, doesn’t guarantee data recovery or deletion, and may violate OFAC sanctions if the group is designated. Any payment decision must involve legal counsel and a sanctions screening check before any funds move. Report every ransomware incident to ic3.gov immediately — this activates federal support regardless of payment decision.

Does MFA prevent ransomware attacks?

MFA significantly reduces risk but doesn’t eliminate it. Standard SMS-based OTP and authenticator apps are increasingly bypassed through real-time phishing proxies, session hijacking, and SIM-swapping. Phishing-resistant MFA — FIDO2 hardware security keys or passkeys — is the 2026 recommended standard. These are cryptographically bound to the authentic domain and cannot be intercepted by a phishing proxy. Enforce this for all privileged accounts immediately.

What backup strategy best prevents ransomware?

The 3-2-1 backup rule — three copies, two media types, one offsite — is the foundation, but 2026 best practice adds: immutable air-gapped offline backups that ransomware cannot reach, object lock enabled on cloud storage, and tested restores conducted quarterly. Untested backups consistently fail under incident pressure. Note: backups don’t prevent double extortion — data already exfiltrated remains a leverage point regardless of your backup posture.

How long does recovery from a ransomware attack take?

Recovery time varies dramatically based on preparation. Organizations with tested, offline backups and a rehearsed incident response plan typically restore within days to weeks. Those without can face months of downtime. Sophos 2025 research puts mean recovery cost at $1.53 million — separate from any ransom payment. The median ransom demand alone is $1.32 million. The ROI on prevention investment is unambiguous.

What industries are most targeted by ransomware in 2026?

The most targeted sectors in 2025–2026 are healthcare, manufacturing, financial services, government, and IT/technology — including MSPs. All 16 U.S. critical infrastructure sectors reported ransomware incidents in 2025, per the FBI IC3 2025 Annual Report. Healthcare and manufacturing face the highest operational impact due to life-critical or production-critical uptime requirements, which maximize attacker leverage.

What You Now Know

Ransomware prevention in 2026 is not an endpoint security problem. It’s an identity problem, a network architecture problem, a third-party risk problem, and increasingly an AI problem that moves faster than human response cycles allow. The threat landscape that shaped your current security stack — phishing as the primary vector, weeks of dwell time for detection, malware as the payload — has been replaced by something structurally different.

In the next 6–18 months, watch for three developments that will reshape the prevention calculus: autonomous AI attack agents moving from modeled capability to confirmed operational deployment; regulators tightening mandatory ransomware disclosure windows (the SEC’s current rules are a floor, not a ceiling); and ransomware groups increasing pressure on the insurance ecosystem, making policies harder to claim and forcing security requirements upward.

Three things to act on this week: audit your internet-exposed edge devices against the CISA Known Exploited Vulnerabilities catalog, schedule a ransomware tabletop exercise for this quarter, and check whether your backup restore procedure has been tested in the past 90 days. If any of those three are outstanding, they represent more risk than anything else on your to-do list.

May 30, 2026

What Is Zero Trust Security? The NIST Guide (2026)

Zero Trust Security: Why “Never Trust, Always Verify” Is Winning the Cybersecurity War

Cybersecurity

Zero Trust Security: Why “Never Trust, Always Verify” Is Winning the Cybersecurity War

NeuralWired Staff · May 24, 2026 · 12 min read

$40B+ Global ZT market size in 2025

30% Organizations that have actually implemented ZT

$1.76M Average breach cost saved with mature ZT (IBM 2024)

In 2020, hackers slipped into SolarWinds’ build pipeline and pushed poisoned software updates to 18,000 organizations, including the U.S. Treasury, Homeland Security, and the Pentagon. They moved through networks undetected for months. The perimeter had held. The castle walls were intact. The attackers were already inside, trusted by every system they touched.

That’s the problem zero trust security was designed to solve. And after two decades of being dismissed as too complex, too expensive, or too theoretical, it has become the dominant cybersecurity framework for enterprises, governments, and anyone who can’t afford to assume the person inside the network is actually who they say they are.

The zero trust security market hit $40.01 billion in 2025. It’s projected to reach $182.59 billion by 2035. Every major federal agency in the United States is under a legal mandate to adopt it. Yet only 30% of organizations have actually done it. That gap, between the promise and the practice, is the real story.

What Zero Trust Security Actually Means

Zero trust is not a product. It’s not software you buy. It’s a philosophy, and that distinction matters enormously, because hundreds of vendors are selling “zero trust solutions” while the framework’s own creator is calling them out on it.

“Zero Trust is first and foremost a strategy. It’s something that you do, not something you buy.” — John Kindervag, Chief Evangelist, Illumio; Creator of the Zero Trust model; speaking at RSAC 2025. Source

Kindervag created zero trust around 2009–2010 while a VP and Principal Analyst at Forrester Research. His foundational paper proposed a framework in which companies abandon the assumption that any device or user, inside or outside the corporate network, can be trusted by default. The phrase he coined: never trust, always verify.

The authoritative technical definition comes from NIST (Special Publication 800-207, published August 2020): zero trust “provides a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised.”

In plain English: assume the network is already breached. Verify every user, every device, every access request, every time. Grant only the minimum access required for that specific task. And continuously monitor, because a device that was clean at 9 a.m. might be compromised by 11 a.m.

The Core Shift

Traditional security asks: Are you inside the network? If yes, you’re trusted. Zero trust asks: Who are you, what device are you on, what do you need, and does this request make sense right now?, every single time.

How It Works: The Five Pillars

CISA’s Zero Trust Maturity Model organizes the architecture across five pillars. If you’re building or assessing a zero trust program, this is your map.

Pillar	What It Covers	Why It Matters
Identity	Multi-factor authentication, privileged access, identity governance	The highest-ROI starting point. Most breaches begin with compromised credentials.
Devices	Endpoint detection, device health validation, mobile device management	A user with valid credentials on a compromised device is still a threat.
Networks	Micro-segmentation, encrypted traffic inspection, DNS security	Limits lateral movement — what attackers do after they’re in.
Applications & Workloads	App-layer access control, secure APIs, cloud workload protection	The average enterprise uses 130 SaaS apps. Each is a potential attack vector.
Data	Data classification, DLP, encryption at rest and in transit	Ultimately, data is what attackers want. This pillar protects the final target.

Each pillar progresses through maturity stages, Traditional, Initial, Advanced, and Optimal. Cross-cutting capabilities including visibility, analytics, automation, and orchestration apply across all five. The point isn’t to buy a tool for each pillar. It’s to map your existing security investments to this framework and identify what’s genuinely missing.

The VPN vs. ZTNA Distinction

The most misunderstood comparison in enterprise security: a VPN and Zero Trust Network Access (ZTNA) are not the same thing. A VPN grants broad network access once a user authenticates, you’re in, and you can reach most of what’s on the network. ZTNA grants access only to specific resources, verified continuously for every session. It’s the difference between handing someone a master key and escorting them directly to the one room they need. Gartner predicted that by 2025, 60% of companies would replace VPNs with ZTNA solutions, and that transition is still very much underway.

Why Zero Trust Is Winning Now

Three forces converged to make zero trust urgent rather than optional.

The Perimeter Collapsed

The traditional “castle and moat” security model assumed that everything inside the corporate network could be trusted. That assumption died slowly, then all at once. SolarWinds (2020), Colonial Pipeline (2021), and the MOVEit breach (2023) each involved extensive lateral movement that perimeter defenses couldn’t detect. The attackers weren’t breaking through the walls, they were walking through the gate with stolen credentials.

Remote Work Killed the Network Edge

When 2020 sent millions of employees home overnight, it didn’t just complicate security, it obliterated the physical boundary the perimeter model depended on. Workers logging in from home networks, personal devices, coffee shops, and foreign countries made the “inside vs. outside” distinction meaningless. Zero trust, which had been growing steadily, became unavoidable.

The U.S. Government Made It Mandatory

In May 2021, President Biden’s Executive Order 14028 formally required federal civilian agencies to develop plans for Zero Trust Architecture. The OMB memorandum M-22-09 (January 2022) went further, requiring all federal agencies to meet specific ZT objectives by the end of FY 2024. When the U.S. government mandates a cybersecurity framework across every civilian agency, the private sector follows, not because it has to, but because the vendor ecosystem, talent pool, and enterprise procurement processes all orient toward it.

A CISA progress report published January 2025 assessed federal agency implementation through FY 2024. It was candid about failures and outlined next steps, which is itself a signal that the mandate has teeth, even if delivery is uneven.

The Implementation Gap: 72% Planning, 30% Doing

Here’s the single most important number in zero trust right now: according to Forrester, 72% of security decision-makers at large organizations plan to pursue zero trust or are already doing so. According to CyberRisk Alliance’s 2024 survey, only 30% of organizations have actually implemented zero trust practices.

That’s a 42-point execution gap. And it has a name: the implementation problem.

“Anything that helps me get visibility and reduces risk is a win, but Zero Trust has to start with a mindset and a strategy aligned to business outcomes.” — Jared Nussbaum, CISO, Ares Management; speaking at RSAC 2025. Source

What’s stopping organizations? The data from a StrongDM survey of 600 U.S.-based cybersecurity workers is blunt: 48% cite cost and resource constraints as their primary barrier. Another 22% report internal resistance. The obstacles aren’t technical, they’re organizational and financial.

Gartner’s estimate cuts even deeper: by the end of 2026, only 10% of large enterprises will have a mature and measurable zero trust program, up from less than 1% in 2023. Even among organizations that have started, most are mid-journey. Approximately 52% of organizations have completed full ZTNA deployment; 38% remain in partial implementation phases.

The ROI Case CISOs Should Be Making to Their Boards

The IBM Cost of a Data Breach Report 2024 found that the average breach costs $4.88 million, a record high, up 10% from 2023. Organizations with mature zero trust deployments save an average of $1.76 million per breach compared to those without. A mid-market zero trust program can pay for itself from a single avoided breach.

For CISOs navigating this, the practical guidance is consistent: don’t buy new platforms before mapping existing investments. If you have MFA, EDR, and IAM tools already deployed, map them to the five pillars first. Identity is almost always where the highest-ROI work begins, because it’s where most breaches start.

The Hard Truth: What Zero Trust Can’t Do

No serious coverage of zero trust is complete without this part. Three categories of criticism deserve attention from anyone making real decisions about it.

The Vendor Exploitation Problem

The 2023 Okta breach is the cautionary tale. A threat actor accessed a stolen credential from the identity and access management firm, a company whose entire value proposition is verifying identity, and used it to access customer systems across Okta’s client base. As Jason Steer, CISO of Recorded Future, noted in the aftermath:

“A lot of organizations are now all in on companies like Okta, who offer zero trust, and that means threat actors understand that as well.” — Jason Steer, CISO, Recorded Future. Infosecurity Magazine, March 2026

Steer’s point is precise: zero trust can consolidate organizational risk into single-vendor dependencies. The identity pillar, when it relies on one provider, becomes a single point of failure with a much larger blast radius than the perimeter it replaced.

Kindervag himself has addressed the product misconception directly: “Any business or vendor that claims to have a zero trust product is either lying or doesn’t understand the concept at all.”

MFA Is Not Impenetrable

Identity is zero trust’s highest-ROI pillar and its most exploited weakness simultaneously. Attackers have developed reliable techniques to circumvent MFA: man-in-the-middle attacks that intercept one-time codes, SIM swapping to take over a user’s phone number, and push notification fatigue attacks that bombard users with authentication requests until they approve one out of frustration. Zero trust doesn’t prevent these. It raises the cost of exploitation, it doesn’t eliminate it.

The Academic Challenge: Is True Zero Trust Even Achievable?

This one is uncomfortable, and it mostly hasn’t penetrated vendor marketing materials or government mandates. Professor Virgil D. Gligor of Carnegie Mellon University, a 2019 inductee into the National Cyber Security Hall of Fame and recipient of NIST’s National Information Systems Security Award, published a formal technical challenge to zero trust’s theoretical foundations.

His argument: enterprise networks rely on “black box” devices whose security properties cannot be proven unconditionally. Because of this, the name “zero trust” is technically incoherent. What practitioners are building is trust minimization, which is valuable, but different. As Gligor concluded in his CMU CyLab Technical Report (22-002): “Zero trust is impossible in any enterprise network and has meaning only as an unreachable limit of trust establishment.”

What This Means Practically

Gligor’s argument isn’t that zero trust programs are worthless, it’s that teams which believe they have achieved complete trust elimination may operate with false confidence that itself becomes a vulnerability. The goal should be trust minimization, not trust elimination. If your security culture assumes zero trust means zero risk, that’s the threat.

The Friction-Shadow IT Paradox

Ironically, aggressive zero trust implementation can recreate the exact vulnerabilities it’s designed to prevent. When continuous verification creates too much friction, too many authentication prompts, too many blocked workflows, users find workarounds. Shadow IT proliferates. Unmonitored channels open. Organizations attempting comprehensive overnight transitions typically face implementation failures and user resistance that undermine the program entirely. Incremental deployment by pillar, starting with identity, consistently outperforms big-bang rollouts.

What’s Changing in 2025–2026

Two developments define the frontier of zero trust right now.

AI Integration

The integration of AI and machine learning within zero trust architectures is producing real capability improvements, particularly in behavioral analytics and anomaly detection. The canonical early example: in August 2025, Cloudflare launched new capabilities within its Cloudflare One platform designed to help organizations monitor AI usage and protect against Shadow AI, which it describes as the unsanctioned use of generative AI tools that bypass corporate security controls. Our read: this signals that zero trust is evolving to treat AI models themselves as entities that require access verification, not just the humans using them.

Post-Quantum Cryptography

In March 2025, Cloudflare announced end-to-end support for post-quantum cryptography within its ZTNA solution, enabling quantum-safe connectivity from web browsers to corporate applications without requiring organizations to individually upgrade each system. This matters because the encryption underpinning zero trust’s secure communications, the channel through which continuous verification happens, needs to be quantum-resistant before quantum computing makes current encryption breakable. The organizations that don’t start this transition now will face a retroactive security crisis when the threat matures.

NIST released the final version of SP 1800-35 (Implementing a Zero Trust Architecture) in June 2025, documenting end-to-end implementations built with 24 commercial vendors in a government lab environment. It’s the most comprehensive practical build guide available for organizations starting from scratch.

Frequently Asked Questions

What is zero trust security in simple terms?

Zero trust security is a cybersecurity approach that eliminates automatic trust for any user, device, or network connection, including those already inside a corporate network. Instead of trusting based on location, every access request is verified continuously. The core principle: “never trust, always verify.” NIST defined the framework in SP 800-207 in 2020.

What are the five pillars of zero trust?

The CISA Zero Trust Maturity Model defines five pillars: Identity, Devices, Networks, Applications & Workloads, and Data. Each pillar progresses through maturity stages, Traditional, Initial, Advanced, and Optimal. Cross-cutting capabilities including visibility, analytics, automation, and orchestration apply across all five pillars.

Is zero trust the same as a VPN?

No. A VPN grants broad network access once a user authenticates. ZTNA (Zero Trust Network Access) grants access only to specific resources, verified continuously for every session. It’s the direct VPN replacement technology. Gartner predicted that by 2025, 60% of companies would replace VPNs with ZTNA solutions, a transition still underway for most organizations.

Who created zero trust security?

Zero trust was created by John Kindervag while a VP and Principal Analyst at Forrester Research around 2009–2010. He published the foundational paper introducing the model and the phrase “never trust, always verify.” Kindervag is now Chief Evangelist at cybersecurity company Illumio and served as a primary author of the NSTAC report to the President on zero trust.

Does zero trust prevent ransomware?

Zero trust significantly reduces ransomware risk by limiting lateral movement, the ability of attackers to spread through a network after initial compromise. Micro-segmentation, a core zero trust control, contains breaches to smaller network zones. However, zero trust doesn’t prevent the initial point of entry, and identity controls remain vulnerable to MFA bypass techniques.

How much does it cost to implement zero trust?

Costs vary widely by organization size, existing infrastructure, and vendor choices. The financial case rests on IBM’s 2024 data: the average breach costs $4.88 million, while organizations with mature zero trust programs save an average of $1.76 million per breach. Most practitioners recommend starting with existing MFA and IAM tools mapped to the five pillars before purchasing new platforms.

What You Now Know That Most Organizations Don’t Act On

Zero trust security isn’t a product, a perimeter replacement, or a checkbox. It’s a strategic reorientation, from “trust by location” to “verify always, grant least privilege, monitor continuously.” The concept is 15 years old. The mandate, the market, and the threat landscape have finally caught up.

The implementation gap, 72% intent, 30% execution, is the central story of cybersecurity in 2025. The organizations closing that gap are not the ones that bought a “zero trust platform.” They’re the ones that mapped identity as pillar one, built maturity incrementally, and didn’t mistake a vendor’s marketing claim for a security guarantee.

Watch three things over the next 12–18 months:

AI as a zero trust entity: As enterprises adopt generative AI tools, the frameworks for verifying AI model access, not just human access, will become a new frontier of zero trust architecture.
Post-quantum cryptography adoption: Organizations that don’t begin transitioning the cryptographic layer of their zero trust implementations will face a retroactive security crisis when quantum computing matures.
Regulatory enforcement sharpens: GDPR, NIS2, and U.S. federal compliance requirements are tightening. A breach without a documented zero trust program is increasingly being treated as negligence by regulators and cyber liability insurers alike.

If you’re building this, start with identity. Resist the “zero trust in a box” pitch. And read Gligor’s paper, not because he’s right that zero trust is theoretically impossible, but because the organizations that understand its limits are the ones that won’t be surprised when it doesn’t live up to its name.

May 24, 2026

Canvas LMS Breach: ShinyHunters Steals 275M Student Recordsi

ShinyHunters Breaches Canvas: 275M Student Records Stolen | NeuralWired

Cybersecurity May 7, 2026 · 9 min read

ShinyHunters Breaches Instructure’s Canvas: 275 Million Student Records Stolen in Education’s Worst Data Catastrophe

Instructure confirmed a criminal cyberattack on Canvas LMS after ShinyHunters claimed responsibility for exfiltrating 3.65 TB of data from nearly 9,000 schools worldwide. The breach exposed names, email addresses, student IDs, and billions of private messages, triggering urgent questions about how a single SaaS platform can become the master key to the personal data of an entire generation of learners.

On April 30, 2026, engineers at Instructure, the company behind the Canvas learning management system, noticed something wrong with their API keys. What followed over the next week was a slow-motion confirmation of a catastrophe: a criminal threat actor had breached the platform used by more than 7,000 universities, K-12 districts, and education ministries across the globe. ShinyHunters, the extortion group behind high-profile hits on Ticketmaster and Snowflake customers, took credit. The alleged haul of 275 million records makes this one of the single largest education-sector data thefts ever recorded.

Instructure’s Canvas holds roughly 41% of the North American higher-education market. That concentration is exactly what makes it so attractive to attackers, and so dangerous when it fails. One breach, one exfiltration window, one unplugged credential, and the academic records, private messages, and institutional identities of an entire generation of students can land on a criminal leak site.

What Happened: A Supply-Chain Attack on Global Education

Canvas is not a single school’s system. It’s a multi-tenant cloud platform hosted on AWS that aggregates data across thousands of individually isolated institutional accounts, centralizing them for analytics, integrations, and API-driven services. That architecture is its commercial strength. It’s also its security liability.

Instructure detected the first signs of unauthorized access on April 30, escalating through a formal incident declaration by May 2. By May 3, ShinyHunters had posted claims on monitored leak sites, alleging exfiltration of 3.65 terabytes spanning approximately 275 million user records across close to 9,000 institutions. The data allegedly includes names, institutional email addresses, student ID numbers, and messages exchanged between users over the platform. No passwords, dates of birth, government identifiers, or financial information appear to have been involved, according to Instructure’s own investigation at the time of publication.

Context: ShinyHunters previously targeted Instructure in a separate breach in September 2025, reportedly via a third-party Salesforce integration. Two confirmed attacks in eight months. The May 2026 incident is the larger of the two by any available measure.

The scale is difficult to contextualize. At 275 million records, the alleged dataset is larger than the entire population of Brazil. The 3.65 terabytes of raw data represents not just identifying fields but conversation logs, the actual content of messages between students and instructors, which adds a dimension of personal exposure that no simple identity-fraud warning can address.

Instructure’s Incident Timeline

April 30, 2026 — 17:06 MDT

Instructure engineers detect anomalous API key activity. Internal investigation begins immediately.

May 2, 2026 — 12:46 MDT

Instructure formally declares a confirmed “cybersecurity incident perpetrated by a criminal threat actor.” Credentials revoked, keys rotated, vulnerabilities patched.

May 3, 2026

ShinyHunters claims responsibility on monitored leak sites, alleging 275 million records and 3.65 TB of stolen data across approximately 9,000 schools globally.

May 6, 2026 — 15:13 MDT

Instructure CISO Steve Proud issues formal public statement. Incident declared resolved with no ongoing malicious activity confirmed.

The containment window from detection to resolution spanned roughly six days. Whether the threat actor had access for days or weeks before the April 30 detection remains an open forensic question Instructure has not yet answered publicly.

Who Are ShinyHunters, and Why Does It Matter?

ShinyHunters has operated since 2019, building a reputation as one of the most prolific data-theft and extortion groups active today. Their model is straightforward: breach a high-value target, exfiltrate as much data as possible, then demand payment under threat of public release. Past victims include Ticketmaster, AT&T, and numerous Snowflake enterprise customers. In 2025, the group was reported to have merged operations with elements of Lapsus$, expanding its technical reach considerably.

“ShinyHunters… Threat Classification: Data Theft, Extortion, Database Monetization… Amount of Available Information: High.”
Jon DiMaggio, Threat Actor Analyst, Analyst1 — Analyst1 Threat Actor Profile, February 2026

The education sector is a particularly appealing target. Schools hold rich personal data on minors and young adults, including contact information, internal communications, and institutional identifiers that don’t change the way passwords do. Phishing campaigns built on this kind of dataset can be devastatingly precise: a message appearing to come from a student’s actual professor, referencing a real assignment, is far more convincing than a generic credential-harvesting attempt.

The group operates on a “pay or leak” extortion model, but Instructure’s public statements made no reference to any ransom demand or payment deadline. As of publication, no deadline confirmation from primary sources has been independently verified.

Why Canvas Is Such a High-Value Target: The Multi-Tenancy Problem

Canvas’s architecture concentrates risk in ways that a federated, institution-by-institution deployment model would not. The platform runs as a SaaS product on AWS multi-region infrastructure, including regions such as us-east-1 and eu-west-1, using API keys, OAuth, and SSO for integrations. Each institution’s data is logically isolated in separate tenant partitions, but the administrative and analytics layers, including products like Canvas Data 2, aggregate across tenants for reporting and integration purposes. That aggregation layer is where the exposure multiplies enormously.

Instructure’s response involved revoking credentials, rotating API keys, and patching unspecified vulnerabilities. The company did not publicly name the precise attack vector, so whether the breach entered through credential compromise, API misconfiguration, or a third-party integration remains officially unconfirmed. What is clear is that the platform’s privileged access layer, once breached, could reach data across thousands of institutions in a single exfiltration operation.

Technical note: Canvas stores user messages without end-to-end encryption in order to support search and moderation functionality. Any actor with sufficient API privileges can read message content in plain text, not just metadata. That’s a deliberate architectural trade-off, and one that massively amplifies the harm when access is compromised.

Security researchers have noted for years that edtech platforms lag behind enterprise software in zero-trust adoption. API keys are often long-lived, minimally scoped, and infrequently audited. In a world where multi-tenant SaaS platforms handle hundreds of millions of records, those gaps compound quickly into catastrophic exposure windows.

How the Instructure Breach Compares to Other Major Incidents

Incident	Date	Records Affected	Data Type	Sector	Group Responsible
Instructure Canvas (May 2026)	Apr–May 2026	~275 million	Names, emails, IDs, messages	Education	ShinyHunters
National Public Data	Aug 2024	~2.9 billion	SSNs, addresses, names	Data broker	USDoD
Ticketmaster / Live Nation	May 2024	~560 million	Payment, contact, ticket info	Entertainment	ShinyHunters
Instructure Canvas (Sep 2025)	Sep 2025	Undisclosed	Undisclosed (Salesforce integration)	Education	ShinyHunters (reported)
PowerSchool	Dec 2024	~60 million	Student and teacher records	Education (K-12)	Unknown

The Canvas breach lands as the largest confirmed education-sector data exposure on record by volume of affected individuals. Its significance lies not just in scale but in the content dimension: unlike records-only breaches, the inclusion of private messages creates social-engineering ammunition that is qualitatively more dangerous than a name-and-email dataset alone.

Instructure’s Response: What CISO Steve Proud Said

Instructure’s formal public statement on May 6 came from CISO Steve Proud via the company’s incident status page. The statement was measured and carefully scoped, confirming the incident while stopping short of independently verifying ShinyHunters’ stated data volumes.

“While we continue actively investigating, thus far, indications are that the information involved consists of certain identifying information of users at affected institutions, such as names, email addresses, and student ID numbers, as well as messages among users. At this time, we have found no evidence that passwords, dates of birth, government identifiers, or financial information were involved.”
Steve Proud, Chief Information Security Officer, Instructure — Instructure Status Page, May 6, 2026

The statement notably avoids confirming the number of affected institutions or individuals, describing the exposed data as “certain identifying information” rather than quantifying scope. Instructure also did not publicly confirm or deny the 9,000-institution figure ShinyHunters cited. The gap between the vendor’s scoped language and the attacker’s sweeping claims is itself a forensic question worth watching as the investigation develops.

Affected institutions are legally responsible for notifying impacted students and staff under frameworks like FERPA in the United States and GDPR in Europe. The burden of individual notification and regulatory compliance falls on the schools, not on Instructure directly, a structural asymmetry that critics argue under-incentivizes platform vendors to invest aggressively in breach prevention.

What Students, Teachers, and IT Teams Should Do Right Now

🔑

Rotate credentials

Change passwords for any account sharing credentials with your Canvas login. Enable multi-factor authentication on every account you can access.

📧

Watch for phishing

Expect highly targeted emails appearing to come from real professors or classmates. Verify any unusual request via phone or in-person before acting on it.

🔍

Monitor Have I Been Pwned

Check haveibeenpwned.com for your institutional email. The dataset is not yet listed as of publication, but listings can appear weeks after a breach.

🛡

IT: Audit all API keys

Revoke all long-lived Canvas API tokens. Re-issue with minimum required scopes. Audit every third-party integration connected to your institution’s Canvas instance.

Universities operating under FERPA have independent notification obligations once they become aware of a breach affecting student educational records. Institutions should not wait for Instructure’s official notification before beginning their own incident response. Legal counsel familiar with FERPA breach obligations should be involved from day one.

Instructure Has a Posture Problem, Not a Luck Problem

Two ShinyHunters attacks in eight months is not a coincidence. The first breach, in September 2025, reportedly entered through a Salesforce integration, a third-party surface. The second, in April 2026, used API keys as the initial detection signal. Different vectors, same outcome. That pattern points not to an unlucky run of sophisticated attacks but to systemic gaps in how Instructure manages its external attack surface over time.

One anonymous security analyst writing for GBlock put it plainly: two breaches in eight months “is not a streak of bad luck. It is a posture problem.” That’s a harder verdict than Instructure’s measured containment language suggests, and it’s the kind of institutional accountability question that procurement officers at universities will be asking directly in the months ahead.

The repeat-target dynamic also raises questions about the security diligence frameworks universities apply when selecting and renewing LMS contracts. Canvas dominates with roughly 41% of the North American higher-ed market. When a platform is that entrenched, switching costs are enormous and competitive pressure to improve security posture weakens. That structural dynamic is as much a systemic risk as any individual vulnerability.

What the industry needs, and what this incident may accelerate, is a shift toward zero-trust architecture in edtech procurement standards: short-lived tokens, minimal API scopes, mandatory MFA at the integration layer, and third-party audits with real teeth. Whether Instructure’s customer base has the leverage to demand those changes is the real question this breach puts on the table.

What to Watch

01 Instructure’s full disclosure. Will the company confirm or refute ShinyHunters’ 275 million figure? The gap between “certain identifying information” and 275 million records needs closing publicly.

02 FERPA enforcement action. The U.S. Department of Education has jurisdiction here. Whether regulators treat this as a systemic vendor failure, rather than individual school failures, sets an important precedent.

03 Phishing campaigns. Message data in attacker hands means tailored social-engineering campaigns targeting students and faculty are likely in the weeks ahead. Watch for credential harvesting at institutional scale.

04 Instructure contract renewals. Several major university systems will be up for LMS contract reviews in 2026-2027. This breach enters those conversations directly.

Cross-Chain Bridge Security: The $292M DVN Flaw

DeFi’s $292M Bridge Crisis: Why Cross-Chain Security Keeps Failing | NeuralWired

DeFi Security May 3, 2026 · 11 min read

DeFi’s $292M Bridge Crisis: How One Validator Flaw Drained a Protocol in 46 Minutes

The Kelp DAO exploit wasn’t a smart contract bug. It was an attack on the invisible plumbing beneath DeFi, and the fix requires the industry to rethink bridge security from the ground up.

At 17:35 UTC on April 18, 2026, 116,500 rsETH tokens left Kelp DAO’s bridge contract on Ethereum and landed in an attacker’s wallet. That transfer, worth roughly $292 million at the time, represented about 18 percent of rsETH’s entire circulating supply. The bridge held reserves backing the token across more than 20 blockchains. With the reserve gone, hundreds of millions in rsETH on Arbitrum, Base, Linea, and a dozen other L2s were suddenly backed by nothing.

Within hours, the attacker deposited the stolen tokens into Aave as collateral and borrowed over $190 million in real ETH against assets that were effectively counterfeit. Aave froze rsETH markets across its V3 and V4 deployments within the same afternoon. SparkLend and Fluid followed. Total DeFi TVL fell by over $13 billion in the 48 hours after the drain, as users raced to withdraw from protocols they no longer trusted.

The most troubling part? The vulnerability had been flagged publicly in an Aave governance forum post fifteen months earlier. The attack didn’t exploit a novel zero-day. It exploited a known configuration flaw that nobody fixed. Here’s exactly how it happened, and what the industry can actually do about it.

Anatomy of the Attack: Not a Contract Bug

To understand what went wrong, you first need to understand what cross-chain bridges actually do. When rsETH moves from Unichain to Ethereum, some piece of software on Ethereum has to verify that the corresponding tokens were locked or burned on Unichain. That verification is the entire security model. Get it wrong, and you can mint tokens on the destination chain that don’t correspond to anything real on the source chain.

Kelp DAO’s rsETH bridge used LayerZero’s OFT (Omnichain Fungible Token) standard across more than 20 networks. LayerZero’s architecture uses Decentralized Verifier Networks, or DVNs, to attest that a cross-chain message is valid before the destination chain acts on it. The critical variable is how many DVNs must agree before a message is accepted. Kelp’s rsETH bridge was configured with a 1-of-1 setup: one DVN, one required signature, no second check.

The 1/1 problem in plain terms: A 1-of-1 DVN configuration means that if the single verifier can be convinced something happened on the source chain, the destination chain will act on it, regardless of whether that thing actually occurred. There is no independent party to catch the error.

The attackers knew this. According to LayerZero’s incident statement, they gained access to the list of RPC nodes the LayerZero Labs DVN used to read source-chain state. RPC nodes are the servers that let off-chain software query blockchain data. The attackers then swapped the binary software on two of those nodes with malicious versions. The malicious nodes told the DVN a specific fraudulent transaction had occurred, while simultaneously returning accurate data to every other system that queried them, including LayerZero’s own monitoring infrastructure. That selective lying was the heart of the attack.

Compromising two nodes alone wasn’t enough. The DVN also used external RPC nodes for redundancy. So the attackers launched a DDoS attack against those external nodes, forcing the DVN to fail over onto the poisoned ones. Once failover triggered, the DVN confirmed a cross-chain burn event that never happened. The Ethereum contract released 116,500 rsETH. The malicious node software then self-destructed, wiping binaries and logs. The entire operation unfolded between 10:20 and 11:40 AM Pacific Time.

“This was not a smart contract hack. There was no reentrancy bug, no missing access check, no price oracle sleight-of-hand. The KelpDAO incident is something arguably more dangerous: an attack on the off-chain verification layer on which many cross-chain protocols depend.”
Chainalysis Investigation Team, Chainalysis, Inc. — Inside the KelpDAO Bridge Exploit

Kelp’s emergency pause multisig activated 46 minutes after the drain, at 18:21 UTC. Two follow-up attempts by the attacker at 18:26 and 18:28 UTC, each trying to pull an additional 40,000 rsETH worth roughly $100 million, both reverted because of the freeze. Without that pause mechanism, total losses could have approached $490 million. The attacker was later linked by LayerZero and Chainalysis to North Korea’s Lazarus Group, specifically the TraderTraitor subunit responsible for a string of DeFi attacks throughout 2025 and 2026.

Why This Attack Is More Dangerous Than a Smart Contract Bug

Smart contract vulnerabilities are findable. Auditors scan for reentrancy, missing access controls, integer overflows, and the other known failure modes. The industry has spent years building audit checklists, formal verification tools, and bug bounty programs oriented around on-chain code. This attack bypassed all of that. The smart contracts worked exactly as written. Every transaction on-chain looked completely valid.

What the attack targeted was the off-chain infrastructure layer: the RPC nodes that verifiers depend on to read chain state. That layer sits outside the scope of typical smart contract audits. No Solidity audit would catch a configuration that leaves a bridge with a single off-chain verifier, because the configuration isn’t in the contract code. It’s a deployment parameter chosen by the protocol team.

The configuration audit gap: The fault in the Kelp exploit was not in any line of smart contract code. It was in the deployment configuration, which sits outside the usual scope of a Solidity audit. Configuration reviews are a newer and less common discipline in DeFi security, and this incident is likely to accelerate demand for them considerably.

The blame dispute that followed the attack illustrated just how structural the problem is. LayerZero’s post-mortem said Kelp chose 1-of-1 despite recommendations to use multi-DVN redundancy. Kelp fired back that the 1/1 configuration appears in LayerZero’s own V2 OApp Quickstart, where the sample configuration file wires every pathway with one required DVN and no optional DVNs, and that no specific recommendation to change the rsETH DVN configuration was ever communicated through the direct channel between the two teams, open since July 2024. Security researchers backed Kelp’s reading: Yearn Finance developer Artem K pointed out that LayerZero’s public deployment code uses single-source verification defaults across Ethereum, BSC, Polygon, Arbitrum, and Optimism. Kelp wasn’t an outlier. According to sources cited by CoinDesk, roughly 40% of protocols on LayerZero run the same 1/1 configuration. A Dune Analytics review of approximately 2,665 active LayerZero OApp contracts found 47% using 1/1 setups.

LayerZero’s response to the exploit was swift: the company announced it would stop signing messages for any application running a 1-of-1 configuration, forcing a protocol-wide migration. That’s a meaningful response. But it also implicitly confirms that the default behavior of a $166 billion-volume cross-chain messaging protocol had, until April 2026, been compatible with the exact configuration that enabled this attack.

The Scale of DeFi’s Bridge Problem

The Kelp DAO exploit didn’t arrive in isolation. It was the largest single incident in a sustained wave. Drift Protocol, a Solana-based perpetuals exchange, lost approximately $285 million on April 1 in an attack also attributed to Lazarus Group. April 2026 ended with total DeFi losses estimated at around $647 million across 28 to 30 documented incidents, making it one of the most damaging months in DeFi history.

Incident	Date	Loss	Attack Type	Attribution
Kelp DAO (rsETH bridge)	April 18, 2026	~$292M	Off-chain RPC poisoning + DDoS	Lazarus Group (DPRK)
Drift Protocol	April 1, 2026	~$285M	Social engineering	North Korea-affiliated actors
Remaining April exploits	April 2026	~$70M	Various	Multiple

The pattern across years is damning. Bridges and cross-chain infrastructure have accounted for some of the largest individual DeFi losses since 2022, from the $625 million Ronin Bridge hack (5 of 9 validator keys compromised via spear phishing) through the Wormhole and Nomad exploits, and now to Kelp DAO. The specific attack vectors shift, but the underlying dynamic stays the same: cross-chain verification requires trusting off-chain actors or infrastructure, and when that trust is misplaced, the consequences are catastrophic and instantaneous.

The contagion from Kelp extended well beyond the $292 million direct loss. Bad debt on Aave from rsETH collateral reached into the hundreds of millions. Aave, SparkLend, and Fluid all froze rsETH markets. The broader DeFi ecosystem saw TVL decline sharply as users withdrew from lending protocols they associated with rsETH exposure. The event exposed how tightly coupled DeFi lending markets have become with cross-chain assets, and how a single bridge failure can transmit losses through the entire stack.

The Path Forward: What Actually Fixes This

There’s no single solution that eliminates cross-chain bridge risk. The problem is architectural: you’re asking one blockchain to verify the state of another, without a shared execution environment. But there are concrete steps that meaningfully reduce the attack surface, and the good news is that several of them are available today.

Multi-DVN consensus: the immediate fix

The most direct lesson from Kelp is that 1/1 verifier configurations should be treated as insecure by default. LayerZero’s V2 architecture supports X-of-Y-of-N configurations, where multiple independent DVNs must agree before a message is accepted. Under a 2/3 or 3/5 configuration, compromising one DVN’s RPC infrastructure isn’t enough. A second independent verifier would read from different nodes, see the discrepancy, and reject the forged message. The Kelp exploit would have failed.

LayerZero’s DVN ecosystem now includes major independent operators including Google Cloud, Chainlink, and Polyhedra Network, each running separate infrastructure. A multi-DVN configuration requiring consensus across two or more of these independent operators is available today and doesn’t require waiting for research to mature. The cost is slightly higher latency and fees. For a bridge holding hundreds of millions in user funds, that tradeoff isn’t a close call.

ZK-light clients: the cryptographic long game

The deeper fix is to eliminate the need to trust verifiers entirely. Berkeley’s zkBridge research demonstrates that zero-knowledge proofs can be used to verify cross-chain state without any external trust assumptions. Rather than asking a validator to attest that something happened on Chain A, a ZK-light client generates a cryptographic proof that a specific state transition occurred on Chain A, verifiable on Chain B using only mathematics.

“With succinct proofs, zkBridge not only guarantees strong security without external assumptions, but also significantly reduces on-chain verification cost. We propose novel succinct proof protocols that are orders-of-magnitude faster than existing solutions for workload in zkBridge.”
UC Berkeley RDI Center Research Team — zkBridge: Trustless Cross-chain Bridges Made Practical

The catch is that ZK proving remains computationally expensive, and building ZK-light clients for chains with complex consensus mechanisms (like EVM chains with large validator sets) is still an active research problem. Polyhedra Network’s zkBridge DVN, which uses zkSNARKs to verify cross-chain state, is already available as a LayerZero DVN option and has processed over 20 million cross-chain transactions. It’s not the default configuration for most protocols. It should be.

Cross-chain invariant monitoring

One reason the Kelp exploit succeeded for 46 minutes is that traditional monitoring tools only read from a single chain. They saw valid on-chain transactions and raised no alerts. What would have caught the attack much faster is cross-chain invariant monitoring: continuously comparing the total supply of a token on the destination chain against the total locked on the source chain. If those numbers diverge by more than a rounding error, something is wrong.

This type of monitoring doesn’t require waiting for ZK proofs to mature. It requires reading state from two chains, comparing numbers, and triggering an alert when they don’t match. Chainalysis noted in its post-mortem that spotting this class of exploit requires exactly this approach: continuously verifying that tokens released on a destination chain mathematically match tokens burned on the source chain. Protocols moving significant value across chains should treat this as non-optional infrastructure, not an optional add-on.

Canonical bridges for high-value assets

For the very highest-value transfers, canonical bridges (the bridges built directly into L2 rollup protocols, secured by Ethereum L1 consensus itself) offer a security guarantee that no third-party bridge can match. Arbitrum Bridge, Optimism Gateway, and Base Bridge inherit Ethereum’s validator set with no additional trust assumptions. The tradeoff is a seven-day withdrawal window on optimistic rollups and limited flexibility. For large institutional transfers or reserve-backing of major assets, that tradeoff is worth making.

🔒

Multi-DVN Consensus

Require 2+ independent verifiers to approve every cross-chain message. Available today on LayerZero V2. Eliminates single-point-of-failure. Highest immediate impact.

🧮

ZK-Light Clients

Cryptographic proofs verify source-chain state without trusting any validator. Polyhedra’s zkBridge DVN is live. Strongest security model; proving cost declining rapidly.

📊

Cross-Chain Monitoring

Continuously compare token supply across source and destination chains. Catches invariant violations before they become catastrophic losses. No new infrastructure required.

🛡

Canonical Bridges

For maximum-value transfers, use L1-secured canonical bridges. Seven-day withdrawal window is the cost. Ethereum validator security is the benefit.

What Builders Must Do Now

The Kelp incident makes clear that a smart contract audit is not a security audit for a cross-chain protocol. If your protocol bridges assets, you need a different and more expansive review process. Here’s what that looks like in practice.

Audit your DVN configuration, not just your contracts. Review what configuration your bridge deployment is actually using, not what your documentation says it should use. If you’re on a 1/1 setup, treat that as a critical vulnerability and migrate before you’re targeted.
Require at least two independent DVNs from different operators. Google Cloud, Chainlink, and Polyhedra are all live LayerZero DVN operators with independent infrastructure. A 2-of-3 requiring any two of them is materially more secure than a 1/1 setup at minimal additional cost.
Add Polyhedra’s zkBridge as an optional DVN. Even as an optional rather than required verifier, a ZK-proof-based DVN adds a mathematically grounded check that targeted RPC poisoning can’t defeat.
Deploy cross-chain supply monitoring on day one. Any bridge that issues tokens on destination chains should maintain a real-time comparison of locked supply on the source chain against circulating supply on all destination chains. Automate alerts and automatic pausing on significant divergence.
Test your emergency pause mechanism under realistic conditions. Kelp’s pause multisig worked. It fired 46 minutes in and prevented an additional $200 million in losses. Not every protocol that has a pause mechanism has verified it actually works under the conditions where it would be needed.
Harden your RPC infrastructure independently of your bridge vendor’s recommendations. Use multiple RPC providers from different geographic regions and organizational structures. Implement RPC consistency checking that alerts when different providers return materially different state for the same query.

The documentation default problem: LayerZero’s own V2 OApp Quickstart, at the time of the Kelp exploit, showed a sample configuration with one required DVN and no optional DVNs. Default configurations in developer tooling become de facto standards. Infrastructure providers have a responsibility to make the secure configuration the default, not an advanced option that teams have to discover separately.

Frequently Asked Questions

What is a DVN (Decentralized Verifier Network) in LayerZero?

A DVN is an independent off-chain network that reads source-chain state and attests that a cross-chain message is valid before the destination chain accepts it. LayerZero’s architecture lets each protocol choose which DVNs must confirm a message and how many must agree. A 1/1 configuration requires only one DVN’s attestation; a 2/3 configuration requires two of three to agree before any action is taken.

How did the Kelp DAO exploit actually work?

Attackers compromised the RPC nodes that LayerZero’s single DVN used to read source-chain state, installing malicious software that reported a fake token burn event to the DVN while returning accurate data to all other systems. They simultaneously DDoS’d the backup external RPC nodes, forcing the DVN to rely on the poisoned infrastructure. The DVN validated the fake message, and Kelp’s Ethereum contract released 116,500 rsETH to the attacker. The exploit took roughly 80 minutes from start to finish.

Would a standard smart contract audit have caught this vulnerability?

No. The Kelp DAO smart contract code was correct and performed as designed. The vulnerability was in the deployment configuration, specifically the decision to use a 1-of-1 DVN setup, which sits outside the scope of a typical Solidity audit. This is a significant gap in how DeFi security reviews are currently structured, and it’s driving demand for dedicated bridge configuration audits.

What is zkBridge and how does it improve cross-chain security?

zkBridge uses zero-knowledge proofs to verify that a specific state transition occurred on a source chain, without relying on any external validator to attest to it. The proof can be checked on the destination chain using only cryptographic math. This eliminates the need to trust any off-chain infrastructure, making the class of attack that hit Kelp DAO impossible. UC Berkeley’s RDI Center published the foundational research; Polyhedra Network has deployed a production implementation.

Is LayerZero itself compromised after this attack?

No. LayerZero’s incident post-mortem confirmed zero contagion to other applications on the protocol. Every application using multi-DVN configurations was unaffected. The attack targeted one specific application’s single-verifier deployment, not a flaw in LayerZero’s protocol code. LayerZero has since announced it will stop signing messages for any application using a 1/1 DVN configuration.

What is the safest type of cross-chain bridge for large asset transfers?

For the highest-value transfers, canonical bridges secured by Ethereum L1 consensus (Arbitrum Bridge, Optimism Gateway, Base Bridge) offer the strongest security guarantees, since they inherit Ethereum’s full validator set with no additional trust assumptions. The tradeoff is a seven-day withdrawal window on optimistic rollups. Third-party bridges using multi-DVN configurations with ZK-proof verifiers are the next-best option when speed and flexibility are required.

Who was behind the Kelp DAO attack?

LayerZero and Chainalysis attributed the attack with preliminary confidence to North Korea’s Lazarus Group, specifically the TraderTraitor subunit. The same group was linked to the Drift Protocol exploit earlier in April 2026 and a series of DeFi attacks going back several years. Lazarus Group has developed expertise in both technical infrastructure attacks and social engineering of crypto teams.

The Bridge Problem Isn’t Going Away

Multi-chain DeFi isn’t a temporary phase. Users and capital will continue to move across chains, and bridges will remain the critical infrastructure that makes that movement possible. The question isn’t whether to use cross-chain bridges. It’s whether the industry will build them with the security rigor their role demands.

The Kelp DAO exploit exposed two overlapping failures. The first is technical: a 1/1 verifier configuration is not an appropriate security model for a bridge holding hundreds of millions in user funds, and that configuration was both a common default and underaudited across the industry. The second is systemic: DeFi’s lending markets have grown deeply entangled with cross-chain assets, meaning a bridge failure no longer stays in the bridge. It transmits instantly to lending protocols, stablecoin markets, and the broader TVL of the entire ecosystem.

The good news is that the technical tools to build materially more secure bridges exist today. Multi-DVN configurations, ZK-proof-based verifiers, and real-time cross-chain invariant monitoring aren’t research concepts. They’re deployable options that the Kelp incident will likely force into mainstream adoption far faster than any industry working group ever could. Fifteen months of ignored governance forum warnings accomplished nothing. A $292 million loss is already reshaping how protocols configure their bridges. That’s not how security lessons should have to be learned. But at least they’re being learned.

Watch For

01 LayerZero’s forced migration off 1/1 DVN configurations: the protocol announced it will stop signing messages for single-verifier apps, driving a wave of bridge reconfigurations across dozens of protocols through mid-2026.

02 DeFi United’s rsETH recovery plan: a coalition of protocols has proposed using Aave to systematically unwind bad debt tied to the exploit and restore rsETH’s backing. The outcome will shape how DeFi handles post-exploit socialized losses going forward.

03 ZK-proof DVN adoption rates: Polyhedra’s zkBridge DVN is live on LayerZero. Watch whether major protocols add it as a required or optional verifier in the months following this incident, signaling an industry shift toward cryptographic rather than validator-based bridge security.

04 Aave’s LRT collateral policy: this is the second 2026 incident where liquid restaking token collateral on Aave produced nine-figure bad debt from a non-Aave failure. A policy overhaul on how Aave handles cross-chain or bridge-dependent assets is increasingly likely.

Stay ahead of DeFi security. More analysis on blockchain infrastructure and protocol security at NeuralWired.

Explore DeFi Coverage

May 3, 2026

PyTorch Lightning Malware on PyPI: Urgent Fix Guide 2026

PyTorch Lightning Hit by Supply Chain Attack — Malicious PyPI Versions Steal Credentials | NeuralWired

Cybersecurity May 1, 2026 · 9 min read

PyTorch Lightning Hijacked: 16M Monthly Downloads Exposed to Credential-Stealing Malware

Two versions of the popular AI framework package were quietly poisoned on PyPI, executing a credential harvester the moment any developer imported them. Here’s what got stolen, how it worked, and what you need to do right now.

At some point on the morning of April 30, 2026, someone published two versions of the lightning package on PyPI that should never have gone live. Versions 2.6.2 and 2.6.3 of PyTorch Lightning, a high-level wrapper used by machine learning engineers around the world to train scalable models, carried hidden malware that kicked off the moment a developer ran import lightning. No extra steps. No warnings. Just a background thread quietly draining credentials.

By the time PyPI quarantined the package, the malicious releases had been available for hours. With over 302,000 downloads recorded in a single day and more than 16 million across the past month, the exposure window was not trivial. Any developer who updated Lightning that morning and then ran a training script could have handed over their GitHub tokens, AWS access keys, and more without realizing it.

This wasn’t an opportunistic smash-and-grab. The attack was carefully engineered, obfuscated behind multiple layers, and tied to a broader supply chain campaign that had already hit SAP-related npm packages the day before. The AI and machine learning community, which has built considerable institutional trust in the PyTorch ecosystem, now has a reason to reconsider how it handles package hygiene.

What Happened on April 30

The malicious packages were pushed to PyPI under the lightning project namespace, almost certainly using a compromised PyPI token belonging to the Lightning-AI maintainer account. That’s the most probable entry point, though the full forensic picture hasn’t been publicly confirmed by Lightning-AI at time of writing.

What followed was a rapid sequence of moves that suggested the attacker had a plan well beyond the initial payload. Within hours, a GitHub account identified as pl-ghost pushed and then quickly deleted six short-lived branches across Lightning-AI repositories, including litAI, utilities, and torchmetrics. The branch names were either random 10-character strings or fake Dependabot labels, both designed to blend into the background noise of an active open source project. Fortunately, branch protections and automated workflows on the Lightning-AI repos blocked any of those branches from merging.

Safe version: PyTorch Lightning 2.6.1, released January 30, 2026, is the last confirmed clean release. If you’re running 2.6.2 or 2.6.3, treat your environment as compromised until you’ve completed a full credential rotation.

Community members noticed quickly. A GitHub issue, numbered #21689 on the Lightning-AI repo, described the hidden execution chain in detail. It was closed without explanation. When Socket Research opened a follow-up issue, it was shut down within one minute by the pl-ghost account, which posted a “SILENCE DEVELOPER” meme before closing it. That behavior strongly suggests the project’s GitHub account had already been taken over at that point.

“The issue was closed within one minute by the pl-ghost account, which then posted a ‘SILENCE DEVELOPER’ meme… strongly indicating that the project’s GitHub account appears to be compromised.”
Socket Research Team, Socket.dev — Socket Research Blog, April 30, 2026

The Lightning-AI maintainers eventually acknowledged the situation with a short statement confirming an active investigation, and a subsequent advisory described the affected versions as containing “functionality consistent with a credential harvesting mechanism.” That’s a careful way of saying the packages were designed to steal developer secrets.

Inside the Malware: A Multi-Stage Credential Harvester

The technical sophistication here is worth understanding, because this wasn’t a simple script that grabbed a few environment variables. Socket Research’s full payload teardown reveals a multi-stage attack chain that starts on import and fans out aggressively.

Stage One: The Launcher

The malware hides inside a directory called _runtime/ within the package. A file named start.py triggers silently when the library is imported. Its first job is downloading the Bun JavaScript runtime directly from GitHub. This is an unusual dependency for a Python machine learning library, which is exactly why it works as a hiding mechanism.

Stage Two: The 11 MB Payload

Once Bun is installed, the launcher executes router_runtime.js, an 11-megabyte obfuscated JavaScript file running in a daemon thread. The obfuscation uses string-array rotation combined with AES decryption, consistent with the javascript-obfuscator toolchain. The size and complexity of this file signal that substantial development time went into making it hard to analyze.

🔑

703 process.env References

The payload systematically scans environment variables for any tokens, secrets, or credentials present in the developer’s shell.

🔐

463+ Auth Token References

Targeted scanning for authentication tokens, API keys, and bearer credentials across multiple platforms and services.

📦

336 Repository References

Once credentials are harvested, the payload attempts to poison up to 50 branches per stolen token across reachable repositories.

🪛

npm Worm Component

Local npm .tgz files get infected via postinstall hooks, enabling the malware to spread laterally through package dependencies.

Stage Three: Credential Validation and Exfiltration

The payload doesn’t blindly dump everything it finds. It validates harvested credentials against live APIs before exfiltrating them, confirming that GitHub tokens, npm tokens, and cloud provider keys (AWS, Azure, GCP) are actually active before sending them out. This validation step is a meaningful refinement over simpler stealers; it signals a mature operation focused on quality over volume of data.

Stage Four: Repository Poisoning

With a valid GitHub token, the malware attempts to inject .claude/router_runtime.js and malicious workflow files into up to 50 branches per token. Commits are impersonated using the email claude@users.noreply.github.com, a deliberate choice to blend in with automated commits from legitimate Claude AI tooling. The npm worm component handles local spread, bumping package versions and inserting postinstall hooks into any .tgz files it can reach.

Important dependency: The entire attack chain requires the Bun runtime to be downloadable from GitHub. In environments with strict egress controls or GitHub access restrictions, the payload may not fully execute. That said, any affected version should still be treated as compromised regardless of network configuration.

Detection in 18 Minutes, and the Response That Followed

One of the few things that went right here was speed. Socket’s AI-powered scanner flagged both 2.6.2 and 2.6.3 as potentially malicious just 18 minutes after they were published to PyPI. That’s an impressively short detection window for a supply chain attack, where traditional signature-based tools often lag by hours or days.

“Socket’s AI scanner flagged both versions 2.6.2 and 2.6.3 as potentially malicious eighteen minutes after publication.”
Socket Research Team, Socket.dev — Socket Research Blog, April 30, 2026

PyPI’s own response was also fairly rapid, moving to quarantine the lightning project once the situation was confirmed. Quarantine on PyPI means the affected versions can no longer be installed, though anyone who already pulled them down retains the packages in their local cache.

The maintainer response was more complicated. The GitHub suppression behavior, whether it represents a fully compromised account or something more ambiguous, created a trust problem that a brief advisory statement can’t fully repair. When community members raising legitimate security concerns get silenced by memes within 60 seconds, it damages the project’s credibility in ways that outlast the technical incident itself.

Understanding the Scale of the Risk

PyTorch Lightning isn’t a niche tool. It’s infrastructure for how a meaningful slice of the global AI research and engineering community trains models at scale. The download numbers make that concrete.

Metric	Figure	Why It Matters
Daily Downloads (lightning)	302,431	Reflects how many installs could occur within a single attack window
Weekly Downloads	3,429,724	Shows how quickly compromised versions propagate through CI/CD pipelines
Monthly Downloads	16,201,959	Long-tail exposure risk for teams with infrequent dependency updates
GitHub Stars (pytorch-lightning)	31,100+	Indicator of broad developer adoption and community reliance
Companies using PyTorch	17,196+	Enterprise-scale attack surface across industries
AI research papers using PyTorch	~85%	Academic ML pipelines potentially feeding compromised credentials into research infrastructure

The PyTorch ecosystem is effectively the default substrate for AI research. When something this deeply embedded gets compromised, the blast radius isn’t just individual developers. It extends to corporate training clusters, academic compute environments, and any CI/CD pipeline that automatically pulls the latest compatible version. That last category is particularly dangerous, since many ML projects pin a major version but not a specific patch, meaning an automated update could trigger the malware silently.

It’s also worth noting, as Socket Research flags, that PyPI download statistics include CI mirrors and caching infrastructure. The “real” number of human-initiated installs is lower than 16 million, but that caveat doesn’t meaningfully reduce the risk surface for organizations running automated pipelines.

Connecting the Dots: Mini Shai-Hulud and TeamPCP

This attack didn’t emerge in isolation. The Hacker News assessed the Lightning incident as an extension of the Mini Shai-Hulud campaign, which struck SAP-related npm packages on April 29, just one day earlier. The shared patterns are hard to dismiss: similar obfuscation techniques, the same focus on credential harvesting to enable repository poisoning, and an operational tempo that suggests a coordinated actor moving across ecosystems quickly.

“The campaign is assessed to be an extension of the Mini Shai-Hulud supply chain incident that targeted SAP-related npm packages on Wednesday.”
Ravie Lakshmanan, Editor, The Hacker News — The Hacker News, April 30, 2026

A group calling itself TeamPCP has claimed responsibility via a Tor-accessible site, posting a PGP-signed message that references both LAPSUS$ and a group called CipherForce. Those claims should be treated skeptically. Attribution in supply chain attacks is genuinely difficult, and extortion groups have strong incentives to name-drop well-known threat actors to inflate their perceived credibility. Socket Research itself notes that the Lightning payload lacks specific IOCs tied to Mini Shai-Hulud, suggesting it may be a distinct actor mimicking the same playbook rather than the same crew.

What’s not disputed is the sophistication of the operational security. The use of fake Dependabot branch names, commits impersonating Claude AI tooling, and rapid deletion of evidence branches all point to an attacker who has studied how modern DevOps environments look and knows how to hide in plain sight within them.

IOC note: The specific IOC “SHA1HULUD,” associated with the Mini Shai-Hulud npm campaign, was not found in the Lightning payload. Researchers at Aikido Security and OX Security have documented overlapping infrastructure patterns, but the exact actor relationship remains unconfirmed.

What You Should Do Right Now

If there’s any chance your environment pulled Lightning 2.6.2 or 2.6.3, the response isn’t optional. Here’s the practical order of operations.

Immediately uninstall both affected versions: pip uninstall lightning. Then reinstall the last clean release: pip install lightning==2.6.1.
Rotate every secret in your environment. GitHub personal access tokens, fine-grained tokens, npm tokens, and cloud provider credentials (AWS, Azure, GCP) should all be treated as compromised. Don’t audit first and rotate later; rotate now and audit afterward.
Review your GitHub repository’s branch history for any unexpected branches created around April 30, particularly any with random alphanumeric names or fake Dependabot labels.
Audit your GitHub Actions workflow files for any unauthorized modifications. The malware attempts to insert malicious workflows; check .github/workflows/ carefully across all branches.
Check your local npm cache and any .tgz packages in your project directories. The worm component targets these specifically via postinstall hooks.
If your CI/CD pipeline automatically installs the latest compatible lightning version, add a version pin to 2.6.1 immediately and lock it until Lightning-AI publishes a verified clean release with an explicit security advisory.
Scan your environment with Socket’s security tooling or equivalent software composition analysis (SCA) tools. Look for any .claude/router_runtime.js files that shouldn’t be there.

For teams: If anyone on your team ran a training job or imported Lightning on April 30 before the quarantine, assume shared secrets are at risk. Service accounts with broad repository access should be rotated first. Check your GitHub security log for any unusual OAuth activity or API calls originating from unfamiliar IP addresses.

Frequently Asked Questions

Are PyTorch Lightning versions 2.6.2 and 2.6.3 safe to use?

No. Both versions contain credential-stealing malware that executes automatically when you import the library. PyPI has quarantined these releases, so they can no longer be installed fresh. If you already have either version, uninstall immediately and downgrade to 2.6.1, the last verified clean release.

What credentials were targeted in the PyTorch Lightning supply chain attack?

The payload targeted GitHub tokens, npm tokens, and cloud provider credentials including AWS, Azure, and GCP access keys. It also scanned environment variables broadly, referencing over 700 process.env lookups. Credentials were validated against live APIs before exfiltration, so only active secrets were sent out.

How do I remove the compromised PyTorch Lightning package?

Run pip uninstall lightning, then pip install lightning==2.6.1 to restore the last clean version. After uninstalling, rotate all secrets in your environment, audit your GitHub repository for unexpected branches or workflow changes, and scan local npm files for signs of the worm component.

Does this affect pytorch-lightning as well as the lightning package?

The confirmed malicious versions were published under the lightning PyPI namespace. The pytorch-lightning package name was previously used but the project migrated to lightning. If your requirements file references lightning at version 2.6.2 or 2.6.3, you’re affected. Check both package names in your environment to be safe.

What is the Mini Shai-Hulud campaign?

Mini Shai-Hulud is the name researchers applied to a supply chain attack that compromised SAP-related npm packages on April 29, 2026. The Lightning PyPI incident shares similar obfuscation techniques and credential-harvesting patterns, leading researchers to assess them as potentially related. A group called TeamPCP has claimed responsibility for both, though attribution remains unconfirmed.

How quickly was the PyTorch Lightning malware detected?

Socket’s AI-powered scanner flagged versions 2.6.2 and 2.6.3 as potentially malicious within 18 minutes of publication. This rapid detection is faster than traditional signature-based approaches, though the packages were still available for several hours before PyPI completed quarantine.

Was the Lightning-AI GitHub account compromised?

Evidence strongly suggests it was. The pl-ghost account closed a legitimate community security report within one minute while posting a dismissive meme, then pushed and deleted six suspicious branches across multiple Lightning-AI repositories. Socket Research concluded this behavior is consistent with a compromised maintainer account, not normal project management.

What should ML engineering teams do to prevent similar attacks?

Pin exact package versions in production environments rather than floating on minor versions. Integrate software composition analysis tools like Socket into your CI/CD pipeline to catch malicious packages before they deploy. Regularly audit your dependency tree, enable two-factor authentication on all package registry accounts, and implement least-privilege policies for tokens used in automated pipelines.

What This Means Going Forward

The PyTorch Lightning compromise is a useful case study in how supply chain attacks actually work in practice: not through spectacular zero-days, but through a compromised token, a sophisticated payload, and a brief window before the community noticed. The 18-minute detection by Socket is genuinely impressive. The hours-long exposure window before full quarantine is not.

For ML engineers specifically, this incident highlights a risk profile that the security community has been raising for years. Training infrastructure typically runs with broad cloud permissions and direct access to sensitive model weights, datasets, and API keys. A credential harvester that lands inside a framework as foundational as PyTorch Lightning doesn’t just steal tokens; it can open doors into production model serving environments, data pipelines, and cloud billing accounts. The attack surface for a compromised ML developer is meaningfully wider than for a compromised web developer.

OSS trust is a fragile thing. The speed of the technical response, from Socket’s detection to PyPI’s quarantine, shows the system can work. But the GitHub suppression behavior, whatever its precise explanation, is the kind of thing that makes developers question whether the open source projects they depend on are actually being watched by anyone paying attention. That’s a confidence problem the Lightning-AI team will need to address directly, not just through code patches, but through transparency about how the account was compromised and what access controls have changed since.

The broader lesson isn’t novel, but it’s clearly not yet internalized everywhere: every package in your dependency tree is a potential attack surface. The more foundational the package, the more attractive the target. In an ecosystem where 85% of AI research runs on PyTorch, “foundational” doesn’t get more foundational than this.

Watch For

01 Lightning-AI’s official post-incident report — particularly whether they confirm full compromise of the PyPI token and GitHub account, and what token-rotation and account-audit steps have been implemented.

02 TeamPCP’s next move. If the attribution holds, a group claiming LAPSUS$ ties that successfully hit both npm and PyPI in 48 hours is likely to attempt more OSS ecosystem targets. Watch for unusual activity in popular ML framework namespaces on PyPI and conda-forge.

03 PyPI’s policy response. The incident is a test case for whether package registries will accelerate adoption of mandatory publisher attestations, two-factor requirements for high-download packages, and faster automated quarantine tooling.

04 Secondary infections from the npm worm component. Any developer who ran affected Lightning versions alongside active npm projects may have locally infected .tgz files that could propagate the payload if shared or published, even after removing the original package.

Stay ahead of AI security threats. More on supply chain attacks, model security, and the tools protecting the ML ecosystem at NeuralWired.

Explore Cybersecurity

April 30, 2026

Copy Fail Linux Vulnerability Explained: Root Access in 2026

Copy Fail (CVE-2026-31431): The 9-Year Linux Kernel Flaw That Gives Any User Root Access | NeuralWired

Security April 30, 2026 · 10 min read

Copy Fail: The 9-Year Linux Kernel Flaw That Hands Any Local User Root Access

CVE-2026-31431 lets any unprivileged user on virtually every major Linux distribution gain full root access using 732 bytes of Python. An AI found it in roughly one hour. Nobody spotted it for nine years.

Three separate kernel changes, written years apart by engineers who had no reason to connect them, quietly assembled a trap inside the Linux cryptographic subsystem. The last piece clicked into place in August 2017. Nobody noticed. Servers got deployed. Containers launched. Cloud providers scaled. And somewhere in the intersection of an IPsec helper module, a zero-copy file transfer mechanism, and a performance shortcut, a fully working privilege escalation waited.

On April 29, 2026, offensive security firm Xint.io published the full technical details of CVE-2026-31431, now publicly named Copy Fail. The flaw carries a CVSS 7.8 severity score, which sounds manageable until you read what it actually does: it gives any local user, no matter how restricted, a reliable path to full root on nearly every Linux system shipped since 2017. No race condition. No per-distro adjustments. No compiled payload. Just Python, and patience.

The discovery itself is almost as striking as the vulnerability. Theori’s Xint Code Research Team, using an AI-assisted analysis pipeline, surfaced Copy Fail as its highest-severity finding roughly an hour after pointing the system at the Linux kernel’s crypto/ subsystem. The same scan, the team noted, found additional high-severity bugs still working through coordinated disclosure.

A Bug Built in Three Acts

Copy Fail isn’t a single coding mistake. It’s the result of three individually reasonable kernel changes, each made years apart, that only become dangerous in combination.

Act One: 2011 – The authencesn Module

The authencesn module arrived in 2011 to handle IPsec ESP Extended Sequence Numbers, defined in RFC 4303. From the start, it used the caller’s destination scatterlist as scratch space to rearrange ESN bytes during decryption. This was entirely harmless: only the kernel’s internal xfrm layer ever called it, and the kernel controlled both ends of the operation.

Act Two: 2015 – The AF_ALG AEAD Socket

In 2015, the AF_ALG interface gained AEAD support, including a splice() path that could deliver pages directly from the page cache into the cryptographic subsystem. authencesn was converted to the new AEAD interface. Still not exploitable: AF_ALG used out-of-place operations, keeping input and output buffers separate.

Act Three: August 2017 – The In-Place Optimization

A performance optimization in algif_aead.c changed how decryption handled memory. For efficiency, the new code copied AAD and ciphertext into an output buffer, but chained the authentication tag pages by reference using sg_chain() and then set req->src = req->dst, creating an in-place operation. Page cache pages delivered via splice() were now sitting inside the writable destination scatterlist. The trap was set.

The core insight: Nobody connected the 2017 in-place optimization to authencesn‘s scratch writes or to splice()‘s page cache delivery mechanism. Each change was reasonable in isolation. The vulnerability lives entirely at their intersection, across a six-year window and three separate subsystems.

How the Exploit Actually Works

The attack chain is deceptively clean. An unprivileged user opens an AF_ALG socket bound to authencesn(hmac(sha256),cbc(aes)) and uses the standard splice() system call to transfer pages from a readable target file into the socket. No special permissions. No kernel modules. Nothing that triggers standard audit rules.

Inside the kernel, the 2017 in-place optimization causes those file pages to end up in the writable destination scatterlist. When authencesn‘s decrypt routine runs, it writes four bytes at an offset past the AEAD tag, directly into what it believes is its own output buffer. Those bytes land in the kernel’s cached copy of the target file.

“An unprivileged local user can write four controlled bytes into the page cache of any readable file on a Linux system, and use that to gain root.”
Xint Code Research Team, Theori — xint.io

The write fails HMAC verification and recvmsg() returns an error. The caller sees a failed decryption. But the four-byte write into the page cache persists. Repeat the process across targeted offsets of a setuid binary, and the kernel’s cached version of that binary contains attacker-controlled code. Call execve() on it, and the kernel loads from the page cache rather than disk.

Stealth note: The corrupted page is never marked dirty for writeback, so the file on disk remains unchanged. Disk-based integrity checks and standard checksums won’t catch the modification. The in-memory version, which is what actually executes, is corrupted system-wide.

The result is a four-property combination that the Xint team describes as nearly unique in their experience:

📦

Portable

Confirmed working on Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1, and SUSE 16 with no per-distro modifications.

🔬

Tiny

The full working proof-of-concept is 732 bytes of standard-library Python. No compiled payload, no external dependencies.

👻

Stealthy

Disk-based integrity checks see nothing. The modification exists only in the page cache, invisible to on-disk forensic tools.

🐳

Cross-Container

Container isolation doesn’t stop it. Part two of Theori’s research series covers a full Kubernetes container escape using the same primitive.

“This vulnerability is unique because it has four properties that almost never appear together: it’s portable, tiny, stealthy, and cross-container. It allows any user account, no matter how low-level, to increase their privilege to full admin access.”
Xint.io Spokesperson, Theori — xint.io

The Scale of Exposure

Linux isn’t just popular on servers. It is, for practical purposes, the substrate on which the cloud runs. The numbers make the exposure concrete.

Platform	Linux Share	Implication
Google Cloud VMs	91.6%	Highest Linux density of any major cloud provider
AWS EC2 Instances	83.5%	Amazon Linux 2023 directly confirmed vulnerable
Microsoft Azure VMs	61.8%	Majority of Azure workloads run affected kernels
Public Cloud Overall	~90%	CNCF estimate across combined AWS/Azure/GCP infrastructure
Production Kubernetes	96.4%	Container escape risk affects nearly all K8s deployments

The affected kernel range compounds the problem. Theori confirmed the exploit works across kernel versions 6.12, 6.17, and 6.18. The vulnerable commit dates to August 2017, meaning any system running a kernel from that point forward and exposing AF_ALG sockets to unprivileged users is potentially affected. That’s essentially every major distribution shipped in the past nine years.

Shared hosting environments face the most acute risk. A single compromised tenant account can traverse to root, from which the entire host is accessible. Multi-tenant SaaS platforms, university computing clusters, and developer PaaS environments all sit in this category.

“732 bytes of Python. Root on every major Linux distribution shipped since 2017. No race conditions. No per-distro offsets. No version checks. 100% success rate.”
Brian Pak, Xint Code Research Team, Theori — xint.io

AI Found It in One Hour

The vulnerability’s discovery story is, in many ways, just as significant as the vulnerability itself. Taeyang Lee, a researcher at Theori, formed an initial hypothesis: the combination of AF_ALG sockets and splice() creates a path where unprivileged userspace can feed page cache pages directly into the crypto subsystem, and that scatterlist page provenance might be an underexplored source of vulnerabilities.

Rather than manually auditing the kernel’s crypto subsystem, the Xint Code Research Team fed that one-line hypothesis into an AI-assisted scanning pipeline pointed at crypto/. About an hour later, Copy Fail came back as the highest-severity finding. The same scan surfaced additional high-severity bugs that are still working through coordinated disclosure.

“About an hour later, Copy Fail came back as the highest-severity finding. The same scan surfaced additional high-severity bugs, still in coordinated disclosure.”
Xint Code Research Team, Theori — xint.io

The implications for the security research field are hard to overstate. Traditional manual kernel audits are expensive, slow, and require deep specialist knowledge. This approach condensed what might have been weeks of expert review into a single hour of autonomous scanning. The economics of vulnerability discovery are shifting, and not symmetrically: defenders don’t automatically get faster just because attackers do.

David Brumley, Chief AI and Science Officer at Bugcrowd, drew a direct line between Copy Fail and earlier high-profile kernel primitives in a post on Bugcrowd’s research blog:

“Copy Fail is the same class of primitive, in a different subsystem. The 2017 in-place optimization in algif_aead allows a page-cache page to end up in the kernel’s writable destination scatterlist for an AEAD operation submitted over an AF_ALG socket. An unprivileged process can then drive splice() into that socket and complete a small, targeted write into the page cache of a file it doesn’t own.”
David Brumley, Chief AI and Science Officer, Bugcrowd — bugcrowd.com

Logic bugs like Copy Fail are particularly hard for humans to spot. Memory corruption flaws produce signals: crashes, sanitizer output, fuzzer hits. A logic bug that writes to the right memory location, through the right interfaces, in a sequence that spans three subsystems and six years of kernel history, produces nothing. It just works.

Patching: Fast Upstream, Slow Everywhere Else

The upstream kernel response was fast. Theori reported the flaw to the Linux kernel security team on March 23, 2026. An initial acknowledgment came the next day. Patches were proposed and reviewed by March 25. The fix landed in the mainline kernel on April 1, 2026, via commit a664bf3d603d, which reverts the 2017 in-place optimization. Upstream patch time: under 10 days from report to commit.

The problem is what happens after that. Enterprise deployments average 60 to 90 days to roll out Linux patches after vendor releases, according to Qualys TruRisk data. Roughly 15 to 25 percent of systems running older LTS kernel branches wait more than 100 days. The gap between “patch exists” and “patch deployed” is where attacks happen.

Stage	Typical Timeline	Status for CVE-2026-31431
Upstream kernel patch	24-48 hours (critical)	Committed April 1, 2026
Distro security advisory	Days to weeks	Debian and SUSE advisories published
Enterprise deployment	60-90 days average	Majority of systems still unpatched
LTS branch backport	Varies widely	15-25% may wait 100+ days

For immediate mitigation before patching is possible, administrators can restrict AF_ALG socket access using seccomp profiles or AppArmor/SELinux policies. The Debian security tracker and SUSE CVE advisory both carry current package status for their respective distributions.

Action required: Check your kernel version against your distribution’s patched release. On systems where live patching isn’t available, restrict AF_ALG socket creation for unprivileged users as an interim control. Container workloads should be treated as high priority given the forthcoming Kubernetes container escape research.

Disclosure Timeline

Copy Fail followed a thorough coordinated disclosure process, giving vendors and distributors time to prepare patches before full public release.

Date	Event
August 2017	Vulnerability introduced via in-place optimization commit in `algif_aead.c`
March 23, 2026	Theori reports flaw to Linux kernel security team
March 24, 2026	Kernel security team acknowledgment received
March 25, 2026	Patches proposed and reviewed
April 1, 2026	Fix committed to mainline kernel (commit a664bf3d603d)
April 22, 2026	CVE-2026-31431 officially assigned
April 28, 2026	Bugcrowd blog post published by David Brumley
April 29, 2026	Full public disclosure via xint.io; The Hacker News coverage published
April 30, 2026	Heise.de German-language coverage; broader security community response

Theori has also confirmed that this is part one of a two-part research series. Part two will detail a Kubernetes container escape built on the same underlying primitive. Container security teams should treat this as an active, evolving situation rather than a closed incident.

Frequently Asked Questions

What is CVE-2026-31431 (Copy Fail)?

CVE-2026-31431, called Copy Fail, is a local privilege escalation flaw in the Linux kernel’s algif_aead cryptographic interface. It allows any unprivileged local user to write four controlled bytes into the kernel page cache, enabling root access on any major Linux distribution shipped since August 2017.

Which Linux distributions are affected by Copy Fail?

Confirmed affected distributions include Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1, and SUSE 16. Any Linux distribution running a kernel from August 2017 onward with the authencesn and algif_aead modules is likely affected. Debian and SUSE have published security advisories with current patch status.

How do I know if my system is patched?

Check your running kernel version against your distribution’s patched release. The upstream fix landed on April 1, 2026, in mainline commit a664bf3d603d. Check the Debian security tracker or your distro’s equivalent CVE advisory page for the specific patched package version.

Does Copy Fail affect cloud virtual machines?

Yes. Cloud VMs running unpatched Linux kernels are vulnerable to any user who can execute code on the instance. This includes multi-tenant environments. Cloud providers run Linux on over 60% to 91% of VMs depending on the platform, making this a high-priority patch for cloud workloads.

Does Copy Fail work inside containers?

Yes. Container isolation does not prevent exploitation because the flaw exists in the host kernel’s page cache, which is shared across containers. Theori has confirmed a full Kubernetes container escape using the same primitive; full details are expected in a forthcoming Part 2 research post.

Why did this go undetected for nine years?

The vulnerability exists only at the intersection of three kernel changes made in 2011, 2015, and 2017 across separate subsystems. Logic bugs don’t produce crashes or fuzzer signals. Each individual change was reasonable in isolation, making the combined effect essentially invisible to standard review and testing processes.

What’s the interim mitigation if I can’t patch immediately?

Restrict AF_ALG socket creation for unprivileged users via seccomp filter policies, AppArmor profiles, or SELinux policy rules. This blocks the attack path without requiring a kernel update. Verify your container runtime and Kubernetes policies also restrict this system call for workloads running as non-root users.

How significant is the AI-assisted discovery angle?

Theori’s AI pipeline found Copy Fail in roughly one hour from a one-line research hypothesis. The same scan identified additional high-severity bugs still in coordinated disclosure. This suggests AI tools can compress vulnerability discovery timelines from weeks to hours, changing the economics of both offensive and defensive security research significantly.

What Comes Next

Copy Fail is a clean illustration of how complexity creates risk in long-lived software. The Linux kernel is audited more thoroughly than virtually any codebase on earth, yet a logic bug spanning three subsystems and six years of history slipped through every review. The flaw wasn’t in any single commit. It was in the space between them.

The AI discovery angle changes the calculus going forward. If a one-line hypothesis fed into an autonomous scanner can surface a CVSS 7.8 kernel flaw in an hour, the assumption that lightly funded attackers lack the research capacity to find such bugs needs revisiting. The same tools available to Theori’s researchers are available to anyone willing to build or buy similar infrastructure. Coordinated disclosure and rapid upstream patching matter more than ever, because the window between bug introduction and discovery is likely to shrink.

For enterprise security teams, the immediate priority is simple: patch, or restrict AF_ALG access today. The 60-to-90-day average remediation window is a liability Copy Fail was designed to exploit. And with Part 2 of Theori’s research series, covering the Kubernetes container escape, still to come, the organizations most at risk may not have fully mapped their exposure yet.

Watch For

01 Theori’s Part 2 Kubernetes container escape research, expected soon after the April 29 initial disclosure, which will detail how Copy Fail’s page cache primitive translates into a full container breakout on production clusters.

02 Additional high-severity kernel bugs found by the same Xint Code AI scan, currently in coordinated disclosure. Expect further CVE assignments and patching cycles in the weeks following Copy Fail’s public release.

03 Enterprise patch deployment rates for CVE-2026-31431 across major cloud providers. Given the 60-to-90-day average lag and the simplicity of the exploit, any confirmed in-the-wild exploitation reports in May or June 2026 would mark a significant escalation.

04 Broader adoption of AI-assisted vulnerability scanning by both security teams and threat actors. Copy Fail’s one-hour discovery time is a benchmark that will likely pressure security organizations to rethink how they audit critical infrastructure code.

Stay ahead of the curve. More on Linux security, AI-assisted research, and enterprise threat intelligence at NeuralWired.

Explore Security

April 30, 2026

SAP npm Supply Chain Attack 2026: Credentials Stolen

SAP npm Packages Poisoned: Credential Theft Hits CAP Devs | NeuralWired

Cybersecurity April 30, 2026 · 9 min read

SAP npm Packages Poisoned: Credential Theft Hits CAP Devs

Four widely used SAP npm packages were quietly backdoored on April 29, 2026, exposing millions of developers to a credential-stealing attack that swept up GitHub tokens, cloud secrets, browser passwords, and AI tool configurations before anyone had a chance to respond.

It took less than four hours. Between 09:55 and 14:00 UTC on April 29, 2026, a threat actor known as TeamPCP published malicious versions of four SAP npm packages that together pull over 2.25 million downloads every month. Any developer who ran npm install during that window didn’t just install a package. They handed over their credentials.

The campaign, which the attacker named “Mini Shai-Hulud” after the sandworms of Frank Herbert’s Dune universe, was uncovered by researchers at Aikido Security, Wiz Research, Socket, SafeDep, and StepSecurity. It targets the SAP Cloud Application Programming (CAP) ecosystem, meaning the victims are predominantly enterprise developers building business-critical cloud applications at some of the world’s largest companies.

The attack didn’t just steal credentials. It was engineered to spread them.

What Happened: A Four-Hour Window

Four packages received malicious updates within a single morning. All were central to SAP’s CAP framework for Node.js. All are now either deprecated or patched with clean replacement versions.

Package	Malicious Version	Safe Version	Monthly Downloads
@cap-js/sqlite	v2.2.2	v2.4.0, v2.3.0	2.25M+ (combined)
@cap-js/postgres	v2.2.2	v2.3.0	Included above
@cap-js/db-service	v2.10.1	v2.10.1 (re-published clean)	Included above
mbt (MTA Build Tool)	v1.2.48	v1.2.49	Included above

Researchers at Chainguard confirmed the combined download volume, underscoring the scale of potential exposure. The malicious versions were deprecated within roughly four hours, but in CI/CD pipelines and containerized build environments where package versions aren’t always pinned, even a narrow window causes serious damage.

Action required now: If your team ran npm install on any of these packages between 09:55 and 14:00 UTC on April 29, 2026, treat all tokens and secrets accessible from that machine as compromised. Rotate immediately and investigate second.

How the Attack Actually Worked

The technique is clean and devastating. Each malicious package version added a single line to its package.json: a preinstall hook pointing to a new file called setup.mjs. That hook fires automatically the moment anyone runs npm install. No user interaction. No confirmation prompt. No warning of any kind.

“The compromised releases added a preinstall script that acts as a runtime bootstrapper, downloading a platform-specific Bun ZIP from GitHub Releases, extracting it, and immediately executing the extracted Bun binary. The implementation also follows HTTP redirects without validating the destination and uses PowerShell with -ExecutionPolicy Bypass on Windows, increasing the risk for affected developer and CI/CD environments.”
Socket Security Research Team — The Hacker News

Choosing the Bun JavaScript runtime was deliberate. Most developer security tooling and CI/CD monitors are tuned to watch Node.js process behavior. Bun sidesteps that coverage entirely. The attacker downloaded Bun v1.3.13 directly from GitHub Releases at install time, then used it to execute the real payload: a file named execution.js.

That file is 11.6 to 11.7 megabytes of heavily obfuscated JavaScript. It’s a full credential-stealing and propagation framework, and its size alone tells you this wasn’t a script thrown together over a weekend.

The Multi-Stage Kill Chain

First, setup.mjs (4,549 bytes, shared identically across all four packages) downloads and extracts the Bun binary. Then Bun runs execution.js, which sweeps the developer’s environment systematically. Data gets encrypted using AES-256-GCM with the key wrapped in RSA-4096 using an embedded attacker public key. Only TeamPCP can decrypt what was stolen. The encrypted packages are pushed to attacker-controlled public GitHub repositories with Dune-themed names like prescient-lasgun-242 and descriptions reading “A Mini Shai-Hulud has Appeared.”

Verified SHA256 hashes for detection and incident response:

@cap-js/postgres v2.2.2:
1d9e4ece8e13c8eaf94cb858470d1bd8f81bb58f62583552303774fa1579edee

@cap-js/db-service v2.10.1:
258257560fe2f1c2cc3924eae40718c829085b52ae3436b4e46d2565f6996271

@cap-js/sqlite v2.2.2:
a1da198bb4e883d077a0e13351bf2c3acdea10497152292e873d79d4f7420211

mbt v1.2.48:
86282ebcd3bebf50f087f2c6b00c62caa667cdcb53558033d85acd39e3d88b41

setup.mjs (shared across all 4 packages):
4066781fa830224c8bbcc3aa005a396657f9c8f9016f9a64ad44a9d7f5f45e34

By the end of April 29, researchers had counted over 1,100 exfiltration repositories on GitHub. That number was still climbing when initial reports went out.

What Was Stolen: A Comprehensive Sweep

The payload didn’t target one type of credential. It swept everything a developer might have accessible from their machine or build environment. The scope is striking even by supply chain attack standards.

🔑

Git & npm Tokens

GitHub PATs and OAuth tokens via gh auth token, plus npm tokens extracted from .npmrc files and environment variables.

☁️

Cloud Provider Secrets

AWS (STS, Secrets Manager, SSM), Azure Key Vault, and GCP Secret Manager credentials all swept in a single pass.

⚙️

CI/CD Pipeline Secrets

GitHub Actions secrets extracted directly from Runner.Worker process memory. Kubernetes service account tokens also targeted.

🌐

Browser Credentials

Saved passwords from Chrome, Safari, Edge, Brave, and Chromium. A brand-new capability not seen in prior TeamPCP operations.

🤖

AI Tool Configurations

Claude config files and MCP (Model Context Protocol) configurations, enabling persistence inside AI-assisted development workflows.

“The payload is an 11.7 MB credential stealer and propagation framework. It harvests local developer credentials, GitHub and npm tokens, GitHub Actions secrets, and cloud secrets from AWS, Azure, GCP, and Kubernetes. It then exfiltrates encrypted results through public GitHub repositories.”
Raphael Silva, Security Researcher, Aikido Security — Aikido Security Blog

One feature drew particular attention from StepSecurity researchers: the malware injects a .claude/settings.json with a SessionStart hook, and a .vscode/tasks.json configured with runOn: folderOpen. Every time a developer opens the infected repository in VS Code or Claude Code afterward, the payload re-executes. StepSecurity called it one of the first attacks to specifically target AI coding agent configurations as a persistence and propagation vector.

The malware also ships with a Russian locale guardrail. If the system language or date format begins with “ru,” the stealer exits without exfiltrating anything. This type of region exclusion is a consistent marker of threat actors operating within Russian-speaking jurisdictions, and also functions as a practical legal buffer.

How the Attackers Got Publishing Access

The access method differed between the @cap-js packages and mbt, but both paths point to fundamental gaps in how modern open-source projects handle CI/CD trust.

The @cap-js Packages: An OIDC Scope Problem

Researchers at SafeDep traced the root cause to a configuration gap in how the cap-js/cds-dbs repository had set up npm’s OIDC trusted publishing. The team had migrated to OIDC in November 2025, allowing GitHub Actions to request short-lived npm tokens without storing long-lived secrets in the repository. The gap was in the scope of what the configuration trusted.

“npm’s OIDC trusted publisher configuration for @cap-js/sqlite trusted any workflow in cap-js/cds-dbs, not just the canonical release-please.yml on main. A branch push could exchange an OIDC token on behalf of the package if the workflow had id-token: write permission and the environment: npm reference.”
Leon Avalos, SafeDep — cited in The Hacker News

The attacker compromised a GitHub account called RoshniNaveenaS that held write access to the repository. They pushed a modified workflow to a non-main branch via a draft PR titled “feat: ci speedup” from a fork named gruposbftechrecruiter/harkonnen-navigator-149. The PR closed within minutes and the branch was force-pushed, wiping the diff. But the OIDC token exchange had already completed. The resulting CircleCI build logs exposed the npm publish token, GitHub token, OIDC tokens, Docker Hub credentials, and Cloud Foundry credentials before anyone could intervene.

The mbt Package: Token Compromise

For mbt, the path was simpler and murkier. Researchers suspect the cloudmtabot static npm token was compromised through a channel that hasn’t been fully identified yet. The investigation is ongoing. What’s confirmed is that the attacker held valid publish credentials for all four packages and targeted specific version numbers with precision.

Part of a Larger and Accelerating Pattern

Mini Shai-Hulud is TeamPCP’s fourth confirmed operation in roughly five weeks. The pace is notable, and each campaign has added new capabilities.

Campaign	Date	Target	Exposure Window
Checkmarx supply chain attack	March 23, 2026	Checkmarx developer tooling	Not disclosed
Trivy scanner attack	April 27, 2026	Trivy security scanner npm package	Not disclosed
Bitwarden CLI attack	April 22, 2026	Bitwarden CLI npm package	93 minutes
Mini Shai-Hulud	April 29, 2026	4 SAP @cap-js and mbt packages	~4 hours

Attribution across all four campaigns was confirmed by Wiz Research through a shared RSA public key alongside overlapping encoding routines and region guardrails. The actor is also tracked under the aliases DeadCatx3, PCPcat, and ShellForce, per SecurityWeek’s tracking of the group.

“A new supply chain operation from TeamPCP calling itself ‘Mini Shai Hulud’ compromised SAP-related npm packages by injecting malicious preinstall scripts that execute during dependency installation. TeamPCP is very likely responsible for this campaign, based on a shared RSA public key and overlaps in encoding routines and region guardrails.”
Wiz Research Team, Wiz (Google-owned) — Wiz Research Blog

The broader trend adds weight. According to PkgPulse’s trend analysis, npm supply chain attacks roughly tripled between 2022 and 2025. TeamPCP didn’t cause that trend, but they’re currently its sharpest expression. It’s also worth noting that SAP’s own April 2026 security patch cycle released 19 new security notes including a CVSS 9.9-rated SQL injection in SAP BPC and BW, per SAP Insider. Enterprise SAP environments were already under pressure from the vendor side before this npm campaign landed.

What Affected Teams Should Do Right Now

Remediation isn’t just about updating package versions. If the malicious version ran in your environment, you have a credential exposure problem, not a package problem. The Sophos CTU Research Team was direct: investigate whether compromised versions were installed, review all GitHub, npm, and cloud activity tied to potentially exposed credentials, and rotate anything that may have been accessible.

Check your package-lock.json and build logs for the malicious version numbers: @cap-js/sqlite v2.2.2, @cap-js/postgres v2.2.2, @cap-js/db-service v2.10.1, and mbt v1.2.48.
Compare installed tarballs against the SHA256 hashes listed in the infobox above. A match confirms the payload executed on that machine.
Rotate all GitHub tokens, npm tokens, and cloud provider credentials accessible from any affected build environment. Don’t wait to confirm; rotate first, investigate second.
Search your GitHub organization’s audit log for the commit message keyword OhNoWhatsGoingOnWithGitHub. This is the propagation dead-drop marker the malware uses for token exchange between infected systems.
Check for injected .claude/settings.json and .vscode/tasks.json files in repositories recently touched from affected machines. These are the persistence hooks.
Review browser credential stores on developer machines that ran the malicious install, specifically Chrome, Safari, Edge, Brave, and Chromium password managers.
Update all affected packages to their clean versions and enforce explicit version pinning across your dependency tree going forward.

For teams working on CI/CD pipeline security hardening, this incident is a live case study in why preinstall script auditing needs to be part of every build pipeline by default. The npm ecosystem doesn’t sandbox lifecycle scripts, doesn’t prompt for confirmation, and grants full system access by default. That architecture hasn’t changed in years.

Frequently Asked Questions

What is the Mini Shai-Hulud npm supply chain attack?

Mini Shai-Hulud is a supply chain attack that injected malicious preinstall scripts into four SAP npm packages on April 29, 2026. When developers installed the compromised versions, the scripts automatically downloaded and executed a credential-stealing payload that harvested GitHub tokens, cloud secrets, and browser passwords without any user interaction.

Which SAP npm packages were compromised?

The four affected packages were @cap-js/sqlite (v2.2.2), @cap-js/postgres (v2.2.2), @cap-js/db-service (v2.10.1), and mbt v1.2.48. All are part of the SAP Cloud Application Programming (CAP) framework used widely in enterprise Node.js development. Clean replacement versions are now published on npm.

How long were the malicious packages available to download?

The malicious versions were live for approximately four hours, between 09:55 and 14:00 UTC on April 29, 2026. Any npm install that pulled these specific version numbers during that window should be treated as a confirmed execution of the credential-stealing payload.

Who is TeamPCP and what other attacks have they conducted?

TeamPCP is the threat actor behind Mini Shai-Hulud, also operating under aliases DeadCatx3, PCPcat, and ShellForce. Researchers linked them to three prior supply chain operations in 2026: a March 23 attack on Checkmarx tooling, an April 22 attack on Bitwarden CLI (93-minute exposure), and an April 27 attack on the Trivy security scanner npm package.

Why did the attacker use the Bun runtime instead of Node.js?

Bun is a newer JavaScript runtime that most security monitoring tools and endpoint agents don’t watch as closely as Node.js. By downloading and invoking Bun at install time, the attacker bypassed process-level monitoring that would typically flag unusual Node.js behavior in developer and CI/CD environments.

What is the OIDC misconfiguration that enabled the attack?

The @cap-js packages used npm’s OIDC trusted publishing system, which should restrict token exchange to specific approved workflows on the main branch. The configuration instead trusted any workflow in the repository. An attacker with write access to any branch could trigger a legitimate OIDC token exchange and use it to publish malicious package versions.

How does the malware maintain persistence after the initial infection?

The payload injects a SessionStart hook into .claude/settings.json and a folderOpen trigger into .vscode/tasks.json. This means the malicious code re-executes every time the infected repository is opened in VS Code or Claude Code, continuing to harvest any new credentials added to the environment after the initial compromise.

What should I check to confirm whether my environment was affected?

Check your package-lock.json and build logs for the malicious version numbers listed above. Compare installed tarballs against the SHA256 hashes provided by Wiz Research. Also search your GitHub commit history for the string OhNoWhatsGoingOnWithGitHub, which is the propagation marker the malware embeds to signal infected environments to the attacker.

The Bigger Picture: Trust Is the Attack Surface

The Mini Shai-Hulud attack is a study in how trust chains collapse at scale. SAP developers trusted @cap-js/sqlite because it had millions of downloads and came from a recognized source. npm users trusted the preinstall hook because it’s a standard part of the package specification. CI/CD pipelines trusted the OIDC token exchange because it was explicitly configured to be trusted. At every step, a legitimate mechanism became an attack vector.

The credential theft is serious enough on its own. But the propagation design is what should concern security teams most. Stolen GitHub tokens don’t just expose the original victim. They expose every repository that token can reach, every pipeline it can trigger, and every secret those pipelines can access. The attacker built a cascading compromise engine, not a one-shot stealer.

For the broader npm ecosystem, supply chain security has moved from secondary concern to first-tier priority. Postinstall and preinstall scripts are the single most-exploited vector in npm compromises. That’s been documented since the 2018 event-stream incident. The npm runtime still doesn’t sandbox them, still doesn’t prompt for confirmation, and still grants full system access by default. What has changed is the sophistication of the actors who know exactly how to exploit it.

TeamPCP has now run four confirmed operations in five weeks, and each campaign adds new capabilities. Browser credential theft wasn’t in their prior toolkit. Targeting AI coding tool configurations is genuinely novel territory. For organizations running SAP enterprise environments, the immediate priority is investigation and credential rotation. For everyone else, this is a concrete reminder that your software supply chain security is only as strong as the weakest OIDC configuration in your entire dependency graph.

Watch For

01 TeamPCP’s fifth campaign. The group has run four attacks in five weeks, with each iteration adding new capabilities. A follow-on operation targeting another high-download npm ecosystem is likely within days to weeks.

02 npm’s response to OIDC scope enforcement. SafeDep’s disclosure revealed a structural gap in how npm’s trusted publishing validates workflow scope. Watch for a policy update restricting OIDC token exchange to specific branches and workflow files only.

03 Secondary breaches from stolen tokens. With over 1,200 exfiltration repositories created and GitHub tokens from enterprise SAP environments harvested, downstream compromises of internal repositories and cloud accounts may surface over the coming weeks.

04 AI coding tool attack surface expansion. Injecting persistence hooks into Claude Code and VS Code configurations is a first for this actor. Expect other threat groups to adopt this technique as AI-assisted development becomes more deeply embedded in enterprise software workflows.

Stay ahead of the curve. More on cybersecurity, supply chain threats, and developer security at NeuralWired.

Explore Cybersecurity

April 30, 2026

Category: Cybersecurity

How to Prevent Ransomware Attacks in 2026: The Complete IT Manager’s Guide

What Is Ransomware and Why Is 2026 Different?

The Rise of AI-Powered Ransomware

Ransomware-as-a-Service Has Industrialized

How Ransomware Attacks Work in 2026 (Step-by-Step)

How to Prevent Ransomware Attacks: 10 Proven Controls

Patch Edge Devices First — VPNs, Firewalls, Gateways

Deploy Phishing-Resistant MFA — Not SMS, Not Authenticator Apps

Implement Zero Trust Architecture

Maintain Immutable, Air-Gapped Backups

Use Behavioral EDR — Not Signature-Based Antivirus

Segment Your Network (Micro-Segmentation)

Control Third-Party and MSP Access

Run Quarterly Ransomware Tabletop Exercises

Develop and Test Your Incident Response Plan

Monitor for Data Exfiltration — Not Just Encryption

What Industries Are Most at Risk from Ransomware in 2026?

Should You Pay the Ransom?

What to Do After a Ransomware Attack

Ransomware Prevention Checklist — Print and Post This

Identity and Access

Network and Perimeter

Endpoint and Detection

Data and Backup

Process and Readiness

Frequently Asked Questions About Ransomware Prevention

The Neural Loop — Free Weekly Security Intelligence

Zero Trust Security: Why “Never Trust, Always Verify” Is Winning the Cybersecurity War

What Zero Trust Security Actually Means

How It Works: The Five Pillars

The VPN vs. ZTNA Distinction

Why Zero Trust Is Winning Now

The Perimeter Collapsed

Remote Work Killed the Network Edge

The U.S. Government Made It Mandatory

The Implementation Gap: 72% Planning, 30% Doing

The Hard Truth: What Zero Trust Can’t Do

The Vendor Exploitation Problem

MFA Is Not Impenetrable

The Academic Challenge: Is True Zero Trust Even Achievable?

The Friction-Shadow IT Paradox

What’s Changing in 2025–2026

AI Integration

Post-Quantum Cryptography

Frequently Asked Questions

What You Now Know That Most Organizations Don’t Act On

Stay Sharp on What’s Next

ShinyHunters Breaches Instructure’s Canvas: 275 Million Student Records Stolen in Education’s Worst Data Catastrophe

What Happened: A Supply-Chain Attack on Global Education

Instructure’s Incident Timeline

Who Are ShinyHunters, and Why Does It Matter?

Why Canvas Is Such a High-Value Target: The Multi-Tenancy Problem

How the Instructure Breach Compares to Other Major Incidents

Instructure’s Response: What CISO Steve Proud Said

What Students, Teachers, and IT Teams Should Do Right Now

Instructure Has a Posture Problem, Not a Luck Problem

People Also Ask

DeFi’s $292M Bridge Crisis: How One Validator Flaw Drained a Protocol in 46 Minutes

Anatomy of the Attack: Not a Contract Bug

Why This Attack Is More Dangerous Than a Smart Contract Bug

The Scale of DeFi’s Bridge Problem

The Path Forward: What Actually Fixes This

Multi-DVN consensus: the immediate fix

ZK-light clients: the cryptographic long game

Cross-chain invariant monitoring

Canonical bridges for high-value assets

What Builders Must Do Now

Frequently Asked Questions

The Bridge Problem Isn’t Going Away

PyTorch Lightning Hijacked: 16M Monthly Downloads Exposed to Credential-Stealing Malware

What Happened on April 30

Inside the Malware: A Multi-Stage Credential Harvester

Stage One: The Launcher

Stage Two: The 11 MB Payload

Stage Three: Credential Validation and Exfiltration

Stage Four: Repository Poisoning

Detection in 18 Minutes, and the Response That Followed

Understanding the Scale of the Risk

Connecting the Dots: Mini Shai-Hulud and TeamPCP