WFX GitHub Attack Tracker
This page tracks PR markers linked to the wfx campaign, in which attackers use compromised GitHub accounts to push code designed to steal CI secrets.
PRs from a wfx-docs branch are signs that the campaign targeted those repositories.
We built this tracker on the same data pipeline as GitHub Pulse, our live view of public GitHub activity. Check it out.
Connecting to the shared collector results. Live totals are unknown.
Campaign trajectory
New markers, hour by hour
No hourly observations available yet.
Captured accounts
Matching PRs by account
Authored: PR-author data or an opened event. Activity only: first observed participant when the author is unknown. Neither means the account pushed malicious code. Each repository ID + PR number is counted once.
Waiting for account counts.
Times are captured GitHub events across each account's matching PRs, not account creation or last login. Coverage gaps and backfill can change them. Latest stored usernames may have changed or be missing. Profile links use these stored names and may be outdated; counts use stable IDs. Evidence shows up to three recent stored PR observations per account.
Collected campaign matches
Search suspicious PRs
Results appear as you type. Partial repository names work, and search ignores case. Clear the search to browse all saved matches. Results refresh every 30 seconds.
Times use GitHub event time, not capture time or PR creation time. First observed suspicious PR is the earliest matching event across all stored PRs for that repository ID. Backfill can reveal earlier matches. Names are observed labels and may have changed.
Search the stored matches. Marker PRs point to repositories targeted by the campaign.
Captured activity
Recent suspicious PRs
The ten most recent first-captured matches.
Ranked by GitHub stars
Most popular affected projects
Star counts captured November 11–12, 2026.
- 65,542
- 10,819
- 9,880
- 3,955
- 1,355
- 1,203
- 653
- 649
- 403
- 329
Partial ranking: 669 of 34,971 tracked repositories had known star counts. Campaign markers do not confirm compromise.
How the campaign works
A quiet probe. A possible second act.
The wfx-docs PR probes access. Where access allows, a separate payload can run in GitHub Actions, take secrets, then erase its traces.
Reported sequence. A marker PR does not prove the later steps happened in that repository.
Methodology & coverage limits Read the signal, not an inference
What is counted?
A PullRequestEvent whose head ref is exactly wfx-docs, case-sensitive. Enriched head ref is preferred, falling back to the raw PR head ref. The marker does not itself verify malicious code or execution; the docs-only probe description provides campaign context, not an additional title or content filter.
Identity is stable repository ID + PR number, counted once at the earliest captured matching event. Account attribution prefers explicit PR-author data, then the opened-event account, then the first observed participant. A closer may be a participant without being the author. Backfill can replace participant attribution with author evidence. Stable account IDs keep renamed users together. This does not establish who controlled an account or pushed code.
Where do observations come from?
GitHub’s public Events API, captured by Pulse’s collector. Coverage is incomplete, and the API can lag 30 seconds–6 hours. This is an observatory, not a real-time attack prevention service.
Chart buckets use event time: when GitHub says the event happened. Live scans and backfills use landing (ingestion) time: when the record reached our table. Late arrivals can revise earlier hours and first-match times.
What does “unknown” mean?
Coverage begins 2026-11-10 00:00 UTC. Pending bootstrap or gap-repair intervals mean captured counts are lower bounds, not a complete census. Hatched hours overlap pending ingestion intervals; all hours remain incomplete until bootstrap finishes. Stale or disconnected data cannot establish the current pace. Even complete captured coverage is not complete GitHub coverage.