Auditing GitHub Actions for the wfx-loot Pattern: Triggers, OIDC, and npm
The wfx-loot campaign didn't break authentication — it logged in. Stolen GitHub accounts pushed workflows, and GitHub Actions did the rest: checkout, npm install, then an OIDC token exchanged for cloud credentials. This short walks the audit path from the OX Security reporting: the pull_request_target and workflow_run trigger shapes that put secrets in the same job as attacker-controlled code, the id-token: write permission that mints a bearer credential nobody has to store, and the npm lifecycle scripts that run inside the runner. What the video shows: - The vulnerable trigger, write token, OIDC identity and head-ref checkout in one job - A two-command grep triage pass over .github/workflows (triage, not proof — read every hit) - The fix order: plain pull_request trigger, contents: read, no id-token: write on fork-reachable jobs, installs without lifecycle scripts Note on scope: public reporting contains no workflow filenames, payloads, hashes, IOCs or CVE, and this isn't a GitHub Actions vulnerability — every capability used is documented platform behaviour. So detection is written against the pattern, not the campaign. Everything here is defensive and lab-scoped. Full write-up: https://hackyjs.com/posts/auditing-github-actions-for-the-wfx-loot-pattern-workflow-triggers-oidc-scope-and-npm-execution