PENTESTY · EDITORIAL ANALYSIS · · 4 min read
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.
By 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.
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.