Shai-Hulud: supply-chain token theft — why FIDO2 MFA is non-negotiable

Excerpt — On June 12, 2026, Zscaler documented the “Shai‑Hulud” campaign: GitHub/npm/PyPI account takeovers, OIDC abuse, and public IOCs. Here’s why phishing‑resistant MFA (FIDO2/WebAuthn) meets GDPR Article 32 and blocks attacker access.

What happened

On June 12, 2026, Zscaler ThreatLabz published an in‑depth analysis of “Shai‑Hulud,” an active campaign targeting the open‑source software supply chain (npm and PyPI), with confirmed waves in March, May, and early June 2026. Operators first captured TOTP codes via Adversary‑in‑the‑Middle (AiTM) phishing, then shifted to abusing CI/CD workflows and OpenID Connect (OIDC) “trusted publishing” to ship malicious packages with seemingly valid SLSA provenance. Between June 1 and 2, 2026, a Red Hat engineer’s GitHub account was reportedly compromised, allowing a burst release of 32 packages and 96 versions within hours. Researchers also describe a network ruse: a C2 channel masked behind a non‑existent path to “api.anthropic.com/v1/api.”

Key indicators of compromise (IOCs) include defender‑friendly files and hashes: persistent “.pth” files in Python site‑packages (e.g., “litellm_init.pth,” “-setup.pth”), “_index.js” scripts with prompt‑injection headers, and SHA‑256 hashes such as dc48b09b2a5954f7ff79ab8a2fd80202bd3b59c08c7cdbc6025aa923cb4c0efe and e1342a80d4b5e83d2c7c22e1e0aaa95f2d88e3dbf0d853a4994b180c93a4b17d for “_index.js” variants. The analysis stresses that early waves exploited OTP‑based 2FA via real‑time phishing, whereas a switch to FIDO2/WebAuthn would have blocked that initial step. Source: Zscaler ThreatLabz, June 12, 2026.

The applicable legal framework

For any entity processing personal data in the EU, GDPR Article 32 mandates “appropriate technical and organisational measures,” considering state of the art, costs, processing nature, and risks. Securing engineering accounts, code repositories, and CI/CD pipelines falls directly under this obligation whenever personal data (customers, employees, logs, test datasets, etc.) could be impacted by upstream compromise. References: EDPB — Article 32 and CNPD Luxembourg — Chapter IV.

For public security and essential/important entities, NIS 2 (Article 21(2)(j)) explicitly lists multi‑factor authentication and secure communications as baseline measures. ENISA’s technical guidance notes that some methods (SMS/OTP) are vulnerable to hijacking and recommends phishing‑resistant factors (FIDO2/WebAuthn) for sensitive access (administration, CI/CD, secrets management). References: ENISA — NIS2 Security Measures and the text reminder: NIS 2, Art. 21.

The technical solution to deploy

Phishing‑resistant MFA (FIDO2/WebAuthn) for privileged accounts and build chains:

• Principle: public‑key authentication bound to the domain (origin binding); no reusable secret or code entry; local challenge‑response with hardware‑backed or secure‑enclave signature.
• In practice: enable FIDO2/WebAuthn passkeys on GitHub, GitLab, npm, PyPI, cloud registries, and VPN/SSO; disallow TOTP/SMS for CI/CD roles, org owners, publishing accounts, registries, and cloud consoles.
• Associated controls: Conditional Access policies (key enrollment, legacy auth block), authenticator attestation when available, and re‑authentication for sensitive actions (package publish, secret rotation).

Why this counters Shai‑Hulud: earlier intrusions leveraged real‑time OTP interception (AiTM). With FIDO2/WebAuthn, a phishing page cannot validate the challenge because the origin doesn’t match. Binding publishing to FIDO2 keys on hardened endpoints further reduces OIDC session/token hijack risks.

Reference standards: ISO 27001:2022 — Annex A.5.15, A.8.2, A.8.3, A.8.20; NIST CSF 2.0 — ID.AM, PR.AC; CIS Controls v8 — IG1/IG2 for IAM and MFA.

How Luxgap delivers this

• Our ISO 27001 governance: scoping of high‑risk roles (publishing, CI/CD, cloud root), “phishing‑resistant by default” MFA policy, secure enrollment procedures (attestation/key registry, loss/rotation), and evidence (signed auth logs, quarterly reviews).
• Our 24/7 managed SOC: correlating IAM/SSO events (anomalous enrollments, off‑hours auth attempts, repeated FIDO2 failures, unusual OIDC calls from runners), hunting Shai‑Hulud IOCs on CI/dev hosts (“.pth” files, “_index.js,” IDE paths like .vscode/tasks.json, .claude/settings.json), and network blocking of known C2/artifacts.
• Our e‑learning platform: micro‑modules for developers and release managers (AiTM, trusted publishing, secrets hygiene, rights review on pull_request_target), with attestations useful for GDPR/NIS 2 audits.

Concrete EU/Luxembourg case

A Luxembourg‑based fintech (subject to NIS 2 and GDPR) used app‑based OTP for GitHub/npm and allowed OIDC publishing from shared runners. In six weeks, we: (1) migrated all “owner,” “publish,” “secrets‑admin,” and “cloud‑admin” roles to hardware FIDO2/WebAuthn; (2) enforced Conditional Access and blocked legacy auth; (3) segmented runners and constrained OIDC to intended audiences; (4) integrated SOC detections for Shai‑Hulud IOCs. Result: publishing is blocked without an approved FIDO2 key, complete audit trails to demonstrate an “appropriate” Article 32 measure, and a documented reduction of illegitimate access risk to repos and secrets.

First practical steps

1. Enable FIDO2/WebAuthn this week for all GitHub/GitLab/npm/PyPI org owners and cloud consoles. Disallow TOTP/SMS for these scopes.
2. Harden your OIDC workflows: limit audiences and permissions, remove unjustified pull_request_target, pin CI tool versions, restrict runner egress, and rotate tokens/npm PATs.
3. Scan CI/dev endpoints for published IOCs (e.g., -setup.pth, litellm_init.pth, _index.js with Zscaler‑listed SHA‑256) and suspicious IDE folders (.vscode, .claude, .cursor, .gemini).
4. Log and retain authentication and publishing events (who, what, when, where); configure SOC alerts on key enrollments, factor changes, and off‑hours publishing.
5. Train your teams: a 30‑minute module on AiTM and publishing best practices (origin verification, signing, secrets review) for developers and release; include a dedicated security awareness session.

Official sources

• Threat intel and IOCs: Zscaler ThreatLabz — “Shai‑Hulud,” June 12, 2026.
• GDPR framework: EDPB — Article 32 (Security of processing) and CNPD Luxembourg — Chapter IV (incl. Art. 32).
• NIS 2 framework: Text of NIS 2 Article 21 and ENISA presentation (NIS 2 measures incl. MFA): ENISA — Security Measures under NIS 2.