Gone in under a minute: the attack that planted a secret stealer in thousands of repositories and left no trace in today's code

HomeBuilding AI Systems

Gone in under a minute: the attack that planted a secret stealer in thousands of repositories and left no trace in today's code

Justin Graham

Principal AI Solutions Architect, Andela

Nov 13, 2026

5 min

Gone in under a minute: the attack that planted a secret stealer in thousands of repositories and left no trace in today's code

A contributor to webdriverio, an open-source test automation framework, spotted an odd commit from the project's own bot account. It was a credential stealer, and they flagged it within about 20 minutes. Most targets didn't get that lucky.

The campaign behind it began a day earlier. On Nov. 10, someone started signing in to GitHub as thousands of real developers. Over the next two days, they used those accounts to probe about 60,000 repositories, slip a credential stealer into the build pipelines of thousands of them, and then erase the evidence.

In my last post I wrote about PHP2Shell, a flaw that sat in PHP for 14 years before anyone found it. This campaign, which researchers are calling wfx-loot, is close to the opposite. The malicious code sat in each repository for less than a minute. It ran, took every key the pipeline could reach, and reverted itself. In most affected repositories, today's code looks perfectly clean.

Nothing here required a bug in GitHub. The attacker used stolen logins and the access those developers already had. That's the part I'd plan around, because it means the weak point is how your organization hands out and cleans up access.

Sixty seconds, start to finish

Aikido Security, which first reported the campaign, counted 4,837 compromised accounts opening probe pull requests in 61,764 repositories, and found signs the payload ran in more than 1,800 of them (Aikido). Other firms have published somewhat different totals, and the campaign was still active when they checked (SafeDep).

The stealer is gone within a minute, but every step leaves a trace.
What the attacker does, and where to look afterward.

In each repository, the attacker ran the same four steps, in about a minute:

Probe. Open a harmless pull request titled "docs: dependency audit notes" from a branch called wfx-docs. If it goes through, the stolen token can write to the repository.
Plant. Push the stealer, a single shell script of about 1,500 lines, into an existing workflow, a new workflow on a throwaway branch, or an npm install hook.
Run. GitHub Actions runs it with access to everything the pipeline can reach.
Erase. Revert the commit, then delete the workflow run and its logs.

Endor Labs, a software supply chain security company, calls this a "sandwich commit" (Endor Labs). Scan today's code and you'll find nothing. The evidence is in commit history, and in a missing run number in the workflow's history. When Aikido published, 92% of the probe pull requests were still open, which suggests most owners hadn't noticed.

The damage didn't stop at each developer's own projects. More than 10,000 of the probe pull requests went into repositories the account didn't own, reached through collaborator or organization access (Aikido). One stolen login exposes every repository that person can write to, including your company's if an employee or contractor had their account taken over.

Well-run projects were hit too. On Nov. 11, the WebdriverIO Bot account pushed the stealer into the webdriverio repository, past its branch protection. The contributor who caught it asked maintainers to rotate the bot and npm publishing tokens (Endor Labs).

The stealer also slipped into two published packages through automated release triggers: Packagist's digitalelvis/neuronai-studio version 3.14.3, and the Go module github.com/onuragtas/docker-env versions 1.0.278 and 1.0.280. In the Go module, the payload sits only in a workflow file, so people who use the module are likely unaffected (Aikido).

How the credentials were stolen hasn't been confirmed for the campaign as a whole. One victim reports that a leaked GitHub CLI token was used, and researchers believe many of the accounts were compromised in earlier attacks (Endor Labs). I'll come back to both.

Rotating your keys won't close every door

The usual answer to stolen credentials is to rotate them. Here that's necessary, but it isn't enough, because the script is built to get deeper access and keep it (Aikido).

First it collects everything on the build machine: every Actions secret and variable, the pipeline's GitHub token, cloud credential files, shell histories, .env files, and even the memory of the runner process. Then it uses the pipeline's own cloud identity to sign in to AWS, Google Cloud, and Azure, hops into other AWS roles it finds, and creates long-lived AWS access keys.

Then it tries to stay. Three of its moves stand out:

In AWS, it rewrites a role's trust policy, the rule that decides who can use the role, so that any AWS account in the world can assume that role.
In Azure, it adds a federated identity credential, named wfx-ci-*, that lets the compromised repository sign in to Azure with no stored secret at all. That keeps working after every token is rotated.
In GitHub, it posts fake "success" results under the names of your required status checks, the automated checks a pull request has to pass before it can merge. Branch protection matches on the check's name, not on who posted it, so the forgeries can clear your merge gates.

No similar back door has been reported in Google Cloud, though the script does impersonate service accounts there. Either way, if the stealer ran in one of your repositories, the job is bigger than a key rotation. You're also hunting for back doors in your cloud accounts.

One more detail is worth knowing. The script has settings meant for private repositories, which outside researchers can't see into (Aikido). I'd treat the public numbers as a floor.

October's leftovers

wfx-loot isn't the first attack of its kind this year. A campaign called GhostAction has been planting credential-stealing workflows in GitHub repositories since 2025. Its October wave used about 1,900 compromised accounts to target more than 30,000 repositories (The Hacker News).

The cleanup after those earlier waves was thin. By Oct. 5, only 16% of the repositories hit in the previous wave had been cleaned up (The New Stack). Some October victims had been compromised before, which suggests the attackers were counting on secrets nobody had rotated (The Hacker News).

Now the pattern continues. Accounts hit by GhostAction in October were significantly more likely to be hit by wfx-loot, and in more than 100 repositories, wfx-loot was injected into GhostAction's own leftover workflow files (Aikido). Aikido believes the two campaigns are run by different groups. Stolen credentials tend to get passed around.

In my PHP2Shell post, the risk was old code that nobody wanted to own. Here it's an old incident that nobody finished cleaning up. A token that wasn't rotated after the last scare, or a malicious workflow file nobody deleted, is the way in for the next attacker.

Why AI agents raise the stakes

To be clear up front: nobody has reported that AI was used to find or run this campaign. But I think it says a lot about the risks teams take on as they adopt AI coding agents.

The stealer goes out of its way to collect AI credentials, including keys for OpenAI, Anthropic, Gemini, and Hugging Face, and for developer tools like Cursor, Copilot, and Codex (Aikido). Those keys cost money when abused, and more and more of them come with access to code and data.

The one access route reported so far matters too. A victim says the attacker used a leaked GitHub CLI token. Those tokens are long-lived, carry the user's full repository access, and sit in a plain config file on the developer's machine (Endor Labs). That's often the same login a coding agent uses to open pull requests and push branches, because it's the easiest one to hand it.

Agents also change what normal looks like. When a team ships with agents, reviewers see a steady stream of automated "chore:" and "ci:" commits. The attacker's commit messages, like "ci: refresh build cache" and "chore: add ci helper," were written to blend into exactly that stream. And the webdriverio case shows that bot accounts allowed to bypass branch protection are prime targets. Many teams are setting up accounts like that for their agents right now.

In fairness, nothing here is unique to agents. A leaked token is just as dangerous on a laptop where no agent ever runs. What agents change is volume: more tokens, more bots, and more automated commits to keep track of.

None of this is a reason to slow down on agents. It's a reason to give them their own identities, with narrow permissions that expire, instead of borrowing a developer's full access.

If I were in your seat this week

Find out whether you were probed. Search every organization you own for pull requests from a wfx-docs branch created on or after Nov. 10, and search commit history for the attacker's commit messages. GitHub search only shows repositories you can read, so run it as an organization owner (Cycode). If a probe pull request exists, that account's credentials are stolen, even if nothing else followed. Aikido and Endor Labs both publish the full list of indicators.
Check whether the stealer ran. GitHub numbers workflow runs in order, so a deleted run leaves a gap. A missing run number right after an attacker commit is the most reliable sign the payload ran (Endor Labs).
Lock the affected accounts. Revoke their sessions, personal access tokens, SSH keys, and OAuth grants, including GitHub CLI tokens, and require phishing-resistant multi-factor authentication.
Rotate everything those pipelines could reach. That means repository and organization secrets, cloud keys, package registry tokens for npm, PyPI, Packagist, and crates, and AI provider keys.
Hunt for back doors. In AWS, look for role trust policies that allow any account and for access keys created since Nov. 10. In Azure, look for federated identity credentials named wfx-ci-*. In Google Cloud, no back door has been reported, but check audit logs since Nov. 10 for service account impersonation (generateAccessToken and signJwt calls), and rotate any service account keys the pipeline could read. In GitHub, check the status checks posted on the attacker's commits.
Finish cleaning up October, then harden. If any of your accounts were hit by GhostAction, confirm the malicious workflow files are gone and the secrets were rotated. Then start on the changes that limit the next attack:
‍
- Make the default pipeline token read-only.
- Require code-owner review for workflow files and package.json.
- Pin required status checks to the specific GitHub App expected to post them.
- Scope cloud trust to specific repositories, branches, and environments.
- Replace classic personal access tokens with short-lived, fine-grained ones.
- Audit every user, bot, and agent allowed to bypass branch protection.

The week after this week

Steps 1 through 5 make for a hard week. Step 6 is a project. It touches every repository, every workflow file, every token, and every cloud trust policy, usually across teams that each own a slice and nobody who owns the whole. That's why the cleanup from October was still unfinished when November's attack arrived.

The webdriverio maintainers had someone watching. For everyone else, the evidence is a missing number in a workflow's run history. Go look for yours.

How Andela can help

This is the work we do at Andela, as a GitHub partner. An engagement starts with a two-week assessment. You get an inventory of every repository and workflow, and every person, bot, agent, and token that can change them. We map which workflows can reach which secrets and cloud accounts, and flag the patterns this attack relied on: pipelines that hand every secret to a single step, tokens with write access by default, cloud trust that any branch can use, and accounts on the bypass list. The assessment is read-only and doesn't touch your running pipelines, so it won't slow down incident response that's already underway.

Then we do the hardening in your organization. AI agents handle the repetitive refactoring across hundreds of workflow files, while our engineers scope every change, review every diff, and your team approves what merges. If you're rolling out Copilot or other coding agents, we set them up with their own narrow, expiring identities from the start.

If step 1 turned up probe pull requests, or you're not sure who and what can change your workflows, book a discovery call and we'll start with the inventory.