{"id":2324,"date":"2026-10-22T16:38:51","date_gmt":"2026-10-22T11:08:51","guid":{"rendered":"https:\/\/www.hexnode.com\/threat-watch\/?p=2324"},"modified":"2026-10-28T18:38:19","modified_gmt":"2026-10-28T13:08:19","slug":"ghostaction-github-supply-chain-credential-theft","status":"publish","type":"post","link":"https:\/\/www.hexnode.com\/threat-watch\/ghostaction-github-supply-chain-credential-theft\/","title":{"rendered":"GhostAction GitHub supply chain attack: How Malicious Workflows Expose Developer Secrets"},"content":{"rendered":"

A security check in a software repository should help protect your project. In the GhostAction GitHub supply chain attack, attackers used that familiar label to disguise credential-stealing workflows.<\/p>\n

Activity observed from August 31, 2026, expanded sharply in October. Researchers reported approximately 1,900 compromised GitHub accounts and more than 30,000 targeted repositories during the October wave. These figures describe account compromise and targeting, rather than confirmed secret theft from every repository.<\/p>\n

For enterprise teams, the concern is what those repositories can access: deployment infrastructure, package registries, and other services that trust their credentials.<\/p>\n \t\t

\r\n \t\t\tWho is behind GhostAction?<\/span> \t\t\t \t\t\t\t

\r\n \t\t\t\t\tGhostAction names a credential-theft campaign, rather than a publicly identified threat group. The research reviewed does not establish a verified operator identity or group alias.<\/p>\n

Its operators abuse developer access to introduce malicious GitHub Actions workflows into repositories. Suspected sources of this access include stolen personal access tokens (PATs) circulating in infostealer logs and credential dumps traded on underground markets. However, researchers have not confirmed the initial compromise route for every affected account.<\/p>\n

A valid PAT authenticates directly to the GitHub API without triggering the browser-based multi-factor authentication (MFA) prompt. If the token grants sufficient repository and workflow permissions, attackers can use it to commit malicious workflows without completing an interactive sign-in. Token permissions and applicable organization controls still constrain that access.<\/p>\n

These workflows resemble maintenance or security tasks, making their purpose less obvious during a quick review. Targets include individual maintainers and repositories they can modify within organizations.<\/p>\n

The account owner\u2019s permissions determine how far an attacker can reach. Access to one maintainer account may expose several projects, including repositories belonging to other organizations. This makes account permissions and workflow review important security boundaries. A familiar contributor name alone does not establish that a repository change is trustworthy. \t\t\t\t<\/p>\r\n \t\t\t \t\t\t\r\n \t\t<\/div>\r\n \t\t\n

What happened?<\/h2>\n

The campaign expanded across multiple waves<\/h3>\n\n\n\n\n\n\n\n\n\n
Period<\/th>\nVerified findings<\/th>\n<\/tr>\n<\/thead>\n
August 31\u2013September 30, 2026<\/td>\nMalicious workflows reached 772 public repositories and targeted 2,577 secrets.<\/td>\n<\/tr>\n
October 8\u201312, 2026<\/td>\nResearchers recorded more than 30,000 targeted repositories, with the largest spike on October 8\u20139.<\/td>\n<\/tr>\n
October wave<\/td>\nAttackers attempted to extract 3,174 secrets from public repositories\u2019 continuous integration environments. This is not a confirmed theft total.<\/td>\n<\/tr>\n
From October 9<\/td>\nGitHub began blocking the identified malicious workflow. The observed October 10 and 12 batches could not extract secrets.<\/td>\n<\/tr>\n
October 9\u201316, 2026<\/td>\nAfter GitHub\u2019s workflow blocks, attackers added a second stage targeting developer workstations through VS Code tasks. Research published October 16 identified a 94-repository cluster, with second-stage additions on October 14\u201315. The timing does not establish that GitHub\u2019s blocks caused the shift.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

These findings distinguish workflow injection, attempted collection, and successful execution. They should not be combined into a single count of stolen credentials.
\n

<\/div>

AI Agents IT Readiness Checklist: Preparing IT Operations<\/h4>

Assess AI agent readiness with a checklist covering data, permissions, oversight, testing, and recovery.<\/p><\/div><\/div><\/div><\/a><\/div><\/div><\/div><\/p>\n

Compromised access enabled workflow injection<\/h3>\n

Attackers pushed workflow files using compromised maintainer identities. Stolen tokens or other exposed credentials are plausible entry points, but the evidence does not establish how every affected account was compromised.<\/p>\n

Files such as security-audit.yml<\/code> presented the activity as a security improvement. That disguise concerned the malicious repository change; it does not establish that every victim received a phishing message or that attackers bypassed MFA.<\/p>\n

The payload targeted credentials across CI\/CD, repository history, and developer workstations<\/h3>\n

The malicious automation targeted named GitHub Actions secrets and searched repository files and commit history for additional credentials. Targets included cloud access keys, package publishing tokens, and AI provider API keys.<\/p>\n

Later variants captured nearby text around AWS access key identifiers to help locate corresponding secret access keys. This expanded collection beyond isolated identifiers.<\/p>\n

The workflows exfiltrated collected credentials through unencrypted HTTP POST requests using curl to the hardcoded IP address 193.32.204.199<\/code>.<\/p>\n

The second stage targeted developer workstations. Attackers planted malicious .vscode\/tasks.json files alongside public\/fonts\/fa-solid-400.woff2<\/code>, a fake font containing JavaScript. The task\u2019s runOn: folderOpen setting launches the payload through Node.js when a developer opens the project, provided Node.js is available, the workspace is trusted, and automatic tasks are allowed. Opening the project alone does not guarantee execution.<\/p>\n

The local payload reads credential files, SSH private keys, and selected environment variables, and searches the home directory for tokens. It sends collected data to the same IP over unencrypted HTTP on port 8080, extending credential exposure beyond CI\/CD and repository contents.<\/p>\n

Successful exfiltration was confirmed in examined workflow runs. A workflow left in a repository could also execute again on subsequent pushes when execution remained permitted. However, the reviewed October research did not establish malicious package publication from the observed stolen publishing credentials at that time.<\/p>\n

Why this matters<\/h2>\n

A build pipeline often needs credentials to publish software or deploy infrastructure. If an attacker can modify the workflow using those credentials, legitimate automation can become a route to unauthorized access.<\/p>\n

The potential impact depends on each credential\u2019s permissions, validity, and restrictions. A narrowly scoped token limits exposure; a broadly privileged credential can create a much larger investigation.<\/p>\n

This also explains why device security alone cannot resolve the incident. Teams must examine repository changes and credential use alongside developer endpoints. Removing a malicious file does not invalidate credentials already collected.<\/p>\n

The practical response combines tighter access permissions, controlled workflow changes, endpoint investigation, and secret revocation. Each addresses a different part of the attack path.<\/p>\n

How Hexnode can help<\/h2>\n

Hexnode UEM<\/a>: Harden developer endpoints against credential theft<\/h3>\n

Hexnode UEM supports compliance policies that let administrators define device requirements and identify violations. This helps teams prioritize developer devices that need investigation or remediation.<\/p>\n

On supported Windows devices, Application Compliance can flag installed applications against configured allowlists or blocklists. For active enforcement, Hexnode\u2019s separate Blocklist\/Allowlist policy uses Windows AppLocker controls to restrict application execution. Administrators can block unwanted executables or allow approved applications using publisher- or file-path-based rules, reducing opportunities for unauthorized software to run on developer devices.<\/p>\n

Hexnode UEM\u2019s Automated Patch Management also helps close known vulnerabilities in operating systems and supported applications, including browsers. Administrators can automate eligible updates, require approval, and schedule deployments within maintenance windows. Combined with application restrictions, patching can help reduce developer endpoints\u2019 exposure to known vulnerabilities and unapproved software.
\n

\n
\n
\n
\n \"Resource-Page-Reports_Thumbnail\"\n <\/div>\n <\/div>\n
\n
\n Feature Resource \n <\/h5>\n

\n Securing the Supply Chain Sector: A Comprehensive Report\n <\/h4>\n

\n Hexnode conducted a survey involving 1000 IT professionals across various sectors in the supply chain industry, aiming to analyze the cybersecurity landscape within them.\n <\/p>\n \n Get the Report\n \n \n \n \n <\/g>\n <\/svg>\n\n <\/a>\n <\/div>\n <\/div>\n <\/section><\/p>\n

Hexnode XDR<\/a>: Investigate and contain infostealers and local payload execution<\/h3>\n

Hexnode XDR provides Process Tree Visualization showing parent-child relationships within a detected threat\u2019s execution chain. For GhostAction-related investigations, analysts can use this context to examine suspicious activity such as VS Code launching Node.js to execute a fake font file, followed by a curl process. These are investigation examples; legitimate developer tools also create child processes, so analysts should validate the command lines, files, and destinations involved.<\/p>\n

After confirming malicious activity, analysts can apply targeted response controls:<\/p>\n