The long tail of Mini Shai-Hulud:
24 more repositories the first reports missed

Who reported this first

Socket showed that GitHub re-enabled both actions on 16 September with their May tags still pointing at malicious commits, and recorded that GitHub disabled them again on 25 September. SafeDep listed six repositories that received the worm's hook files between 20 and 24 September: jd-opensource/micro-app, MaaXYZ/MaaFramework, ant-design/pro-components, Moonofweisheng/wot-design-uni, vbenjs/vben-admin-thin-next and nineaiyu/xadmin-client. Aikido opened issue #9704 on pro-components the morning it was hit, and our earlier post reconstructed that run from the repository's own logs. The older June build of the worm that we also found on metersphere was reported first by StepSecurity and then by SafeDep (see below).

SafeDep built its list with GitHub code search and said it could miss repositories. The gap turned out to be structural. In each of the four infected organisation projects we name below, the default branch is clean today and the worm sits only on other branches, which GitHub code search does not index.

We reported every project we name here before publishing. Personal forks and repositories we are still reporting appear only as counts.

What the first reports did not name

How we looked

GH Archive publishes every public GitHub event, hour by hour. We read all 1,776 hourly files from 1 August to 13 October 2026, 161,819,014 events and 36.4 GB compressed, and looked for the shape the worm leaves: github-actions[bot] pushing three or more branches of one repository within 15 seconds. Plenty of ordinary automation makes that shape too: on its own it was the worm only 0.66% of the time.

We checked each burst without downloading anything that could run. We asked raw.githubusercontent.com only for the HTTP status of .claude/settings.json and .vscode/tasks.json at the pushed commit. Then we fetched the commit objects alone, with no trees or files, to read the author and message. A burst counted when both files were present and the commit was a github-actions[bot] commit reusing its parent's message, which is how the payload writes.

70 bursts in 25 repositories passed, 329 branch pushes in all. Every one falls between 20 Sep 02:52 and 24 Sep 21:12 UTC, inside the window when GitHub had re-enabled the actions. The hunt found none outside it.

GH Archive is a partial feed. Two of SafeDep's six repositories, pro-components among them, have no events in it for their worm runs, and a third shows a single push, so the hunt found only three of SafeDep's six. Every count in this post is a floor.

Two more repositories came from outside GH Archive. One of the 22 is a personal fork of element-plus, and checking its upstream found element-plus/element-plus itself, infected in May. A separate sweep of the workflow files of repositories behind packages we track found alibaba/hooks, also infected in May, and the four projects still wired to the action.

Where the worm is, and who has cleaned up

Branch counts below compare .claude/settings.json and .vscode/tasks.json at every branch head with the worm's files by SHA-256. Workflow counts are lines on the default branch that call actions-cool/issues-helper@ or actions-cool/maintain-one-comment@ by tag; the pinned -backup forks are not counted. We re-checked everything on 20 October 2026, 18:30 to 18:37 UTC, logged out, with git ls-remote and raw.githubusercontent.com.

element-plus/element-plus: fixed

The worm wrote 27 branches of element-plus, among them next, generic and perf/table, in two runs about 30 seconds apart at 00:07 UTC on 19 May 2026, the day GitHub blocked the actions. The maintainers pinned every action to a commit the same day, which closed the entry point, but the branches stayed. The project has no security policy and private reporting was off, so on 17 October we emailed the maintainers listed on npm. They deleted all 27 branches, and our re-check at 16:10 UTC on 20 October found none of the remaining 74 infected. Thank you to the element-plus maintainers for the quick fix, and for letting us name the project.

alibaba/hooks: 16 branches since May, and still wired to the action

16 of 28 branches carry the worm, written between 00:28 and 00:31 UTC on 19 May 2026. The default branch, master, is clean. On 20 May the maintainers removed the action from one issue workflow, but two others still call actions-cool/issues-helper@v3 by tag, in three places. Today only GitHub's block on the action stops those runs. We reported it privately on 17 October. Nothing had changed when we re-checked on 20 October.

metersphere/metersphere: two generations of the worm on the same branches

The actions-cool worm first wrote metersphere's dev branch at 00:29 UTC on 19 May 2026. It came back on 21 September, when GH Archive shows github-actions[bot] pushing to four branches within 17 seconds at 00:14:30 UTC. On 20 October, 24 of the 44 branches carried its files, including dev and every v1 release branch. The default branch, v3.x, is clean, and no workflow on it uses actions-cool today.

20 branches also carry an older generation: the June 2026 build of the same worm kit, known as Miasma, which StepSecurity reported first on 3 June. Its hooks run .github/setup.js, and it also plants .gemini/settings.json and .cursor/rules/setup.mdc. SafeDep documented how it forges commits under a maintainer's own name, and its list of infected repositories includes metersphere/helm-chart, but not metersphere/metersphere.

What we add is small. The June build sits on 20 branches of metersphere/metersphere itself. It arrived in June 2026, not through the CI action. Each commit copies its parent's author name, email and date, appends [skip ci] to the parent's message and is unsigned, so the history shows the name and email of a real maintainer, on commits dated as far back as December 2021. On 5 branches, v1.15 and v1.17 to v1.20, the September worm then landed on top: two generations, four months apart, arriving by different routes. Counting both, 39 of the 44 branches carry one worm or the other, and all 39 are in our private report to the maintainers, filed on 17 October.

jdf2e/nutui-react: 41 branches, no reply yet

GH Archive saw one burst, 10 branches in 37 seconds at 07:31 UTC on 21 September; on 20 October, 41 of 49 branches carried the worm. The default branch, feat_v4.x, is clean, but two of its issue workflows still call actions-cool/issues-helper@v3 by tag. The public run list shows a successful run of one of them in each window when the action was live. The project has no security policy and private reporting is off. Its team address bounced on 17 October, so we emailed the maintainers who publish its npm package. We have had no reply.

Four projects still wired to the hijacked action

The workflow sweep found four projects with no worm files on any branch whose default-branch workflows still call the hijacked action by tag:

• antvis/G6 and ant-design/ant-design-charts: nine lines each, in manage-labeled.yml and mark-duplicate.yml, at @v3 and @v3.6.0.
• umijs/umi: maintain-one-comment@v3 once and issues-helper@v3 twice, in issue-checker.yml.
• umijs/dumi: issues-helper@v1 twice, in issue-reply.yml.

Three of them had a successful run of the affected workflow while the action was live. umi's Issue Checker (run 3268) and G6's Mark Duplicate Issue (run 1545) ran between 16 and 25 September, and dumi's Issue Reply (run 1381) on 18 or 19 May. A successful run does not prove the payload ran, and no worm files reached their branches. Only the run logs can settle it, so we recommended rotating any secret those workflows could reach. ant-design-charts shows no run in either window. If GitHub re-enables the actions again, the next issue event runs the payload in all four. We reported umi, dumi and G6 privately on 17 October, and added ant-design-charts to Ant Design's existing private advisory. G6's npm package, @antv/g6, was among those compromised in the separate May npm wave; this finding concerns its GitHub workflows.

19 personal and abandoned forks

19 of the 22 repositories we found in GH Archive are personal forks: 12 of ant-design and seven of other projects. They kept the upstream's issue workflows, and most look abandoned. The ant-design forks were written in the same minutes, at 02:52 and 05:56 UTC on 20 September and 07:53 and 11:06 UTC on 22 September, which fits a scheduled workflow they share. On 20 October all 19 still carried the worm, on 416 branches in all, and in 17 of them the default branch is infected. None has a security contact or open issues, so we reported them to GitHub on 17 October. We do not name personal accounts.

Two more we are still reporting

We are still reporting two more organisation repositories. One carries the worm on its branches and is counted in the 24. The other is not exposed. We will name neither until the owners have been told.

Exfiltration repositories

The payload falls back to exfiltrating through public repositories it creates with a stolen token, under fixed descriptions such as the reversed niagA oG eW ereH :duluH-iahS that Corgea documented in May. The same hunt matched 866 new repositories under 13 accounts whose whole description is one of the worm's markers, created between 4 August and 13 October across several waves. One account alone holds 767, created between 20 and 30 September. We did not open them, and we do not name the accounts: they belong to victims.

Why the worm outlived the clean-up

• Disabling the action stops new runs, not old commits. element-plus and alibaba/hooks were written early on 19 May, the day GitHub blocked the actions, and kept the files for five months.
• The fixes went to the entry point. element-plus pinned its actions the same day, and alibaba/hooks removed the action from one workflow the next day. Neither removed the branches the worm had already written.
• The worm writes to branches nobody watches. It pushes to up to 50 branches with the job's token. Here it sits on release lines, Renovate branches and old feature work. Code search indexes only the default branch, and branch protection and review usually centre on it too.
• Forks run their upstream's automation. Abandoned forks kept scheduled issue workflows that called the action, so they ran the payload in September with nobody watching.
• A commit's author proves nothing. On metersphere, the June build sits in commits that carry a real maintainer's name and email, with dates as old as 2021. Check every branch for the files, whoever the history says wrote them.
• A tag is a moving pointer. Every workflow line we found that calls the action uses a tag such as @v1, @v3 or @v3.6.0, and every tag of the action was moved.

What we run now

The two checks behind this hunt went into our hourly GH Archive pipeline on 19 October. One looks for the burst shape and verifies each burst the same way, with HTTP status checks and commit metadata only. The other flags any new repository whose whole description is one of the worm's exfiltration markers. On the hunt window, a burst with both files at the pushed commit was the worm 83% of the time (70 of 84). Adding the copied-message check kept 70 of 70, but that figure is partly circular, since the same evidence confirmed them. The independent check is timing: all 70 fall inside the window when the actions were live. Findings go to our analysts for review. They do not alert customers on their own.

A second job reads the workflow files of repositories behind the packages we track and flags any that call a known-compromised action. On 17 October it flagged alibaba/hooks, ant-design-charts and G6 on its own, with eight HIGH findings.

Indicators of compromise

Check every branch, then the machine

The default branch tells you nothing here. List the worm's config files on every branch of a clone, without checking any branch out:

Any branch that lists .claude/settings.json, .gemini/settings.json, .vscode/tasks.json, .cursor/rules/ or .github/setup.js needs a look. Read them with git show, and look for a SessionStart hook or a folderOpen task that runs a script. If you find the worm and might have opened that branch, check the machine:

Scan a checkout before you open it

Our CLI reads these files without running them. We ran the released version, 1.4.75 from PyPI, signed out and with uploads off, against a shallow clone of one infected alibaba/hooks branch, chore/node_version. We never opened that clone in an editor or agent, and we deleted it afterwards.

code-scan agents reads Claude Code and Gemini settings, VS Code folder-open tasks and agent instruction files. It matched all five worm files by hash and flagged both autorun entries:

Each finding says what to do. The first reads: “.claude/index.js is byte for byte a known Mini Shai-Hulud file (sha256 26bc468790d3fa35..., seen as .claude/index.js in ant-design/pro-components@1bc4049d). Do not open this checkout in an AI agent or editor.”

code-scan ci on the same branch named the hijacked action in all five places its issue workflows use it:

Both commands exited 1. So did the thresholds our GitHub Action uses by default, --fail-on critical for the CI scan and --fail-on high for the agents scan. CyberXYZSecurity/depalert-action v1.3.0 runs both scans next to its dependency gate. Pin it by commit like any other action:

What it does not do:

• It scans the checkout in front of it, one branch at a time, and cannot see the others. In every organisation project here, that is where the worm sits. Run the branch loop above first.
• The known-file check matches the hashes we hold, including copies with Windows (CRLF) line endings, which we tested. The June build's files are not on that list, but the same version flags all five of them as critical through its hook, agent-rule, folder-open and payload checks. It does not detect the forged commit history.
• Its offline list of compromised actions names actions-cool/issues-helper but not yet maintain-one-comment. On umi's workflow that line is reported only as an unpinned action, at high.

What to change

• Delete or clean the branches, all of them. List every branch with the loop above, not just the default. Delete the branches you no longer use, and revert the worm commit on the rest, which removes all five files.
• Remember what deleting a branch does not reach. GitHub keeps pull request refs (refs/pull/N/head), which maintainers cannot delete, and forks keep their own copies. Ask GitHub Support to remove pull request refs that point at worm commits, and tell fork owners.
• Pin every third-party action to a full commit SHA, and replace actions-cool/issues-helper and maintain-one-comment, for example with actions/github-script. Give each workflow an explicit permissions: block: an issue bot needs issues: write, not write access to contents.
• Rotate secrets. If a workflow called either action by tag and ran between 18 and 19 May or between 16 and 25 September 2026, rotate every secret and token that job could read. Check its log for a setup-bun step followed by a long bun run.
• Treat agent and editor configuration as code. Review .claude/ and .vscode/tasks.json changes in pull requests, set task.allowAutomaticTasks to off in VS Code, and read a repository's hooks before you trust it.

MITRE ATT&CK