PyTorch Lightning Hit by Supply Chain Attack — Malicious PyPI Versions Steal Credentials | NeuralWired
CybersecurityMay 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
01Lightning-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.
02TeamPCP’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.
03PyPI’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.
04Secondary 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.
Copy Fail (CVE-2026-31431): The 9-Year Linux Kernel Flaw That Gives Any User Root Access | NeuralWired
SecurityApril 30, 2026 · 10 min read
Copy Fail: The 9-Year Linux Kernel Flaw That Hands Any Local User Root Access
CVE-2026-31431 lets any unprivileged user on virtually every major Linux distribution gain full root access using 732 bytes of Python. An AI found it in roughly one hour. Nobody spotted it for nine years.
Three separate kernel changes, written years apart by engineers who had no reason to connect them, quietly assembled a trap inside the Linux cryptographic subsystem. The last piece clicked into place in August 2017. Nobody noticed. Servers got deployed. Containers launched. Cloud providers scaled. And somewhere in the intersection of an IPsec helper module, a zero-copy file transfer mechanism, and a performance shortcut, a fully working privilege escalation waited.
On April 29, 2026, offensive security firm Xint.io published the full technical details of CVE-2026-31431, now publicly named Copy Fail. The flaw carries a CVSS 7.8 severity score, which sounds manageable until you read what it actually does: it gives any local user, no matter how restricted, a reliable path to full root on nearly every Linux system shipped since 2017. No race condition. No per-distro adjustments. No compiled payload. Just Python, and patience.
The discovery itself is almost as striking as the vulnerability. Theori’s Xint Code Research Team, using an AI-assisted analysis pipeline, surfaced Copy Fail as its highest-severity finding roughly an hour after pointing the system at the Linux kernel’s crypto/ subsystem. The same scan, the team noted, found additional high-severity bugs still working through coordinated disclosure.
A Bug Built in Three Acts
Copy Fail isn’t a single coding mistake. It’s the result of three individually reasonable kernel changes, each made years apart, that only become dangerous in combination.
Act One: 2011 – The authencesn Module
The authencesn module arrived in 2011 to handle IPsec ESP Extended Sequence Numbers, defined in RFC 4303. From the start, it used the caller’s destination scatterlist as scratch space to rearrange ESN bytes during decryption. This was entirely harmless: only the kernel’s internal xfrm layer ever called it, and the kernel controlled both ends of the operation.
Act Two: 2015 – The AF_ALG AEAD Socket
In 2015, the AF_ALG interface gained AEAD support, including a splice() path that could deliver pages directly from the page cache into the cryptographic subsystem. authencesn was converted to the new AEAD interface. Still not exploitable: AF_ALG used out-of-place operations, keeping input and output buffers separate.
Act Three: August 2017 – The In-Place Optimization
A performance optimization in algif_aead.c changed how decryption handled memory. For efficiency, the new code copied AAD and ciphertext into an output buffer, but chained the authentication tag pages by reference using sg_chain() and then set req->src = req->dst, creating an in-place operation. Page cache pages delivered via splice() were now sitting inside the writable destination scatterlist. The trap was set.
The core insight: Nobody connected the 2017 in-place optimization to authencesn‘s scratch writes or to splice()‘s page cache delivery mechanism. Each change was reasonable in isolation. The vulnerability lives entirely at their intersection, across a six-year window and three separate subsystems.
How the Exploit Actually Works
The attack chain is deceptively clean. An unprivileged user opens an AF_ALG socket bound to authencesn(hmac(sha256),cbc(aes)) and uses the standard splice() system call to transfer pages from a readable target file into the socket. No special permissions. No kernel modules. Nothing that triggers standard audit rules.
Inside the kernel, the 2017 in-place optimization causes those file pages to end up in the writable destination scatterlist. When authencesn‘s decrypt routine runs, it writes four bytes at an offset past the AEAD tag, directly into what it believes is its own output buffer. Those bytes land in the kernel’s cached copy of the target file.
“An unprivileged local user can write four controlled bytes into the page cache of any readable file on a Linux system, and use that to gain root.”
Xint Code Research Team, Theori — xint.io
The write fails HMAC verification and recvmsg() returns an error. The caller sees a failed decryption. But the four-byte write into the page cache persists. Repeat the process across targeted offsets of a setuid binary, and the kernel’s cached version of that binary contains attacker-controlled code. Call execve() on it, and the kernel loads from the page cache rather than disk.
Stealth note: The corrupted page is never marked dirty for writeback, so the file on disk remains unchanged. Disk-based integrity checks and standard checksums won’t catch the modification. The in-memory version, which is what actually executes, is corrupted system-wide.
The result is a four-property combination that the Xint team describes as nearly unique in their experience:
📦
Portable
Confirmed working on Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1, and SUSE 16 with no per-distro modifications.
🔬
Tiny
The full working proof-of-concept is 732 bytes of standard-library Python. No compiled payload, no external dependencies.
👻
Stealthy
Disk-based integrity checks see nothing. The modification exists only in the page cache, invisible to on-disk forensic tools.
🐳
Cross-Container
Container isolation doesn’t stop it. Part two of Theori’s research series covers a full Kubernetes container escape using the same primitive.
“This vulnerability is unique because it has four properties that almost never appear together: it’s portable, tiny, stealthy, and cross-container. It allows any user account, no matter how low-level, to increase their privilege to full admin access.”
Xint.io Spokesperson, Theori — xint.io
The Scale of Exposure
Linux isn’t just popular on servers. It is, for practical purposes, the substrate on which the cloud runs. The numbers make the exposure concrete.
Platform
Linux Share
Implication
Google Cloud VMs
91.6%
Highest Linux density of any major cloud provider
AWS EC2 Instances
83.5%
Amazon Linux 2023 directly confirmed vulnerable
Microsoft Azure VMs
61.8%
Majority of Azure workloads run affected kernels
Public Cloud Overall
~90%
CNCF estimate across combined AWS/Azure/GCP infrastructure
Production Kubernetes
96.4%
Container escape risk affects nearly all K8s deployments
The affected kernel range compounds the problem. Theori confirmed the exploit works across kernel versions 6.12, 6.17, and 6.18. The vulnerable commit dates to August 2017, meaning any system running a kernel from that point forward and exposing AF_ALG sockets to unprivileged users is potentially affected. That’s essentially every major distribution shipped in the past nine years.
Shared hosting environments face the most acute risk. A single compromised tenant account can traverse to root, from which the entire host is accessible. Multi-tenant SaaS platforms, university computing clusters, and developer PaaS environments all sit in this category.
“732 bytes of Python. Root on every major Linux distribution shipped since 2017. No race conditions. No per-distro offsets. No version checks. 100% success rate.”
Brian Pak, Xint Code Research Team, Theori — xint.io
AI Found It in One Hour
The vulnerability’s discovery story is, in many ways, just as significant as the vulnerability itself. Taeyang Lee, a researcher at Theori, formed an initial hypothesis: the combination of AF_ALG sockets and splice() creates a path where unprivileged userspace can feed page cache pages directly into the crypto subsystem, and that scatterlist page provenance might be an underexplored source of vulnerabilities.
Rather than manually auditing the kernel’s crypto subsystem, the Xint Code Research Team fed that one-line hypothesis into an AI-assisted scanning pipeline pointed at crypto/. About an hour later, Copy Fail came back as the highest-severity finding. The same scan surfaced additional high-severity bugs that are still working through coordinated disclosure.
“About an hour later, Copy Fail came back as the highest-severity finding. The same scan surfaced additional high-severity bugs, still in coordinated disclosure.”
Xint Code Research Team, Theori — xint.io
The implications for the security research field are hard to overstate. Traditional manual kernel audits are expensive, slow, and require deep specialist knowledge. This approach condensed what might have been weeks of expert review into a single hour of autonomous scanning. The economics of vulnerability discovery are shifting, and not symmetrically: defenders don’t automatically get faster just because attackers do.
David Brumley, Chief AI and Science Officer at Bugcrowd, drew a direct line between Copy Fail and earlier high-profile kernel primitives in a post on Bugcrowd’s research blog:
“Copy Fail is the same class of primitive, in a different subsystem. The 2017 in-place optimization in algif_aead allows a page-cache page to end up in the kernel’s writable destination scatterlist for an AEAD operation submitted over an AF_ALG socket. An unprivileged process can then drive splice() into that socket and complete a small, targeted write into the page cache of a file it doesn’t own.”
David Brumley, Chief AI and Science Officer, Bugcrowd — bugcrowd.com
Logic bugs like Copy Fail are particularly hard for humans to spot. Memory corruption flaws produce signals: crashes, sanitizer output, fuzzer hits. A logic bug that writes to the right memory location, through the right interfaces, in a sequence that spans three subsystems and six years of kernel history, produces nothing. It just works.
Patching: Fast Upstream, Slow Everywhere Else
The upstream kernel response was fast. Theori reported the flaw to the Linux kernel security team on March 23, 2026. An initial acknowledgment came the next day. Patches were proposed and reviewed by March 25. The fix landed in the mainline kernel on April 1, 2026, via commit a664bf3d603d, which reverts the 2017 in-place optimization. Upstream patch time: under 10 days from report to commit.
The problem is what happens after that. Enterprise deployments average 60 to 90 days to roll out Linux patches after vendor releases, according to Qualys TruRisk data. Roughly 15 to 25 percent of systems running older LTS kernel branches wait more than 100 days. The gap between “patch exists” and “patch deployed” is where attacks happen.
Stage
Typical Timeline
Status for CVE-2026-31431
Upstream kernel patch
24-48 hours (critical)
Committed April 1, 2026
Distro security advisory
Days to weeks
Debian and SUSE advisories published
Enterprise deployment
60-90 days average
Majority of systems still unpatched
LTS branch backport
Varies widely
15-25% may wait 100+ days
For immediate mitigation before patching is possible, administrators can restrict AF_ALG socket access using seccomp profiles or AppArmor/SELinux policies. The Debian security tracker and SUSE CVE advisory both carry current package status for their respective distributions.
Action required: Check your kernel version against your distribution’s patched release. On systems where live patching isn’t available, restrict AF_ALG socket creation for unprivileged users as an interim control. Container workloads should be treated as high priority given the forthcoming Kubernetes container escape research.
Disclosure Timeline
Copy Fail followed a thorough coordinated disclosure process, giving vendors and distributors time to prepare patches before full public release.
Date
Event
August 2017
Vulnerability introduced via in-place optimization commit in algif_aead.c
March 23, 2026
Theori reports flaw to Linux kernel security team
March 24, 2026
Kernel security team acknowledgment received
March 25, 2026
Patches proposed and reviewed
April 1, 2026
Fix committed to mainline kernel (commit a664bf3d603d)
April 22, 2026
CVE-2026-31431 officially assigned
April 28, 2026
Bugcrowd blog post published by David Brumley
April 29, 2026
Full public disclosure via xint.io; The Hacker News coverage published
April 30, 2026
Heise.de German-language coverage; broader security community response
Theori has also confirmed that this is part one of a two-part research series. Part two will detail a Kubernetes container escape built on the same underlying primitive. Container security teams should treat this as an active, evolving situation rather than a closed incident.
Frequently Asked Questions
What is CVE-2026-31431 (Copy Fail)?
CVE-2026-31431, called Copy Fail, is a local privilege escalation flaw in the Linux kernel’s algif_aead cryptographic interface. It allows any unprivileged local user to write four controlled bytes into the kernel page cache, enabling root access on any major Linux distribution shipped since August 2017.
Which Linux distributions are affected by Copy Fail?
Confirmed affected distributions include Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1, and SUSE 16. Any Linux distribution running a kernel from August 2017 onward with the authencesn and algif_aead modules is likely affected. Debian and SUSE have published security advisories with current patch status.
How do I know if my system is patched?
Check your running kernel version against your distribution’s patched release. The upstream fix landed on April 1, 2026, in mainline commit a664bf3d603d. Check the Debian security tracker or your distro’s equivalent CVE advisory page for the specific patched package version.
Does Copy Fail affect cloud virtual machines?
Yes. Cloud VMs running unpatched Linux kernels are vulnerable to any user who can execute code on the instance. This includes multi-tenant environments. Cloud providers run Linux on over 60% to 91% of VMs depending on the platform, making this a high-priority patch for cloud workloads.
Does Copy Fail work inside containers?
Yes. Container isolation does not prevent exploitation because the flaw exists in the host kernel’s page cache, which is shared across containers. Theori has confirmed a full Kubernetes container escape using the same primitive; full details are expected in a forthcoming Part 2 research post.
Why did this go undetected for nine years?
The vulnerability exists only at the intersection of three kernel changes made in 2011, 2015, and 2017 across separate subsystems. Logic bugs don’t produce crashes or fuzzer signals. Each individual change was reasonable in isolation, making the combined effect essentially invisible to standard review and testing processes.
What’s the interim mitigation if I can’t patch immediately?
Restrict AF_ALG socket creation for unprivileged users via seccomp filter policies, AppArmor profiles, or SELinux policy rules. This blocks the attack path without requiring a kernel update. Verify your container runtime and Kubernetes policies also restrict this system call for workloads running as non-root users.
How significant is the AI-assisted discovery angle?
Theori’s AI pipeline found Copy Fail in roughly one hour from a one-line research hypothesis. The same scan identified additional high-severity bugs still in coordinated disclosure. This suggests AI tools can compress vulnerability discovery timelines from weeks to hours, changing the economics of both offensive and defensive security research significantly.
What Comes Next
Copy Fail is a clean illustration of how complexity creates risk in long-lived software. The Linux kernel is audited more thoroughly than virtually any codebase on earth, yet a logic bug spanning three subsystems and six years of history slipped through every review. The flaw wasn’t in any single commit. It was in the space between them.
The AI discovery angle changes the calculus going forward. If a one-line hypothesis fed into an autonomous scanner can surface a CVSS 7.8 kernel flaw in an hour, the assumption that lightly funded attackers lack the research capacity to find such bugs needs revisiting. The same tools available to Theori’s researchers are available to anyone willing to build or buy similar infrastructure. Coordinated disclosure and rapid upstream patching matter more than ever, because the window between bug introduction and discovery is likely to shrink.
For enterprise security teams, the immediate priority is simple: patch, or restrict AF_ALG access today. The 60-to-90-day average remediation window is a liability Copy Fail was designed to exploit. And with Part 2 of Theori’s research series, covering the Kubernetes container escape, still to come, the organizations most at risk may not have fully mapped their exposure yet.
Watch For
01Theori’s Part 2 Kubernetes container escape research, expected soon after the April 29 initial disclosure, which will detail how Copy Fail’s page cache primitive translates into a full container breakout on production clusters.
02Additional high-severity kernel bugs found by the same Xint Code AI scan, currently in coordinated disclosure. Expect further CVE assignments and patching cycles in the weeks following Copy Fail’s public release.
03Enterprise patch deployment rates for CVE-2026-31431 across major cloud providers. Given the 60-to-90-day average lag and the simplicity of the exploit, any confirmed in-the-wild exploitation reports in May or June 2026 would mark a significant escalation.
04Broader adoption of AI-assisted vulnerability scanning by both security teams and threat actors. Copy Fail’s one-hour discovery time is a benchmark that will likely pressure security organizations to rethink how they audit critical infrastructure code.
Stay ahead of the curve.
More on Linux security, AI-assisted research, and enterprise threat intelligence at NeuralWired.
SAP npm Packages Poisoned: Credential Theft Hits CAP Devs | NeuralWired
CybersecurityApril 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:
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
01TeamPCP’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.
02npm’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.
03Secondary 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.
04AI 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.
The OpenAI Growth Wall: How a 1B User Miss Is Reshaping a $750B AI Cycle | NeuralWired
Big TechApril 29, 2026 · 12 min read
The OpenAI Growth Wall: How a 1B User Miss Is Reshaping a $750B AI Cycle
A leaked internal memo from OpenAI CFO Sarah Friar has set off a chain reaction across the Magnificent Seven, exposing the fragile math behind a $600 billion infrastructure bet and forcing an immediate pivot to agentic commerce as the only viable exit ramp.
For three years, the market operated on a single comfortable assumption: user growth for large language models would follow an uninterrupted exponential curve. That assumption died on April 28, 2026. An internal report surfaced by The Wall Street Journal revealed that OpenAI had failed to reach 1 billion weekly active users by its own internal deadline and had missed multiple monthly revenue targets. The Nasdaq Composite fell 0.9% within hours of the news breaking.
The damage radiated outward with mechanical precision. Oracle dropped 7% to $161, its $300 billion compute contract with OpenAI suddenly reframed as a liability rather than an anchor. CoreWeave slid 7.4%, SoftBank fell nearly 10% in Tokyo trading, and Arm Holdings dropped 7.7% as investors unwound positions across the AI supply chain. What looked like a company-specific stumble was, in fact, a system-wide repricing of the premise that unlimited AI engagement justifies unlimited infrastructure spending.
Tonight, Alphabet, Microsoft, Meta, and Amazon report earnings against a backdrop of nearly $600 billion in collective AI-related capital committed for 2026. The central question isn’t whether these companies are growing. It’s whether the underlying software can attract and monetize users at the rate their valuations demand. One missed guidance number, one downward revision, and the “OpenAI Slump” stops being a warning shot and becomes a full-scale sector rout. The earnings window opening tonight may be the most consequential 48 hours in the AI super-cycle to date.
The Compute-Revenue Chasm That Wall Street Ignored
The structural fault line at the center of this crisis has a name: the Compute-Revenue Chasm. To maintain its training lead, OpenAI entered into agreements for computing power that assume a revenue trajectory the company hasn’t hit. The five-year, $300 billion deal with Oracle is the clearest example. It was underwritten on the belief that ChatGPT’s user base would grow without friction toward the billion-user mark, generating subscription and API revenue sufficient to cover the monthly burn of GPU clusters at that scale.
When the Sarah Friar memo signaled that those projections weren’t materializing, Oracle’s stock didn’t just react to OpenAI’s bad news. It reacted to the realization that its own data center financing model has a single point of failure. CoreWeave, which recently completed an $11.9 billion infrastructure deal with the startup, faces the same exposure. These companies have effectively “leveraged up” on a growth curve that has now flattened.
“The market is discovering that compute contracts written against infinite growth assumptions become toxic assets the moment the growth assumption breaks. OpenAI didn’t just miss a user target; it invalidated the pricing model for an entire generation of AI infrastructure.”
Dan Ives, Senior Equity Analyst, Wedbush Securities — Wedbush Research Note, April 28, 2026
The Inference-Utilization Gap: A report from TechNewsWorld indicates that roughly 95% of enterprise GPU capacity currently sits idle. Companies bought hardware for AI projects that aren’t yet production-ready, creating a capital overhang that could suppress new GPU orders well into late 2026.
The broader implication is what analysts are calling an “efficiency audit” across enterprise AI. The FOMO-driven GPU buying cycle of 2024 and 2025 has left corporations with hardware they can’t fully use, billed at rates that assumed full utilization. As those utilization reports come in, the pressure on Nvidia and AMD isn’t just competitive; it’s arithmetic.
The SoftBank Contagion and the Arm Holdings Margin Call
No entity is more directly exposed to the OpenAI growth wall than Masayoshi Son’s SoftBank Group. The Japanese conglomerate has committed $22.5 billion to OpenAI funding, according to Reuters, and to raise that capital it executed a series of aggressive asset sales including its entire $5.8 billion stake in Nvidia and $4.8 billion of T-Mobile holdings. The logic was sound in a world of infinite AI growth. In a world of finite user engagement, it looks like a concentrated bet on the wrong side of a turning point.
The structural risk deepens because of Arm Holdings. SoftBank reportedly tapped undrawn margin loans secured against its Arm stake to fund a portion of the OpenAI obligations. When Arm fell 7.7% on the news, the collateral value of those loans compressed in real time. The result was a near-10% drop in SoftBank’s Tokyo-listed shares. The concern now circulating among institutional investors is clear: if OpenAI’s valuation is revised downward ahead of its targeted late-2026 IPO at a $1 trillion target, the margin call risk on SoftBank’s Arm-backed loans becomes a market event in its own right.
Entity
Share Move (Apr 28)
Primary Exposure
Risk Vector
SoftBank Group
-9.9%
$22.5B OpenAI funding commitment
Margin loans against Arm collateral
Arm Holdings
-7.7%
Primary SoftBank loan collateral
Collateral compression risk
Oracle
-7.0%
$300B 5-year compute contract
Anchor tenant default risk
CoreWeave
-7.4%
$11.9B infrastructure deal
Revenue dependency on OpenAI growth
AMD
-5.3%
GPU demand from cloud providers
Idle capacity reducing future orders
Nvidia
-3.8%
GPU cluster dominance
Agentic shift toward CPU inference
The Magnificent Seven Crucible: Four Earnings Reports That Define the Cycle
The selloff of April 28 was a preview. The main event runs tonight. Alphabet, Microsoft, Meta, and Amazon collectively committed roughly $600 billion in AI-related capital for 2026, and each faces a different version of the same pressure: prove that the spending is generating returns at the pace implied by their valuations, or face a re-rating that no amount of forward guidance can easily reverse.
Alphabet: The TPU Counter-Narrative
Alphabet enters earnings with a structural advantage its competitors can’t easily replicate. While rivals bid against each other for Nvidia’s H200 and B100 GPUs, Google has been scaling its custom Tensor Processing Unit clusters for years. Google Cloud analysts project a 50% revenue surge to $18.4 billion this quarter, driven in part by enterprise adoption of TPU-powered AI services. That number, if confirmed, would represent the single strongest argument against the “AI monetization is failing” thesis.
The real wildcard is “AI Mode.” Google’s new search paradigm integrates directly with the Universal Commerce Protocol to convert conversational queries into transactions. Internal data suggests a 14% to 27% conversion lift versus standard search ads. If Alphabet can show that this lift is translating into revenue per query, it may successfully decouple its valuation from the OpenAI-adjacent selloff entirely.
Microsoft: Azure Growth vs. the Workforce Paradox
Microsoft is down 11% year-to-date, its worst start since 2008, and it needs a strong Azure print to stop the bleeding. Analysts expect Azure growth of 37% to 38%, which would be healthy by any historical standard. The optics problem isn’t the revenue; it’s the cost structure. Microsoft is reportedly offering voluntary buyouts to roughly 7% of its U.S. workforce to manage the margin squeeze from its AI capex cycle. This is the efficiency paradox in action: the world’s most profitable software company is cutting headcount to fund the hardware that’s supposed to replace headcount.
Investors will also listen for any revision to the renegotiated pact between Microsoft and OpenAI. The recent update to that agreement, which allows OpenAI to forge deals with Microsoft’s direct competitors, signals a cooling of what was once an exclusive partnership. That’s a material shift in Microsoft’s AI moat story.
Amazon: The $200 Billion Question
Amazon has guided toward $200 billion in capital expenditure for 2026, the largest in its history and the largest single-company commitment to AI infrastructure the world has ever seen. AWS sales are projected to grow 26%, up from 24% in the prior quarter. The stock is up 25% in April, reflecting investor confidence that Amazon’s retail margin recovery can buffer its AI spending. But the 95% GPU idle-capacity finding complicates that confidence: if LLM training demand plateaus, Amazon may find itself operating the world’s most expensive underutilized asset base.
Meta: Efficiency or Attrition?
Meta is guiding for $115 to $135 billion in 2026 infrastructure spending while simultaneously planning to cut another 10% of its workforce next month. Sales growth is expected to hit 31%, the fastest since 2021, but free cash flow is projected to drop to a four-year low of $3.9 billion as AI capex consumes the surplus. Meta’s Llama open-source strategy is central to its long-term positioning, but the near-term math is tight enough that any advertising softness could flip the narrative from “efficiency play” to “margin crisis” overnight.
Company
2026 AI Capex
Key Metric to Watch
Pre-Earnings Sentiment
Amazon
~$200B
AWS revenue growth (target: 26%)
Bullish (+25% in April)
Alphabet
$175-$185B
Google Cloud growth (target: 50%)
Optimistic (+12% YTD)
Meta
$115-$135B
Free cash flow (risk: 4-yr low)
Cautious (workforce cuts)
Microsoft
~$176B (FY27)
Azure growth (target: 37-38%)
Bearish (-11% YTD)
Google’s Universal Commerce Protocol: The Exit Ramp from the Chatbot Era
The human-to-chatbot interaction model has a ceiling. The industry now knows where it is. What comes next is the question that the Universal Commerce Protocol is designed to answer.
Launched by Google in January 2026 and substantially expanded in a major March 2026 update detailed on the Google Developers Blog, the UCP is an open-source standard that gives AI agents a direct channel into merchant backends. It goes beyond surfacing product recommendations; it enables an agent to add items to a cart, apply membership pricing, verify inventory in real time, and complete a checkout transaction, all within the conversational interface. The shift is from AI as advisor to AI as executor.
Why this matters for search margins: Google moved UCP-powered ads in “AI Mode” from experimental to primary placement status in April 2026. If the 14% to 27% conversion lift implied by internal data holds at scale, it would represent the most significant uplift in Google’s revenue-per-query metric in over a decade, potentially offsetting the long-term erosion of traditional blue-link search.
The March update to the UCP introduced four functional primitives that collectively solve the “cart abandonment” problem that has cost mobile commerce an estimated $400 billion in annual revenue globally.
🛒
Cart Support
Agents add items from multiple vendors into a single unified basket, enabling one-checkout cross-retailer shopping without leaving the AI interface.
🔑
Identity Linking
User loyalty data binds directly to the agent’s identity, guaranteeing member-only pricing and reward points are applied without manual login.
📦
Live Product Catalog
Real-time inventory and pricing pulls from merchant stores, eliminating AI hallucinations about stock availability or variant options.
💳
Native Checkout
Handles the full payment transaction within the AI interface or the retailer’s own UI, reducing the number of steps between intent and purchase.
The UCP’s commercial coalition already includes Shopify, Etsy, Wayfair, Target, and Walmart. By building a vendor-agnostic standard, Google is attempting to create a commerce layer that works across ChatGPT, Copilot, Gemini, or any future agent. The retailers’ primary incentive is maintaining their status as “Merchant of Record,” which preserves direct customer data ownership. For Google, it’s about owning the transaction protocol that captures a slice of global commerce regardless of which AI assistant a consumer chooses to use.
OpenAI is pursuing a parallel track. Its own advertising pilot, launched in late March 2026, surpassed $100 million in annualized revenue within six weeks, per The Information. That’s a striking number for a product still in pilot phase, and it underscores how desperately the industry needs revenue streams beyond the $20-per-month subscription model that has defined AI monetization since 2023.
Intel’s CPU Renaissance and the End of the GPU Monoculture
The most counterintuitive story of April 28 was Intel surging 20% on a day when the Philadelphia Semiconductor Index had its worst session in a month. The divergence isn’t a market anomaly; it’s a signal about where the next phase of AI compute is heading.
The catalysts are structural. First, the Trump administration took a 10% stake in Intel in late 2025 as part of a “Sovereign Silicon” initiative, positioning the chipmaker as the domestic alternative to a GPU supply chain concentrated in Taiwan and dependent on Nvidia’s pricing power. Second, and more fundamentally, the agentic commerce paradigm described by the UCP doesn’t require the same compute profile as training a frontier model.
“Agents running on UCP don’t need a supercomputer. They need a very fast, very reliable CPU that can handle context, memory, and transactional logic at scale. That’s a completely different hardware requirement from what drove the GPU boom, and Intel is positioned for exactly that workload.”
Patrick Moorhead, Chief Analyst, Moor Insights & Strategy — Moor Insights Research, April 2026
The data makes the case starkly. Enterprise GPU clusters are running at roughly 5% average utilization. Intel’s agentic CPU nodes, by contrast, are operating at approximately 85% utilization. The market is bidding Intel up not on hope, but on evidence of actual throughput demand.
Metric
GPU Clusters (Training)
CPU Clusters (Agentic/Inference)
Utilization Rate
~5% (enterprise average)
~85% (Intel/agentic nodes)
Primary Supplier
Nvidia / AMD
Intel / Arm / Google TPU
Energy Intensity
Extremely high
Moderate to high
Growth Trend
Cooling / oversaturated
Surging / undersupplied
Geopolitical Profile
Taiwan-dependent supply chain
Domestically manufacturable (U.S./EU)
The integration of the Model Context Protocol (MCP) further accelerates this CPU-centric shift. MCP allows agents to understand a retailer’s business logic without requiring a full technical overhaul of that merchant’s systems, lowering the barrier to entry for smaller participants. The net effect is a more distributed, less compute-intensive AI economy, which is structurally bad for Nvidia’s growth thesis and structurally good for Intel’s.
Oil at $115, the Fed’s Final Act, and the Energy Tax on AI
The tech sector’s search for a sustainable monetization model is playing out against a worsening macro backdrop. Crude oil jumped to $115 per barrel on April 29, the highest since June 2022, driven by the ongoing conflict in Iran and compounded by the UAE’s decision to exit the OPEC+ alliance effective May 1, 2026. For the operators of AI data centers, whose energy bills were already rising sharply before this latest spike, these are not rounding errors.
Georgia Power’s six rate hikes over the past three years provide a local example of a global trend: the AI Data Center Boom is straining power grids and driving up the operational cost base for every company in this sector. At $115 oil, those energy costs become a measurable drag on the margin story that each Magnificent Seven company will try to tell tonight.
Fed risk: Jerome Powell is expected to maintain a “higher for longer” rate posture at this week’s FOMC meeting, partly in response to the oil-driven inflation spike. For high-growth tech stocks priced on discounted future cash flows, a hawkish Fed is the macro equivalent of a headwind at full throttle. The earnings tonight need to be exceptional to overcome the combined drag of OpenAI growth concerns, energy cost inflation, and rising discount rates.
There is, however, a security angle that works in the industry’s favor. The FTC’s 2025 annual report on social media fraud found that investment scams on Meta-owned platforms generated more than $1.1 billion in losses, with AI-generated deepfakes playing a growing role. This “security tax” on the digital economy is one of the clearest arguments for agent-based payment systems like the UCP, which uses tokenized payments and verifiable credentials to re-establish transactional trust in an environment where human-to-human digital interaction has become increasingly unreliable.
Google’s push for Merkle Tree Certificates in the context of the UCP addresses this directly. These cryptographic structures allow for verification of large datasets without processing the entire data set, providing proof of user consent for every agent-executed transaction. It’s a post-quantum security architecture built into the commerce layer from the start, not bolted on after the fact.
Frequently Asked Questions
Did OpenAI really miss its 1 billion weekly active user target?
Yes, according to an internal report first published by The Wall Street Journal on April 28, 2026. OpenAI failed to reach 1 billion weekly active users by the end of 2025, the company’s own internal milestone, and also missed several consecutive monthly revenue targets. The report referenced a memo from CFO Sarah Friar that flagged these shortfalls to senior leadership.
How does the OpenAI revenue miss affect Microsoft and Oracle?
Both companies have major financial exposure. Oracle holds a five-year, $300 billion compute contract with OpenAI, which markets are now treating as a credit risk. Microsoft, OpenAI’s largest strategic partner, has committed roughly $176 billion through FY27 and has seen its stock fall 11% year-to-date partly on fears that its OpenAI bet won’t generate expected returns.
