TeamPCP just released the source code for the Shai-Hulud worm. With bounties. They’re paying people to use it in supply chain attacks. If that doesn’t tell you everything about the state of cybersecurity in 2026, the rest of this week probably will.

While they were doing that, Microsoft was scrambling to publish mitigations for an actively exploited Exchange Server zero-day. And Rocky Linux quietly admitted that the upstream Enterprise Linux release model is too slow to handle real exploitation timelines, so they built a separate repository for emergency security fixes. None of these things are happening in isolation. They’re all signs that the people writing exploits ship faster than the people writing patches.

Yes, the worm is on GitHub now

Shai-Hulud spent most of the year as an npm supply-chain headache that kept reappearing in signed packages. Now its operators have published the source code and offered monetary rewards for anyone who uses it to compromise upstream maintainers. Read that sentence again. The development team running an active worm has issued an open call for contributors and posted a bug bounty, except the bounty pays for damage instead of fixes.

This isn’t theatrical. It mirrors what successful open source projects do to scale: lower the barrier to contribution, attract talent with money, and let derivatives multiply. The difference is that the resulting forks all target your build pipeline. Every team running an npm install in CI just gained a wider attack surface than they had last week, because the population of people capable of writing supply chain malware expanded by an order of magnitude overnight.

If you ever wondered why threat detection vendors keep talking about behavioral signals over signature matching, this is why. Signatures assume a finite set of authors. Open source malware has no such limit.

Microsoft shipped another XSS this week, and it cost you

CVE-2026-42897 is a cross-site scripting flaw in on-premises Exchange Server, rated 8.1, exploited in the wild, with attackers crafting emails that trigger arbitrary code execution against Outlook on the web users. Microsoft’s response was to ship mitigations and tell admins to apply them quickly. The vulnerability was reported by an anonymous researcher.

It’s worth pausing on how unglamorous this bug class is. XSS in webmail has been a known risk for over twenty years. The fact that it still produces high-severity, actively exploited zero-days in the most deployed enterprise mail server on the planet shows how hard it is to ship a complex web application that renders untrusted input safely. There is no version of this story where Microsoft “tries harder” and the bug class disappears.

So you patch. And then you find out, like Rocky Linux apparently did, that the patch pipeline itself is the bottleneck. Their new opt-in Security Repository ships urgent fixes when public exploit code exists and upstream patches are still pending. The default repo behavior stays predictable, which is the right call. But the existence of the repo is the news. A major distribution acknowledged out loud that waiting for upstream is incompatible with active exploitation.

What you actually do this week

None of this is hopeless. It’s just a reminder that your defensive posture has to assume the attacker has better tooling, faster distribution, and lower friction than your IT change management process allows. Here is what’s worth doing immediately, regardless of which of this week’s stories applies to you:

• Pin and inventory your build dependencies. If you can’t tell me what version of every transitive dependency made it into your last npm install, you can’t tell me whether Shai-Hulud’s next variant got in either. Lockfiles, mirrored registries, and signed package verification are the bare minimum.
• Treat Outlook on the web like an untrusted browser tab. Restrict OWA access to managed devices, enforce conditional access, and turn off any rendering features you don’t need. The Exchange XSS flaw exists because email is essentially a remote code execution channel that you’ve been told is safe.
• Egress filter your management plane. If a compromised Exchange or build server can’t reach an arbitrary command and control host, the bug becomes far less useful. Default-deny outbound from server VLANs is one of the highest-leverage controls you can deploy this quarter, and it pairs naturally with whatever firewall you already run at the edge.
• Write down your tolerance for accelerated patching. Rocky Linux gave you the framework: there’s the predictable cadence, and there’s the emergency lane. Decide ahead of time which systems get the emergency lane, who can authorize it, and what the rollback plan looks like. Don’t make those decisions during an incident.
• Invest in behavioral threat detection. Signature-based threat-protection cannot keep up with open source malware where every fork mutates. Behavioral baselines on identity, build systems, and endpoint process trees catch the patterns that signatures miss, including credential brute-force attempts and post-compromise lateral movement.

None of this is novel advice. It’s the same security hardening playbook teams have been writing since perimeter brute-force attacks were the main concern. The shift is that each of these controls now has to assume your firewall, your patch cycle, and your antivirus engine are all running behind the curve. Defense in depth stops being a buzzword the moment any single layer is guaranteed to fail.

Your cybersecurity stack vs. their roadmap

The uncomfortable truth this week is that the attacker side has better release engineering than most enterprises. They have public source repositories. They have monetary incentives for contributors. They have a distribution channel via npm and similar registries. They iterate on exploits within days of disclosure, sometimes hours. And the defender response, on average, is a quarterly patch cycle gated by change advisory boards.

Rocky Linux’s opt-in repo isn’t a complete answer, but it’s the right shape of an answer: separate the predictable from the urgent, and let teams who need speed opt into it without breaking everyone else. Apply that model to your own incident response process. Apply it to your CI/CD pipeline. Apply it to your detection engineering backlog.

The asymmetry isn’t going away. The teams that hold up best are the ones that stop pretending it doesn’t exist and start designing around it. Hardening your environment for a world where the attacker ships faster than you do is what cyber security actually looks like in 2026.

Sources

• TeamPCP Ups the Game, Releases Shai-Hulud Worm’s Source Code
• Microsoft warns of Exchange zero-day flaw exploited in attacks
• On-Prem Microsoft Exchange Server CVE-2026-42897 Exploited via Crafted Email
• Rocky Linux launches opt-in security repository for urgent fixes