Tag: Cybersecurity

Predictive autonomous defense, Zero Trust architecture, Identity Threat Detection, and AI-against-AI security frameworks.

PaperCut AI Attack 2026: 440 Orgs Hacked, Patch Now

Cybersecurity September 12, 2026 · 11 min read

PaperCut AI Attack Hits 440 Orgs: What to Patch Now

An AI agent chained two PaperCut flaws to breach 440 print management systems across 48 countries, compromising 11 organizations in 26 seconds flat, and researchers say old fashioned defenses still stopped it cold.

A PaperCut AI attack campaign has compromised at least 440 instances of the popular print management software across 395 organizations in 48 countries, according to a technical disclosure from GreyNoise’s “Agents Gone Wild” report published September 9, 2026. The campaign chains two newly disclosed vulnerabilities, CVE-2026-81578 and CVE-2026-82078, and hands most of the exploitation work to an autonomous AI agent rather than a human operator sitting at a keyboard.

What makes this campaign different isn’t the bug class. Authentication bypasses and unsafe class loading are old problems. It’s the speed. GreyNoise documented one target going from an empty attack workspace to real world remote code execution in under four hours, with domain administrator access following roughly two hours after that. Once the campaign moved from testing to mass exploitation, 11 organizations were compromised in 26 seconds.

Nearly half of the confirmed victims, 204 of 440, sit in the education sector, a skew researchers attribute to PaperCut’s customer concentration in schools and universities rather than deliberate targeting. K-12 districts and major U.S. universities have already confirmed exploitation, per TheHackerNews’s coverage of the campaign, and CISA has given federal agencies until September 14, 2026 to remediate both flaws.

What Happened, in Order

The timeline reads fast even by 2026 standards. Huntress detected the first real world attack activity on August 26 and reproduced a full pre-auth remote code execution chain in its own lab within hours. PaperCut published its first emergency bulletin the next day, confirming active exploitation against customers.

The vendor’s first patch didn’t hold. Attackers found a bypass within days, forcing a second emergency release. By August 31, CISA had added both CVEs to its Known Exploited Vulnerabilities catalog with a September 14 remediation deadline for federal systems. GreyNoise says the AI orchestrated wave of attacks began that same day, from a single IP address it has since attributed to the campaign.

Federal deadline: CISA’s KEV listing sets September 14, 2026 as the hard remediation date for U.S. federal agencies running PaperCut NG or MF. Private-sector IT teams are treating it as the de facto industry deadline too.

PaperCut shipped a third emergency patch release on September 1 after researchers found additional attack paths in the second fix. Arctic Wolf confirmed active exploitation against education sector targets on September 5. GreyNoise’s full technical writeup landed September 9, and by September 10 and 11, BleepingComputer, TheHackerNews, and a wave of other outlets had made it the week’s dominant cybersecurity story.

The Two Flaws PaperCut Missed

Two separate bugs make the full attack chain possible. Neither is exotic on its own, but chained together they hand an unauthenticated attacker complete control of the server.

Detail	CVE-2026-81578	CVE-2026-82078
Severity (CVSS v4.0)	8.8 (High)	9.4 (Critical)
Type	Authentication bypass	Unsafe dynamic class loading
Root cause	CWE-305 “Tapestry request confusion” in the Apache Tapestry framework PaperCut is built on	Database driver classes loaded by configurable name with no allowlist check
Effect	Unauthenticated requests can trigger admin functions	Attacker controlled config leads to arbitrary Java execution
Fixed in	24.1.10, 25.0.13, 26.0.5	24.1.10, 25.0.13, 26.0.5

The Tapestry flaw validates the page a request renders rather than the underlying action it triggers, which lets an attacker slip an admin level command past the login wall entirely. Once inside, the second bug lets that attacker point PaperCut’s database connector at an arbitrary Java class, achieving code execution under the PaperCut server process’s own security context. No credentials required at any step.

Inside the AI Attacker’s Toolkit

GreyNoise’s telemetry, pulled from its Global Observation Grid sensor network, gives an unusually granular look at how the campaign was actually built. The attacker didn’t write custom exploit code by hand and didn’t rely on a single AI model to do everything.

Orchestration: OpenAI’s Codex, used purely as agent scaffolding to sequence tasks, not to generate exploit code.
Exploit writing: A DeepSeek model, which GreyNoise says the attacker chose specifically because it lacks the offensive security content restrictions U.S. frontier labs build into their models.
Reconnaissance: The Netlas.io internet scanning API, used to build target lists from a compromised or self obtained API key.
Post-exploitation: Publicly available tools, including Mimikatz, SharpHound, Certipy, BloodHound, Rubeus, Impacket, NetExec, and Ligolo-ng, pulled live from public GitHub repositories.

“Despite U.S.-based frontier model guardrails, adversaries are using a variety of large language models to conduct intrusions globally.”
GreyNoise Research Team, Global Observation Grid, GreyNoise blog

GreyNoise attributes the campaign to a likely Russian speaking actor, at medium confidence, based partly on a 28 country avoid list topped by Russia, China, Hong Kong, Thailand, and Iran, plus most CIS states. Notably, the agent’s own avoid list failed in several of those countries anyway, a detail GreyNoise flags as evidence that agentic operations can deviate from their intended parameters even when the operator tries to control them.

The model choice question echoes a debate NeuralWired has tracked closely on the defender side too. OpenAI’s own first “Critical” rated model carries far tighter usage restrictions than the DeepSeek model chosen here, and reporting on gaps in frontier lab oversight shows why attackers keep finding a less restricted option to route around rather than trying to jailbreak a guarded one.

Three Paths to Domain Admin

🔑

Path A: Pass the Hash

LSASS memory and registry secrets harvested locally, then replayed against the domain controller.

🧩

Path B: noPac

The known CVE-2021-42278/CVE-2021-42287 chain, still effective against unpatched Active Directory environments.

👑

Path C: Direct Creation

A new domain admin account created outright, when the compromised host was itself the domain controller.

Every successful path ended the same way: a DCSync attack pulling a full NTDS.DIT credential dump for exfiltration, effectively handing the attacker every password hash in the domain at once.

The Numbers Behind the Panic

Speed is the headline, but the funnel matters more than the fastest single case. Credential harvesting was observed at 280 of the 440 compromised instances. Operating system or domain secrets were pulled at 147. Full domain administrator access, the worst possible outcome, was reached at only 12 organizations.

Defense still works: GreyNoise confirmed at least one target’s Cloudflare web application firewall fully defeated the AI driven attack chain before it could progress. Basic network hardening remains an effective control against agentic attackers, not an obsolete one.

Context from outside the PaperCut campaign backs up the speed numbers rather than contradicting them. Anthropic’s own September 2026 threat intelligence report, published one day before GreyNoise’s writeup, disclosed banning 832 accounts for malicious cyber activity between March 2025 and March 2026, with 67.3% of those, 560 accounts, showing evidence of AI assisted attack preparation. Anthropic itself frames that figure as a self selected enforcement sample, not a population level measurement.

CrowdStrike’s 2026 Global Threat Report puts a wider frame around the same trend, recording AI enabled adversary activity up 89% year over year, with 82% of detections involving no malware at all, just stolen credentials, and a fastest recorded breakout time of 27 seconds. Separately, the World Economic Forum’s Global Cybersecurity Outlook 2026 found 94% of surveyed cyber leaders already call AI the single biggest driver of change in their field.

What Researchers Are Actually Saying

Not every voice in this story is willing to over-narrate what happened. Blackpoint Cyber, which independently confirmed parts of GreyNoise’s findings, is notably cautious about the attacker’s end goal.

“At this time, we cannot confirm the exact end goal of this campaign.” The methodology “is consistent with initial access activity, but we do not yet have sufficient evidence to confirm whether they are operating as an initial access broker.”
Nevan Beal, Principal MDR Analyst, Blackpoint Cyber, TheHackerNews

The clearest pushback on the “AI changes everything” framing comes from Nathan House, founder and CEO of StationX, a cybersecurity training firm, and a working practitioner with three decades in the field.

“When a number can’t survive a click to its origin, it’s marketing. The verified data shows AI rising in attacker tooling. The recycled data inflates that into a tidal wave. Both things are true at once, and only one belongs in your threat model.”
Nathan House, Founder & CEO, StationX, StationX

House points out that Anthropic’s own numbers actually show AI assisted phishing falling 8.6% over the same study period, even as AI use shifted deeper into post compromise account discovery, which rose 8.9%. That complicates any narrative that AI attacks are simply exploding across every category at once.

Jacob Klein, Anthropic’s head of threat intelligence, offers a similar note of caution when describing how his own team evaluates misuse cases, in comments made about adjacent bioweapons related findings in the same report.

“You are not seeing someone in a comic book kind of way say, ‘Hey, I want to build a biological weapon to kill everybody.’ It’s an incredibly nuanced situation.”
Jacob Klein, Head of Threat Intelligence, Anthropic, La Voce di New York

Read together, these voices point to a specific, narrower conclusion than the loudest headlines suggest. The GreyNoise report itself is primary source, IOC backed, and independently corroborated. But the leap from “the attacker picked an uncensored model” to “a coming safety shopping economy” is analyst interpretation layered on top of solid data, not a claim GreyNoise makes as a general trend. Overstating that leap risks pushing policy conversations toward restricting model access broadly, when the controls that actually worked here, CISA’s KEV listing driving urgency, a web application firewall, and basic credential rotation, had nothing to do with which language model the attacker used.

It’s also worth remembering that this campaign didn’t start with AI. GreyNoise’s four hour and 26 second statistics describe the deployment phase. A skilled human operator still had to find and weaponize both CVEs before any agent was turned loose, work that closely echoes Anthropic’s earlier disclosure of a largely autonomous, state sponsored Claude Code campaign against roughly 30 organizations in November 2025. This is the clearest criminal, financially motivated follow-on to that pattern, and the largest one yet by victim count.

What IT Teams Should Do Now

PaperCut has a history here. A 2023 exploitation chain, CVE-2023-27532, previously led to extortion campaigns, and defenders are watching this one for the same pattern. The response checklist is straightforward, even if the timeline to act on it is not.

Confirm every PaperCut NG/MF instance is on Emergency Patch Release 3, versions 24.1.10, 25.0.13, or 26.0.5 or later.
Remove PaperCut’s web management interface from direct internet exposure and put it behind a VPN or firewall allowlist.
Rotate every credential on any PaperCut host that touched the internet between August 31 and September 9, since harvested credentials remain valid until manually changed.
Treat any print or asset management server with SYSTEM level Windows privileges and Active Directory integration as a Tier 0 asset, regardless of its perceived business importance.
If your PaperCut deployment is still on version 23 or earlier, isolate it now. Huntress data shows 47% of roughly 2,500 tracked installations remain on that unpatched branch, which has no fix available.

ShadowServer’s internet-wide scanning still counted more than 1,000 PaperCut NG/MF instances exposed directly to the internet as of early September, weeks into the patch cycle. That number, not the AI angle, is the more actionable warning for most security teams this week.

Frequently Asked Questions

What is CVE-2026-81578?

CVE-2026-81578 is a high severity (CVSS 8.8) authentication bypass in PaperCut NG/MF’s web management interface, disclosed August 27, 2026. It lets unauthenticated attackers modify server configuration and, when chained with CVE-2026-82078, achieve full remote code execution. CISA added it to its KEV catalog August 31, 2026.

How many organizations were affected by the PaperCut AI attack?

GreyNoise confirmed at least 440 compromised PaperCut instances across 395 identified organizations in 48 countries, with credential harvesting at 280 victims and full domain administrator access achieved at 12 organizations, as of its September 9, 2026 report.

Why did the PaperCut attacker use DeepSeek instead of ChatGPT?

GreyNoise’s analysis states the attacker used a DeepSeek model specifically because it lacks the offensive security content restrictions imposed by U.S. frontier labs like OpenAI and Anthropic, while using OpenAI’s Codex only as an orchestration harness, not for exploit generation.

Is PaperCut safe to use in 2026?

PaperCut NG/MF is safe if fully updated to Emergency Patch Release 3, versions 24.1.10 or higher, 25.0.13 or higher, or 26.0.5 or higher, and not exposed directly to the internet. Roughly 47% of tracked installations still run version 23 or earlier, which has no available patch and should be isolated immediately.

How fast can AI agents hack a company?

In the PaperCut campaign, GreyNoise documented AI agents achieving remote code execution against a real victim in under four hours from a standing start, domain administrator access as fast as five minutes after initial access, and 11 separate organizations compromised within 26 seconds once the full campaign launched.

Did traditional security tools stop the AI-driven attack?

Yes, in at least one confirmed case. GreyNoise reported that a target’s Cloudflare web application firewall fully blocked the AI orchestrated attack chain, showing that conventional hardening, network segmentation, and credential hygiene still function against agentic AI attackers.

What is the CISA KEV deadline for PaperCut?

CISA added CVE-2026-81578 and CVE-2026-82078 to its Known Exploited Vulnerabilities catalog on August 31, 2026, setting September 14, 2026 as the remediation deadline for U.S. federal agencies. Most private-sector security teams are treating it as the practical industry deadline as well.

Conclusion: A Faster Clock, Not a New Rulebook

The PaperCut campaign is genuinely new in one respect: it’s among the first disclosures to put a stopwatch on an AI driven intrusion, from empty workspace to domain admin, with minute-by-minute telemetry instead of a summary statistic. That level of detail is exactly why this story is outperforming last year’s AI hacking headlines in pickup and search interest.

But the underlying lesson is closer to an update than a rewrite. The bugs are conventional. The privilege escalation paths, pass the hash, noPac, direct account creation, are all years old. What changed is how little time defenders now have between disclosure and exploitation at scale. Patch cadences built around weeks no longer match a threat model built around hours.

Watch For

01 Whether the September 14, 2026 CISA KEV deadline actually drives federal remediation, or whether a meaningful share of the roughly 1,000 exposed instances ShadowServer found are still online after the date passes.

02 The durable, unpatchable population running PaperCut version 23 or earlier, currently 47% of Huntress’s tracked base, which has no fix path and will remain a target indefinitely.

03 Whether the “model shopping” narrative around DeepSeek hardens into export control or procurement policy debates that target model access broadly, rather than the patch management fundamentals that actually stopped this campaign in at least one confirmed case.

Stay ahead of the curve. More on AI security and threat intelligence at NeuralWired.

Explore Cybersecurity

September 12, 2026

Generative AI in Cybersecurity: IBM’s 2026 Threat Reality

Generative AI in Cybersecurity 2026: The Weapon Defending and Attacking You at the Same Time

Cybersecurity Intelligence / Deep Analysis

Generative AI in Cybersecurity: The Weapon Defending and Attacking You at the Same Time

Generative AI has fractured cybersecurity into two simultaneous realities. It is the most powerful defensive tool deployed at enterprise scale, and the cheapest offensive weapon ever handed to criminals. Here is the honest picture, with numbers.

By NeuralWired Research Desk • Published: May 31, 2026 • Last Updated: May 31, 2026 • 14 min read

$12.87B GenAI Cybersecurity Market 2025

5 min To craft an AI phishing email (was 16 hrs)

80 days Shorter breach lifecycle with AI defense

94% Of security leaders say AI is #1 change driver

The Core Paradox of 2026

A financial services firm in Frankfurt tightened its breach lifecycle by 80 days last year. Its AI-powered security operations center caught a credential-stuffing campaign at 2 a.m. with no human analyst in the loop. The same quarter, one of its treasury executives received a video call from what appeared to be the CFO, instructing a wire transfer. The voice was real. The face was real. Neither was human.

This is the defining tension of generative AI in cybersecurity right now. The same technology compressing your incident response timeline is compressing an attacker’s phishing production pipeline. The World Economic Forum Global Cybersecurity Outlook 2026, drawing on 804 respondents across 92 countries including 316 CISOs, found that 94% of security leaders identify AI as the most significant driver of change in their field. The same report found that 87% flagged AI vulnerabilities as the fastest-growing cyber risk throughout 2025.

Both numbers refer to the same technology. That is not a contradiction. That is the story.

Our Read

This signals something the vendor community is reluctant to say plainly: investing in AI for defense does not reduce your exposure to AI as an attack vector. It changes the nature of the fight. Organizations that grasp this distinction will build genuinely resilient security postures. Those chasing “AI-powered security” as a procurement category will be left exposed in ways their tools cannot detect.

How Generative AI Is Used in Cybersecurity

Generative AI in cybersecurity refers to the application of large language models and generative systems to automate threat detection, accelerate incident response, generate synthetic attack scenarios for red teaming, analyze vulnerabilities, and craft adaptive security policies. It powers security operations centers (SOCs) by triaging alerts, reducing analyst workload, and identifying anomalous behavior in real time. (Sources: IBM, Fortinet, WEF GCO 2026)

On Defense: What the Numbers Actually Show

The IBM Cost of a Data Breach Report 2025, now in its 20th year and covering 600 organizations across 17 industries and 16 countries, produced the most credible measurement of AI’s defensive ROI to date. Organizations using AI extensively in their security operations cut their breach lifecycle by 80 days and saved nearly $1.9 million on average per breach, compared to organizations that did not.

The global average breach cost fell 9% to $4.44 million in 2025, the first decline in five years. That is the headline. The subtext is more important: the U.S. average breach cost rose to a record $10.22 million, up from $9.36 million in 2024. The organizations pulling the average down are those investing in AI-augmented detection and response. The ones pulling it up are those that are not.

Specific Use Cases That Are Working Now

Across platforms from IBM Security QRadar to CrowdStrike and Palo Alto Networks (named by MarketsandMarkets as the dominant players in this market), the applications generating real operational value in 2026 include the following.

Use Case	What It Does	Maturity Level
AI-assisted alert triage	Filters noise, prioritizes high-fidelity incidents, reduces analyst fatigue	Production-ready now
GenAI phishing detection	Identifies AI-crafted emails via behavioral and linguistic pattern analysis	Production-ready now
Synthetic red teaming	Generates adversarial attack scenarios at scale for penetration testing	Production-ready now
Vulnerability auto-remediation	Identifies and patches insecure code in development pipelines	Scaling fast (Gartner: 40% of dev teams by end of 2026)
Autonomous SOC response	Full end-to-end incident containment without human input	Aspirational. 3 to 5 years from reliable deployment.

Gartner projects that by the end of 2026, 40% of development teams will routinely use AI-based auto-remediation for insecure code. That figure was under 5% in 2023. The acceleration is real. So is the risk it carries.

AI Cybersecurity Threats 2026: How Attackers Are Using It

One statistic from IBM’s 2025 breach report has become the most visceral data point in enterprise security conversations this year. Generative AI has reduced the time required to craft a convincing phishing email from 16 hours to 5 minutes. That is not an incremental efficiency gain. It is a structural change to the economics of social engineering at scale.

According to IBM’s findings, 1 in 6 breaches in 2025 involved attackers using AI. Phishing was the primary method at 37% of AI-assisted attacks, followed by deepfake impersonation at 35%. These are the first statistics of their kind at scale, and they represent a floor, not a ceiling.

“Defenders will likely see threat actors use agentic AI in an automated fashion as part of intrusion activities, continue AI-driven phishing campaigns, and continued development of advanced AI-enabled malware. They’ll use agentic AI to implement hacking agents that support their campaigns through autonomous work.”
Alex Cox, TIME Director and AI Working Group Lead, LastPass (TechNewsWorld, January 2026)

The Speed Problem Is Now Structural

FortiGuard Labs’ 2025 cyberthreat data shows that newly discovered vulnerabilities are now being weaponized in an average of 4.76 days, a 43% increase in speed compared to prior periods. The window between a CVE being published and an attacker having a working exploit is now smaller than most organizations’ patch cycles by a significant margin.

This is where generative AI’s role in offense is most concrete and most dangerous. It is not creating fundamentally new classes of malware (the Picus 2025 Red Report found no notable uptick in AI-driven malware innovation in 2024). It is compressing the timeline of every phase of an attack, from reconnaissance to exploitation to lateral movement.

Critical Risk Flag

Deepfake executive impersonation is now technically feasible at enterprise scale according to Palo Alto Networks’ 2026 cybersecurity predictions. Real-time AI video and voice replicas of your C-suite require organizations to retire any multi-factor authentication method tied to voice or video verification immediately. This is not a 2027 concern.

Shadow AI: The $670,000 Threat Nobody Is Governing

Shadow AI refers to the unauthorized use of AI tools such as ChatGPT, Claude, or Gemini by employees without IT approval or oversight. It creates security risk because sensitive data may be uploaded to external platforms without data loss prevention controls in place. IBM’s 2025 breach data found that shadow AI adds an average of $670,000 to breach costs per incident, placing it among the top three costliest breach factors, displacing skills shortages from that position for the first time.

13% of organizations in IBM’s study experienced AI-specific breaches. Of those, 97% lacked basic security controls for their AI systems at the time of breach. Role-based access governance, data classification, and output monitoring were absent in nearly every case.

Shadow AI is no longer an HR policy issue. It is a board-level financial governance issue. If that framing hasn’t reached your leadership team yet, the IBM numbers are the vehicle.

You can read more about AI system integrity risks and the specific failure modes of autonomous AI systems in NeuralWired’s analysis of AI agent document corruption, which details exactly how unsanctioned agentic systems corrupt enterprise data flows in ways that are difficult to detect and expensive to remediate.

What the WEF Data Shows

64% of organizations are now assessing the security of AI tools before deployment, up from 37% in 2025 according to the WEF Global Cybersecurity Outlook 2026. Governance is accelerating. But 36% of organizations are still deploying AI tools with no formal security assessment. In a market where shadow AI already costs an average of $670,000 per breach, that gap represents enormous, quantifiable financial risk.

Agentic AI and the Next Escalation

Agentic AI in cybersecurity refers to AI systems that autonomously execute multi-step tasks including scanning for vulnerabilities, crafting exploits, or orchestrating attack campaigns without constant human direction. In 2026, both defenders and attackers are integrating agentic AI: defenders for autonomous SOC response and threat hunters, threat actors for fully automated intrusion operations. (Sources: OWASP, WEF 2026, Darktrace)

Darktrace’s State of AI Cybersecurity 2026 report, drawing on more than 1,500 security leaders, captures the shift in a single sentence: 2025 was the year enterprise AI went mainstream; 2026 is when it became a full-scale attack surface.

The deployment of Anthropic’s Project Glasswing, a restricted frontier model with autonomous zero-day research capability deployed with a small set of trusted infrastructure organizations before any public release, represents a strategic threshold. AI can now autonomously discover zero-day vulnerabilities. The question for every CTO in critical infrastructure is: when adversaries gain access to comparable models, what is your baseline threat assumption?

A concrete illustration of the speed at which AI-powered vulnerability discovery operates: as detailed in NeuralWired’s coverage of CVE-2026-31431, AI found a 9-year-old Linux kernel vulnerability in under one hour. Nine years of human security review missed it. That is not a niche benchmark. That is a preview of what autonomous AI exploit research means at scale for every organization running Linux infrastructure.

“I expect the sophistication and intensity of cyber threats will continue to increase, as they have year over year. The ever-expanding tech landscape and rise of Adversarial AI means cybersecurity is not just about protecting business value anymore. It’s now a fundamental driver.”
Adnan Amjad, US Cyber Leader and Partner, Deloitte & Touche LLP

The Case Against the Hype

If you’ve sat through a vendor briefing in the past 12 months, you’ve heard the “AI versus AI cyberwar” framing. It is compelling. It also contains a significant amount of motivated reasoning.

Cybercriminals Are Not Adopting AI as Fast as the Headlines Suggest

Sophos X-Ops research published in January 2025, based on direct investigation of multiple underground criminal forums, found that criminals are still largely skeptical of generative AI. Most criminal AI use is limited to bulk email generation and data analysis. Novel attack classes powered by AI remain rare. The Picus 2025 Red Report, cited by Ivanti, found no notable uptick in AI-driven malware techniques in 2024, stating directly that “AI enhances productivity but doesn’t yet redefine malware.”

The practical implication: vendors are financially incentivized to overstate offensive AI capability to justify defensive AI spending. At least half of the AI-versus-AI cyberwar narrative in circulation right now is marketing material dressed as threat intelligence.

AI Security Tools Create Blind Spots the Industry Isn’t Discussing

VikingCloud’s October 2025 analysis details a specific and underreported risk. Adversarial machine learning can be used to attack AI security tools themselves through crafted inputs designed to deceive AI classifiers, allowing malware to pass through undetected. Data poisoning attacks can corrupt the training datasets those AI tools depend on, creating systemic blind spots that are invisible to the defenders relying on the system.

AI hallucinations in security contexts add another dimension. Based on Artificial Analysis’s AA-Omniscience benchmark covering 40 AI models, all but four were more likely to provide a confident, incorrect answer than a correct one on difficult questions. In a SIEM or incident response workflow, a confidently wrong AI verdict doesn’t just delay response. It actively misdirects it. The Hacker News covered this emerging risk in May 2026, noting it is almost entirely absent from vendor marketing materials.

“As with many other things in life, the mantra should be ‘trust but verify’ regarding generative AI tools. We have not actually taught the machines to think; we have simply provided them the context to speed up the processing of large quantities of data. The potential of these tools to accelerate security workloads is amazing, but it still requires the context and comprehension of their human overseers for this benefit to be realized.”
Chester Wisniewski, Director and Global Field CTO, Sophos

Nearly Half of AI-Generated Code Is Already Shipping Vulnerabilities

This may be the most underappreciated structural risk in enterprise security today. According to Krishna Vishnubhotla, VP of Product Strategy at Zimperium, writing in TechInformed in December 2025: “Nearly half of AI-generated code contains security flaws. We will see more vulnerabilities pushed into production, not fewer.”

If your engineering teams are using GitHub Copilot, Cursor, or any AI coding assistant at scale (and they are), the velocity gains from those tools may be offset or exceeded by downstream remediation costs from the vulnerabilities they ship. This is detailed further in NeuralWired’s analysis of why AI agents fail in production, which covers the specific failure modes that create enterprise security exposure.

“Many people have a huge incentive to keep building the infrastructure, but the vibe has changed. Loans will get more expensive, stock prices are coming down, and profits (except for Nvidia) are few and far between.”
Gary Marcus, NYU Professor Emeritus and AI Critic, co-founder of Robust.AI (Dark Reading, December 2025)

Marcus is making a broader economic argument: the AI cybersecurity vendor landscape is being propped up by a capital environment that may not persist. Arkose Labs’ 2025 AI Maturity in Cybersecurity Report found that only about half of enterprises had realized measurable benefits from AI security investments despite widespread adoption. The governance gap widens faster than deployment in too many organizations.

What Security Engineers Must Do Now

The attack surface now includes the AI stack itself. Every LLM, API integration, plug-in connection, and training pipeline your organization runs is a software layer that must be audited, tested, and governed like any other. If you’re building or maintaining security infrastructure, here is what requires action before the next quarter closes.

Priority Action: Shadow AI Audit

Conduct a full inventory of every AI tool accessing company data across all departments. Engineering, HR, finance, and legal are the highest-risk vectors. Do not assume IT-approved tools are the only ones in use. They are not, and IBM’s 2025 data puts the average cost of getting this wrong at $670,000 per breach.

Beyond shadow AI, there are four actions that move the needle on genuine risk reduction right now.

First, evaluate AI-native EDR and SIEM tools with behavioral analysis rather than rule-based detection. Pattern-matching rules built for human-speed attacks are structurally insufficient for AI-generated phishing arriving at machine speed. Behavioral analytics and AI-versus-AI detection architectures are the operative requirement, not a future consideration.

Second, implement the OWASP LLM Top 10 framework for every internal AI tool and every customer-facing AI product. The OWASP GenAI Security Project is the de facto technical standard for GenAI application security risks and is referenced by enterprise security teams globally. If your AI products are not being assessed against this framework, they are not being adequately assessed.

Third, treat all AI-generated code as high-risk code. Enforce static analysis and adversarial testing pipelines before any AI-generated code reaches production. The Zimperium data on nearly half of AI-generated code containing security flaws is not a prediction. It is a current operational reality for every engineering team using a code copilot.

Fourth, establish role-based access governance for every AI component in your security stack. IBM’s 2025 data shows 97% of AI-specific breaches lacked basic access controls. This is the single most actionable gap with the clearest remediation path.

What CTOs Must Understand Now

The generative AI cybersecurity market sits between $8.65 billion and $12.87 billion in 2025, depending on the methodology used, according to MarketsandMarkets and ResearchAndMarkets respectively. The broader AI in cybersecurity market, which includes all AI categories, reached $34.09 billion in 2025 according to Fortune Business Insights, with North America holding 34.90% of that market. Growth rates across credible forecasters are consistently pegged between 22% and 29% annually through 2031.

The vendor landscape is consolidating fast. CrowdStrike, Palo Alto Networks, and Fortinet hold the largest product footprints. Decision windows for multi-year platform contracts are narrowing as consolidation removes competitive alternatives. If you are still in evaluation mode on your AI security platform strategy, that window is not staying open.

The Post-Quantum Threat Has a Shorter Timeline Than You Were Told

The “harvest now, decrypt later” threat model, where adversaries collect encrypted data today to decrypt when quantum computing matures, is operating on a compressed timeline. AI-accelerated cryptanalysis research is advancing faster than public quantum computing milestones suggest. NIST finalized its first post-quantum cryptography standards in 2024. Organizations have limited runway for cryptographic inventory and migration planning. Begin that inventory now.

Timeline Realism for AI Security Claims

The autonomous SOC is 3 to 5 years from reliable deployment at scale. AI-generated malware redefining attack classes is not in evidence yet. Post-quantum cryptography urgency is a realistic and genuine concern. Calibrate your board communications and investment timelines accordingly.

The G7 Cyber Expert Group issued a formal joint statement in 2025 acknowledging that GenAI, agentic AI, and advanced AI systems present emerging and evolving cybersecurity risks requiring proactive cross-jurisdictional response. That regulatory signal, combined with the EU AI Act’s risk classification requirements now forcing formal security assessments of AI systems in regulated industries, means the compliance architecture around AI security is hardening fast. Organizations that treat AI governance as optional are building technical debt with regulatory interest attached.

How We Got Here: The Four-Year Arc

Pre-2022 AI in cybersecurity meant machine learning for anomaly detection. Pattern matching, SIEM correlation, endpoint behavior analysis. Useful. Narrow. Human-speed attacks, human-speed defense.
2022 to 2023 ChatGPT launches. Natural language AI reaches non-technical threat actors overnight. Phishing, social engineering, and script generation become democratized. The attack surface calculus changes permanently.
2024 First major wave of GenAI-native security products hit enterprise procurement. CrowdStrike, Palo Alto Networks, and Microsoft release AI copilots. OWASP LLM Top 10 is formalized. NIST finalizes first post-quantum cryptography standards. Gartner places AI-powered security operations at the Peak of Inflated Expectations.
2025 IBM documents AI as both defensive asset and attack vector at scale for the first time. Shadow AI becomes a top-3 breach cost factor. G7 issues formal AI cybersecurity statement. Exploit weaponization drops to 4.76 days average.
2026 Agentic AI creates autonomous attack campaigns. Project Glasswing marks the first institutional AI capable of autonomous zero-day research. EU AI Act forces formal security assessments. Cyber-enabled fraud overtakes ransomware as the top CEO concern.

Key Takeaways

Organizations using AI extensively in security operations cut breach lifecycles by 80 days and save an average of $1.9 million per breach (IBM 2025).
1 in 6 breaches in 2025 involved attackers using AI. Phishing leads at 37%, deepfake impersonation at 35%.
Shadow AI adds $670,000 to average breach costs. 97% of AI-specific breaches lacked basic access controls.
Exploits are being weaponized in 4.76 days on average, a 43% increase in speed. AI-speed defense is not optional.
Nearly half of AI-generated code contains security flaws (Zimperium). Engineering velocity gains may be offset by downstream remediation costs.
The autonomous SOC is 3 to 5 years from reliable deployment. Human oversight is the operative model in 2026.
Post-quantum cryptography migration timelines are being compressed by AI-accelerated cryptanalysis. Begin inventory now.

FAQ: Generative AI in Cybersecurity

How is generative AI used in cybersecurity?

Generative AI is used in cybersecurity to automate threat detection, accelerate incident response, generate synthetic attack scenarios for red teaming, analyze vulnerabilities, and craft adaptive security policies. It also powers security operations centers (SOCs) by triaging alerts, reducing analyst workload, and identifying anomalous behavior in real time. (Sources: IBM, Fortinet, WEF GCO 2026)

What are the cybersecurity risks of generative AI?

Generative AI introduces several cybersecurity risks: it enables attackers to generate convincing phishing emails in minutes rather than hours, create deepfake impersonations, and automate malware. For defenders, risks include shadow AI data exposure, AI model poisoning, adversarial inputs bypassing detection, AI hallucinations causing false security verdicts, and governance gaps in unsanctioned AI tool use. (Sources: IBM 2025, WEF 2026, Sophos)

Can generative AI replace human cybersecurity analysts?

No. Generative AI augments but does not replace human cybersecurity analysts in 2026. While AI effectively handles Tier 1 alert triage and enrichment, complex incident response, threat hunting, and strategic decisions still require human judgment. IBM’s 2025 data shows AI-human collaboration reduces breach lifecycles by 80 days. Autonomous SOC response at scale remains 3 to 5 years from reliable deployment.

How are hackers using generative AI to attack organizations?

Hackers use generative AI primarily to craft convincing phishing emails at scale, a process that once took 16 hours and now takes 5 minutes. They also use AI for deepfake voice and video impersonations of executives, to debug and customize malware, and to automate victim profiling for more targeted social engineering campaigns. (Sources: IBM 2025, Sophos X-Ops)

What is shadow AI in cybersecurity?

Shadow AI refers to the unauthorized use of AI tools such as ChatGPT, Claude, or Gemini by employees without IT approval or oversight. It creates security risk because sensitive data may be uploaded to external platforms without data loss prevention controls. IBM’s 2025 report found shadow AI adds an average of $670,000 to breach costs, making it a top-three costliest breach factor.

What is the market size of generative AI in cybersecurity?

The generative AI cybersecurity market was valued at approximately $8.65 billion to $12.87 billion in 2025 depending on methodology, with projections ranging from $35 billion to $45 billion by 2030 to 2031. The broader AI in cybersecurity market reached $34.09 billion in 2025. Growth rates are consistently estimated between 22% and 29% CAGR. (Sources: MarketsandMarkets, ResearchAndMarkets, Fortune Business Insights)

What is agentic AI in cybersecurity?

Agentic AI in cybersecurity refers to AI systems that autonomously execute multi-step tasks such as scanning for vulnerabilities, crafting exploits, or orchestrating attack campaigns without constant human direction. In 2026, both defenders and attackers are integrating agentic AI: defenders for autonomous SOC response, and threat actors for fully automated intrusion operations. (Sources: OWASP, WEF 2026, Darktrace)

Where This Leads in the Next 12 to 18 Months

What you now understand that most of your peers do not yet: generative AI in cybersecurity is not a product category to buy your way into. It is a structural shift in the economics and speed of both attack and defense simultaneously. The organizations winning this transition are not the ones deploying the most AI tools. They are the ones governing the AI they already have.

Three things to watch in the next 12 to 18 months. First, agentic AI moving from experimental deployment to production-scale SOC integration at the largest financial and critical infrastructure organizations. When it works, it will compress defender response times dramatically. When it fails under novel adversarial conditions (which adversarial ML is specifically engineered to trigger), organizations that have reduced their human analyst capacity will face an unguarded gap. Second, the post-quantum migration timeline shortening faster than the public discourse reflects, driven by AI-accelerated cryptanalysis. Third, regulatory requirements under the EU AI Act and successor G7 frameworks creating mandatory security assessment requirements for AI systems in regulated industries, transforming what is currently a governance best practice into a legal obligation.

The mantra for 2026 is the one Chester Wisniewski offered at the start of the year: trust but verify. Not just for your AI tools. For the threat intelligence you’re using to justify buying them.

Get weekly intelligence on AI and cybersecurity delivered to your inbox. No noise. No vendor marketing. Just the analysis that matters.

Subscribe to The Neural Loop

May 31, 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

AI Hallucination in Enterprise | What It Is, Why It Happens, and How to Mitigate It in Production (2026)

AI hallucinations cost global enterprises an estimated $67.4 billion in 2024. Not from science fiction scenarios. From real production systems confidently generating wrong information, fabricated citations, and invented facts, all delivered with the tone of certainty. And 47% of enterprise AI users made at least one major business decision based on hallucinated content that same year, according to Deloitte’s 2026 AI adoption survey.

The headline numbers from model vendors are misleading. Yes, GPT-4o hallucinates just 0.7% of the time on general knowledge summarization benchmarks. But legal AI tools hallucinate on 17–34% of real legal queries. Medical AI reaches 64% hallucination rates on clinical cases without mitigation. And the Stanford AI Index 2026 reports hallucination rates ranging from 22% to 94% across 26 leading LLMs on complex reasoning tasks. The gap between benchmark and production is not a rounding error. It’s an operational hazard.

This guide gives engineering and security leaders the complete picture: what AI hallucination actually is at the model level, why it gets dramatically worse in agentic AI systems, how to measure it in your production environment, and the proven 3-layer mitigation stack that reduces rates by over 85% when properly implemented. This is the article your model vendor doesn’t want you to read before signing a procurement contract.

What AI Hallucination Actually Is | Beyond the Buzzword

The Technical Reality Most Explainers Skip

LLMs do not retrieve facts. They predict the most statistically probable next token based on patterns absorbed from training data. Hallucination is not a bug in the traditional software sense, it is an inherent property of probabilistic text generation. A 2025 mathematical proof confirmed that hallucinations are structurally inevitable under current LLM architectures. Retrieval-augmented generation and human-in-the-loop review reduce them. Neither eliminates them.

That framing matters for enterprise planning. The question is not whether your deployed model hallucinates. It does. The question is how much it hallucinates in the specific domain, on the specific query types, under the specific conditions you’ve deployed it in, and what you’ve built to catch it before it affects a decision.

The Four Hallucination Types

Type	Description	Example	Detection Difficulty
Factual	States something verifiably false as true	Wrong court case dates, fabricated statistics	Moderate — verifiable against external sources
Citation	Invents a source or attributes claims to the wrong source	A journal article that doesn’t exist	Moderate — link checking catches most
Reasoning	Individual facts are correct but the logical chain is invalid	“Revenue grew 20%, costs grew 15%, so margins expanded”, not necessarily true	High — everything looks right until the conclusion
Instruction	Model ignores or partially follows a prompt constraint	Generates content outside specified boundaries	Low to moderate — output review catches it

Factual hallucinations were present in 8–12% of queries in 2024. Top models have pushed general-knowledge factual error rates down to 0.3–0.7%, but rates spike sharply on obscure topics and recent events. Citation hallucinations remain in 30%+ of chatbot-generated answers in research contexts. Reasoning hallucinations are the hardest to catch because the output looks internally coherent.

Why Benchmark Numbers Don’t Reflect Production Reality

The Vectara HHEM Leaderboard measures grounded hallucination: how often a model fabricates facts when summarizing a document it was explicitly given. Top models score below 1% here. Production enterprise AI rarely works on clean single-document summarization. Real enterprise queries involve multi-document retrieval, complex reasoning chains, recent events, and domain-specific knowledge, all conditions where hallucination rates multiply 10–50x above benchmark levels.

The Stanford AI Index 2026 puts the range bluntly: 22% to 94% across 26 leading LLMs on complex tasks. That range is not model variance, it is the gap between what models are benchmarked on and what enterprises actually ask them to do.

The Entropy Gap: Why Creativity and Accuracy Trade Off

Based on Shannon’s information entropy, low entropy produces high accuracy with limited novelty. High entropy produces creative but often false answers. When users push models toward nuanced analysis or edge-case advice, they push models toward higher entropy, and higher hallucination risk. This is the core tension in enterprise AI deployment, and no prompt can fully resolve it. It has to be managed at the architecture level.

Why Hallucination Is Far Worse in Agentic AI Than in Copilots

The Compounding Effect No One Models

A copilot hallucinates once per user interaction, and a human reads the output before acting. An AI agent hallucinates once per step in a multi-step reasoning chain, and acts before a human sees the output. Gartner’s March 2026 research puts agentic workflows at 10–20 LLM calls per task. If each call carries a 2% hallucination rate, a 15-step agent chain has a 26% probability of at least one hallucination affecting the final output, before compounding effects from hallucinations feeding into subsequent steps.

Multi-turn conversational agents show hallucination rates of up to 35% during extended interactions. That’s not a benchmark quirk, it’s what happens when context accumulates, retrieval gaps appear, and the model starts predicting forward from its own earlier (potentially flawed) outputs rather than from grounded source material. This is the stat that should make every engineering lead re-examine their agentic AI production failures retrospective.

When Hallucination Becomes an Unauthorized Action

When agents hallucinate, they don’t just return wrong text. They can make unauthorized API calls, misroute data, trigger incorrect workflows, or delete the wrong records. The Stanford AI Index 2026 specifically flags this: in agentic systems, hallucinations can lead to unauthorized API calls or data leaks. That is categorically different from a copilot hallucination, which a human can catch and discard. An agent hallucination may be irreversible before anyone sees the output.

This is not a theoretical risk. Production agentic systems in finance and legal workflows are triggering real downstream consequences from planning-stage hallucinations. The architecture has to account for this.

Role Separation: The Right Architectural Response

The most effective architectural control for agentic hallucination is role separation. One model plans the actions. A separate deterministic script or monitor model validates the plan against an allowlist of permitted actions before execution. This prevents a planning hallucination from becoming an execution error. It’s the same principle as a four-eyes approval process, except it runs in milliseconds.

For high-stakes agents in security, finance, or healthcare, the complementary principle is “fail-closed”: if the model’s confidence or grounding score falls below a defined threshold, the system escalates to a human analyst rather than proceeding. This is the architectural equivalent of a circuit breaker. Agents designed to fail open, continuing with low-confidence outputs rather than halting, are production liabilities waiting for the right query to expose them.

Hallucination Rates by Domain: Where Your Enterprise Risk Actually Lives

The table below is the insight most enterprise AI conversations skip. Hallucination is not a model property, it is a domain × deployment × mitigation property. The same GPT-4o that hallucinates 0.7% on summarization benchmarks produces hallucinated legal citations in 17–34% of legal research queries. Model selection alone cannot solve this. Architecture and mitigation layers must.

Domain / Use Case	Hallucination Rate	Risk Level	Key Finding
General summarization	0.7–1.8% (top models)	Low	Vectara HHEM Leaderboard 2026, benchmark conditions only
Enterprise chatbots (live production)	~18%	Medium-High	Real production rates far exceed benchmark numbers
Medical / Clinical AI	43–64% without mitigation	Critical	MedRxiv 2025: drops to 23% with structured mitigation prompts
Legal research AI	17–88% depending on model	Critical	Lexis+ AI: 17%; Westlaw: 34%; Stanford RegLab/HAI: 69–88% on complex queries
Code generation	0.8–2.1% (top models)	Medium	Library hallucinations persist, training data lags API updates
Financial analysis AI	Up to 33% (reasoning tasks)	High	Reasoning hallucinations, correct facts, invalid logic chains
RAG-powered enterprise search	17–33% (after RAG)	Medium-High	Stanford: RAG reduces but doesn’t eliminate; retrieval failures persist
Product recommendation AI	Up to 25% accuracy impact	Medium	UC San Diego 2026: AI summaries hallucinated in 60% of tested scenarios

Legal and medical are the clearest danger zones. In legal, the Stanford RegLab/HAI study remains the definitive benchmark: LLMs hallucinate between 69% and 88% of the time on specific legal queries. Researcher Damien Charlotin maintains a database of 120+ court cases where AI-hallucinated quotes, fabricated cases, or fake legal citations were discovered. In legal, hallucination is synonymous with malpractice risk, full stop.

In medical, ECRI listed AI risks as the #1 health technology hazard for 2025. Without mitigation prompts, hallucination rates on clinical cases reach 64.1% on long cases and 67.6% on short cases, according to the MedRxiv 2025 study of 300 physician-validated vignettes. Even at the best-case rate of 23% with full mitigation applied, nearly 1 in 4 medical AI responses contains fabricated information. These are not acceptable residual rates without mandatory physician review on every clinical output.

How to Measure Hallucination Rate in Your Production System

The Measurement Gap Most Teams Don’t Know They Have

91% of enterprises have implemented explicit hallucination mitigation protocols. Far fewer measure actual hallucination rates in production. Without measurement, mitigation is guesswork. Most teams implement RAG and assume the problem is solved. Stanford research shows RAG-powered legal tools still hallucinate 17–33% of the time. Organizations implementing RAG without measuring outcomes are deploying production AI systems they cannot describe, audit, or improve.

The Four RAG Evaluation Metrics Every ML Team Must Track

Metric	What It Measures	What Low Scores Signal
Context Precision	Does the retrieved chunk actually contain the answer?	Retriever is surfacing irrelevant content
Context Recall	Did the retriever find all necessary information?	Model is forced to fill gaps, hallucination risk rises sharply
Faithfulness	Is the answer derived only from the provided context?	Primary hallucination signal in RAG systems
Answer Relevance	Does the response address what was actually asked?	Off-topic generation that can mask hallucinated content

Production Monitoring Tools in 2026

The market for AI hallucination detection tools grew 318% between 2023 and 2025. The tooling has matured to the point where every production enterprise AI system can and should have continuous hallucination monitoring. The leading platforms: Braintrust for real-time monitoring and automated regression testing; Galileo for scalable model-driven evaluations at high output volumes; Fiddler for explainability and compliance-focused evaluation with governance integration; Arize AI for real-time monitoring with drift detection.

The LLM-as-judge pattern is now a production standard: a more capable, accurate model, Claude Sonnet or GPT-4o, evaluates the output of a faster, cheaper model for factual grounding and instruction following. Self-consistency checking, sampling 3–5 responses and comparing for agreement, catches a significant share of remaining hallucinations at low additional cost. Both patterns give teams a practical alternative to human review at scale.

Hallucination Measurement Starter Checklist

If your team can’t answer all six of these questions, you don’t yet have production-grade hallucination visibility:

What is our baseline hallucination rate in our target deployment domain, measured in production, not taken from a vendor benchmark?
Which of the four RAG evaluation metrics do we track continuously, and what are our current scores?
What is our post-mitigation hallucination rate, and when was it last measured?
What are the specific query types or topics where our system shows elevated hallucination risk?
At what confidence or grounding score does our system escalate output to human review rather than proceeding autonomously?
Have we had any documented hallucination-caused production errors, and are they tracked in an incident log?

The 3-Layer Mitigation Stack That Reduces Hallucination by 85%+

Three complementary layers, each additive. Used together, research supports a combined reduction of 85–92% in domain-specific enterprise hallucination rates for properly implemented stacks. This transforms AI hallucination mitigation from “inherent unfixable problem” to “manageable engineering challenge with known solutions.”

Layer 1: Prompt Engineering, 15–25% Reduction, Lowest Cost

The simplest and cheapest intervention. Effective prompt constraints include: “Only answer based on the provided context,” “If uncertain, say you don’t know,” and “Cite the specific source passage for each claim.” A 2025 Nature study confirmed prompt-based mitigation reduces hallucinations by approximately 22 percentage points on medical tasks. That’s a meaningful reduction for near-zero implementation cost.

The ceiling is real, though. LLMs don’t reliably follow instructions when statistical pressure to generate a confident response is high, particularly on topics where the model has strong training signal. Prompt engineering is Layer 1, not a standalone solution. Teams that treat it as sufficient are relying on the model to police itself.

Layer 2: RAG Implementation | 71% Reduction, Moderate Cost

The most impactful single technical intervention available. RAG shifts the model from recalling facts from training data, unreliable, unauditable, to synthesizing information from provided documents. Across 847 production deployments, RAG produced a median 71% hallucination reduction, with a range of 58–89% depending on retrieval corpus quality and chunking strategy, according to February 2026 enterprise vendor consortium data.

Key implementation requirements: a comprehensive retrieval index, accurate chunking, sufficient context window to hold retrieved content, and regular index freshness maintenance. Stale retrieval indexes are a hidden hallucination accelerant, when the index doesn’t contain current information, the model defaults to training-data prediction, bypassing the entire grounding mechanism. This is the most common RAG implementation failure in production.

Layer 3: Output Validation and Confidence Scoring | 65% Additional Reduction

Post-generation verification catches errors that RAG misses. A verification API checks each claim against external sources after generation. Self-consistency checking, sampling 3–5 responses and comparing, adds approximately 65% reduction in residual hallucinations. LLM-as-judge evaluation provides scalable automated review at production volumes.

For regulated industries, finance, healthcare, legal, a human-in-the-loop review layer remains mandatory for high-stakes outputs. It should be the fourth line of defense, not the first. Organizations that rely on human review as their primary hallucination control are paying $14,200 per AI-using employee per year in verification overhead, according to Forrester Research. That’s 4.3 hours per week of pure fact-checking time. The 3-layer stack eliminates most of that cost and shifts human review to the residual edge cases where it actually belongs.

“The question isn’t whether large language models hallucinate, they do, by design. The question is whether your organization has built the architecture to catch and contain hallucinations before they reach decision-makers. Most enterprises haven’t.”Percy Liang, Director, Center for Research on Foundation Models, Stanford University — Stanford AI Index 2026

Industry-Specific Risk Levels and Mitigation Requirements

Healthcare: The Highest Stakes, the Widest Gap

Without mitigation prompts, hallucination rates on clinical cases reach 64.1% on long cases and 67.6% on short cases, per the MedRxiv 2025 study across 300 physician-validated vignettes. With structured mitigation prompts, rates drop to 43.1% and 45.3%, a meaningful 33% reduction. But even at the best-in-class rate of 23% with full mitigation, nearly 1 in 4 medical AI responses contains fabricated information. ECRI named AI risks the #1 health technology hazard for 2025.

Mitigation requirement: Full 3-layer stack plus mandatory physician review for any clinical output, with source citation required for every claim. Any clinical AI system that proceeds without human sign-off on a threshold basis is not compliant with ECRI guidance, and is a liability exposure waiting for a patient outcome to make it a headline.

Legal: Hallucination Is Malpractice Risk

The Stanford RegLab/HAI study is unambiguous: LLMs hallucinate between 69% and 88% of the time on specific legal queries. Even with retrieval augmentation, Lexis+ AI hallucinated in 17% of cases and Westlaw AI-Assisted Research in 34% in 2026. Researcher Damien Charlotin’s database has documented 120+ court cases where AI-hallucinated quotes, fabricated cases, or fake citations were discovered.

Mitigation requirement: Mandatory source disclosure and provenance logging, every LLM legal claim must link to a verified source document. No exceptions for speed or volume. A hallucinated legal citation is not a minor error; it is a professional conduct risk for the attorney who relied on it.

Finance: The Reasoning Hallucination Problem

Reasoning hallucinations are the dominant risk in financial analysis. The model may cite correct facts but produce an invalid logical inference. OpenAI’s o3 reasoning model, widely used for financial analysis, hallucinated 33% of the time on PersonQA benchmarks, double its predecessor. More processing power, more hallucination on open-ended reasoning tasks. Don’t assume a newer model is a safer model until you’ve benchmarked it in your specific deployment context.

Mitigation requirement: Dual-model validation. One model generates. A second model stress-tests the logical chain before the output is used. Output validation must check not just factual accuracy but logical validity, the reasoning hallucination won’t appear wrong until someone follows the chain to its flawed conclusion.

Security and Threat Intelligence: Design for Failure

A hallucinated vulnerability assessment or threat intelligence report can waste hundreds of analyst-hours and create false confidence in defenses. For security AI, the fail-closed principle is non-negotiable: if the confidence score falls below a defined threshold, escalate to a human analyst. Never return a low-confidence threat assessment as if it were confirmed intelligence. The cost of a false negative in security, a missed real threat, far exceeds the cost of a false positive that sends an analyst to verify.

The Cost Anchor That Should Drive Every Procurement Conversation

Global business losses from AI hallucinations reached $67.4 billion in 2024. Enterprises spend an average of $14,200 per AI-using employee per year in hallucination verification overhead, equivalent to 4.3 hours per week of pure fact-checking time. For a 500-person AI-enabled workforce, that’s $7.1 million annually just checking AI’s homework. The 3-layer mitigation stack eliminates most of that cost. Its implementation cost, at any enterprise scale, is a fraction of the overhead it removes.

Building a “Hallucination Datasheet” for Every AI System in Production

What a Hallucination Datasheet Is

A hallucination datasheet is a standardized internal document that profiles the hallucination behavior of each AI system deployed in production: domain-specific rates, known failure modes, measurement methodology, active mitigation layers, and residual risk after mitigation. Leading AI governance controls teams now maintain these as part of their AI registry. It makes hallucination risk visible, comparable, and auditable, the three properties that regulators and enterprise procurement teams will increasingly demand.

The Seven-Field Hallucination Datasheet Template

Field	What to Document
1. Baseline hallucination rate	Measured in target domain in production, not vendor benchmark
2. Active mitigation layers	Which of prompt engineering / RAG / output validation are implemented
3. Post-mitigation hallucination rate	Measured in production after all mitigation layers are applied
4. Known failure modes	Specific query types, topics, or conditions with elevated hallucination risk
5. HITL threshold	Confidence or grounding score below which output requires human review
6. Last measurement date and review cadence	When rates were last measured and how frequently they’re reassessed
7. Incident history	Any documented hallucination-caused errors in production, dates, impacts, resolutions

The Regulatory Case for Doing This Now

Under EU AI Act Article 13, users of high-risk AI must ensure that users understand the system’s capabilities and limitations. A hallucination datasheet is the most direct way to document known limitations in a format regulators, auditors, and enterprise procurement teams can evaluate. Organizations that maintain these documents can demonstrate due diligence in a way that ad-hoc governance cannot.

“Transparency about AI system limitations, including hallucination rates and failure modes, is not optional under the EU AI Act for high-risk applications. It is a documentation requirement with enforcement consequences.”Luca Bertuzzi, AI Policy Correspondent, MLex Media — EU AI Act Compliance Analysis, 2026

Teams that integrate hallucination datasheets into their AI registry now are building the audit trail that procurement reviews and regulatory audits will require in 2027. Teams that don’t are creating a documentation gap that gets expensive to close retroactively.

The Future of Hallucination: Will It Ever Be Solved?

The Structural Constraint That Won’t Go Away

The 2025 mathematical proof is clear: hallucinations are structurally inevitable under existing LLM architectures. They are an emergent property of probabilistic text prediction. Analysis of Hugging Face leaderboard data suggests that zero hallucinations would require models with roughly 10 trillion parameters, a scale not expected before approximately 2027. For enterprise planning purposes, treat hallucination mitigation as a permanent operational discipline, not a problem the next model update will solve.

The Counterintuitive Trend: Better Reasoning, More Hallucination

OpenAI’s o3 reasoning model hallucinated 33% of the time on PersonQA benchmarks, double its predecessor o1. o4-mini reached 48% on person-specific questions. The most sophisticated reasoning models push into higher entropy generation, creating a direct trade-off between reasoning depth and factual accuracy on open-ended queries. Enterprise teams deploying reasoning models for complex financial or legal analysis should benchmark hallucination rates specifically in their deployment domain. Don’t assume newer means more reliable, in reasoning tasks, the evidence currently suggests the opposite.

The 2026 Direction: From Mitigation to Architecture

The frontier of hallucination management is moving from post-generation mitigation to generation-time architecture. “Guarded Generation” patterns, pre-retrieval validation, constrained generation, post-generation verification, are becoming standard in production LLM engineering. The goal is not to prevent hallucination in the model. That’s not achievable at current scales. The goal is to catch and contain it before it reaches enterprise decision-making.

The organizations that will lead on AI reliability through 2026 and beyond are not those that found a hallucination-free model. No such model exists at useful enterprise scale. They are the organizations that built layered mitigation architectures, measured production hallucination rates continuously, and integrated hallucination governance into their enterprise AI reliability strategy and incident response plans. That is the practical definition of production-grade enterprise AI, and it’s an engineering discipline, not a vendor promise.

Frequently Asked Questions

What is AI hallucination and why does it happen in enterprise applications?

AI hallucination occurs when a language model generates information that is factually incorrect, fabricated, or logically invalid, delivered with the same confident tone as accurate output. It happens because LLMs predict the most statistically probable next token based on training data patterns, not factual retrieval. It is structurally inherent to probabilistic generation under current architectures, confirmed by a 2025 mathematical proof, and rates are significantly higher in enterprise production environments than vendor benchmarks suggest.

How much do AI hallucinations cost enterprises financially?

Global business losses from AI hallucinations reached $67.4 billion in 2024, according to a comprehensive AllAboutAI study. Per enterprise employee, organizations spend approximately $14,200 annually in hallucination verification overhead, equivalent to 4.3 hours per week of fact-checking time, per Forrester Research. For a 500-person AI-enabled workforce, that equates to $7.1 million annually in pure verification cost before any downstream error costs are counted.

Does RAG eliminate AI hallucinations completely?

No. RAG significantly reduces hallucinations but cannot eliminate them. Across 847 production deployments, RAG produced a median 71% hallucination reduction, with a range of 58–89% depending on retrieval corpus quality and chunking strategy. However, Stanford researchers found that RAG-powered legal AI tools still hallucinate in 17–33% of queries due to retrieval failures and gaps in the retrieval corpus. RAG should be the foundation of a 3-layer mitigation stack, not a standalone solution.

What are hallucination rates for the best AI models in 2026?

On grounded summarization benchmarks, top models achieve below 1% hallucination rates, GPT-4o and Claude 3.5 Sonnet both score around 0.7–0.8% on the Vectara HHEM Leaderboard. Production rates are dramatically higher: approximately 18% in live enterprise chatbot interactions, 17–34% in legal AI tools, 43–64% in medical AI without mitigation, and 22–94% across 26 models on complex reasoning tasks per the Stanford AI Index 2026.

How do you measure AI hallucination rate in a production system?

Track the four RAG evaluation metrics, Context Precision, Context Recall, Faithfulness, and Answer Relevance, using monitoring tools like Braintrust, Galileo, or Arize AI for continuous production tracking. Implement LLM-as-judge evaluation for scalable automated review. Set a baseline hallucination rate before mitigation is applied, then measure post-mitigation rates on a continuous basis. The current industry improvement trend is approximately a 3-point annual decline in hallucination rate for teams actively measuring and iterating.

Why is hallucination worse in AI agents than in standard chatbots?

Agentic AI workflows trigger 10–20 LLM calls per task, according to Gartner’s March 2026 research. With each call carrying even a modest hallucination probability, the compound probability of at least one hallucination affecting a multi-step chain rises dramatically, and agents act before human review occurs. Multi-turn agents show hallucination rates up to 35% during extended interactions. A chatbot hallucination is caught by the human reader; an agent hallucination may trigger an unauthorized API call, misroute data, or take an irreversible action before anyone sees the output.

How do I reduce LLM hallucination rates in a regulated industry like healthcare or finance?

Regulated industries require the full 3-layer mitigation stack, prompt constraints, RAG implementation, and post-generation output validation, plus mandatory human-in-the-loop review above a defined confidence threshold. Healthcare deployments should require physician sign-off on all clinical outputs and source citation for every claim, given hallucination rates of 43–64% without mitigation. Finance deployments should implement dual-model validation where a second model stress-tests the logical chain before output is used, specifically to catch reasoning hallucinations.

What is a hallucination datasheet and does my team need one?

A hallucination datasheet is a standardized internal document profiling the hallucination behavior of a specific AI system in production: baseline rate, active mitigation layers, post-mitigation rate, known failure modes, human review thresholds, and incident history. EU AI Act Article 13 requires that users of high-risk AI understand system limitations, a hallucination datasheet is the most auditable way to document this. Any enterprise running AI in legal, medical, financial, or security contexts should maintain one for every production deployment.

May 17, 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.

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

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

Tag: Cybersecurity

PaperCut AI Attack Hits 440 Orgs: What to Patch Now

What Happened, in Order

The Two Flaws PaperCut Missed

Inside the AI Attacker’s Toolkit

Three Paths to Domain Admin

The Numbers Behind the Panic

What Researchers Are Actually Saying

What IT Teams Should Do Now

Frequently Asked Questions

Conclusion: A Faster Clock, Not a New Rulebook

The Core Paradox of 2026

How Generative AI Is Used in Cybersecurity

On Defense: What the Numbers Actually Show

Specific Use Cases That Are Working Now

AI Cybersecurity Threats 2026: How Attackers Are Using It

The Speed Problem Is Now Structural

Shadow AI: The $670,000 Threat Nobody Is Governing

Agentic AI and the Next Escalation

The Case Against the Hype

Cybercriminals Are Not Adopting AI as Fast as the Headlines Suggest

AI Security Tools Create Blind Spots the Industry Isn’t Discussing

Nearly Half of AI-Generated Code Is Already Shipping Vulnerabilities

What Security Engineers Must Do Now

What CTOs Must Understand Now

The Post-Quantum Threat Has a Shorter Timeline Than You Were Told

Timeline Realism for AI Security Claims

How We Got Here: The Four-Year Arc

Key Takeaways

FAQ: Generative AI in Cybersecurity

Where This Leads in the Next 12 to 18 Months

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

What AI Hallucination Actually Is | Beyond the Buzzword

The Technical Reality Most Explainers Skip

The Four Hallucination Types

Why Benchmark Numbers Don’t Reflect Production Reality

The Entropy Gap: Why Creativity and Accuracy Trade Off

Why Hallucination Is Far Worse in Agentic AI Than in Copilots

The Compounding Effect No One Models

When Hallucination Becomes an Unauthorized Action

Role Separation: The Right Architectural Response

Hallucination Rates by Domain: Where Your Enterprise Risk Actually Lives

How to Measure Hallucination Rate in Your Production System

The Measurement Gap Most Teams Don’t Know They Have

The Four RAG Evaluation Metrics Every ML Team Must Track

Production Monitoring Tools in 2026

Hallucination Measurement Starter Checklist

The 3-Layer Mitigation Stack That Reduces Hallucination by 85%+

Layer 1: Prompt Engineering, 15–25% Reduction, Lowest Cost

Layer 2: RAG Implementation | 71% Reduction, Moderate Cost

Layer 3: Output Validation and Confidence Scoring | 65% Additional Reduction

Industry-Specific Risk Levels and Mitigation Requirements

Healthcare: The Highest Stakes, the Widest Gap

Legal: Hallucination Is Malpractice Risk

Finance: The Reasoning Hallucination Problem

Security and Threat Intelligence: Design for Failure

The Cost Anchor That Should Drive Every Procurement Conversation

Building a “Hallucination Datasheet” for Every AI System in Production

What a Hallucination Datasheet Is

The Seven-Field Hallucination Datasheet Template

The Regulatory Case for Doing This Now