Only a day has passed since the second Shai Hulud supply-chain attack rippled across the ecosystem, and new users and organizations are still being compromised every hour. As we sift through the fallout, we are beginning to uncover the initial infection vector the attackers used to compromise major projects like AsyncAPI, PostHog, and Postman, and it is becoming clear that we have not seen the full extent of this campaign yet. By exploiting subtle but powerful vulnerabilities in GitHub Actions workflows, the attackers demonstrated a troubling evolution in their delivery methods. This is a strong reminder that our defenses must evolve just as quickly and that the security of the open-source ecosystem depends on continuously hardening the infrastructure we often take for granted.
Ever since the Nx breach and the Shai Hulud attack, we have known that the attacker has been abusing GitHub Actions workflows to exfiltrate data through webhook.site links. In earlier incidents, the method was straightforward. The attacker planted a deliberate backdoor inside a workflow file, and that backdoor quietly transmitted sensitive information, including credentials, back to an attacker-controlled endpoint.
What we are seeing in the latest wave of the Shai Hulud campaign is more advanced. Instead of inserting backdoors directly, the attackers are now exploiting vulnerabilities in existing GitHub Actions workflows to execute their attack. This shift in technique is what allowed them to compromise projects like AsyncAPI, PostHog, and Postman in yesterday’s Shai-Hulud attack.
Our investigation began when we noticed several suspicious uploads to NPM tied to unexpected usernames such as “codespace” and “runner.” These uploads immediately stood out as anomalies, and deeper analysis showed that they were all likely seeded manually by the attacker through GitHub Actions exploitation. We were later notified by a third party about a related malicious OpenVSX extension with a similar pattern. This discovery confirmed that the attackers have evolved their methods and are now leveraging CI misconfigurations as part of their intrusion chain.
GitHub Actions workflows are automated scripts that run inside a repository to handle tasks such as testing, building, publishing, or managing pull requests. They are powerful and flexible, but that power comes with risk, especially when workflows are configured without a full understanding of how they execute untrusted code.
Certain workflow triggers, including pull_request_target and workflow_run, can become dangerous when misconfigured. This is exactly what happened in the case of PostHog, as shown in the screenshot. The issue was first brought to broader attention by Adnan Khan, a security researcher who highlighted the vulnerable workflow in an X post. The attack was likely caused by a vulnerability inside the .github/workflows/auto-assign-reviewers.yml workflow. That file used the risky pull_request_target trigger in a way that allowed code supplied by any new pull request to be executed during the CI run. The vulnerability was first introduced on September 11 2025 through a merged pull request, where it remained available until the Shai Hulud attack. In total, the issue was present for 74 days before the attacker exploited it.
A similar pattern appears in the AsyncAPI repository. We found that their .github/workflows/auto-changeset.yml file contained a vulnerable configuration added on September 9 2025. The AsyncAPI team has since removed the file following our recommendation, but the configuration was available long enough for the attacker to include this project in the campaign.
It is worth noting that one of these projects was already using a PR-scanning tool, yet it still failed to detect the vulnerabilities hidden within the GitHub Actions workflows. In the case of PostHog, GitHub warned about the vulnerability, but that warning went unaddressed. This highlights the need for security tooling that can understand and flag issues across a wide range of systems and languages, including CI configuration vulnerabilities. Once an attacker identifies an exploitable workflow in a project, that single weakness can serve as a foothold for an attack that spreads at a scale we have not seen before, as demonstrated by the Shai Hulud worm.
As these threats continue to evolve, it becomes increasingly important to understand how vulnerabilities in GitHub Actions workflows can expose not just your own project, but every project and user connected to it. A single misconfiguration can turn a repository into a patient zero for a fast-spreading attack, giving an adversary the ability to push malicious code through automated pipelines you rely on every day. Developers can only defend against what they know, so awareness of dangerous workflow patterns such as pull_request_target and workflow_run is essential. Another option is to use a security platform like Aikido that automatically scans repositories and incoming pull requests for these types of vulnerabilities.
It is equally important to remain aware of vulnerabilities in the dependencies you install. Even if your own workflows are secure, compromised packages upstream can still introduce risk. This is where Aikido’s SCA capabilities, Intel Vulnerability Database, and Package Health insights are especially useful, helping teams catch issues early and understand whether the libraries they rely on show signs of compromise or suspicious activity.
Finally, having a tool that can stop malware in real time as it appears can prevent a serious infection. This is the idea behind Aikido Safe Chain, a free tool that wraps around npm and uses both AI and human malware researchers to detect and block the latest supply chain risks before they enter your environment.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。