Make GhostAction Recovery Answer to Each Service Owner
Updated 15 October 2026. GitGuardian‘s 13 October dataset for 8-12 October covers over 30,000 repositories, 3,000 users/organisations, about 1,900 compromised accounts and 3,174 targeted secrets, not confirmed usable-secret theft.
Keep the observation attached to its denominator
On 8 October, StepSecurity counted 345 repositories: 27 from about 13:20 UTC, then 318 during 21:10-21:26. An uber/athenadriver collection request was acknowledged within four seconds, not a usable-secret count.
Socket reported 346 repositories: henrywoo 318, kitao 27, plus Uber’s. Differently documented totals do not establish another intrusion.
A repository count cannot settle a credential incident. One investigation record might describe where a file was written; another might describe a completed job. Preserve both observations rather than forcing them into a single number labelled “compromised”. Doing so avoids giving a release owner false precision about an individual service.
Give each recovery decision a named owner
Compromised maintainers injected default-branch workflows, not evidence of a GitHub-platform breach. They collected configured Actions secrets plus pattern/output-capped working-tree/reachable-history matches after full-depth checkout: AWS, GitHub, GitLab, Google/Firebase, Slack, SendGrid, AI keys. Initial credential acquisition remains unconfirmed.
For a concrete response record, consider a hypothetical team whose build and customer-notification services have different owners. A result filed against the repository should not silently close both services’ obligations. Ask each owner to identify which authority they accepted responsibility for, what evidence supports its withdrawal or replacement, and what still needs investigation. Treat this as a proposed response structure, not an observed victim procedure.
Use the indicators without mistaking them for a verdict
Review runs since 31 August for 193.32.204.199 (ports 80, 3000), AKIA_CTX_START, ?c=monami, ?c=new; remove security-audit.yml, github_actions_security.yml and security-check.yml across affected branches/forks.
Revoke maintainer sessions, PATs, OAuth grants and SSH keys. Scan reachable branches and tags; rotate affected Actions, cloud, SaaS, AI and publishing credentials from a clean system. Before releasing, check artefacts; require workflow review, limited writes, approvals and restricted egress.
In that hypothetical team, the build owner could accept a completed task while the customer-notification owner still awaited an answer. The record should show both positions, the evidence each person reviewed and who may resolve the remaining question. A green overall ticket would hide that disagreement. Keep the unfinished service decision visible rather than making the second owner inherit the first owner’s conclusion.
Read the later evidence as an update
StepSecurity’s 9 October no-malicious-release finding is not clearance. Socket’s 9 October update has an [HH:MM] placeholder. GitGuardian’s 7 October report was updated on 9 and 13 October. These reports specify no CVE.
GitGuardian says GitHub blocked the 10 and 12 October waves from executing. That does not undo earlier exposure.
The operating lesson connects with our earlier analysis of workflow authorisation and push-to-publish permissions. Decide what a piece of evidence actually authorises you to conclude before using it to approve the next release.
