GhostAction Supply Chain Attack Escalates With Automated Phishing, OAuth Exploits, and Persistent Developer Stealers

The threat actors orchestrating the widespread GhostAction supply chain attack have significantly expanded their operational tactics. Rather than relying solely on injecting malicious GitHub Actions workflows into compromised open-source projects, the perpetrators have pivoted toward sophisticated phishing campaigns targeting open-source developers. This evolution includes deploying credential-stealing malware disguised within deceptive files, designed to compromise local developer environments and bypass recent security blocks implemented by code-hosting platforms.

According to threat intelligence findings detailed by OpenSourceMalware, this latest iteration demonstrates that the attackers are actively refining their methodology to circumvent platform-level mitigations. Security researchers report that the threat actor registered a deceptive domain, "my-github[.]com," on October 9, 2026—just 17 days after the registration of a similar code-hosting-themed domain, "my-gitlab[.]com." While researchers have noted the parallel naming structure, definitive technical links connecting the GitLab-themed domain to the core GhostAction infrastructure remain unconfirmed due to differences in registrars, DNS designs, nameserver pairs, and registration records.

However, the "my-github[.]com" domain has been directly linked to an active phishing campaign aimed at open-source maintainers. On the very day of its registration, the domain was utilized to dispatch phishing emails impersonating official GitHub security alerts. The fraudulent messages warned recipients of unauthorized login attempts originating from Moscow, Russia, and directed victims toward a malicious landing page designed to secure their accounts.

Security analysts revealed that this deceptive login portal functioned as a reverse proxy capable of harvesting victims’ account passwords and multi-factor authentication (MFA) codes. Beyond credential harvesting, the page injected background JavaScript that automatically authorized a GitHub OAuth application. This unauthorized app requested broad permissions—specifically targeting repository access, workflow modification capabilities, and organization membership visibility—to facilitate a GhostAction-style compromise without requiring manual user intervention for the authorization sequence.

The attack mirrors advanced device-code phishing methodologies by securing an access token from GitHub and exfiltrating it via TCP port 8443 to the attacker-controlled infrastructure at "my-github[.]com." Security researcher Paul McCarty explained that the automated script handles the device code and user code extraction, submits the authorization forms programmatically, and completes the approval process through the victim’s authenticated proxied session. Consequently, developers do not need to manually enter codes or consciously approve permissions, allowing the attackers to acquire reusable API credentials and automate repository-scale code injection.

Compounding the threat, the campaign has introduced a persistent second-stage component designed to maintain a foothold on developer workstations even after malicious workflows are eradicated from online repositories. Drawing inspiration from tactics previously observed in North Korean cyber operations, the attackers commit specific configuration files that manipulate integrated development environments, such as VS Code, into automatically executing the credential-stealer payload.

Once initiated, the second-stage component establishes a cron job to repeatedly execute malicious scripts at five-minute intervals. Harvested data is subsequently exfiltrated over plain HTTP on port 8080 to the threat actor’s central server. Threat intelligence teams have identified dozens of compromised repositories harboring these persistent mechanisms, many of which belong to abandoned or infrequently maintained open-source projects.

Platform-level interventions prompted this tactical shift. On October 9, GitHub deployed defensive controls to block the execution of the original malicious workflows, effectively cutting off the attackers’ primary pipeline for data exfiltration. The introduction of the second-stage launcher, observed shortly after these blocks went into effect, indicates that the threat actors shifted their strategy toward local execution environments that platform-level workflow controls cannot directly reach.

Despite the breadth of the campaign, security analysts suggest that the perpetrators may possess limited technical experience. Jenn Gile, co-founder of OpenSourceMalware, noted that the stealer’s environment-variable filter frequently overlooks critical API keys, home-directory searches are prone to timing out and discarding results, and a single IP address has been reused for exfiltration, phishing, and noisy internet scanning alike. This operational overlap is ultimately what allowed security researchers to track and identify the ongoing infections.

To mitigate ongoing risks, cybersecurity experts advise affected developers to immediately revoke unauthorized GitHub access tokens from clean devices, update account credentials, thoroughly audit personal and organizational repositories, rotate any API keys or secrets previously exposed to vulnerable workflows, and notify users who may have cloned the impacted projects.