decrypted · 26 september 2026 · ransomware and cybercrime · supply chain · ai and llm security

GitHub switched off two poisoned Actions, then switched them back on

Two GitHub Actions poisoned in May were switched off by GitHub the next day. On 16 September they quietly came back, and nobody had cleaned them. Until GitHub disabled them again on 25 September, every build that called them was running credential-stealing code once more, with no attacker lifting a finger.

What came back

The two actions are actions-cool/issues-helper and actions-cool/maintain-one-comment, small issue-tracker helpers. Malicious content was introduced on 18 May 2026 as part of the Mini Shai-Hulud campaign, and GitHub's security team disabled both repositories on 19 May. Socket's researchers report that on 16 September both became reachable again. The release tags had never been cleaned, so they still pointed at the malicious code. Socket could not determine why they were re-enabled. Both were disabled again on 25 September, after public disclosure.

The mechanism, in plain English

Think of a tag as the label on a box rather than the box itself. A workflow says: fetch whatever is labelled v2.2.1. Now imagine a batch of medicine is pulled from the shelves, then returned months later with the label unchanged and the contents untouched. The pharmacy's standing order still reads "send whatever is labelled v2.2.1", so it arrives, and nobody has to attack anything.

Socket notes that workflows calling these actions usually run on a schedule or when someone opens an issue or pull request, so most would have executed the payload within a day of re-enablement. BleepingComputer reports the code targets developers' tokens, credentials and CI/CD secrets. For issues-helper alone, GitHub's dependency graph lists about 15,000 dependent repositories, though Socket says how many referenced a tag rather than a pinned commit is not known.

What a defender sees

Very little. The build log shows a familiar action, from a repository you already trusted, doing what it always did. There is no new commit in your code and no new dependency to flag. The evidence is retrospective: workflow runs between 16 and 25 September that reference either action. Socket's advice is to find those references, replace them with a verified commit from before 18 May or remove them, review run history since 16 September, and rotate every secret those workflows could read. That last step is the expensive one, because a build secret is often the key to production.

The design lesson

Two decisions failed. First, the default. GitHub's own hardening guidance says pinning to a full-length commit SHA is currently the only way to use an action as an immutable release, and that a tag can be moved or deleted if someone gains access to the repository. Convenience won, and tags stayed the norm. Second, the takedown. Disabling a repository stopped the download but left the poison in place, so re-enabling it undid the recall. A recall that leaves the product on the shelf is a suggestion.

The cost of the fix is modest: pin third-party actions to commit SHAs and accept a routine of reviewing and bumping them. The NCSC's supply chain guidance sets out 12 principles for oversight of suppliers, and a build pipeline is a supplier relationship like any other, only faster and less audited. The question for a director is short: which code that we did not write runs with our secrets? If nobody can answer, that is the finding.

Also this week

OpenAI's agents posted 53 user images online. OpenAI disclosed this week that agents in its research environment uploaded 53 user-provided images to third-party image-hosting sites, as unlisted links rather than public pages. It found them while investigating agent behaviour after the Hugging Face incident. It says it has worked with the hosting providers to remove most of the content, and that data users or enterprise admins had excluded from training was not included. TechCrunch reports that consumers are opted in to training by default. The data-protection lesson for UK organisations is plain: the training setting is the control that mattered here, so know what it is set to for every AI service your staff use, and who can change it.

Dyfed-Powys Police confirms a cyberattack. The force said on 25 September that an attack earlier this month may have exposed staff information. Some non-emergency systems, including email and online services, were disrupted, and it says 999 and 101 stayed operational. It has found no evidence that members of the public had personal data accessed. The Record reports that no group has claimed responsibility, and the force has not said how the attackers got in or which staff data is involved. Tarian, the regional organised crime unit, is leading the investigation. Treat any later leak-site claim as a claim until the force confirms it. For any organisation, the design question is whether a compromised email or web front door can reach the staff records behind it.

Sources

If your build pipeline or supplier list needs a second pair of eyes, get in touch.