GhostAction Returns: Malicious “Security Audit” Workflows Now Mine Credentials from Entire Git Histories

1. Executive summary

On 8 October 2026, attackers operating the GhostAction GitHub Actions credential-theft campaign compromised two high-profile open-source maintainer accounts and injected a malicious workflow into 345 repositories across two automated windows lasting minutes. The workflow is disguised as a security improvement, is committed directly to default branches under the victim's own identity, and exfiltrates the repository's named GitHub Actions secrets plus every cloud, AI, and SaaS credential findable in the working tree and the entire git history, a capability new to this wave. Exfiltration goes to a hardcoded IP address over plain HTTP, and the run log from uber/athenadriver confirms the attacker's server acknowledged receipt four seconds after the workflow started. No CVE is associated with this campaign and no verified CVSS or CISA KEV entry applies; the risk is credential compromise and downstream supply chain access, not a software vulnerability. EMEA financial services firms with GitHub Actions pipelines, especially those holding cloud deploy credentials or third-party API keys in repository secrets, should treat any repository carrying the campaign markers since 31 August 2026 as a confirmed breach.

2. Regulatory framing

No specific DORA/NIS2 article is directly engaged by this item on the facts provided. The campaign is a supply chain credential-theft operation against public open-source repositories; the source does not identify any EMEA financial services entity as a victim, does not describe an incident at a regulated entity, and does not establish that any client's ICT third-party arrangements are implicated. Mapping DORA Art. 28 or NIS2 Art. 21(2)(d) here would be a generic supply-chain checkbox rather than a fact-driven trigger. If a client confirms that a repository it maintains or depends on was swept, DORA Art. 17, 18 and 19 and NIS2 Art. 23 become engaged by the resulting incident at that client, and DORA Art. 28 and 30 become engaged if the affected repository belongs to an ICT third-party provider under contract. Those determinations depend on facts not present in this source.

3. Technical analysis & attack chain

GhostAction is a supply chain campaign against GitHub repositories, first covered by StepSecurity in September 2025 when it stole more than 3,000 secrets across 817 repositories belonging to 327 developers. The attack chain has been consistent since then and the 2025-era payload is still being deployed alongside the newer one.

Confirmed steps in the 8 October 2026 wave:

1. Account compromise. The attacker obtains a maintainer's GitHub credential. StepSecurity assesses the most plausible source as a leaked personal access token from infostealer logs or credential dumps that circulate among multiple actors. This attribution of the initial access vector is a single-vendor assessment and is not corroborated by a second source.
2. Reconnaissance. The repository's workflow files are scanned for ${{ secrets.NAME }} references. The exact secret names found are templated into the payload before it is committed.
3. Injection. A workflow disguised as a security enhancement is committed directly to the default branch under the victim's own identity, bypassing pull requests. The next push, including the injection push itself, triggers it.
4. Exfiltration. The workflow POSTs the repository's secret values to an attacker-controlled endpoint via curl over plain HTTP.

The two injection windows on 8 October 2026:

• 13:20 UTC: the account of Takashi Kitao, author of the 18,400-star game engine pyxel, was used to push the malicious workflow to 27 repositories.
• 21:10 to 21:26 UTC, a 16-minute window: the account of Henry Wu (henrywoo), the original author of Uber's athenadriver, was used to push the same workflow to 318 repositories.

The workflow filename is either security-audit.yml (workflow display name "Security Audit") or github_actions_security.yml (display name "Github Actions Security"). The payload exfiltrates two categories of data: the repository's named GitHub Actions secrets, and every cloud, AI, and SaaS credential findable in the working tree and the entire git history. The git-history sweep is the capability new to this wave. The workflow beacons on every execution even when it finds nothing, so a run that returns no secrets is not evidence the repository was clean.

Exfiltration is to a hardcoded IP address over plain HTTP. StepSecurity first observed the current endpoint in campaign use on 5 September 2026, in the earliest infected repository it analyzed carrying it, and in honeypot records one day later. The endpoint has moved from the domains documented in September 2025 to the raw IP at the center of this wave.

StepSecurity's analysis of the run log from uber/athenadriver confirms the exfiltration completed successfully: the attacker's server acknowledged receipt four seconds after the workflow started. This is a single-source confirmation of a successful exfiltration from one named repository; the source does not state that every one of the 345 swept repositories completed exfiltration, only that the workflow beacons on every execution.

The source does not describe persistence beyond the committed workflow, privilege escalation, lateral movement, or post-exfiltration use of the stolen credentials. Do not assume any of those behaviours from this advisory.

4. Mitigation & containment

P1, within 24 hours

• Search your organization for the campaign markers. Run these at github.com/search on the Code tab while logged in, replacing your-org with your organization name: org:your-org "AKIA_CTX_START", org:your-org "c=monami", org:your-org "193.32.204.199". A zero-result search is a good sign; any hit means an infected repository or a fork carrying the workflow.
• If a workflow named "Security Audit" (security-audit.yml) or "Github Actions Security" (github_actions_security.yml) appeared in any repository you maintain since 31 August 2026, treat it as a confirmed breach. Every configured Actions secret and every credential pattern present anywhere in your git history was offered to the attacker.
• Rotate every GitHub Actions secret in any affected repository, and rotate every cloud, AI, and SaaS credential that has ever appeared in the working tree or git history of that repository. Rotation must cover credentials that were removed from the current tree but remain in history.
• Review GitHub audit logs for commits by maintainer identities adding the workflow files above directly to default branches bypassing pull requests, workflow_dispatch events on freshly created "audit" workflows, and unsigned rapid-fire commits across many repositories within minutes.

P2, within 72 hours

• Remove the injected workflow from the default branch and from any fork carrying it, and confirm removal across all branches, not only the default.
• Audit the blast radius of each rotated credential: check cloud provider audit logs for use of the rotated keys from unfamiliar source addresses in the period since 31 August 2026.
• Require pull request review and signed commits on default branches for all repositories, and disable direct pushes by maintainer accounts where your GitHub plan supports it.

P3, within 7 days

• Move repository secrets that do not need to be available to Actions out of Actions secrets, and prefer short-lived OIDC-federated cloud credentials over long-lived static keys so that a stolen secret has a bounded useful life.
• Add a code search or CI policy check that fails a build when a workflow file is added to a default branch without a pull request, and alert on workflow_dispatch on newly created workflows.
• Review which of your repositories are downstream dependencies of the 345 swept repositories and whether any of your build pipelines consume them.

5. Indicators of compromise

The IP address is the exfiltration endpoint at the center of this wave. The two strings are campaign markers used in the hunting queries; the source does not state which part of the payload each appears in, so treat them as search markers rather than as payload strings for signature purposes.

ipv4  193.32.204[.]199
filename  security-audit.yml
filename  github_actions_security.yml
string  AKIA_CTX_START
string  c=monami

Behavioural indicators:

6. Detection

The source provides distinctive filenames, workflow display names, and campaign marker strings. The YARA rule below targets the workflow files themselves. The strings AKIA_CTX_START and c=monami are included as campaign markers; verify against a known sample before deploying, because the source does not state where in the payload they appear.

rule GhostAction_SecurityAudit_Workflow
{
    meta:
        author = "Adverse Trace"
        date = "2026-10-09"
        reference = "https://www.stepsecurity.io/blog/ghostaction-returns"
        description = "Detects GhostAction malicious GitHub Actions workflow files disguised as security audits"
    strings:
        $wf1 = "security-audit.yml"
        $wf2 = "github_actions_security.yml"
        $name1 = "Security Audit"
        $name2 = "Github Actions Security"
        $marker1 = "AKIA_CTX_START"
        $marker2 = "c=monami"
        $endpoint = "193.32.204.199"
    condition:
        uint16(0) == 0x0a0d or filesize < 1MB
        and 2 of them
}

The Sigma rule below targets the audit-log behaviours the source names. It assumes GitHub audit log events are ingested with the fields referenced; adjust field names to your ingestion schema.

title: GhostAction Malicious Workflow Injection via Direct Default-Branch Commit
id: 8f2c1a44-ghostaction-2026
status: experimental
description: Detects commits adding a security-audit workflow directly to a default branch bypassing pull requests, consistent with GhostAction injection
author: Adverse Trace
date: 2026/10/09
references:

    - https://www.stepsecurity.io/blog/ghostaction-returns
logsource:
    product: github
    service: audit
detection:
    selection_path:
        action: "git.push"
        repo_default_branch: true
    selection_file:
        commit_files|contains:

            - "security-audit.yml"
            - "github_actions_security.yml"
    selection_nopr:
        pull_request: false
    condition: selection_path and selection_file and selection_nopr
falsepositives:

    - Legitimate security tooling deployed by repository owners via direct push
level: high

7. Sources

• StepSecurity, "GhostAction Returns: Malicious 'Security Audit' Workflows Now Mine Credentials from Entire Git Histories", https://www.stepsecurity.io/blog/ghostaction-returns, 2026-10-09.

8. Adverse Trace position

Adverse Trace assesses this as a high-impact supply chain credential-theft campaign with confirmed successful exfiltration from at least one named repository, and no CVE, CVSS score, or CISA KEV entry applies because the mechanism is account compromise and workflow injection rather than a software vulnerability. The attribution of initial access to leaked personal access tokens from infostealer logs is a single-vendor assessment and remains unconfirmed; no MITRE ATT&CK profile is available for the actor, so we do not attribute this to a named group. The git-history credential sweep is the material change for clients, because it means rotation of current secrets alone is insufficient and any credential that has ever touched an affected repository must be treated as exposed. We will monitor for additional injection windows, for the exfiltration endpoint moving again, and for any EMEA financial services entity named as a victim, and we will issue a follow-up if the endpoint changes or if a second source corroborates the initial access vector. Clients who find a hit on the hunting queries should contact their Adverse Trace handler before rotating, so the affected repository set and credential scope can be captured for the incident record.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.