Security

Enterprise IT News: GitHub Actions Secret Theft Wave

Published October 10, 2026 · DNS Benchmark Pro Editorial · Reading time: 7 minutes

The most consequential piece of enterprise IT news this week involves no CVE, no vendor advisory and no patch to deploy. It is a credential-harvesting workflow that an attacker simply committed — using a legitimate maintainer’s identity, to the default branch, with a commit message reading “Add security audit workflow.” The campaign, tracked as GhostAction since September 2025, returned on Thursday with a materially upgraded payload.

Two sweeps, sixteen minutes, 345 repositories

The mechanics are aggressively unsophisticated, which is the point. The operator obtains a maintainer’s GitHub credential — most plausibly a personal access token from infostealer logs — reads their existing workflow files to learn which secret names the repository uses, then pushes one new YAML file.

StepSecurity logged the first sweep from the account of Takashi Kitao, author of the Python game engine pyxel: 27 repositories between 13:20 and 13:44 UTC, with manual workflow_dispatch runs fired seconds after the commits. Roughly eight hours later, the account of Henry Wu — original author of Uber’s athenadriver SQL driver — pushed the same file to 318 repositories inside a 16-minute window, 21:10 to 21:26 UTC. The uber/athenadriver injection landed at 21:25:54; the command-and-control server acknowledged its POST ten seconds later.

Thirteen patterns, and the whole git history

The 2025 version of this payload stole GitHub Actions secrets and stopped there. The 2026 version keeps that capability and bolts on a second, far more damaging collection stage: fetch-depth: 0 pulls every branch and tag, then git log -p --all is scanned for credential patterns. Secrets that were committed by accident in 2021 and “removed” in the next commit are still sitting in that history, and this workflow reads all of it.

Both collections ship in a single request, so a defender watching the wire sees one outbound POST carrying two unrelated classes of secret. The workflow beacons even when it finds nothing, handing the operator a live map of every execution context it can reach. StepSecurity’s code-search sweep found 378 repositories with the workflow live on a default branch, 182 carrying the history-mining marker and 88 showing the query string that indicates named secrets were taken.

The fork problem: why this enterprise IT news is a server infrastructure story

279 of the affected repositories are forks. Each carries the workflow file, and any fork owner who enables Actions and pushes will run it against their own tree and history. Socket’s assessment is blunt: private forks and downstream mirrors are the most exposed, because private repositories are where committed credentials tend to survive unnoticed.

That is what turns a developer-tooling incident into a server infrastructure problem. A build runner is not a sandbox in any meaningful sense. It holds deployment credentials, it has network reach into staging and often production, and in most organisations it runs with an egress policy of “anything.” Treating CI as a lower tier than the servers it deploys to is the structural mistake this campaign monetises.

A DNS blind spot by design

Here is the detail that should interest anyone running network-layer defences. The payload posts to 193.32.204.199 — a bare IPv4 address, over plain HTTP. No hostname. No lookup. No DNS query is ever generated.

That is not an accident. Protective DNS, domain-reputation feeds, newly-registered-domain blocking and sinkholing are the cheapest and most widely deployed egress controls in enterprise IT security, and every one of them operates on names. Resolve nothing and you bypass the lot. It is worth noting that this campaign’s own older infrastructure — the legacy C2s at *.oast.fun — was domain-based and therefore blockable; the move to a raw IP is a deliberate downgrade in convenience for a real gain in evasion.

The corollary is useful. DNS-layer controls remain excellent value, but they filter intent expressed as a name; they are not a boundary. What actually stops this payload is an egress allowlist on the runner: outbound HTTP and HTTPS only to your package registries, artifact store and cloud APIs, everything else dropped and logged. StepSecurity recommends exactly that, and notes its runner tooling now carries the C2 address in a global block list.

What to do this week

1. Search your organisation for the markers. Look in .github/workflows for security-audit.yml and github_actions_security.yml, and in code search for the string 193.32.204.199, AKIA_CTX_START and the query markers ?c=monami and ?c=new.
2. Treat any completed run as confirmed exfiltration. Audit workflow runs back to 31 August 2026. The workflow does not fail quietly — if it ran, it posted.
3. Rotate on history, not on the current tree. Deleting a secret from HEAD achieves nothing here. Scan with git log -p --all including unreachable objects, and rotate everything you find. For AWS, review CloudTrail for new IAM users, unfamiliar access keys and activity in regions you do not use — basic cloud security hygiene.
4. Revoke rather than rotate the GitHub identity. Kill sessions, PATs, OAuth grants and SSH keys on the compromised account, then re-enrol phishing-resistant MFA. A rotated token that the operator already used is not a fix.
5. Remove the file from every branch and check your forks. The default branch is where people look; the workflow triggers on pushes to any branch or tag.
6. Require approval for workflow runs. This measurably worked: on typecho-fans/plugins, two attempts to re-fire the payload stalled in action_required because the repository mandates approval, and the exfiltration never executed.
7. Put an egress allowlist on your runners and protect .github/workflows/* with branch protection and mandatory pull-request review.

None of this diminishes resolver-layer visibility; it defines its edge. Knowing which resolvers your build fleet actually answers to is the first step, and our free DNS benchmark and network diagnostic tool gives a per-resolver view rather than a single vantage point. Our guide to DNS over HTTPS and DNS over TLS covers what encrypted transport does and does not protect, and for the older oast.fun callbacks a quick DNS lookup still confirms where a host points.

Industry impact: the build system is production

Step back from the indicators and the shape of this is familiar. There is no zero-day vulnerability here, no DDoS attack, no clever exploit chain — just a stolen token, a legitimate commit and a platform doing exactly what it was told. The entire campaign is an argument that identity, not software flaws, is the supply chain’s weak joint.

What makes this wave worse than its 2025 predecessor is the history sweep. Organisations have spent years deploying secret scanning and push protection on new commits; few have gone back and rotated the credentials buried in a decade of history, on the reasonable-sounding theory that nobody reads it. Somebody is reading all of it now, automatically, in every repository they can write to.

The pragmatic takeaway for anyone tracking enterprise IT news for operational signal: inventory which of your repositories can trigger Actions with secrets attached, assume your git history is readable, and give your runners the same egress discipline you would give a DMZ host. The attackers have already worked out that a build runner is the cheapest route to a cloud account. The cost of agreeing with them is one afternoon of configuration.

Sources

• StepSecurity — GhostAction returns: malicious “security audit” workflows now mine credentials from entire git histories
• Socket — New GhostAction wave hits hundreds of repos, expanding beyond CI/CD secrets to cloud credentials
• The Hacker News — Credential-stealing GitHub Actions workflows planted in tens of thousands of repositories

Independent editorial analysis published by DNS Benchmark Pro / Genext Information Systems. The Uber Mission Bay photograph is by HaeB, via Wikimedia Commons, licensed CC BY-SA 4.0; the GitHub wordmark is a public-domain file via Wikimedia Commons, reproduced on a dark background; the benchmark screenshots are original captures of the DNS Benchmark Pro engine. No images on this page are AI-generated. DNS Benchmark Pro is not affiliated with GitHub, Microsoft, Uber, StepSecurity, Socket or GitGuardian.