Mini Shai-Hulud Re-Exposure: Re-Enabled GitHub Action Repositories Trigger Malicious Code Execution in CI

1. Overview

• Article Title: Re-Enabled GitHub Actions Expose Thousands of Repositories to Mini Shai-Hulud
• Publisher: Socket
• Publication Date: 2026-09-24
• Updated Date: 2026-09-25
• Source: Socket
• Related Sources: BleepingComputer, GitHub: GITHUB_TOKEN, GitHub: Secure use reference
• Related Malware, Threat Groups, CVEs, and Products: Mini Shai-Hulud, GitHub Actions, actions-cool/issues-helper, actions-cool/maintain-one-comment, Bun
• Severity: High (Even without new commits or tag modifications, the re-enabling of compromised upstream repositories caused existing malicious code to execute again in CI environments. Note that the figure of approximately 15,000 on the dependency graph represents potential usage, not confirmed instances of execution or data theft.)
• Revision Details: Maintained 16 sections and the comparison table, limiting execution confirmation to public logs for issues-helper. Distinguished between static references and execution, the limits of read-only tokens, and the handling of GITHUB_TOKEN versus long-lived credentials.

2. Executive Summary

Two third-party GitHub Actions (issues-helper and maintain-one-comment), which were disabled following a supply chain attack in May 2026, were re-enabled on September 16 while still retaining malicious tags. Socket confirmed via execution logs that workflows referencing issues-helper re-executed the malicious payload. This confirmation cannot be generalized to all users of both Actions. The repositories were disabled again by GitHub on September 25.

3. Attack Flow

Below is the attack mechanism based on public information. Not all stages or impacts necessarily occurred in every individual repository or workflow.

Comparison of Easily Confused Concepts and Prerequisites

Concept / Issue	Misconception	Actual Fact / Specification
Attack Resumption Trigger	The attacker created a new tag or tampered with the workflow.	No new tag creation or commit was required. Re-enabling (unsuspending) the upstream repository made existing malicious tags downloadable again.
Repository Disabling Effect	The code was safely cleaned up because the repository was disabled.	Disabling a repository merely temporarily suspends distribution, rather than sanitizing Git tags or commits. The issue resurfaced when the repository was re-enabled with malicious tags intact.
Impact Count (Approx. 15,000)	Malicious code actually executed and compromised 15,000 repositories.	GitHub’s dependency graph listed approximately 15,000 repositories depending on actions-cool/issues-helper; this was not a count of confirmed executions or compromises.
Read-Only GITHUB_TOKEN	Making tokens read-only prevents supply chain attacks.	While it limits writes using that token, it does not prevent writes via other credentials or existing permissions. Furthermore, it does not prevent malicious code execution on the runner, theft of the token itself, or access to data the token is permitted to read.
Commit SHA Pinning	Pinning to a commit SHA is completely safe.	If the pinned target is a malicious commit, the risk of downloading and executing that code remains. Pinning to a verified clean commit SHA is required.

Path to Re-Downloading and Executing Existing Malicious References in CI

1. Retention of Malicious Tags: Release tags, including v2.2.1, still pointed to malicious commits introduced during the May 2026 compromise. During the subsequent repository disabling period by GitHub, downloads from dependent workflows failed.
2. Resumed Downloads via Upstream Re-Enabling: With the upstream repository re-enabled on September 16, workflows referencing the Action's tags automatically fetched and checked out the malicious commits triggered by routine events such as cron schedules or issue creation.
3. Payload Deployment on Runners: In execution examples confirmed by Socket (issues-helper@v2.2.1), a wrapper script set up the Bun JavaScript runtime and executed the obfuscated index.js (the Mini Shai-Hulud payload).
4. Credential Discovery and Theft: The payload targets available tokens and credentials on the runner. Actual access targets and transmitted content must be verified through job settings and execution records, and it should not be assumed that all secrets stored in the repository were exposed.

4. Attacker Position and Execution Location

• Attacker Position: Public repository of the third-party GitHub Action (upstream supply source).
• Execution Location and Privilege Boundaries:
  • OS-Level Privileges: Job execution user privileges within GitHub-hosted (or self-hosted) runners.
  • External Access and API Privileges: The scope of the GITHUB_TOKEN granted to the job, along with various secrets explicitly or implicitly passed to the workflow. OS privileges and token privileges represent different boundaries.

5. Perspective of Victims and Administrators

Victims

• Routine automated jobs such as issue management and comment updates run successfully alongside intended processing, causing GitHub Actions to display a green checkmark indicating success, which may conceal the compromise.

Administrators

• Workflows that previously resulted in errors due to failed Action downloads suddenly start succeeding.
• Detailed inspection of execution logs reveals indicators such as the installation of Bun or bun run $GITHUB_ACTION_PATH/index.js. However, because no new commits or tag movements are required, monitoring only internal repository diffs may cause administrators to overlook the activity.

6. Success and Failure Conditions

Success Conditions

• The workflow references a malicious tag or commit SHA, and the runner downloads the Action code and reaches the step that executes the payload.
• Credential theft requires that the malicious code can read and externally transmit the target tokens or secrets, though this is not a mandatory prerequisite for malicious code execution itself.
• Subsequent source code tampering or unauthorized package publication requires that the stolen tokens possess write permissions for those actions.

Failure Conditions and Risk Mitigation

• Action Removal or Secure SHA Pinning: Stop using the affected Action or pin it to a verified, full-length commit SHA (40 characters) whose contents and provenance have been verified.
• Action Usage Policy Enforcement: Apply allowlists at the organization level to restrict usage to approved Actions only.
• Principle of Least Privilege: Use the permissions block to restrict GITHUB_TOKEN permissions to the minimum necessary (read-only by default, or strictly required capabilities).
• Secret Isolation: Pass only necessary secrets to individual jobs to avoid exposing secrets through unnecessary environment variables.
• Immediate Credential Revocation: Revoke and reissue long-lived tokens or API keys that may have been accessible in environments where the Action ran during the re-enabling period. Stop ongoing unauthorized jobs and verify the permissions, validity periods, and unauthorized use of automatically issued job-level GITHUB_TOKEN instances.

7. What Happens Upon Success

• Malicious JavaScript code executes on CI runners.
• The GITHUB_TOKEN available on the runner and API keys passed to the job become targets for theft. The success or failure of reading and externally transmitting individual credentials requires separate verification.
• Depending on the privileges of stolen credentials, secondary impacts may occur, including private repository source code exfiltration, unauthorized commits, publication of tampered packages, and unauthorized access to infrastructure environments.
• Note: The figure of approximately 15,000 shown on the dependency graph does not indicate actual victim counts or secret leakage incidents.

8. Observable Logs

Log types and focus areas when investigating internal environments. The credential files listed below are investigation candidates and do not imply that all accesses were observed in every case.

• Email: No reports indicate email was used as the initial entry vector.
• Proxy / SWG / DNS: For self-hosted runners or proxy-routed traffic, check for outbound HTTP/HTTPS traffic to Bun distribution sites (bun.sh, etc.) or suspicious external domains, along with anomalous DNS queries.
• Endpoint / EDR: In self-hosted runner environments, investigate the Bun process spawned by the runner process, the execution command line of index.js, and abnormal access to configuration files under the home directory (.npmrc, .aws/credentials, etc.).
• Identity / IdP: Cross-reference audit logs from GitHub, cloud platforms, and package registries regarding credentials accessible to the affected job to track usage from unusual IP addresses or timeframes, as well as suspicious operations.
• SaaS / Cloud: Review GitHub Actions execution history (workflow logs) to investigate resolved commit SHAs for issues-helper or maintain-one-comment, execution steps, and traces of Bun installation.
• Network: Investigate data transmission sessions from runner hosts to suspicious external IP addresses.

9. Attack Success Determination

Confirmed via Public Information

• Malware Execution or Authentication Success Confirmed: Socket researchers confirmed that in actual workflows referencing actions-cool/issues-helper, the malicious commit (a0c53dd4...) was fetched, Bun was installed, and the malicious index.js was executed. (Scope: Execution history published by Socket)

Internal Determination Criteria

• Attack Attempt Observed (Success Unconfirmed): Mere configuration references represent exposure candidates, not confirmed attack attempts or execution. Distinguish between fetch request generation, Action fetch failure, and execution failures or successes after download.
• Malware Execution or Authentication Success Confirmed: Execution logs show evidence that the Action code at the resolved commit SHA was downloaded during the relevant period and scripts executed within the job.
• Data Theft or Session Compromise Confirmed: Evidence that secrets accessible within the job (GITHUB_TOKEN, cloud credentials, etc.) were transmitted externally, or suspicious API calls using those secrets were confirmed in service audit logs.
• Subsequent Compromise Confirmed: Concrete attack activities executed using stolen credentials, such as pushing unauthorized commits, releasing packages, or modifying infrastructure resources.

10. Investigation Playbook

Recommended procedures for incident investigation and response within your organization.

• Investigation Origin: Detection of actions-cool/issues-helper or maintain-one-comment usage within repositories, or unexpected success events and Bun execution in CI logs from September 16 onward.
• Initial Review: Perform a broad search across all repositories in the organization to identify workflows referencing the affected Action (including reusable workflows and composite Actions). Review execution history from September 16 until after the repositories were disabled again on September 25. Socket estimates the re-enabling occurred between 09:09 and 16:16 UTC; do not prematurely narrow scope by assuming exact start and end times.
• CI Execution Log Review: For each execution log, verify the exact commit SHA checked out, Bun download records, and traces of obfuscated script execution.
• Secret Exposure Assessment: List the permissions of the GITHUB_TOKEN granted to the affected job and any secrets accessible to the job via Action inputs, environment variables, or credential files.
• Account and Service Audit: Verify provider-side audit logs for unauthorized usage regarding potentially exposed credentials (GitHub Personal Access Tokens, AWS/GCP/Azure keys, npm/PyPI tokens, etc.).
• Containment and Eradication: Completely remove references to the affected Action from workflows or change them to a verified full-length SHA. Revoke and rotate long-lived credentials that may have been exposed, and stop ongoing unauthorized jobs. Verify validity periods, permissions, and usage records for job-level GITHUB_TOKEN instances.
• Determination Categories: Maintain incident records distinguishing between static references, download failures, code execution on runners, external credential exfiltration, and unauthorized subsequent actions.

11. Defense and Detection Ideas

• Single Event: Detect unauthorized third-party Action execution in CI workflows, or unexpected package manager (Bun, etc.) downloads during job execution.
• Temporal Correlation: Correlate the sequence of workflow execution starts, external Action resolution, installation of anomalous runtime tools, and outbound traffic to suspicious external IPs.
• Threat Hunting: Expand scope beyond .github/workflows/*.yml in repositories to private actions, composite actions, and reusable workflows, exhaustively searching for strings including actions-cool/.
• Log Limitations Awareness: Because GitHub-hosted runners typically use temporary environments per job, post-incident memory dumps or detailed OS log preservation can be difficult. Combine information visible in workflow logs with audit logs from connected cloud services. Individual reads of environment variables or secrets are not always logged.
• Priority Mitigations: Prioritize pinning third-party Actions to verified full-length commit SHAs, configuring default read-only GITHUB_TOKEN permissions, introducing organization-level Action allowlists, and isolating secrets per job.

12. Facts / Inference / Hypothesis

Facts

• actions-cool/issues-helper and actions-cool/maintain-one-comment were compromised on May 18, 2026, and disabled by GitHub the following day, though malicious tags remained inside the Git repositories.
• According to Socket's research, these two repositories were re-enabled between 09:09 and 16:16 UTC on September 16, 2026. The exact circumstances and reasons for the re-enabling have not been publicly disclosed.
• Socket's presented execution logs show that issues-helper@v2.2.1 resolved to the malicious commit a0c53dd42fc842d2f9276c5a1d4f9a26abe8713d, fetched oven-sh/setup-bun, and executed bun run $GITHUB_ACTION_PATH/index.js.
• GitHub's dependency graph showed approximately 15,000 repositories, but this is a static usage aggregation and does not indicate the number of repositories where code actually executed or suffered compromise during the re-enabling period.
• Both repositories were disabled again by GitHub on September 25, and subsequent executions observed by Socket failed at the Action download stage. This does not imply sanitization of already fetched copies or forks, nor the revocation of previously exposed credentials.
• Under GitHub's official specifications, Actions running within workflows can access GITHUB_TOKEN via context without explicit parameter passing. Access to other secrets depends on job settings and environment variable definitions.

Inference

• Disabling (suspending) a repository merely blocks external access temporarily; it does not automatically purge malicious commits or tags from the repository. Consequently, re-enabling without cleanup immediately revives the supply chain threat.
• Auxiliary utility Actions (such as automated issue closing or comment management) possess privileges capable of executing arbitrary code on CI runners. Strict provenance management and privilege restrictions are necessary not only for core build tools but also for auxiliary Actions.

Hypothesis

No additional hypotheses. Unconfirmed items are listed in "Unresolved Points and Additional Investigation".

13. MITRE ATT&CK Mapping

ID	Technique	Confidence	Basis
T1195.002	Supply Chain Compromise: Compromise Software Supply Chain	high	Malicious code was distributed and executed in dependent CI pipelines through the re-enabling of compromised third-party GitHub Actions.
T1059.007	Command and Scripting Interpreter: JavaScript/JScript	high	Obfuscated malicious JavaScript (index.js) was executed via the Bun runtime introduced on the runner.

14. Unresolved Points and Additional Investigation

• The specific circumstances, approval processes, and reasons why malicious tags remained unremoved when the repositories were re-enabled.
• The exact number of repositories and organizations where malicious code actually executed during the September 16–25 re-enabling period.
• The total number of secrets actually exfiltrated externally from execution environments and evidence of subsequent malicious commits or package tampering utilizing them.

15. Impact on SOCs and Organizations

Many organizations leverage GitHub Actions for software development and operational automation. This incident demonstrates a supply chain-specific risk: Workflows can become exposed again when a compromised upstream repository is re-enabled. Tag-based references such as @v2 remain dependent on what the upstream tag resolves to. Furthermore, the belief that "making GITHUB_TOKEN read-only ensures safety" is incorrect; if arbitrary code executes on a runner, other environment variables and secrets may be leaked. Organizations should enforce rules pinning third-party Actions to verified full-length commit SHAs and strengthen secret isolation per job to guard against potential execution.

16. Summary by Target Audience

• For SOCs: Review GitHub Actions execution logs between September 16 and 25, 2026, investigating resolved commit SHAs for issues-helper and maintain-one-comment, Bun execution, and outbound traffic to unknown destinations.
• For Administrators: Immediately remove references to affected Actions or pin them to verified, secure commit SHAs. If evidence of execution exists during the period, revoke and reissue long-lived secrets accessible to jobs, stop ongoing unauthorized jobs, and verify GITHUB_TOKEN permissions and usage history.
• For Users: Workflows configured with scheduled events execute code in the background without user interaction. Verify whether team repositories reference third-party Actions via tags.