GhostAction malicious GitHub workflows
Report edition: 22 October 2026 · PDF page 17
Research reviewed 22 October 2026 · Evidence and editorial planning guidance are distinguished below.
- Operational priority
- Critical*
- Evidence
- Research-observed ongoing campaign
October 2026 wave of a campaign tracked since 2025
Priority is conditional on actual exposure. An asterisk highlights especially conditional exposure; these are editorial judgments, not CVSS scores.
Explore this topic in depth
Ten detailed reports: four shared analyses and six audience perspectives. Research reviewed 22 October 2026; the original PDF account remains below as a dated snapshot.
Research update and qualifications
GitGuardian reports malicious workflow changes targeting repository secrets across observed public repositories. Its repository and secret-target counts describe research observations, not a verified total of unique victims or successful thefts. Workflow configuration can expose authority without changing application source.
GitGuardian GhostAction investigation · Original workflow investigation revisited.
A clean application diff does not clear CI configuration. Masked logs and trusted action pins do not by themselves prevent a malicious first-party workflow from using available secrets.
The original PDF snapshot
What the report establishes
GitGuardian reports workflow injection through compromised accounts, harvesting CI secrets and repository history. Its October dataset covers more than 30,000 targeted repositories and about 1,900 compromised accounts; attempted extraction is not proof that every targeted secret was stolen.
Impact and potential reach
Repositories and automation reachable through compromised developer identities, including cloud and AI credentials present in CI or history. Repository counts are not end-user counts.
Required actions
Repository owners: inspect workflow changes and run history, disable malicious jobs, and revoke the credential that permitted injection as well as exposed downstream secrets. Review old implants and enforce approval and least-privilege controls.
Six perspectives on this topic
For the business manager
Treat restricted CI as an operational constraint that needs a controlled release process. A normal application status does not mean the publishing channel is trustworthy. Coordinate urgent changes through a verified path and preserve a record of exceptions.
Read the business manager report for priorities, evidence and a decision checkpoint.
For the business owner
Review repository authority as business authority. The ability to edit automation can become the ability to deploy, publish or access commercial systems. Ask for controls that match that reach, including independent recovery and review of privileged changes.
Read the business owner report for priorities, evidence and a decision checkpoint.
For the technical manager
Combine repository history, workflow runs and credential scope in one investigation. Different triggers and environments can expose different secrets. Do not rely on application tests to verify the integrity of the automation that runs those tests.
Read the technical manager report for priorities, evidence and a decision checkpoint.
For the software engineer
Review automation as executable security-sensitive code. Inspect how untrusted event data enters commands, which jobs receive secrets and which identities they can request. A pinned external action does not make a malicious local workflow safe.
Read the software engineer report for priorities, evidence and a decision checkpoint.
For the customer service
Keep customer-facing release commitments aligned with the verified publishing process. If a release is delayed for investigation, provide an approved explanation and alternatives without implying that every previous version is compromised.
Read the customer service report for priorities, evidence and a decision checkpoint.
For the customer
Use established software distribution channels and follow product-specific notices. A repository automation incident may affect a supplier’s release process, but its relevance to your installation depends on what was actually distributed.
Read the customer report for priorities, evidence and a decision checkpoint.
In this section
- GhostAction: Evidence and scopeA clean application diff does not clear CI configuration. Masked logs and trusted action pins do not by themselves prevent a malicious first-party workflow from using available secrets.
- GhostAction: Business impact and costsA small configuration change may turn routine CI into a route to production or publishing authority. The business can face a release freeze and cross-account review even if the application continues to behave normally.
- GhostAction: Technical exposure and controlsReview workflow definitions, triggering events, repository permissions and changes to automation identities. Map secrets and short-lived credentials to the jobs able to request them and the environments they can affect.
- GhostAction: Response and recoveryResume automated publishing when workflow integrity, identity ownership and deployment authorization have been reviewed together.
- GhostAction: Business manager reportWho is allowed to approve a production change while normal automation is restricted?
- GhostAction: Business owner reportDoes someone with routine repository access also hold an unreviewed route to production?
- GhostAction: Technical manager reportWhich workflow can request production authority from an event we do not sufficiently control?
- GhostAction: Software engineer reportCan a change to this workflow bypass the review that protects application code?
- GhostAction: Customer service reportAre we distinguishing a delayed release from a confirmed issue in a customer’s installed version?
- GhostAction: Customer reportHas the supplier verified the integrity of the release I received?