Open‑sourcing a worm: TeamPCP releases Shai‑Hulud on GitHub, raising legal alarms

A worm goes public

Security researchers at Ox discovered two GitHub repositories that contain the full source code of the Shai‑Hulud worm, a supply‑chain malware family that has been compromising npm packages, SAP modules and other developer tools since late 2025. The repositories carry the banner “Shai‑Hulud: Open Sourcing The Carnage” and are licensed under the permissive MIT licence.

Within hours the projects were forked dozens of times – five forks on one repo and thirty‑nine on the other – and a pull request from a user called agwagwagwa added FreeBSD support. The rapid forking shows that independent actors are already adapting the code for their own campaigns.

How Shai‑Hulud works

1. Supply‑chain infection – The worm injects a malicious post‑install script into npm packages that are then published to the public registry. Developers who install the compromised package automatically execute the payload.
2. Credential harvesting – Once on a victim machine, the worm searches for cloud‑service keys (AWS, GCP, Azure) and GitHub personal access tokens stored in configuration files or environment variables.
3. Self‑propagation – Stolen credentials are used to create new private repositories, push poisoned code, and open pull requests that appear legitimate. This creates a feedback loop that spreads the worm to new projects.
4. Destructive fallback – If the worm cannot obtain usable credentials, it may wipe local files or delete the infected package to cover its tracks.

The code retains the same patterns observed in earlier attacks – base‑64‑encoded payloads, dynamic C2 URL generation, and a hard‑coded list of known npm packages used as infection vectors.

Legal basis: why open‑sourcing malware matters

GDPR (EU)

• Article 32 – Security of processing requires controllers to implement appropriate technical and organisational measures. Distributing code that deliberately undermines those measures can be interpreted as facilitating unlawful processing of personal data.
• Article 5(1)(f) – Integrity and confidentiality obliges controllers to ensure that personal data are processed in a manner that ensures appropriate security. Providing a ready‑made tool for mass credential theft breaches this principle.
• Article 83 – Administrative fines allows supervisory authorities to levy penalties up to €20 million or 4 % of global annual turnover, whichever is higher, for violations that result in a data breach.

CCPA (California)

• Section 1798.150(b) defines a “security breach” as the unauthorized acquisition of personal information. Publishing a worm that automates such acquisition can be treated as a negligent act, exposing the publisher to statutory damages of $2,500–$7,500 per violation and civil penalties of up to $2,500 per violation for each unintentional breach.

U.S. federal law

• The Computer Fraud and Abuse Act (CFAA) criminalises the intentional transmission of a program that causes damage to a protected computer. While the MIT licence does not provide immunity, the act of publishing the code with the explicit intent to enable further attacks could be viewed as a conspiracy to commit computer fraud.

Impact on users and companies

• Developers may unknowingly pull compromised packages, exposing their local environments and any linked cloud accounts.
• Enterprises that rely on open‑source components could face massive credential leaks, leading to ransomware extortion, data exfiltration, or service disruption.
• Cloud providers risk large‑scale abuse of stolen keys, which can inflate usage bills and damage brand reputation.
• Regulators will likely treat any breach caused by the worm as a violation of GDPR/CCPA obligations, triggering investigations and potential fines.

What organisations should do now

1. Audit the npm ecosystem – Run tools such as npm audit, Snyk, or GitHub Dependabot to identify any packages that match the known Shai‑Hulud signatures.
2. Rotate and revoke credentials – Immediately invalidate all AWS, GCP, Azure and GitHub tokens that may have been exposed. Use short‑lived tokens and enforce MFA.
3. Implement supply‑chain hardening – Adopt signed packages (e.g., Sigstore), enforce provenance checks, and require code‑review policies for any third‑party dependencies.
4. Monitor GitHub activity – Set up alerts for new repositories that contain the worm’s hash or for unusual pushes to private repos from newly created accounts.
5. Update incident‑response playbooks – Include a scenario for a supply‑chain worm that exfiltrates cloud credentials, and test the response regularly.
6. Legal compliance check – Review GDPR and CCPA obligations in light of the breach. Document the incident, notify supervisory authorities within 72 hours (GDPR Art. 33), and inform affected California residents as required by the CCPA.

Why open‑sourcing malware is a red line

By releasing the code under an MIT licence, TeamPCP removes the usual barrier that keeps sophisticated tools in the hands of a limited group. The licence explicitly permits “any use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies.” In the context of malicious code, this means that a low‑skill attacker can simply clone the repo, change the C2 server address, and launch a full‑scale campaign without writing any code.

The open‑source model also complicates platform‑provider responsibilities. GitHub’s Terms of Service prohibit the distribution of malicious software, yet the repositories remain live. This inaction may expose Microsoft to “failure to act” claims under the Digital Services Act (EU) if the platforms are deemed to have knowingly facilitated illegal content.

Looking ahead

The Shai‑Hulud episode illustrates a worrying trend: cyber‑criminals are borrowing the collaborative ethos of open source to accelerate weaponisation. Regulators are likely to tighten enforcement around the publication of malicious code, and platforms may introduce stricter automated scanning for dangerous repositories.

For now, the safest defence is vigilance: keep supply‑chain tooling up to date, enforce strict credential hygiene, and treat any open‑source component as a potential attack surface.

---

Sources: Ox research brief (2026‑05‑13), GDPR text, CCPA statutes, Microsoft GitHub Terms of Service.