> ## Content Index
> Fetch the complete content index at: https://f4n6.co.uk/llms.txt
> Use this file to discover other available public pages before exploring further.

# GhostAction Compromises About 1,900 GitHub Accounts, Targets Over 30,000 Repositories
- URL: https://f4n6.co.uk/security-feed/ghostaction-compromises-about-1-900-github-accounts-targets-over-30-000-repositories/
- Published: 2026-10-15T11:46:20.000Z
- Updated: 2026-10-15T11:46:20.000Z
- Author: Jeff Davies
- Tags: #security-feed, GhostAction

## 1\. Executive summary

A credential-theft campaign tracked as GhostAction compromised the GitHub accounts of about 1,900 users and pushed malicious GitHub Actions workflows into more than 30,000 repositories belonging to roughly 3,000 users and organisations, with the spike observed on 8 and 9 October 2026\. The campaign attempted to extract 3,174 secrets from public repositories' CI pipelines, and earlier waves exfiltrated PyPI, npm and DockerHub tokens. The actor name "GhostAction" has no MITRE ATT&CK profile in our reference data, so attribution to a tracked group is unconfirmed. For EMEA financial services the exposure is supply-chain: any CI/CD pipeline that pulls from, or trusts a workflow in, an affected repository can leak cloud credentials, package-registry tokens and signing keys that reach production. No CVE is involved, so there is no patch to schedule; the control is credential rotation and workflow review.

## 2\. Regulatory framing

| Article                                                                 | Trigger (the fact in this item)                                                                                                                                          | Practical impact                                                                                                                                  |
| ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| DORA Art. 28: ICT third-party risk — general principles                 | The compromise runs through GitHub-hosted CI/CD, an ICT third-party service, and through package registries (PyPI, npm, DockerHub) that firms depend on for build inputs | Firms must be able to evidence that third-party CI/CD and registry dependencies are risk-assessed and that leaked tokens are revoked on detection |
| DORA Art. 30: key contractual provisions with ICT third-party providers | Stolen CI secrets include registry and cloud tokens issued under provider agreements                                                                                     | Contract terms should cover notification of compromise affecting the provider's platform and cooperation on credential revocation                 |
| NIS2 Art. 21(2)(d): supply chain security measures                      | Malicious workflows were pushed into repositories that downstream firms consume as build dependencies                                                                    | Entities in scope must show supply chain security measures covering the software build path, not only runtime vendors                             |

No DORA Art. 17/18/19 or NIS2 Art. 23 reporting obligation is engaged by this item on its own. Those articles attach to an incident at the firm; this is a third-party platform campaign. If a firm confirms its own secrets were exfiltrated and that meets its classification threshold, the incident-management and reporting articles then apply.

## 3\. Technical analysis & attack chain

The campaign is a credential-theft and supply-chain operation against GitHub Actions, not an exploitation of a software vulnerability. No CVE is referenced in any source. The confirmed steps, as reported:

1. The attacker obtains control of GitHub maintainer accounts. GitGuardian attributes the October spike to the compromise of about 1,900 user accounts. An earlier wave, reported by StepSecurity, used the account of Takashi Kitao, author of the pyxel game engine, to push a malicious workflow to 27 repositories starting at 13:20 UTC.
2. From those accounts the attacker commits a malicious GitHub Actions workflow file into repositories. The second wave uses a file named `security-audit.yml` that presents itself as a security audit.
3. The workflow executes in the repository's CI context and reads secrets available to the pipeline. GitGuardian recorded an attempt to extract 3,174 secrets from public repositories' CI in the October spike; StepSecurity's earlier count was 3,325 secrets exfiltrated across 817 repositories and 327 users, including PyPI, npm and DockerHub tokens.
4. The second wave extends collection to the entire Git history rather than only the current pipeline environment, mining credentials and cloud credentials from historical commits.
5. Exfiltrated secrets are used to reach downstream systems: package registries, container registries and cloud accounts whose credentials were present in CI.

The scale figures differ between sources and should be read as a progression rather than a contradiction. StepSecurity's earlier report covers 817 repositories and 327 users; the October spike reported by GitGuardian covers more than 30,000 repositories across about 3,000 users and organisations, driven by the compromise of about 1,900 accounts. The 3,174 and 3,325 secret counts are from different waves.

Two confidence caveats. First, the account and repository counts rest on GitGuardian reporting relayed by The Hacker News, with StepSecurity covering the earlier wave; treat the totals as vendor-reported and single-sourced per wave. Second, the "GhostAction" name has no MITRE ATT&CK profile in our reference data. Do not map it to a tracked group on the strength of the name alone.

The mechanism matters more than the numbers. A workflow file committed to a repository runs with whatever secrets that repository's CI is configured to expose, and it runs with the permissions of the workflow token. An attacker who holds a maintainer account does not need to exploit anything: the pipeline executes the malicious workflow as designed. The second wave's Git-history collection widens the blast radius to credentials that were committed and later removed but remain in history.

## 4\. Mitigation & containment

P1 within 24 hours

- Enumerate every GitHub Actions workflow across your organisations and audit for unexpected or recently added files, in particular any file named `security-audit.yml`. Compare against the last known-good commit and review the commit author and timestamp.
- Rotate every secret that any affected or suspect repository's CI could read: PyPI, npm and DockerHub tokens, cloud provider access keys, and any long-lived credentials stored as repository or organisation secrets. Rotation is the only reliable containment once a workflow has run.
- Disable or restrict GitHub Actions on repositories that do not need CI until the audit completes. Where Actions must run, set the workflow token permission to read-only and require approval for first-time contributors' workflows.
- Review Git history, not just the working tree, for committed credentials. The second wave collects from history, so a secret removed from HEAD but still in history is exposed.

P2 within 72 hours

- Search organisation audit logs for workflow file creation and modification events, and for pushes by accounts that were dormant or whose activity pattern changed around 8 and 9 October 2026.
- Check package-registry and container-registry publish logs for artefacts pushed with the rotated tokens between the compromise window and rotation. A stolen PyPI or npm token can publish a malicious package version that downstream consumers install.
- Enable GitHub push protection and secret scanning across all organisations if not already on. SecurityWeek reports roughly 500,000 active credentials exposed on GitHub, about 200,000 of them after push protections were enabled by default, so default protections alone do not close the gap.

P3 within 7 days

- Move CI credentials to short-lived, scoped tokens issued per job rather than long-lived repository secrets, so a single workflow run cannot yield a durable credential.
- Add a required review step for any change to files under `.github/workflows/` so a single compromised maintainer account cannot push a workflow unreviewed.
- Extend third-party risk assessment (DORA Art. 28) to cover the CI/CD platform and package registries as in-scope ICT third parties, with contractual notification and revocation cooperation terms (DORA Art. 30).

## 5\. Indicators of compromise

No atomic indicators (hashes, domains, IP addresses, file paths) are present in the source material. The sources describe behaviours and named artefacts only.

| type      | value                                                                           | confidence | source                                         |
| --------- | ------------------------------------------------------------------------------- | ---------- | ---------------------------------------------- |
| filename  | security-audit.yml (malicious workflow, second wave)                            | medium     | Step Security (corpus-2)                       |
| behaviour | Malicious GitHub Actions workflow committed by a compromised maintainer account | high       | GitGuardian via The Hacker News; Step Security |
| behaviour | CI secrets exfiltrated from public repositories (PyPI, npm, DockerHub tokens)   | high       | Step Security (corpus-1)                       |
| behaviour | Credential and cloud-credential collection from entire Git histories            | medium     | Step Security (corpus-2)                       |

### Behavioural indicators

| behaviour                                                                                   | where to observe                            | confidence |
| ------------------------------------------------------------------------------------------- | ------------------------------------------- | ---------- |
| New or modified workflow file in .github/workflows/, especially security-audit.yml          | GitHub audit log, repository commit history | medium     |
| Push activity from a maintainer account outside its normal pattern, around 8-9 October 2026 | GitHub audit log, organisation security log | medium     |
| Workflow runs reading repository or organisation secrets at unusual volume                  | GitHub Actions run logs                     | medium     |
| Package or container published with a token that should not have been used                  | PyPI, npm, DockerHub publish logs           | medium     |

```iocs
filename  security-audit.yml

```

The filename is the only machine-pivotable artefact in the sources. It is not defanged because it is a file path, not a network indicator.

## 6\. Detection

The sources give one usable artefact for a file-based rule: the workflow filename `security-audit.yml`. A YARA rule keyed on a filename alone is weak, and the sources provide no distinctive content strings from inside the workflow, so a content-based YARA rule cannot be written without inventing strings. Detection is better placed in log and repository monitoring, where the observable is the commit and the workflow run.

```yaml
title: Suspicious GitHub Actions Workflow Committed by Maintainer Account
id: 8f2c1a44-7b6e-4d21-9c3a-0e5f1b2d7a90
status: experimental
description: Detects creation or modification of a GitHub Actions workflow file consistent with the GhostAction campaign, which pushes a malicious workflow (reported as security-audit.yml) from compromised maintainer accounts to harvest CI secrets.
author: Adverse Trace
date: 2026-10-15
references:

  - https://thehackernews.com/2026/10/ghostaction-compromises-about-1900.html
  - https://www.stepsecurity.io/blog/ghostaction-returns
logsource:
  product: github
  service: audit
detection:
  selection_path:
    action: 'workflows.created'
  selection_file:
    workflow_file|endswith:

      - 'security-audit.yml'
  selection_push:
    action:

      - 'git.push'
      - 'workflows.created'
  condition: selection_path or selection_file or selection_push
fields:

  - actor
  - repo
  - workflow_file
  - created_at
falsepositives:

  - Legitimate security audit workflows added by repository maintainers
level: medium

```

The Sigma rule is deliberately broad on the push and workflow-creation actions because the sources do not give a stable signature beyond the filename. Tune `selection_push` against your own baseline of maintainer activity before enabling it as an alert; as written it will fire on normal workflow maintenance.

## 7\. Sources

- The Hacker News, "GhostAction Compromises About 1,900 GitHub Accounts, Targets Over 30,000 Repositories", https://thehackernews.com/2026/10/ghostaction-compromises-about-1900.html, 2026-10-15
- Step Security, "GhostAction Campaign: Over 3,000 Secrets Stolen Through Malicious GitHub Workflows", https://www.stepsecurity.io/blog/ghostaction-campaign-over-3-000-secrets-stolen-through-malicious-github-workflows
- Step Security, "GhostAction Returns: Malicious 'Security Audit' Workflows Now Mine Credentials from Entire Git Histories", https://www.stepsecurity.io/blog/ghostaction-returns
- The Hacker News, "Credential-Stealing GitHub Actions Workflows Planted in Tens of Thousands of Repositories", https://thehackernews.com/2026/10/credential-stealing-github-actions.html
- SecurityWeek, "500,000 Active Credentials Left Exposed on GitHub", https://www.securityweek.com/500000-active-credentials-left-exposed-on-github/

## 8\. Adverse Trace position

Adverse Trace assesses this as a high-impact supply-chain credential-theft campaign with no CVE and therefore no patch path: the exposure is entirely about which secrets your CI can read and how fast you can rotate them. The scale figures are vendor-reported and single-sourced per wave, and the "GhostAction" name has no MITRE ATT&CK profile, so we do not attribute it to a tracked group. Client impact concentrates in firms whose build pipelines consume open-source repositories or whose own repositories run GitHub Actions with long-lived registry and cloud tokens; those firms should treat any secret readable by an affected workflow as compromised. We will track further GitGuardian and StepSecurity reporting for a stable workflow signature and for any confirmed list of affected repositories, and we will update this advisory if either appears. Clients who need help enumerating workflow files and rotating CI secrets across their GitHub organisations can request support through the usual channel.

---

[Read the original source →](https://thehackernews.com/2026/10/ghostaction-compromises-about-1900.html?ref=f4n6.co.uk)

*Published via PulseTrace — Adverse Trace threat intelligence.*