Brifing

Compromised GitHub Actions Reactivated Malware Execution

Previously disabled malicious workflows resumed operations after repositories were re-enabled.

The Hacker News2 min

1Reactivation of compromised workflows

Two GitHub Actions repositories disabled in May 2026 became accessible again on September 16, 2026, without proper cleanup. The repositories still contained malicious content from the original compromise, causing any workflows referencing them by version tag to resume downloading and executing the payload. GitHub staff disabled access again after detecting the violation, but not before potential widespread impact.

2Original compromise details

The GitHub Actions were initially compromised on May 18, 2026, as part of the Mini Shai-Hulud campaign. The malicious code harvested sensitive credentials from CI/CD pipelines and exfiltrated them to attacker-controlled servers. The attack was linked to a specific activity cluster through the exfiltration domain 't.m-kosche[.]com', which matched patterns seen in other attacks targeting the @antv npm ecosystem.

3Re-enablement timeline

The repositories were re-enabled between 11:09 a.m. and 6:16 p.m. GMT+2 on September 16, 2026. The exact reason for this re-enablement remains unknown. This reactivation occurred without any new malicious code being published or configuration changes being made, demonstrating how mutable tags can pose persistent threats even after initial containment.

4Automated threat reactivation

The affected Actions automated issue and comment housekeeping tasks like closing inactive issues and updating bot comments. Workflows typically ran these Actions daily or on issue/pull request events. Most affected repositories likely executed the malicious payload within a day of re-enablement, requiring no additional action from threat actors to achieve widespread impact across dependent workflows.

5Supply chain implications

This incident differs from typical supply chain attacks as it didn't involve new malicious versions, hijacked accounts, or injected workflows. Instead, it exploited the mutable nature of version tags in existing compromised code. The case highlights how inadequate cleanup of compromised repositories can reactivate threats without requiring new attacker infrastructure or techniques.

6Impact assessment

The reactivation posed significant software supply chain security risks, particularly for workflows that hadn't pinned to pre-compromise commit SHAs. The exposure could have led to widespread credential harvesting across dependent projects without requiring threat actors to develop new exploits or infrastructure, demonstrating the persistent nature of such compromises.

7Recommended protections

Developers are advised to pin Actions to full commit SHAs from before the compromise date (May 18, 2026) rather than using version tags. SHA pinning removes dependency on the upstream repository's state and prevents automatic execution of potentially malicious updates. This incident underscores the importance of immutable references in CI/CD pipeline security.

8Broader security implications

The incident reveals systemic vulnerabilities in dependency management systems where mutable references can reintroduce contained threats. It highlights the need for better repository state management and cleanup procedures after security incidents. The persistence of such threats emphasizes the growing sophistication of software supply chain attacks and the importance of defense-in-depth strategies.

Original article: The Hacker News — Compromised GitHub Actions Reactivated Malware Execution