GhostAction on GitHub Actions: protecting secrets and reviewing workflows
An automation with a security label can still carry dangerous behavior. Our analysis proposes authorized tests for workflow changes, secret exposure and runner boundaries.
Czytaj po portugalskuBy Pentesty
What researchers documented
In October 9, 2026 analyses, StepSecurity and Socket described GhostAction using compromised accounts to insert workflows disguised as GitHub Actions audits. The files collected credentials, including from Git history. Their published counts use different scopes; Socket did not establish how the maintainers’ initial credential was obtained.
Why an automation’s name does not establish trust
Businesses commonly recognize a review request through its author and change description. These details help organize work, but an execution decision should consider the content and authority given to the process. An audit label cannot replace that assessment.
We propose treating each workflow as a small application. It has inputs, code, dependencies, an identity and communication destinations. It may also receive credentials to publish packages, deploy services or query environments. These relationships need to be visible to whoever approves a change.
Consider a project that uses the same automation for testing and release publication. If any file change can receive publishing secrets, code review protects a business boundary. The assessment target extends beyond the application delivered to customers.
History needs a decision too
Deleting a line from the current file is different from revoking a credential. In the proposed review, record where a test secret was previously available, who could reach it and whether it remains valid. This connects repository cleanup with a decision in the service that issued the access.
Include forks and mirrors in the exercise inventory when they belong to the authorized environment. Ask whether a copy inherits automation with unexpected permissions. Distinguish file presence, the possibility of execution and an execution actually observed.
A response team should be able to preserve records without leaving a dangerous operation running. Coordinate repository, identity, pipeline and destination service owners. During a simulation, measure how long it takes to locate those people and record their decisions.
Using the result to improve delivery
Prioritize combinations of poorly reviewed changes, broad credentials and important destinations. One control may reduce available authority; another may improve approval or make an attempt visible. Assess effectiveness along the complete path.
The related articles connect this review to token management, developer tooling and evidence quality. After remediation, repeat the scenario with synthetic data and confirm that legitimate work remains possible.
The review must now include the developer workstation
Editorial update: October 20, 2026
In research published on October 16, OpenSourceMalware described an additional GhostAction stage: VS Code tasks launched code disguised as a font and installed local persistence. The study identified 94 repositories but analyzed 79; it did not establish that phishing described in a separate investigation caused all those compromises. Similarity to PolinRider also does not prove common authorship.
Opening a folder does not prove malware execution. The VS Code task documentation states that automatic tasks require a trusted workspace and permission to run automatically. An investigation needs those conditions, together with the editor version and the settings actually applied.
Extend the exercise above with a credential-free laboratory folder and a harmless task that only records a marker. Compare an untrusted opening, the approved configuration and authorized execution. Preserve the trust decision and process record. Workstation review and credential revocation each need an owner; removing a workflow does not demonstrate that the computer has recovered.
Frequently asked questions
Is every workflow named Security Audit malicious?
No. The name is a triage clue, not a conclusion. Examine content, change origin, permissions and records before classifying the event.
Does removing a secret from code end the risk?
Deletion does not determine validity at the issuing service. Review history and authorized copies, then test credential revocation.
Does a temporary runner resolve exposure?
Duration is only one characteristic. Assess the secrets, permissions and connections available during each execution.
What evidence shows a useful correction?
The unauthorized change stays blocked, the synthetic secret is absent from the prohibited context and authorized automation still works.
Sources and references
- StepSecurity: GhostAction Returns research
- Socket: GhostAction campaign analysis
- Cyber Security Brazil: editorial news reference
Original Pentesty analysis, published October 15, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.