Guardrails AI PyPI Supply Chain Compromise (CVE-2026-45758): TeamPCP Mini Shai-Hulud Campaign, Rotate All Credentials If You Pulled 0.10.1

blog/Articles/AI Component Guardrails AI Hit by a Poisoned Package: CVE-2026-45758, TeamPCP's New Target

News Updated today

Makoto Horikawa

Backend Engineer / AWS / Django

2026.06.069 min1 views

Share X Hatena LINE LinkedIn RSS

Key takeaways

The PyPI distribution of Guardrails AI, a popular OSS component for validating LLM I/O, was laced with a credential-stealing poisoned version 0.10.1. Tracked as CVE-2026-45758 (CVSS 9.6), it is part of a chain of supply-chain attacks by TeamPCP that spread 400+ poisoned versions across 170+ packages including TanStack and Mistral AI, expanding into AI development. Here are the safe versions and the steps to check and respond.

Guardrails AI, a popular open-source component used to validate the inputs and outputs of large language models (LLMs), was hit by a "supply chain attack" in which an attacker distributed a poisoned version on its behalf. A version 0.10.1 laced with malicious code was published to PyPI, the Python package registry, designed to steal credentials from the machines of developers who pulled it in. It is tracked as CVE-2026-45758, with a CVSS v3.1 severity score of 9.6 ("Critical").

This poisoned version was published to PyPI on May 11, 2026 (U.S. Pacific time), and the threat research team at the security firm Socket detected and quarantined it within about two hours. The problem is that this was not an isolated incident but part of an ongoing chain of supply-chain attacks run by a group calling itself "TeamPCP." In the same wave, over 170 npm/PyPI packages including TanStack, Mistral AI, UiPath, and OpenSearch — more than 400 poisoned versions in total — were spread. We have tracked this same series on this blog as the Telnyx compromise and the chain that spread from TanStack to Nx Console; the new target this time is an AI component.

This article explains, in plain terms, who is affected, what happened, why AI tools are being targeted, and what developers should do right now.

Who is affected, which version to avoid, and what to do

Here is the bottom line. Those affected are people who newly installed guardrails-ai 0.10.1 during the roughly two-hour window starting the evening of May 11, 2026 (U.S. Pacific time), while the poisoned version was circulating. Safe are 0.10.0 and earlier, and the fixed 0.10.2 and later. If this applies to you, remove 0.10.1 immediately and rotate (reissue) your credentials as described below.

Version	Status	What to do now
0.10.2 or later	Safe (post-fix)	OK to use as is
0.10.1	Poisoned (compromised)	Remove now and rotate all credentials
0.10.0 or earlier	Not affected	No action if you never touched 0.10.1

The malicious code was written to run only on Linux. That said, development containers and CI (automated builds) often run on Linux, so caution is warranted if 0.10.1 was pulled into such an environment. The official advisory says "a review of system and access logs has produced no evidence of user data exfiltration," while stating that any host that pulled in 0.10.1 should be treated as potentially compromised. Concretely, this means reissuing GitHub, cloud, and npm/PyPI tokens and checking accounts for suspicious activity. Also, the API keys for Guardrails AI's paid services (Snowglobe / Guardrails Hub) were invalidated en masse by the operators, so users need to reissue them.

What happened: the second stage is summoned the moment it is imported

A supply-chain attack does not exploit a "flaw" in software; it mixes poison into the legitimate distribution itself so users pull it in as the genuine article. Here, the attacker published a poisoned 0.10.1 to PyPI impersonating the real guardrails-ai, targeting developers who ran pip install as usual.

In the poisoned version, about 13 lines of new code were added to guardrails/__init__.py, the package's entry point. This runs automatically the moment the package is loaded (imported), fetches a second-stage program from an attacker site (git-tanstack[.]com), and executes it with Python (python3). According to SafeDep's analysis, this second stage is a credential stealer that also reaches a special address returning cloud internal information (169.254.169.254), attempting to seize cloud-side privileges as well.

CVE-2026-45758: a malicious 0.10.1 published to PyPI (CWE-506)

This incident is tracked as CVE-2026-45758. Its technical classification is "embedded malicious code" (CWE-506) — not a coding mistake in the software, but malice intentionally planted in the distribution. The CVSS breakdown shows it succeeds over the network (AV:N), with no special privileges (PR:N), needing only the user to pull in the package (UI:R), with impact spreading beyond the affected environment (S:C) and reaching theft, alteration, and destruction of information alike (C:H/I:H/A:H). From the attack's footprints, this poisoned version is attributed to a group called "TeamPCP," which left the signature "With Love TeamPCP" on the external site.

Who wants this bug, and what do they walk off with

What makes this attack frightening is not that the software had a flaw, but that poison was planted in the legitimate distribution itself, so the attacker's code starts running the instant you pip install and load it. The people who go after this are groups like "TeamPCP" that impersonate legitimate package names to publish poisoned versions, the CI dependency resolution that pulls those poisoned versions in automatically, and distributors who use fake update notices to make you take the bait. What they are after is the keyring on that dev machine or build environment: GitHub and npm/PyPI tokens, AWS, GCP, and Azure cloud keys, SSH private keys, and CI/CD credentials — the things that translate directly into the next intrusion. The moment the poisoned 0.10.1 is pulled in, a second-stage program is summoned on Linux and these are siphoned off.

The more it is the developer's keyring that gets taken, the less the damage stops at one machine. With the stolen tokens, attackers move into the person's repositories and published packages, and plant further poison there for distribution, growing into a worm (a self-propagating attack) that spreads to every downstream user of those packages. In fact, this chain of attacks spread more than 400 poisoned versions across over 170 packages including TanStack, Mistral AI, and OpenSearch. From the design that even reaches the cloud internal-information address, a single developer's pull-in can ripple out to the cloud infrastructure and all release artifacts beyond it.

And the cleanup lands not only on the developer who pulled it in but on every product and user that depends on the package. Bulk revocation and reissuance of leaked tokens, rebuilding the build environment, notifying users where supply-chain poisoning is suspected — heavier than the CVSS 9.6 is the fact that even if not a single line of your own code is wrong, you get caught up if just one of the components you depend on is poisoned. That is why verifying the provenance of the components you pull in, and having a way to notice poisoning quickly, are indispensable in modern development.

This is not a one-off: the chain of supply-chain attacks by "TeamPCP"

This Guardrails AI poisoning is part of a large wave of attacks that has continued for months. The group "TeamPCP" left the same signature as in the March 2026 compromise of the distribution of the security scanner Trivy, and in May it poisoned a large number of packages across npm and PyPI at once in what is called the "Mini Shai-Hulud" self-propagating attack.

The targets in this wave were the TanStack router family of data-fetching libraries (42 packages), the UiPath automation tooling (65 packages), the OpenSearch search backend (1.3M weekly npm downloads), and, in AI, Mistral AI's SDK and Guardrails AI. According to SecurityWeek's reporting, the poisoned code used hooks that run automatically on install or import, stole CI/CD tokens, cloud keys, and GitHub credentials, and was designed to linger via persistence programs like gh-token-monitor.

We have also tracked the same TeamPCP's compromise of Telnyx (a new technique hiding malware inside WAV files) and the chain that spread from TanStack to the VS Code extension Nx Console on this blog. This Guardrails AI case shows the same attacker expanding its targets into AI development. To continuously inspect dependencies prone to poisoning, the mindset of monitoring and scanning the OSS supply chain is useful.

From discovery to response

The poisoned version was detected and quarantined quickly, but environments that pulled it in during that window are affected. Here is the timeline.

← Swipe to move

Why AI-related tools are being targeted

It is no accident that components used in AI development, like Mistral AI and Guardrails AI, were targeted one after another in this wave. AI-related libraries add features fast, and developers pull in the latest versions frequently. The higher the update cadence, the higher the odds of pulling in a poisoned version right after it appears.

On top of that, building and running AI apps tends to happen in environments holding powerful cloud privileges and API keys. Model calls, reading and writing data, GPU-backed builds — because it is a place where high-value credentials gather, the payoff for an attacker who can poison just one component running there is large. Around AI components, cases where a setting that trusts and loads external models is abused have also been reported, making the risk of "just installing a handy AI component" very real.

Guardrails AI itself is a component that provides "safety mechanisms" to strip personal information and harmful content from LLM output. The very component for using AI safely became an entry point for attack when its distribution channel was hit — that is the shape of this incident. Even a tool that protects AI does not complete its defense unless the channel through which you pull it in is inspected too.

What to do right now

What developers should do first is check whether their environment pulled in 0.10.1. The steps are as follows.

Check the installed version of guardrails-ai; if it is 0.10.1, immediately update to 0.10.2 or later (or roll back to 0.10.0)
Review CI build logs and container history to see whether 0.10.1 was pulled in during the roughly two-hour window in question
If you pulled in 0.10.1, reissue all GitHub, cloud (AWS/GCP/Azure), npm/PyPI, and SSH tokens and keys, and check for suspicious activity
Reissue the API keys for Guardrails AI's paid services (Snowglobe / Guardrails Hub)
For the future, adopt dependency version pinning (lock files), hash verification, and supply-chain scanning

In particular, if you run setups that automatically pull in the latest versions in CI or containers, prioritize checking whether past builds touched the poisoned version. Because this attack succeeds "at the instant of install or load," even if you notice later, any environment that pulled it in during that window must be treated as compromised. In team development, the surest move is to broadcast the check and rotation to everyone who shares the same dependencies.

FAQ

Q. How do I check whether I was affected?

Check whether the installed version of guardrails-ai is 0.10.1. If it is 0.10.0 or earlier, or 0.10.2 or later, that version itself is safe. That said, it is safest to also review build history for whether CI or containers pulled in 0.10.1 during the roughly two-hour window from the evening of May 11, 2026 (U.S. Pacific time).

Q. Are Windows or macOS affected?

This poisoned code was written to run only on Linux. However, development containers and CI often run on Linux, so even if your local machine is Windows/macOS, a Linux build environment may have been affected. Judge by whether it was pulled in.

Q. Has data already been stolen?

The official advisory says that, as far as logs show, there is no evidence of data exfiltration. That said, any environment that pulled in the poisoned version should be treated as potentially compromised, so it is safest to reissue credentials and check for suspicious activity as a precaution.

Q. Is it OK to keep using Guardrails AI?

The problem was only the poisoned 0.10.1; there was no flaw in the design of the software itself. If you use the safe 0.10.2 or later, there is no problem using it as a tool. Going forward, combining version pinning with supply-chain scanning makes it harder to get caught up in the same kind of incident.

Conclusion

CVE-2026-45758 is a supply-chain attack in which a malicious 0.10.1 was mixed into the PyPI distribution of the popular LLM-output validation component Guardrails AI. The poisoned version fetches a second stage from outside the moment it is loaded and tries to steal GitHub, cloud, and CI/CD credentials. Safe versions are 0.10.0 and earlier and 0.10.2 and later; environments that pulled in 0.10.1 need to reissue credentials on the assumption of compromise.

This incident is not a one-off but part of a chain of attacks in which the group "TeamPCP" spread 400+ poisoned versions across over 170 packages including TanStack and Mistral AI, showing that its targets have expanded into AI development. The handier a component, the faster we tend to pull it in — but inspecting the channel through which you pull it in, and having a way to notice poisoning early, are the surest defense.