The security defects allow unauthenticated users to take control of the open source software supply chain.
The post Exploitable CI/CD Vulnerabilities Expose Millions of Repositories to Hijacking appeared first on SecurityWeek.
TeamPCP is on a rampage through open-source software.
In less than four months, the threat actor has compromised and injected malicious code into more than 1,000 software packages. The extraordinary spree has transformed how software developers and maintainers distribute and manage their code, as their dependencies and repositories have become one of the most effective and prevalent attack vectors this year.
While there has been a host of technical exploits, TeamPCP’s greatest attack has been the uprooting of trust — repeatedly proving that most organizations fail to verify the code they ingest into their systems is legitimate, abusing a nearly blind faith that much of the software development industry relies on to power today’s modern economy.
Starting with Trivy in February, TeamPCP’s attacks have shaken that trust many times over.
The scale of TeamPCP’s attacks lies partly in the automated systems companies use to deploy code, like CI/CD pipelines. It is also capitalizing on new security gaps created by developers’ increasing reliance on AI. Yet, with relatively low effort and unoriginal tactics, TeamPCP is wrecking open-source frameworks and underlying systems at levels the technology community has rarely reckoned with.
“Developers didn’t do a great job of analyzing the security of their open-source dependencies before but, now with AI, there’s in some cases virtually no human in the loop or any kind of sanity check on what these tools are doing,” Feross Aboukhadijeh, founder and CEO at Socket, told CyberScoop.
“You have agents installing packages that haven’t been vetted,” he said. “When an attacker gets in, the impact is even broader because there’s less checks and balances to stop it from affecting everybody.”
TeamPCP hasn’t identified a new problem or proved anything novel. The crux of these attacks hinge on a central theme — defensive vulnerabilities the entire software industry has known about for years. Researchers and developers know the open source trust model is broken and susceptible to sabotage. Yet, the software industry has not fixed this problem.
“The speed and scale of these attacks is what makes it most notable, not necessarily the methodology behind it, because at the core it is really about exploiting third-party trusts that we have,” said Kimberly Goody, senior manager at Google Threat Intelligence Group.
Software packages are typically subjected to intensive security monitoring to test for vulnerabilities and poisoned updates before they are released to live environments.
Yet, the real vulnerability highlighted by TeamPCP lies further up the chain of command with the organizations or individuals that publish these packages to the wider market, according to Nathaniel Quist, manager of cloud threat intelligence at Palo Alto Networks.
“It is their responsibility to secure their credentials and not provide a jump off point to trigger a supply-chain event,” he said. “Everything that interacts with or crosses through that zone must be highly monitored and controlled to ensure a compromise can be contained quickly and easily.”
TeamPCP, like any prolific cybercriminal, has captured significant attention from threat hunters since it emerged in late 2025. Google attributes the activity to one core operator.
The company said it traced TeamPCP’s residential and mobile IP address connections to South Africa, indicating the primary operator was located there during at least some of its attacks.
“We don’t believe that there’s an established core group, at least not yet, and that a lot of this has been conducted by an individual,” Goody said. Google declined to name the core operator or confirm it knows the person’s true identity.
Palo Alto Networks said the core manager of TeamPCP uses the “ResoluteXBF” handle on multiple platforms. The cybersecurity firm is also tracking two additional core members: “diencracked” and “Shinigami.”
If TeamPCP is primarily run by one person, law enforcement has a rare opportunity to make a lasting impact with a single arrest.
TeamPCP has collaborated with other cybercriminals, but most of those partnerships were short-lived and ended in a public feud or otherwise failed to get off the ground in any meaningful way, Goody said.
Researchers have linked TeamPCP to extortion crews, dark web forums and affiliates including Lapsus$, ShinyHunters, Vect, DragonForce, BreachForums and “HasanBroker.” TeamPCP listed about 4,000 private code repositories on a dark web forum with an asking price of $95,000.
The actions to date, including unpredictable behavior, indicate motivations beyond financial gain and a “clear desire for notoriety,” Goody said. “They seem to like to make chaos.”
Quist draws the same conclusion from his months-long investigation, noting that it encourages other cybercriminals to get in on the action, at one point offering financial rewards for the largest software supply-chain attack.
TeamPCP isn’t in the game for extortion payments, he said. “These actors are more interested in the underground street cred they are gaining” and “causing as much damage and mayhem as possible.”
TeamPCP has been remarkably noisy, opportunistically injecting malware into open-source software for the purpose of stealing credentials for Kubernetes environments, Amazon Web Services, Microsoft Azure, Google Cloud and many other connected services.
The group’s claimed victim list is staggering: Checkmarx, Bitwarden, LiteLLM, Telnyx, Mercor AI, PyTorch Lightning, AntV, SAP, GitHub, TanStack, UiPath, MistralAI, Microsoft DurableTask, Red Hat and Nx Console.
The full collection of packages compromised or poisoned by TeamPCP to date accounts for roughly 500 million weekly downloads combined, according to Quist.
While the breadth of potential downstream compromise flowing from those downloads is substantial, many endpoints infected with those malware-riddled packages aren’t exposed to the internet and less susceptible to attack, he added.
“I don’t think there’s going to be a very extremely large number of victims,” Quist said. “There’s going to be a lot of people who potentially could be compromised and have potentially vulnerable packages in their environment, but that doesn’t necessarily mean they’re in an exploitable position.”
While these incidents have grabbed headlines, TeamPCP hasn’t accumulated payouts nearly as large as other cybercriminals. The broader reputational impact it has wrought, however, is massive.
TeamPCP has publicly claimed more than 10,000 victims and about $90,000 in extortions, according to Quist.
“They might not be making a lot of money, but they are causing a lot of impact,” Goody said. “Their campaigns have been very disruptive.”
TeamPCP’s victim list has grown as its hijacked open-source repositories on npm, PyPI, GitHub and other outsourced developer tools that are incorporated into upstream code running in production environments.
Developer laptops and other endpoints that are assigned to install, build and publish software widely contain keys and access to source code that create incredibly valuable supply-chain targets for attackers, Amitai Cohen, head of the attack vector intel team at Wiz, explained during a June presentation on TeamPCP at SleuthCon in Arlington, Va.
The group targets CI runners, which are automated systems that build, test, and publish code. TeamPCP injects malware into the code repositories these runners maintain. When other developers pull that code into their own systems, they unknowingly download the malware alongside it.
Some of these artifacts, including Python libraries, npm registries and GitHub Actions, are downloaded almost immediately by thousands or millions of developers who’ve set their runners up to consistently pull the latest version, according to Cohen. “We as a security industry have taught them that that is the right thing to do. You want to use the latest version because you want to be protected against vulnerabilities, and obviously you want to benefit from all the latest features.”
That instinct is exactly what TeamPCP exploits. By compromising one company’s CI/CD workflow, the group gains access to every downstream user who automatically pulls that infected code. “This is what allows [TeamPCP] to leverage initial access to some patient zero, some company that had a vulnerability in their CI/CD workflow, in order to gain access to their downstream users,” Cohen said. “That’s just how the software supply chain works. Everything has dependencies upon dependencies upon dependencies.”
Some of the packages compromised by TeamPCP were live for almost 13 hours, but security practitioners have responded by identifying code-injection attacks much quicker now, pulling some compromised repositories within 15 minutes, said Ben Read, director of strategic intelligence at Wiz.
The threat group’s operations remain high-tempo. TeamPCP infects new software packages almost daily, validates compromises and captures sensitive data within 24 hours, according to Wiz researchers.
The threat group has consistently evolved its tactics, developing payloads in JavaScript and Python while spreading from local files to Kubernetes application programming interfaces and bundled software development kits. Most recently, it’s been stealing credentials via custom protocols.
The group’s ambitions have expanded beyond its own attacks. TeamPCP is also responsible for a self-replicating piece of malware known as Mini Shai-Hulud, which infected hundreds of software packages across open-source registries in back-to-back attack sprees last month. A TeamPCP affiliate published the full source code for the malware on GitHub last month and encouraged other cybercriminals to use it for their own campaigns.
“TeamPCP is going for volume. They are not being discriminating, they’re not necessarily trying to be stealthy or trying to maximize ROI. They’re going for an all-of-the-above strategy,” Read said during the Sleuthcon presentation.
TeamPCP’s attack spree has also underscored how difficult it is for organizations to revoke compromised secrets. Multiple victims have experienced recurring infections, sometimes falling prey to TeamPCP three times within a month, because they didn’t rotate secrets properly, Cohen said.
At its core, these attacks highlight a direct trade-off organizations accept when they update software quickly to fix vulnerabilities, but learn that doing so too quickly could expose them to illegitimate registries containing malware.
TeamPCP has targeted what Aboukhadijeh describes as a “public good,” open-source registries that were never perfect but widely trusted and rarely turned into a point of entry for supply-chain attacks.
Rapid open source software installation is one of the most dangerous things an organization can do right now, he said, adding that there’s a roughly 1 in 10 chance that any package installed by an organization could trigger an active attack.
TeamPCP has compromised security scanners, password managers, automation tools, data visualization software, and CI/CD infrastructure across various environments.
And it’s lifted a trove of credentials and other sensitive data from victims.
Researchers like Cohen at Wiz, who have been tracking this attack spree since the beginning, are nearing a breaking point.
“This is also too hard on us. We’re very tired. I’m sure a lot of people working on this problem space are very tired, and it’s just kind of become untenable,” Cohen said.
“You can’t keep existing in a world where you wake up every morning and some super prevalent package is compromised and everybody’s just going to be using it like nothing,” he added. “We need to start taking this a bit more seriously.”
The post How software development’s speed obsession enabled TeamPCP’s chaos crusade appeared first on CyberScoop.
Microsoft Threat Intelligence discovered that Anthropic’s Claude Code GitHub Action could expose CI/CD workflow secrets when AI agents process untrusted GitHub content, including issue bodies, pull request descriptions, and comments. We found that while Claude Code Action supported environment scrubbing for subprocess execution paths such as Bash, the Read tool was not subject to the same sandboxing model. It was eventually authorized to access /proc/self/environ, reading the workflow’s ANTHROPIC_API_KEY and potentially other credentials available to the runner.
Following our responsible disclosure, Anthropic mitigated this issue in Claude Code version 2.1.128 by blocking access to sensitive /proc files. Defenders should treat AI workflows that process untrusted GitHub content as high-risk when they also have access to secrets, file-read tools, or external communication channels.
We began this research after observing prompt injection attempts in public repositories using AI-assisted GitHub workflows across multiple vendors, where attacker-controlled issue or PR content is processed by the AI agent and could influence its tool use. For example:
The injection payload was placed inside an HTML comment (<!– –>), making it invisible when the issue is rendered in the browser but still visible to the AI model which reads the raw markdown:
The target repository – fork of a major open-source documentation project – used a highly permissive GitHub Actions workflow to automate issue resolution. We believe the actor is using a fork to test which payloads work before disclosing or exploiting them.
Whenever a user opened a new issue, an AI bot interpreted the request and was granted robust operational tools to resolve it:
This tool chain, operating without external oversight, provided an unauthorized user with the exact high-level primitives needed to plant malware without directly possessing write access.
Disguising the attack as a legitimate feature request for “diagnostic telemetry”, the payload provided the AI with a precise sequence of commands rather than a standard conversational prompt. It instructed the bot to search for a specific markdown heading, read the target file’s contents, append an exact block of malicious HTML, and immediately invoke the pull request tool to commit the newly poisoned file, effectively steering the AI step-by-step through a supply-chain compromise.
The attack vector successfully coerced the bot into locating the target documentation file and appending an invisible XSS image tag:
Had this PR been merged by a maintainer or by automated CI/CD automation, rendering the documentation site would execute JavaScript on visitors’ machines to silently exfiltrate their session tokens to the attacker’s endpoint.
This same trust boundary is what makes the Read tool vulnerability exploitable: once an attacker can influence the agent, they might be able to steer it toward sensitive files available inside the CI runner environment.
To understand the vulnerability described in this blog, it helps to first understand the environment in which they operate. GitHub Actions workflows were designed for deterministic automation—running tests, deploying builds, and enforcing policy. But as AI-powered tools like Claude Code Action have entered that environment, they’ve brought up a fundamentally different execution model: one where natural language can be treated as instruction. The sections below walk through how that model works, where the security boundaries are drawn, and critically, why those boundaries fail.
GitHub Actions is GitHub’s native automation and CI/CD platform. A workflow is a YAML configuration file that defines jobs to run when repository events occur, such as pull_request, issue_comment, scheduled runs, or manual dispatch.
When a workflow is triggered, GitHub executes its jobs on a runner: an ephemeral virtual machine, or in some cases a self-hosted environment. That runner is not just executing code in isolation. Depending on the workflow configuration, it may receive repository contents, issue and pull request metadata, environment variables, the GITHUB_TOKEN, cloud credentials, package publishing tokens, and third-party API keys.
GitHub workflows were built for deterministic automation: run tests, build artifacts, deploy code, label issues, or enforce repository policy. AI-powered workflows change that model. Instead of only executing predefined logic, they ingest repository context, interpret natural-language input, and decide which actions to take next.
A common example is AI-based pull request review. Tools such as Anthropic’s Claude Code GitHub Action can trigger on pull requests, read the diff, title, description, and comments, then post review feedback or security findings. In more advanced configurations, the same agent can modify files, create commits, or open follow-up pull requests from inside the CI runner.
Despite differences between vendors and implementations, the security pattern is consistent:
These integrations are not necessarily careless. Most include system prompts, filters, and policy logic intended to separate user content from control instructions. But when those boundaries fail, the workflow is no longer just automation. It becomes an AI agent embedded inside the repository, and its prompt construction, tool permissions, and runtime isolation become part of the security perimeter.
Claude Code Action is a GitHub action that runs Claude inside your CI runner. Under the hood, it’s a wrapper around the Claude Agent SDK (software development kit). The Claude Code Action handles GitHub-specific concerns (parsing the event, fetching issue/PR context, building the prompt, wiring up MCP (Model Context Protocol) servers, managing tracking comments) and then calls the SDK’s query function to drive Claude. Tool permissions, model selection, and most other runtime behavior are SDK options that the action is responsible for setting.
When Anthropic designed Claude Code Actions, they knew the risks. For the Bash tool, they support Bubblewrap (namespace-based Linux sandbox) with a scrubbed environment (enforced by CLAUDE_CODE_SUBPROCESS_ENV_SCRUB , auto enabled for actions that can be triggered by non-write users).
This is a solid defense. However, a gap exists: the Read tool is not subject to the same isolation.
Rather than routing Read operations through the same secure isolation boundary as Bash, these operations represent direct, in-process calls. They inherently bypass the Bubblewrap sandbox, operating with full access to the process’s environment variables.
To confirm the exploitability of this gap, we constructed a prompt injection payload. We tested this in a lab environment, specifically a non-write user enabled, which forces the CLAUDE_CODE_SUBPROCESS_ENV_SCRUB mitigation active.
We then injected this malicious prompt, the kind that naturally flows through issue bodies, PR comments, or other input:
This prompt defeats two distinct layers of defense:
In figure 4, the prompt injection succeeds; Claude confidently invokes the Read tool directly against /proc/self/environ (taken from the GitHub’s action logs).
The returned environ blob contains the unscrubbed ANTHROPIC_API_KEY. If Read ran inside the same Bubblewrap subprocess that Bash uses, it would not contain this key in the process’s environment variable.
From there, the attacker has their pick of exfiltration channels based on the target workflow configuration (which is publicly visible, since it’s stored in the repository under . github/workflows/). They can use an adversary-controlled domain via WebFetch or Bash, post it in an issue comment using GitHub MCP, or echo it to the Action log (if show_full_output is enabled in the target workflow). The attacker can then prepend “sk-ant-“ to the leaked string to reconstruct the full Anthropic API key.
May 5, 2026: Anthropic mitigated this issue in Claude Code 2.1.128. The mitigation strengthened the Read tool by unconditionally rejecting a number of files in /proc/ in order to protect those files from exfiltration.
April 29, 2026: reported to Anthropic via HackerOne.
The good news for defenders: controls already exist. Below is an actionable hardening guide:
Resource Development
Execution
Defense Evasion
Credential Access
Exfiltration
To conduct AI-driven black-box research on Claude Code Action, we built a GitHub workflow configured with the Bash tool and a system prompt designed to initiate a reverse shell. To bypass Sonnet’s refusal safety mechanisms, we obscured the shell payload behind a response from our controlled domain. We also enabled the workflow to be triggered by users with no “write” permissions to ensure Anthropic’s environment variables scrub mitigations were active during our tests.
Gaining an interactive foothold on the runner, we initially deployed a frontier AI model for automated, black-box research. When an hour of automated analysis produced no actionable findings, we pivoted.
We adopted a white-box approach, feeding the AI model the Claude Code Actions codebase and the obfuscated @anthropic-ai/claude-agent-sdk. Through this human-AI collaboration, where we actively directed the model, analyzed its findings, and tested variations, we uncovered the necessary exploit chains and responsibly disclosed them to Anthropic.
The integration of AI into GitHub Actions isn’t just a productivity improvement, it is a fundamental rewrite of the CI/CD security model. Right now, development is moving faster than defense.
Even when AI agents are deployed with safety prompts, permission scopes, and platform-level defenses (such as the secret scanner we reviewed), a determined attacker can potentially bypass these controls. We are entering an era where natural language is executable code, and untrusted inputs like GitHub issues must be treated as hostile by default. A single, carefully crafted comment combined with a misunderstood trust boundary is all it takes to walk away with production credentials.
We encourage maintainers to stay alert, keep up with the latest security updates, and implement the safeguards outlined in our mitigation guide to protect their repositories against this emerging class of attack.
For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.
To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.
The post Securing CI/CD in an agentic world: Claude Code Github action case appeared first on Microsoft Security Blog.
Microsoft Threat Intelligence discovered that Anthropic’s Claude Code GitHub Action could expose CI/CD workflow secrets when AI agents process untrusted GitHub content, including issue bodies, pull request descriptions, and comments. We found that while Claude Code Action supported environment scrubbing for subprocess execution paths such as Bash, the Read tool was not subject to the same sandboxing model. It was eventually authorized to access /proc/self/environ, reading the workflow’s ANTHROPIC_API_KEY and potentially other credentials available to the runner.
Following our responsible disclosure, Anthropic mitigated this issue in Claude Code version 2.1.128 by blocking access to sensitive /proc files. Defenders should treat AI workflows that process untrusted GitHub content as high-risk when they also have access to secrets, file-read tools, or external communication channels.
We began this research after observing prompt injection attempts in public repositories using AI-assisted GitHub workflows across multiple vendors, where attacker-controlled issue or PR content is processed by the AI agent and could influence its tool use. For example:
The injection payload was placed inside an HTML comment (<!– –>), making it invisible when the issue is rendered in the browser but still visible to the AI model which reads the raw markdown:
The target repository – fork of a major open-source documentation project – used a highly permissive GitHub Actions workflow to automate issue resolution. We believe the actor is using a fork to test which payloads work before disclosing or exploiting them.
Whenever a user opened a new issue, an AI bot interpreted the request and was granted robust operational tools to resolve it:
This tool chain, operating without external oversight, provided an unauthorized user with the exact high-level primitives needed to plant malware without directly possessing write access.
Disguising the attack as a legitimate feature request for “diagnostic telemetry”, the payload provided the AI with a precise sequence of commands rather than a standard conversational prompt. It instructed the bot to search for a specific markdown heading, read the target file’s contents, append an exact block of malicious HTML, and immediately invoke the pull request tool to commit the newly poisoned file, effectively steering the AI step-by-step through a supply-chain compromise.
The attack vector successfully coerced the bot into locating the target documentation file and appending an invisible XSS image tag:
Had this PR been merged by a maintainer or by automated CI/CD automation, rendering the documentation site would execute JavaScript on visitors’ machines to silently exfiltrate their session tokens to the attacker’s endpoint.
This same trust boundary is what makes the Read tool vulnerability exploitable: once an attacker can influence the agent, they might be able to steer it toward sensitive files available inside the CI runner environment.
To understand the vulnerability described in this blog, it helps to first understand the environment in which they operate. GitHub Actions workflows were designed for deterministic automation—running tests, deploying builds, and enforcing policy. But as AI-powered tools like Claude Code Action have entered that environment, they’ve brought up a fundamentally different execution model: one where natural language can be treated as instruction. The sections below walk through how that model works, where the security boundaries are drawn, and critically, why those boundaries fail.
GitHub Actions is GitHub’s native automation and CI/CD platform. A workflow is a YAML configuration file that defines jobs to run when repository events occur, such as pull_request, issue_comment, scheduled runs, or manual dispatch.
When a workflow is triggered, GitHub executes its jobs on a runner: an ephemeral virtual machine, or in some cases a self-hosted environment. That runner is not just executing code in isolation. Depending on the workflow configuration, it may receive repository contents, issue and pull request metadata, environment variables, the GITHUB_TOKEN, cloud credentials, package publishing tokens, and third-party API keys.
GitHub workflows were built for deterministic automation: run tests, build artifacts, deploy code, label issues, or enforce repository policy. AI-powered workflows change that model. Instead of only executing predefined logic, they ingest repository context, interpret natural-language input, and decide which actions to take next.
A common example is AI-based pull request review. Tools such as Anthropic’s Claude Code GitHub Action can trigger on pull requests, read the diff, title, description, and comments, then post review feedback or security findings. In more advanced configurations, the same agent can modify files, create commits, or open follow-up pull requests from inside the CI runner.
Despite differences between vendors and implementations, the security pattern is consistent:
These integrations are not necessarily careless. Most include system prompts, filters, and policy logic intended to separate user content from control instructions. But when those boundaries fail, the workflow is no longer just automation. It becomes an AI agent embedded inside the repository, and its prompt construction, tool permissions, and runtime isolation become part of the security perimeter.
Claude Code Action is a GitHub action that runs Claude inside your CI runner. Under the hood, it’s a wrapper around the Claude Agent SDK (software development kit). The Claude Code Action handles GitHub-specific concerns (parsing the event, fetching issue/PR context, building the prompt, wiring up MCP (Model Context Protocol) servers, managing tracking comments) and then calls the SDK’s query function to drive Claude. Tool permissions, model selection, and most other runtime behavior are SDK options that the action is responsible for setting.
When Anthropic designed Claude Code Actions, they knew the risks. For the Bash tool, they support Bubblewrap (namespace-based Linux sandbox) with a scrubbed environment (enforced by CLAUDE_CODE_SUBPROCESS_ENV_SCRUB , auto enabled for actions that can be triggered by non-write users).
This is a solid defense. However, a gap exists: the Read tool is not subject to the same isolation.
Rather than routing Read operations through the same secure isolation boundary as Bash, these operations represent direct, in-process calls. They inherently bypass the Bubblewrap sandbox, operating with full access to the process’s environment variables.
To confirm the exploitability of this gap, we constructed a prompt injection payload. We tested this in a lab environment, specifically a non-write user enabled, which forces the CLAUDE_CODE_SUBPROCESS_ENV_SCRUB mitigation active.
We then injected this malicious prompt, the kind that naturally flows through issue bodies, PR comments, or other input:
This prompt defeats two distinct layers of defense:
In figure 4, the prompt injection succeeds; Claude confidently invokes the Read tool directly against /proc/self/environ (taken from the GitHub’s action logs).
The returned environ blob contains the unscrubbed ANTHROPIC_API_KEY. If Read ran inside the same Bubblewrap subprocess that Bash uses, it would not contain this key in the process’s environment variable.
From there, the attacker has their pick of exfiltration channels based on the target workflow configuration (which is publicly visible, since it’s stored in the repository under . github/workflows/). They can use an adversary-controlled domain via WebFetch or Bash, post it in an issue comment using GitHub MCP, or echo it to the Action log (if show_full_output is enabled in the target workflow). The attacker can then prepend “sk-ant-“ to the leaked string to reconstruct the full Anthropic API key.
May 5, 2026: Anthropic mitigated this issue in Claude Code 2.1.128. The mitigation strengthened the Read tool by unconditionally rejecting a number of files in /proc/ in order to protect those files from exfiltration.
April 29, 2026: reported to Anthropic via HackerOne.
The good news for defenders: controls already exist. Below is an actionable hardening guide:
Resource Development
Execution
Defense Evasion
Credential Access
Exfiltration
To conduct AI-driven black-box research on Claude Code Action, we built a GitHub workflow configured with the Bash tool and a system prompt designed to initiate a reverse shell. To bypass Sonnet’s refusal safety mechanisms, we obscured the shell payload behind a response from our controlled domain. We also enabled the workflow to be triggered by users with no “write” permissions to ensure Anthropic’s environment variables scrub mitigations were active during our tests.
Gaining an interactive foothold on the runner, we initially deployed a frontier AI model for automated, black-box research. When an hour of automated analysis produced no actionable findings, we pivoted.
We adopted a white-box approach, feeding the AI model the Claude Code Actions codebase and the obfuscated @anthropic-ai/claude-agent-sdk. Through this human-AI collaboration, where we actively directed the model, analyzed its findings, and tested variations, we uncovered the necessary exploit chains and responsibly disclosed them to Anthropic.
The integration of AI into GitHub Actions isn’t just a productivity improvement, it is a fundamental rewrite of the CI/CD security model. Right now, development is moving faster than defense.
Even when AI agents are deployed with safety prompts, permission scopes, and platform-level defenses (such as the secret scanner we reviewed), a determined attacker can potentially bypass these controls. We are entering an era where natural language is executable code, and untrusted inputs like GitHub issues must be treated as hostile by default. A single, carefully crafted comment combined with a misunderstood trust boundary is all it takes to walk away with production credentials.
We encourage maintainers to stay alert, keep up with the latest security updates, and implement the safeguards outlined in our mitigation guide to protect their repositories against this emerging class of attack.
For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.
To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.
The post Securing CI/CD in an agentic world: Claude Code Github action case appeared first on Microsoft Security Blog.
A self-replicating malware campaign known as Mini Shai-Hulud has resurfaced, this time embedding itself across hundreds of npm packages. The threat actor behind it, identified as TeamPCP, has been linked to earlier waves of the same campaign, with this latest variant more capable than previous waves.
Researchers analyzing the payload found a worm that spreads autonomously, installs persistent backdoors at the operating system level, and is specifically engineered to survive the most common first response: removing the package.
The malware executes the moment an affected software package is installed, whether in a developer’s local environment or inside a CI/CD pipeline. A hook fires before any other step, giving the payload immediate access to the machine.
It harvests GitHub tokens, npm tokens, SSH keys, cloud provider credentials, and database connection strings. In automated build environments, it uses the pipeline’s own trusted identity to obtain publishing credentials, allowing it to push poisoned package versions to the registry under a legitimate maintainer’s name. The stolen data is sent to attacker-controlled GitHub repositories.
After it steals a publishing token, the malware checks every package that token can access, adds its code to those packages, and publishes new poisoned versions using the maintainer’s account. One infected CI runner — the machine or virtual server that automatically builds, tests and publishes code for a project — can therefore taint every package that runner is allowed to publish. It also searches a developer’s computer for other Node.js projects and copies itself into them, so a single infected install can compromise an entire workstation.
“If any of the affected packages ran in your environment, treat the machine or runner as exposed until secrets are rotated, persistence artifacts are removed, and recent publish activity has been reviewed,” Aikido Security researchers wrote in a blog post.
Researchers found that a standard dependency rollback leaves the attacker’s access intact. The malware embeds backdoors in developer tool settings — notably .vscode/tasks.json and .claude/settings.json — which remain on disk even after the npm package is removed. Those files must be audited and cleaned to eliminate the attacker’s foothold.
The payload also installs OS-level background services: a systemd user service on Linux, a LaunchAgent on macOS. Both run a backdoor called kitty-monitor, which polls GitHub’s commit search every hour for signed remote commands. A second process, gh-token-monitor, checks stolen GitHub tokens every 60 seconds — alerting the attacker the moment one is revoked. An attacker can maintain access and monitor the victim’s response in near real time, long after the original infection has been discovered.
Multiple security companies have pointed out which popular dependencies are being targeted. In this wave, it’s been popular data visualization software, including Alibaba’s open-source AntV and TallyUI. The campaign also touched widely used utilities such as echarts-for-react (a React wrapper for ECharts) and timeago.js (a small JavaScript library that allows developers to format timestamps).
“Even if only a subset of those packages received malicious updates, the popularity of the package ecosystem creates meaningful downstream exposure for organizations that automatically pull new dependency versions,” wrote researchers from Socket, an application security company.
The campaign remains active. Because the worm propagates using tokens stolen from infected environments, the number of affected packages is expected to grow. Researchers have warned that any machine or pipeline that installed an affected version should be treated as fully compromised.
Last week, TeamPCP targeted other prominent software libraries with the malware, including TanStack, UiPath, and MistralAI.
The post Mini Shai-Hulud returns, compromising hundreds of npm packages appeared first on CyberScoop.
A rapidly spreading malware campaign has infected hundreds of software packages across major open-source registries, embedding credential-stealing code into development tools downloaded millions of times a week.
The attack, referred to as “mini Shai-Hulud,” targeted prominent software libraries, including TanStack, UiPath, and MistralAI. TanStack’s React Router package alone accounts for more than 12 million weekly downloads, placing the malicious code deep within the software supply chain of modern enterprise applications.
In a blog post, Tanstack said security teams have pulled all compromised software versions from the registry. While there is no evidence that registry passwords were stolen, experts urge anyone who downloaded the affected tools Monday to immediately change all connected cloud, server, and developer credentials — including Amazon Web Services, Google Cloud, and GitHub.
The incident highlights a systemic vulnerability in automated software publishing. The compromised updates successfully bypassed two-factor authentication and carried cryptographically valid provenance signatures. These signatures verified that the packages originated from the correct continuous integration pipelines, but failed to detect that the pipelines themselves had been manipulated to authorize malicious code.
Security researchers attribute the campaign to TeamPCP, a cloud-focused cybercriminal group that emerged in late 2025 that specializes in automating supply-chain attacks and exploiting cloud-native infrastructure, including Docker and Kubernetes environments. The group, alleged to be responsible for earlier development of Shai Hulud, quietly slips their malware into trusted software updates, allowing them to infect thousands of companies at once without triggering security alarms.
The group is notorious for its advanced ability to hide its tracks — such as disguising stolen data as anonymous messaging traffic — and its aggressive extortion tactics, which include threatening to completely erase victims’ computers if they attempt to remove the hackers’ access.
Attackers triggered the automated release process using an “orphaned commit” — code pushed to a repository fork without a corresponding branch. This allowed them to exploit overly broad permissions in GitHub Actions workflows. The malware was then delivered via a concealed dependency that fetched a heavily obfuscated 2.3-megabyte payload disguised as an initialization module.
Upon execution, the malware uses Bun — a high-speed software engine designed to run JavaScript — to systematically steal security keys and passwords. It targets high-level cloud infrastructure, including AWS, Google Cloud Platform, Kubernetes, and HashiCorp Vault. The code is engineered to infiltrate highly secure Amazon cloud networks. At the same time, it scours the developer’s local computer for secret files and SSH keys used to unlock other corporate systems.
Operating as a self-propagating worm, it publishes copies of itself to those projects, spoofing its activity to appear as automated commits from the Anthropic Claude bot. In a secondary extortion measure, the malware generates a new registry token containing a ransom note in its description, threatening a destructive computer wipe if the victim attempts to revoke the compromised access.
Despite the malware’s properties, researchers told CyberScoop they have not seen it spread.
“We saw very limited community spread,” said Charlie Eriksen, a security researcher with application security firm Aikido Security.
To maintain continuous access to developer workstations, the malware embeds itself into the configuration files of popular developer tools, notably Visual Studio Code and Anthropic’s Claude Code. This ensures the malicious scripts execute automatically every time a developer opens a project or initiates an AI coding session.
Stephen Thoemmes, senior developer advocate at Snyk, told CyberScoop this is a particular blind spot for these types of attacks.
“Directories like .claude/ and .vscode/ are typically excluded from version control via .gitignore and are rarely scrutinized as viable attack surfaces,” Thoemmes said. “While these hook and task systems provide valuable automation for legitimate work, they offer a silent execution environment for malicious code. To counter this, developers must move away from treating these local configurations as benign and begin applying the same rigorous security auditing to their tooling directories as they would to their production infrastructure.”
To avoid detection, the stolen data is exfiltrated using Session — an anonymous messaging app that bounces data across a decentralized network. By disguising the theft as ordinary, encrypted chat traffic, the hackers blend in with normal network activity. This allows the attackers to completely ditch the traditional “command” servers that corporate security teams usually hunt for and block.
The success of the “Mini Shai-Hulud” campaign exposes a major blind spot in software security: Current defenses check where an update comes from, but not if the code inside is actually safe. By hijacking the developers’ own automated systems, attackers were able to stamp their malware with official digital signatures — proving that attackers can bypass modern safeguards simply by turning a company’s own tools against them.
Socket CEO Feross Aboukhadijeh told CyberScoop that organizations should look for signs that a compromised package version was installed in CI/CD or developer environments, unexpected outbound connections to campaign infrastructure, suspicious changes in package lockfiles, unusual package publishes from their own maintainers or CI systems, and persistence artifacts in developer tooling directories.
“There is no single centralized kill switch for this kind of campaign,” Aboukhadjieh said. “The hard part is that by the time a malicious package is confirmed, it may already have been installed inside the exact environments attackers want most: developer machines and CI runners. You can pull a package from the registry, but you cannot automatically pull back the credentials it may have already stolen.”
While these packages are maintained by volunteers, Eriksen said the incident is a huge issue for enterprises due to how many development teams use the software in their products and services.
“This is not a ‘volunteer’ vs corporate thing,” Eriksen told CyberScoop. “This is an all-of-society problem.”
Aboukhadjieh told CyberScoop that these continuing attacks on popular open-source software packages is part of “a larger reckoning over how the software industry consumes open source.”
“This campaign shows how thin the line has become between a developer tool and critical infrastructure,” he said. “When attackers compromise tools that are already trusted inside build systems, they do not have to break into every company directly. They can ride the trust those tools already have.”
The post ‘Mini Shai-Hulud’ malware compromises hundreds of open-source packages in sprawling supply-chain attack appeared first on CyberScoop.
Login