Socket reported on Sep 24 that two third-party GitHub Actions, actions-cool/issues-helper and actions-cool/maintain-one-comment, had come back online with a months-old payload still in place. Both were given malicious code on May 18 during the Mini Shai-Hulud campaign. GitHub disabled them on May 19, but the malicious release tags were not removed. On Sep 16 (between 09:09 and 16:16 UTC) both repositories became reachable again, with every release tag still pointing to the malicious commit. Any workflow that referenced them by tag (for example @v2.2.1) downloaded and ran the obfuscated index.js payload on its next scheduled or issue-triggered run, with that workflow’s GITHUB_TOKEN and secrets. Socket says most affected repos “probably ran the payload within a day of the re-enablement,” and that it could not determine why the repos were re-enabled. GitHub’s dependency graph lists about 15,000 repositories that depend on issues-helper. That is a dependents count, not a compromise count; Socket has not determined how many referenced it by mutable tag. Both repos were disabled again on Sep 25, so affected workflows now fail at job setup instead of running the payload. No confirmed victims or stolen-secret counts are public.
Also disclosed last week (Sep 24): the storage pools behind Cloudflare Containers and Cloudflare Sandboxes were configured with dm-thin skip_block_zeroing, so reused 64 KiB disk blocks weren’t wiped. A Workers Paid customer could write 4 KiB into a fresh block and read the remaining ~60 KiB left by a previous container on the same host. Researchers found residual material on 18 of 24 placements and 20 of 22 nodes across four continents, including directory structures, database pages, and structurally complete SQLite databases. An attacker could not pick a victim or read an actively attached disk. The researchers at Accomplish say the remnants included Chromium profiles, .env files, and credential files, and that Cloudflare Browser Run was also affected. Cloudflare’s post names Containers and Sandboxes and says the materials submitted to it contained no credentials or third-party identifiers. Oren Yomtov (Accomplish) reported the flaw via HackerOne on Sep 4. Cloudflare finished rolling out the fix on Sep 7, and by Sep 19 had retired running container disks and purged pre-fix cached snapshots. It says historical disk-I/O telemetry showed no evidence of malicious exploitation and that no customer action is required.
Livermore takeaway: search .github/workflows/ in every repo you own for actions-cool/issues-helper@ and actions-cool/maintain-one-comment@. If any workflow ran a tag reference on or after Sep 16, rotate every secret it could reach, review what its GITHUB_TOKEN was allowed to do, and audit for unexpected commits since Sep 16. In run history, look for jobs that went from failing in seconds to running for minutes, and for oven-sh/setup-bun or bun run $GITHUB_ACTION_PATH/index.js in the logs. Then remove the actions or pin a verified pre-May-18 commit SHA. More broadly, pin all third-party actions to full commit SHAs: “disabled” is not “cleaned,” and Socket notes the malicious tags are still there if the repos come back again. On Cloudflare there is nothing to patch, but treat it as a tenant-isolation reminder, including for AI-agent sandboxes. Keep long-lived secrets out of container images and root disks, prefer short-lived credentials pulled at runtime, and ask providers how they sanitize reused storage. Rotating secrets that lived on Cloudflare container disks before Sep 7 is optional hygiene; Cloudflare doesn’t require it. The common thread: containment isn’t cleanup, on your platforms or your providers’.