Mini Shai-Hulud Resurfaces (No CVE): GitHub Worm Re-Probe new repo after Floods 1,600 Repos Across 21 Compromised Accounts

Executive Summary

Mini Shai-Hulud is a self-propagating supply chain worm in the broader Shai-Hulud lineage that harvests developer and CI secrets, then publishes the stolen material into freshly created public GitHub repositories carrying the description marker “A Mini Shai-Hulud has Appeared.” It was first tracked across npm and PyPI in May 2026 and attributed to TeamPCP. A scan run on 19 June 2026 shows the worm is active again rather than dormant.

The 19 June probe found 1,614 exfiltration repositories tied to 21 genuinely compromised GitHub accounts, all created under the same description marker and named with Dune-themed prefixes such as kralizec-, sardaukar-, fremen-, and harkonnen-. The worm does not need a software flaw to spread. It runs on stolen identity: a postinstall or workflow execution lifts an npm token or an OIDC-minted publish credential, the worm enumerates what that identity can reach, and it republishes itself or dumps secrets into new repos under the victim’s account. Every stage of this happens without a CVE, without a CVSS score, and without anything a scanner keyed to advisory feeds can see.

For defenders, the operational risk is twofold. First, any account on the victim list is a confirmed secret-exfiltration event, so credentials that ever touched those environments are in scope for rotation. Second, this is a forward-looking npm risk: several compromised GitHub identities also publish packages, and none of those packages are flagged yet. The window between identity compromise and package weaponization is the gap that matters, and the May lineage showed TeamPCP can pivot delivery inside 72 hours.

Check Live tracking dashboard at https://sha1hulud-phoenix.pplx.app 

TL;DR for Engineering Teams

Vulnerability Overview

Protect yourself with the latest threat intelligence, get access to PHOENIX BLUE Today

Technical Anatomy (Root Cause + Exploit Mechanics)

Root Cause Analysis

Compromise account and credentials remain the root cause but there is no single vulnerable function here. The root cause is the trust model around publishing credentials and CI identity. The npm and GitHub ecosystems treat a valid token — whether a long-lived npm automation token, a GITHUB_TOKEN, or an OIDC JWT minted by a CI workflow — as sufficient proof of intent. The worm abuses that. Once code runs inside a developer or CI context, it reads whatever credential material is reachable and uses it exactly as the legitimate owner would. The publish that follows is cryptographically valid, and in the May lineage it carried genuine Sigstore provenance attestations. Provenance proves the artifact was built where it claims; it does not prove the build was honest.

The second structural failure is persistence through AI coding tool configuration. The worm writes into .claude/settings.json, .claude/ hook scripts, .vscode/tasks.json, and similar files. These are read and executed by developer tooling on routine actions, and they are not touched by npm uninstall. Removing the malicious package leaves the persistence in place.

Exploit Path — Three Steps

1. Entry point — Execution lands in a developer or CI environment, either through a poisoned package install hook or through a workflow run on a compromised identity. No import of the package is required; install-time hook execution is enough.
2. Vulnerability trigger — The worm enumerates reachable secrets: npm tokens, GITHUB_TOKEN, OIDC token request endpoints, cloud credentials, and on-disk .env and SSH material. It then uses the identity directly — minting an npm publish token via OIDC where federation is enabled, or reusing a stolen token where one exists.
3. Execution impact — Two outputs. The worm republishes infected package versions under the now-controlled namespace to continue propagation, and it creates public GitHub repositories under the victim’s account holding the exfiltrated secrets, each tagged with the description “A Mini Shai-Hulud has Appeared.”

Campaign Phase Breakdown

• Phase 1 — Initial foothold: Credential capture inside a developer or CI context, following the same playbook as the May 2026 TanStack-origin wave.
• Phase 2 — Expansion: OIDC-minted or stolen npm tokens used to enumerate and republish across reachable namespaces; GitHub tokens used to write directly to branches.
• Phase 3 — Ecosystem targeting: Mass creation of Dune-themed exfil repos under compromised accounts. The 19 June probe attributes the bulk of 1,614 repos to seven high-volume accounts.
• Phase 4 — Persistence: Hook and config injection into .claude/ and .vscode/, which re-executes on developer tool invocation and survives package removal.

The 19 June 2026 Probe — What the Hunt Found

The hunt tool searched GitHub for the worm’s signature: the repository description string “A Mini Shai-Hulud has Appeared.” A raw pass returned 2,009 candidate repos across 142 accounts, mixing genuine victims with detection tooling and research repos that merely quote the marker string in a file. Filtering to the description-source signal only — the worm’s own exfil repos, not code or commit mentions — collapsed that to a clean set: 1,614 IOC repositories across 22 accounts, of which one (copyleftdev, running a detection tool named mini-shai-hulud-dragnet) is a confirmed false positive. The real victim count is 21.

The naming scheme is consistent across all victims. Repos combine a Dune-faction prefix with a Dune-object middle and a numeric suffix — kralizec-cogitor-256, sardaukar-thumper-839, fremen-navigator-289, harkonnen-phibian-466. The top theme prefixes by volume were kralizec (111), powindah (110), and sardaukar (109); the top middles were heighliner (113), phibian (112), and stillsuit (107). This is templated, automated repo generation, not hand-crafted naming.

New Compromised accounts

Compromised Accounts (description-source, 19 June 2026)

The top seven accounts hold roughly 1,520 of the 1,614 repos. This concentration is consistent with a small number of high-value identities — likely CI service accounts or prolific maintainers — being looped repeatedly by the worm, while the long tail of single-repo accounts represents one-shot captures.

Similar tactic and techniques 

IOCs

Affected Versions

This wave is identity-level, not version-level. No new poisoned package versions were confirmed by the 19 June probe — the actionable artifact is the set of compromised accounts and their exfil repos. For continuity, the package inventory from the May 2026 Mini Shai-Hulud wave remains relevant for any environment that resolved dependencies during that window.

The 19 June hunt cross-referenced the 21 compromised accounts against the known compromised-package database and found zero matches. None of the npm packages published by these identities is currently flagged. The single npm link surfaced (copyleftdev-guthubcheck) belongs to the detection-tool false positive, not a victim. That clean result is not reassurance — it is the warning. These are compromised identities whose secrets are already exfiltrated, and the packages they publish are the most likely next delivery vehicle.

Exposure Analysis

Real-World Impact

The scale signal in this probe is the repo count, not download numbers. 1,614 exfil repositories created under a single description marker, concentrated in 21 accounts, on a single day’s scan, is evidence of an active automated propagation loop. Each repo represents a captured secret bundle published to the public internet under a victim’s name.

Realistic attack scenarios from this position:

• Account takeover chaining: A compromised GitHub identity that also holds npm publish rights becomes a launch point for poisoning that maintainer’s packages — the exact mechanism that produced the May wave’s 170-package blast radius.
• Cloud credential theft: Secrets harvested into exfil repos include cloud keys, enabling movement out of the dev/CI plane into production infrastructure.
• Persistence beyond removal: Injection into AI coding tool config means the worm re-executes on routine developer actions even after the triggering package is uninstalled.
• Downstream supply chain poisoning: The forward-looking risk — today’s compromised identity is tomorrow’s poisoned package, distributed to every consumer of that package.

Detection Guidance

Log Indicators

• GitHub audit log: repository creation events with description exactly matching A Mini Shai-Hulud has Appeared.
• Repository names matching the pattern {word}-{word}-{int} drawn from the Dune lexicon above, created in bulk under a single account in a short window.
• npm publish events from CI runners minting fresh OIDC tokens outside expected release workflows.
• Unexpected commits to .claude/ or .vscode/ paths, particularly those authored to mimic the Claude Code GitHub App identity.
• Outbound traffic to decentralized messaging bootstrap nodes (Session network) from CI or developer hosts, consistent with the May lineage exfil channel.

Scanner References

• Phoenix Security scanners — match the 21 compromised accounts and the exfil-repo IOC pattern against your maintainer and dependency inventory; flag any first-party or transitive package published by a listed identity.
• SCA / SBOM tooling — resolve your full dependency tree and check maintainer attribution against the account list, not just package names.
• GitHub dependency and secret scanning — enable across all repositories; alert on the description marker.
• External attack surface management — identify which internet-facing services run packages maintained by the affected identities.

Verification Steps for Teams

1. Search GitHub org audit logs for any repo created with the marker description, and for the Dune naming pattern.
2. Cross-reference your dependency inventory against the 21 compromised accounts; list every direct and transitive package they maintain.
3. Grep all repositories for injected .claude/ and .vscode/ hooks and config not authored by your team.
4. Review SBOMs for transitive dependencies whose maintainer handle appears on the list.
5. Audit CI runner logs for unexpected npm publish or OIDC token-request activity during June 2026.

Remediation Guidance

Immediate Actions

1. Treat every credential reachable from a listed account’s environment as exposed. Rotate npm automation tokens, GITHUB_TOKEN and PATs, OIDC-federated publish trust, and any cloud keys (AWS access keys, role ARNs) that touched those contexts.
2. Report and request takedown of exfil repositories under the marker description; do not clone them into internal infrastructure.
3. Remove worm persistence explicitly. Delete injected files under .claude/ and .vscode/ — npm uninstall will not remove them. Inspect .claude/settings.json and .vscode/tasks.json for unauthorized hook entries.
4. Add the 21 accounts and their published packages to a monitored watchlist so any new version triggers manual review before it resolves into a build.

Temporary Mitigations

1. Block the description string A Mini Shai-Hulud has Appeared and the Dune naming pattern in repository monitoring and CI policy gates.
2. Disable OIDC trusted-publishing federation on any CI workflow that does not strictly require it; require human-gated publish for high-value namespaces.
3. Pin dependencies to known-good versions and enforce lockfile integrity; do not float to latest for any package maintained by a listed identity.
4. Apply egress filtering on CI runners and developer hosts to constrain exfiltration over decentralized messaging channels.

There is no version to upgrade to here — the remediation is rotation, takedown, and persistence removal, not a patch.

Phoenix Security Recommendations

Mini Shai-Hulud is the structural case for behavioral, identity-aware supply chain detection rather than advisory-fed scanning. Every stage of this campaign produces no CVE, so a CVE-keyed scanner sees nothing across all 1,614 repos and 21 accounts.

• Contextual deduplication — correlate the account-level IOC signal with package and repository findings across scanners into one prioritized backlog, so a compromised maintainer identity surfaces once with full context rather than as scattered alerts.
• Reachability analysis — determine which packages maintained by the affected accounts are actually reachable in your runtime, separating the forward-looking watch items that matter from inventory noise.
• Remediation campaigns — stand up a campaign for the 21 accounts, assign maintainer and repo owners, track token rotation and persistence cleanup to closure, and verify against runtime exposure.
• Vulnerability ownership attribution — map every affected dependency to the responsible internal team automatically, so rotation and review land with the people who can act.
• Attack surface management — identify internet-exposed services running packages tied to the compromised identities before a follow-on wave weaponizes them.

Phoenix Security correlates compromised maintainer identities with the packages they publish and the runtime workloads that consume them, then assigns remediation ownership — turning a 1,614-repo exfil event into an owned, trackable backlog before the next package goes live.

Protect yourself with the latest threat intelligence, get access to PHOENIX BLUE Today

External References

Mini Shai-Hulud hunter probe output, 19 June 2026 (internal Phoenix telemetry — clean run mini_shai_hulud_hunt_20260619_120153.json)

Phoenix Security Malware Analysis https://phxintel.security/malware.html 

Phoenix Security — original Mini Shai-Hulud campaign analysis (May 2026 TanStack-origin wave)

OpenSourceMalware.com — Mini Shai-Hulud campaign tag #mini-shai-hulud

socket.dev — supply chain attacks, Mini Shai-Hulud and Shai-Hulud lineage tracking

Phoenix Security editorial archive — phoenix.security/?s=sha1

phxintel.security — live IOC and malicious package intelligence feed