Compromised GitHub Actions switched back on with malware intact

Two third-party GitHub Actions that had been compromised in a supply-chain campaign known as "Mini Shai-Hulud" were re-enabled by their maintainer while still pointing to malicious code, and remained accessible for more than a week, according to a report published by BleepingComputer on 26 September 2026.

GitHub Actions are reusable automation components. Developers reference them by name in a workflow file, and GitHub runs the referenced code inside the project's own build environment, often with access to repository contents and stored secrets. That design is what makes a compromised Action serious: the malicious code does not have to be installed by anyone directly, because every project that references the Action pulls it in automatically the next time a workflow runs.

According to the report, the two Actions had already been caught up in the Mini Shai-Hulud campaign, a supply-chain attack on the open source ecosystem. Rather than staying disabled while the malicious code was removed, they were turned back on by their maintainer with the payload still in place. They then sat on the GitHub Marketplace, the directory where developers browse and pick up Actions for their pipelines, in that state for over a week.

The incident record compiled from the reporting lists GitHub Actions as the affected product and supply chain compromise as the root cause, with the status of the incident marked as reported. No figure has been published for how many downstream repositories referenced the two Actions during the window in which they were live, and the report does not say what the payload did once it executed.

The case highlights a recurring weakness in how automated build systems handle recovery from a compromise. Disabling a package or Action is a containment step, not a fix. If the underlying code is never cleaned, re-enabling restores the original problem, and anyone who resumed using the Action on the assumption that its return signalled a clean bill of health would have been exposed again. Marketplace listings carry no visible indication of that history.

For teams running workflow agents and continuous integration pipelines, the usual mitigations apply and do not depend on the specifics of this case. Actions can be pinned to a specific commit hash rather than a moving tag, which prevents a maintainer's later changes from flowing into a build automatically. Build environments can be given narrow, short-lived credentials so a compromised step has less to steal. Dependency inventories can be checked against published lists of affected components after any supply-chain report.

BleepingComputer's report is the sole public account of the re-enablement at the time of writing. GitHub has not been reported as issuing a statement on the two Actions, and no advisory or fix announcement has been attributed to the platform in the available reporting.