Skip to content
You can now search across every topic, entity and event.What's new
Cybersecurity: Threats and Defences
14JUN

Attack worm kit now open-sourced freely

4 min read
11:51UTC

UNC6780 released its Shai-Hulud repository-poisoning worm as open-source under an MIT licence, turning a bespoke operation into a kit anyone can run; a copycat used it to poison 5,561 repositories in six hours.

TechnologyDeveloping
Key takeaway

Shai-Hulud's open-source release commoditises supply-chain poisoning, and valid signatures no longer prove a package is safe.

The UNC6780 supply-chain toolkit has been franchised. Shai-Hulud 3.0 was released as open-source under an MIT licence on 12 May with a $1,000 Monero bounty for the largest attack built on it, turning a bespoke operation into a kit anyone can download 1. UNC6780 (also tracked as TeamPCP) is the financially-motivated cluster that cloned 300-plus Cisco repositories via stolen credentials and roughly 3,800 of GitHub's own internal repositories through a trojanised editor extension . UNC6780 has done this twice before; what is new on 12 May is the technique leaving the originator's hands. A copycat campaign tracked as Megalodon used the kit to poison 5,561 GitHub Actions repositories in six hours, with around 5,718 malicious commits 2.

A variant tracked as Phantom Gyp, observed on 3 June, runs where defenders are not yet looking. It weaponises the binding.gyp native-build file so malicious code runs during npm (the Node package manager, JavaScript's standard dependency tool) install through Node's compiler step. That slips past the preinstall and postinstall hook monitors most software-composition tools watch, the same developer-toolchain surface that the SAP npm, OpenVSX and PyPI compromises first opened .

Worse for the trust model: researchers confirmed valid SLSA provenance attestations (cryptographic signatures proving where a package was built) on malicious packages 3. The signature proves origin without proving the code is clean, so attestation alone is not a control. A defender who treats a valid provenance stamp as a safety guarantee is reading the wrong signal. The shift here is economic as much as technical: poisoning thousands of projects no longer needs a sophisticated operator, only stolen credentials and an evening.

Deep Analysis

In plain English

Software developers rely on shared code libraries, called packages, to build applications quickly. Most developers install packages via automated tools, trusting that the packages are safe. Supply-chain attacks poison those packages with hidden malicious code so that when a developer installs a package, their computer also runs the attacker's code without knowing it. A criminal group called UNC6780 released a tool kit called Shai-Hulud that automates these attacks, and published it publicly in May 2026, offering a $1,000 prize to whoever used it to run the biggest attack. One copycat used the kit to poison 5,561 code repositories on GitHub in six hours. A second variant called Phantom Gyp found a way to sneak past the security checks npm, the most popular package installer, uses to catch malicious code. Security researchers also confirmed that a widely used security certificate system called SLSA gave legitimate-looking certificates to some of the poisoned packages, because SLSA only proves where a package was built, not whether the code inside it was safe.

Deep Analysis
Root Causes

The binding.gyp evasion in Phantom Gyp exploits a specific gap in npm's security model: npm's hook-monitor systems scrutinise preinstall and postinstall script fields in package.json for malicious commands, but the native build step invoked via binding.gyp runs through Node.js's node-gyp compiler infrastructure rather than the npm lifecycle hooks.

Node-gyp was designed to compile C/C++ native extensions legitimately; it predates modern supply-chain security thinking and its execution is not surfaced as a lifecycle event to npm audit tooling.

The SLSA provenance confirmation on malicious packages exposes a conceptual gap in how the supply-chain security community communicated SLSA's guarantees. SLSA Level 2 and 3 attestations prove that a package was built from a specific commit in a specific repository by a specific build system; they do not attest that the commit itself contained safe code.

UNC6780 exploited this gap by building packages from legitimate-looking repositories that contained poisoned dependency declarations, generating valid SLSA attestations on packages that delivered malicious payloads at runtime.

UNC6780's decision to open-source Shai-Hulud under an MIT licence reflects a threat-actor business model shift: the group has moved from conducting targeted supply-chain breaches (the Cisco repository clone via SANDCLOCK credentials, ) to operating as a supply-chain attack platform provider, collecting intelligence on which techniques produce the largest real-world campaigns without conducting those campaigns directly.

Escalation

Elevated and accelerating. The open-source release of Shai-Hulud converts repository poisoning into a commodity attack. The Phantom Gyp binding.gyp evasion, observed 3 June, adds a concrete mechanism that bypasses current npm hook-monitoring defences without a published fix from npm.

What could happen next?
  • Risk

    npm's preinstall/postinstall hook-monitoring does not cover the binding.gyp native build path, leaving packages with native extensions as an unmonitored attack surface until npm ships a fix.

    Immediate · Assessed
  • Consequence

    SLSA provenance attestations confirmed on malicious packages will likely trigger a revision of how SLSA Level 2 and 3 guarantees are communicated in developer-security guidance from OpenSSF and CISA.

    Short term · Reported
  • Precedent

    The Monero bounty model for the largest attack built on an open-sourced framework may signal a new class of threat actor that monetises technique publication rather than direct attack execution.

    Medium term · Reported
First Reported In

Update #7 · VPN zero-day, no-patch KEV, late Exchange

Protos Labs· 14 Jun 2026
Read original
Different Perspectives
Beijing-aligned attribution sceptics
Beijing-aligned attribution sceptics
CNCERT has noted that Western KEV ransomware-risk flags on DoS-only flaws such as Serv-U CVE-2026-28318 conflate disruption capability with breach capability, and that CJEU referrals for NIS2 non-transposition create compliance obligations that presuppose software-patchable architectures the Arista case shows are not universal.
Enterprise security buyers
Enterprise security buyers
Three successive KEV cycles in which federal deadlines precede, exceed or are refused by vendor patches require buyers to re-weight patch-SLA contractual terms: the KEV deadline is now the planning constraint, not the vendor advisory, and procurement due diligence must cover whether a hardware platform is even patchable in principle.
Check Point
Check Point
Check Point disclosed CVE-2026-50751 and shipped a hotfix on 8 June, roughly 30 days after exploitation had begun, with a Qilin affiliate already inside at least one victim. Its delayed disclosure on a CVSS 9.3 perimeter bypass leaves customers to absorb a month-long pre-patch exposure window under CISA's three-day federal deadline.
European Commission and ENISA
European Commission and ENISA
NIS2 full personal-liability enforcement from 1 June and CJEU referrals against laggard member states represent the sharpest regulatory escalation in EU cyber history, backed by ENISA NIS360 sector-maturity evidence naming water, rail and waste water as the priority enforcement targets. NCAF 2.0 and NIS360 function as audit instruments rather than political signals.
UK NCSC
UK NCSC
The NCSC issued the Dutch NCSC's imminent-abuse warning on the Check Point flaw in the same fortnight its sponsoring legislation cleared the Commons, widening incident-reporting duties to cover attacker pre-positioning. The payment-reporting gap left by the CS&R Bill means the NCSC continues to rely on voluntary Early Warning submissions for ransomware economics data.
US Federal CISO community
US Federal CISO community
Federal CISOs face three active compliance obligations without a clean resolution: a three-day Check Point deadline met with a hotfix, a 23 June Arista deadline partially met with ACLs only, and a 16-day Exchange overrun still being fully remediated. BOD 22-01 is operating as an urgency signal but not as a vendor-cooperation mechanism.