plaincve:~$

// threat brief

CVE-2026-45758

guardrails-ai 0.10.1 shipped malicious code: a PyPI supply-chain compromise of an AI safety library

CVSS
9.6 CRITICAL
CISA KEV
Not listed
Weakness
CWE-506
Topics
Supply chain · AI security

PlainCVE Team · Published 2026-09-24 · AI-assisted · Press brief ↓

Human review 2026-09-24Command tests: none yetReproduced: not yetVerification record ↓

A malicious guardrails-ai 0.10.1 was pushed to PyPI with a stolen token; on Linux, importing it fetched and ran a remote payload.

Who is affectedAny computer, CI environment or container image that installed guardrails-ai 0.10.1 from PyPI during a roughly two-hour window on 2026-05-11. Versions 0.10.0 and 0.10.2 are not affected.
What happensResearchers say the malicious code downloaded and ran a credential stealer. On any machine that installed and imported 0.10.1, treat every GitHub token, cloud key, registry token and API key it could reach as possibly stolen.
What to do nowCheck your environments and lockfiles for 0.10.1. If you find it, switch to 0.10.0 or 0.10.2 or later, treat the machine as possibly compromised, and rotate every credential it could reach.
View evidence(4)
  • Vendor / maintainerVendor advice: if you installed 0.10.1, treat the host as possibly compromised, rotate every credential it could reach, and audit your GitHub accountIf you installed 0.10.1, treat the host as potentially compromised.github.com
  • Vendor / maintainerVendor advice: consider reimaging the machine if it holds sensitive credentialsConsider a full machine reimage if the host handles sensitive credentialsgithub.com
  • ResearchersThe Hacker News, about the npm payload in the same wave: isolate and image the machine before revoking tokensIt's therefore essential that developers do not revoke the npm tokens before isolating and imaging the system.thehackernews.com
  • Our assessmentWhether the guardrails Python payload also wipes files when its token is revoked is unconfirmed; we still suggest isolating before rotating because it costs little
Affected versions0.10.1 only
View evidence(4)
  • Vendor / maintainerGuardrails AI advisory: anyone who installed 0.10.1 from PyPI on 2026-05-11 is affectedany user who installed guardrails-ai==0.10.1 from PyPI on May 11, 2026.github.com
  • CVE recordThe CVE record's structured data lists only 0.10.1 as affected"version":"= 0.10.1"cveawg.mitre.org
  • Vulnerability databaseOSV lists only 0.10.1 as affectedosv.dev
  • ResearchersSocket researchers: the malicious code downloads and runs a remote payload on Linux when the package is importedThe compromised version contains malicious code that downloads and executes a remote payload on Linux systems upon import.github.com
Fixed versions0.10.0 (vendor advisory) or 0.10.2 and later (CVE record and NVD)
View evidence: sources disagree(4)
  • Vendor / maintainerDisputedGuardrails AI advisory names only 0.10.0 as safe; when it was published there was no patched version above 0.10.1No patched version above 0.10.1 is available yet.github.com
  • Vendor / maintainerDisputedVendor SECURITY_ADVISORY.md: 0.10.0 and earlier are safe; it does not mention 0.10.2github.com
  • CVE recordDisputedCVE record: upgrade to 0.10.2 or downgrade to 0.10.0, both unaffectedUsers should upgrade to version 0.10.2 or downgrade to version 0.10.0, both of which are unaffected.cveawg.mitre.org
  • Vendor / maintainerVendor release notes: 0.10.2 moved to PyPI trusted publishingrelease workflow for trusted publishinggithub.com
CVSS vector
Show full vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
Timeline
  • Introduced 2026-05-11 · Malicious 0.10.1 published to PyPI (Pacific time) source
  • First public 2026-05-11
CISA KEVNot listed(Not being in KEV does not mean it has not been exploited)
View evidence(4)
  • Our assessmentOur 2026-09-24 CISA KEV snapshot does not list this CVE; not being listed does not mean it has not been exploited
  • CERT / governmentCISA's SSVC assessment in the CVE record says Exploitation: none; the malicious release is itself the attack, so this does not mean machines that installed it are safe"Exploitation":"none"cveawg.mitre.org
  • Vendor / maintainerVendor advisory: an attacker published the malicious 0.10.1, which researchers caught and PyPI quarantined within about two hoursSecurity researchers identified the malicious package within approximately 2 hours of publication, and PyPI quarantined the repository.github.com
  • Vendor / maintainerThe vendor's review of its own system and access logs found no evidence of user data exfiltration through its systems; this covers only the vendor's systems and does not prove that machines which installed the package were safea review of system and access logs has produced no evidence of user data exfiltration through our systems.github.com

Blue team playbook

Check, fix / mitigate, respond, harden. Matching the affected versions does not mean you were compromised, and a check that finds nothing does not prove you are safe; each item says what it can and cannot show. Tagged steps point to where the attack flow below can be stopped.

DETECTCheckAm I affected? Any signs of compromise?
  1. 01Find out whether 0.10.1 was ever installed

    Vendor advice: check dev machines, virtual environments, lockfiles (files that record exact dependency versions) and CI images. Anything that installed 0.10.1 from PyPI on 2026-05-11 is exposed. poetry.lock, uv.lock and Pipfile.lock put the package name and version on separate lines, so they are matched separately; the last line looks for the installed metadata folder directly. Do not use pip or python to check a possibly infected environment.

    Read-only check
    grep -rnE 'guardrails-ai==0\.10\.1' --include='*.txt' --include='*.in' . 2>/dev/null
grep -rn -A2 '^name = "guardrails-ai"' --include=poetry.lock --include=uv.lock . 2>/dev/null | grep 'version = "0.10.1"'
grep -rn -A6 '"guardrails-ai": {' --include=Pipfile.lock . 2>/dev/null | grep '"==0.10.1"'
find / -type d -name 'guardrails_ai-0.10.1.dist-info' 2>/dev/null
    Step 4
  2. 02Check for the file path researchers published

    Socket says the payload is written to /tmp/transformers.pyz. This path comes from researchers; the vendor has published no indicators of compromise (IoCs). /tmp may be wiped on reboot, so finding nothing doesn't prove the machine is clean.

    Read-only check
    ls -l /tmp/transformers.pyz 2>/dev/null
    Step 5
  3. 03Audit GitHub account activity

    Vendor advice: look for unauthorized workflow runs, new repositories or unexpected commits.

    Read-only check
    gh run list --repo OWNER/REPO --limit 100
    Step 1Step 2Step 6
MITIGATEFix / mitigatePatch; block it if you cannot patch yet
  1. 01Remove 0.10.1 and move to a safe version

    The vendor advisory recommends 0.10.0, which you can also install from the v0.10.0 git tag. The CVE record and NVD also list 0.10.2 and later as safe.

    Changes your environment
    pip install "guardrails-ai==0.10.0"   # or "guardrails-ai>=0.10.2" per CVE record / NVD
    Step 5
  2. 02Snowglobe / Guardrails Hub users: get new API keys

    The vendor force-invalidated all Snowglobe and Hub API keys on 2026-05-13, so you need new ones.

RESPONDRespondIf you find signs of compromise
  1. 01Treat the machine as possibly compromised

    Vendor advice: consider reimaging if the machine holds sensitive credentials. The npm payload in the same wave wipes files when it detects that its stolen token was revoked, so The Hacker News advises isolating and imaging the machine before revoking tokens. Whether the guardrails Python payload does the same is unconfirmed.

    Step 5Step 6
  2. 02Rotate every credential the machine could reach

    The vendor lists GitHub PATs, cloud keys, package registry tokens and API keys. TanStack's guidance for the same wave also covers AWS, GCP, Kubernetes, Vault and SSH credentials.

    Step 6
HARDENHardenPrevent the next one
  1. 01Publish packages with trusted publishing

    Starting with 0.10.2, guardrails-ai publishes through PyPI trusted publishing, so no long-lived upload token exists. You can do the same for packages you maintain.

    Step 2Step 3
  2. 02Narrow CI token scopes and check dev tool config folders

    Socket's advice for this wave: limit the scope of GitHub Actions OIDC (the mechanism CI uses to get short-lived cloud credentials), and check .claude/ and .vscode/ folders for planted persistence.

    Step 1Step 2
Full remediation steps and notes

Order matters. The npm payload in the same wave wipes the home directory when it detects that its stolen token was revoked, so The Hacker News advises isolating and imaging the machine before revoking tokens. Whether the guardrails Python payload does the same is unconfirmed, but isolating first costs little.

  1. Find every place 0.10.1 was installed. Check dev machines, virtual environments, requirements*.txt, poetry.lock, uv.lock, CI caches and container images. Even if an image has since been rebuilt, old build logs may show which version was installed at the time.
  2. Switch to a safe version. The vendor recommends pip install "guardrails-ai==0.10.0" or installing from the v0.10.0 git tag. The CVE record and NVD also accept 0.10.2 or later.
  3. Isolate, then rotate. Rotate every token and key that machine (or CI job) could reach, not just the ones related to guardrails.
  4. The vendor’s data statement has limits. The vendor says that after reviewing its own system and access logs it found no evidence of user data being exfiltrated through its systems. “No evidence found” is not the same as “nothing was taken”, and it covers only the vendor’s own systems. Researchers say the payload downloaded a stealer from the attacker’s server, so the vendor’s statement can’t show that your machine is safe.

Attack flow

Read left to right: this is the order the attack happens in. A blue shield means the step can be stopped; the earlier, the better. Click an icon for details.

guardrails-ai 0.10.1 shipped malicious code: a PyPI supply-chain compromise of an AI safety library: 1. Steals one employee's GitHub personal access token → 2. Triggers GitHub Actions in about 30 repos and pulls secrets out of build artifacts → 3. Publishes a malicious 0.10.1 to PyPI with the stolen upload token → 4. A user or CI job installs guardrails-ai 0.10.1 → 5. On Linux, importing the package downloads and runs a remote payload → 6. A credential stealer collects secrets from the machineCVE-2026-45758 · guardrails-ai 0.10.1 shipped malicious code: a PyPI supply-chain compromise of an AI safety libraryAttackerYour systemExternalSteals one employee's GitHub personal access token — A personal access token (PAT) is a string that can act on GitHub in place of a password. The vendor says the breach started here but hasn't said how the token leaked. 1Steals oneemployee's GitHubpersonal accesstokenTriggers GitHub Actions in about 30 repos and pulls secrets out of build artifacts — GitHub Actions is a CI/CD system that builds and publishes code automatically. From the job output, the attacker got the repositories' secrets, including a PyPI upload token. The vendor says the attacker also tried and failed to reach its Ray inference cluster and other package systems. 2Triggers GitHubActions in about30 repos and pullssecrets out o…Publishes a malicious 0.10.1 to PyPI with the stolen upload token — It went up around 6:00 PM Pacific on 2026-05-11. Researchers spotted it about two hours later, and PyPI quarantined the project. 3Publishes amalicious 0.10.1to PyPI with thestolen upload tokenA user or CI job installs guardrails-ai 0.10.1 — Any install during that window that didn't pin a version could pull 0.10.1. 4A user or CI jobinstallsguardrails-ai0.10.1On Linux, importing the package downloads and runs a remote payload — Socket says the code was added to __init__.py. It writes a file to /tmp/transformers.pyz and runs it with python3 without any integrity check. No source says whether installing without importing runs anything. 5On Linux,importing thepackage downloadsand runs a remot…A credential stealer collects secrets from the machine — Wiz reports that the download is a modular credential stealer fetched from the attacker's command-and-control (C2) server. The vendor hasn't said what it did. 6A credentialstealer collectssecrets from themachineAttack pathCan be stopped herePlainCVE · plaincve.date/en/vulns/cve-2026-45758-guardrails-ai-pypi-compromise · CC BY 4.0
Free to use in reporting and teaching under CC BY 4.0. Attribution is already on the image.
  1. Attacker

    Steals one employee's GitHub personal access token

    A personal access token (PAT) is a string that can act on GitHub in place of a password. The vendor says the breach started here but hasn't said how the token leaked.

    Defense: Use narrowly scoped, short-lived tokens and regularly review which ones are still active.

  2. Attacker

    Triggers GitHub Actions in about 30 repos and pulls secrets out of build artifacts

    GitHub Actions is a CI/CD system that builds and publishes code automatically. From the job output, the attacker got the repositories' secrets, including a PyPI upload token. The vendor says the attacker also tried and failed to reach its Ray inference cluster and other package systems.

    Defense: Keep secrets out of build artifacts and limit who can trigger workflows.

  3. Attacker

    Publishes a malicious 0.10.1 to PyPI with the stolen upload token

    It went up around 6:00 PM Pacific on 2026-05-11. Researchers spotted it about two hours later, and PyPI quarantined the project.

    Defense: Switch to PyPI trusted publishing so no long-lived upload token exists. The project did this in 0.10.2.

  4. Your system

    A user or CI job installs guardrails-ai 0.10.1

    Any install during that window that didn't pin a version could pull 0.10.1.

    Defense: Pin exact versions in a lockfile so a new release can't slip in unnoticed.

  5. Your system

    On Linux, importing the package downloads and runs a remote payload

    Socket says the code was added to __init__.py. It writes a file to /tmp/transformers.pyz and runs it with python3 without any integrity check. No source says whether installing without importing runs anything.

    Defense: Move to 0.10.0 or 0.10.2+ and remove 0.10.1.

  6. External

    A credential stealer collects secrets from the machine

    Wiz reports that the download is a modular credential stealer fetched from the attacker's command-and-control (C2) server. The vendor hasn't said what it did.

    Defense: Rotate every credential the machine could reach and audit GitHub activity.

Who is affected

ConditionAffected?
Installed guardrails-ai 0.10.1 from PyPI on 2026-05-11 and imported it on LinuxAffected; treat the machine as possibly compromised
Installed 0.10.1 but only used it on non-Linux systems, or never imported itResearchers say the payload runs only on Linux and only at import. Whether install alone is safe is unconfirmed. Rotating credentials is still advised
0.10.0 or earlierNot affected
0.10.2 or laterNot affected (per the CVE record and NVD)

Sources don’t fully agree on which versions are safe:

SourceAffectedSafe
Vendor GHSA advisory0.10.1Names only 0.10.0
Vendor SECURITY_ADVISORY.md0.10.10.10.0 and earlier; doesn’t mention 0.10.2
CVE record (CNA: GitHub)0.10.1 only0.10.0 or 0.10.2 and later
NVD0.10.1Upgrade to 0.10.2 or downgrade to 0.10.0
OSV0.10.1 onlyNot listed

PyPI no longer shows 0.10.1. The release history jumps straight from 0.10.0 to 0.10.2 (released 2026-06-04).

How it works

This is not a coding bug. The release process was broken into, and malicious code was deliberately put into an official version. That kind of case is classed as CWE-506 (Embedded Malicious Code).

How the vendor says the break-in happened:

  1. One employee’s GitHub personal access token (PAT, a string that can act on GitHub in place of a password) leaked.
  2. The attacker used it to trigger GitHub Actions (the CI/CD system that builds and publishes code automatically) in about 30 repositories in the guardrails-ai organization, then pulled the repositories’ secrets out of the build artifacts.
  3. With one of those secrets, a PyPI upload token, the attacker published the malicious 0.10.1. The vendor says the attacker also tried and failed to reach its Ray inference cluster and other package systems.

What researchers observed (the vendor has not published this):

  • Socket says the code was added to the package’s __init__.py, the file that always runs when the package is imported. On Linux, it downloads a remote file, writes it to /tmp/transformers.pyz, and runs it without any integrity check.
  • Wiz says the addition was only 13 lines, which download and run a modular credential stealer from the attacker’s command-and-control (C2) server. Socket published the download domain as git-tanstack[.]com (defanged here so it can’t be clicked).
  • The Hacker News notes that the npm packages in the same wave ran at install time, while this Python package ran at import time.

Conceptual illustration (not Guardrails’ actual configuration): the root problem is a long-lived upload token stored in CI. Once repository secrets leak, anyone holding that token can publish a new version.

Show code example(yaml)
# Risky: a long-lived upload token stored in repo secrets
- run: twine upload dist/*
  env:
    TWINE_PASSWORD: ${{ secrets.PYPI_TOKEN }}
Show code example(yaml)
# Safer: trusted publishing swaps for a short-lived credential at release time
permissions:
  id-token: write
- uses: pypa/gh-action-pypi-publish@release/v1

The 0.10.2 release notes say the project has moved to PyPI trusted publishing.

Timeline

DateEvent
2026-05-11 ~6:00 PM PTMalicious 0.10.1 published to PyPI
2026-05-11 ~8:00 PM PTDetected; PyPI quarantines the project
2026-05-12Socket opens GitHub issue #1473; vendor publishes the GHSA advisory
2026-05-13CVE ID reserved; vendor invalidates all Snowglobe / Hub API keys at 2:00 PM PT
2026-05-19OSV entry published
2026-06-040.10.2 released
2026-06-05CVE published
2026-06-08CISA adds its SSVC assessment
2026-07-23NVD last modified (status “Analyzed”)

Further reading

  • Score: CVSS 3.1 9.6 (Critical), assigned by GitHub (the CNA). NVD shows it as a secondary score and hasn’t added its own.
  • “Exploited”? This CVE is not in CISA KEV, and CISA’s SSVC assessment says Exploitation: none. But a malicious package is itself the attack: if you installed and imported 0.10.1, assume the malicious code ran.
  • Link to Mini Shai-Hulud: Socket, Wiz, The Hacker News and SecurityWeek all place this incident in the 2026-05-11 Mini Shai-Hulud wave, and Socket names TeamPCP. The vendor only calls it part of a broader campaign and names neither. The entry routes also differ: TanStack was breached through a pull_request_target workflow and cache poisoning, while Guardrails reports a leaked employee PAT. Whether the worm spread to this package automatically or it was a separate hands-on intrusion is unconfirmed.
  • Unconfirmed claims: SecurityWeek says the payload targeted password managers such as 1Password and Bitwarden, and on systems with Israel or Iran locale settings played audio at maximum volume and deleted files. Only that one source reports this.
  • Aliases: GHSA-xmpw-2vmm-p4p6, PYSEC-2026-206.
  • Mistral AI’s PyPI package (mistralai 2.4.6) was hit the same day. TanStack’s incident has its own ID, CVE-2026-45321.

Verification Reviewed and checked against sources; not yet reproduced in our lab

Reviewed2026-09-24

Verification records describe the environment and the result only, never reproduction steps or code that could attack other people’s systems. See our policy.

Sources

  1. AdvisoryMalicious code in guardrails-ai 0.10.1 (supply chain compromise) — GHSA-xmpw-2vmm-p4p6 · Guardrails AI (GitHub), 2026-05-12 · accessed 2026-09-23
  2. VendorSECURITY_ADVISORY.md · Guardrails AI · accessed 2026-09-23
  3. AdvisoryCVE-2026-45758 record · CVE Program / GitHub_M, 2026-06-05 · accessed 2026-09-23
  4. CVE / NVD / OSVNVD - CVE-2026-45758 · NIST NVD, 2026-06-05 · accessed 2026-09-23
  5. AdvisoryGHSA-xmpw-2vmm-p4p6 · OSV, 2026-05-19 · accessed 2026-09-23
  6. AdvisoryAdvisories for Pypi/Guardrails-Ai package · GitLab · accessed 2026-09-23
  7. Patch / releaseReleases · guardrails-ai/guardrails · Guardrails AI, 2026-06-04 · accessed 2026-09-23
  8. Otherguardrails-ai release history · PyPI · accessed 2026-09-23
  9. Research[SECURITY] Supply Chain Compromise in guardrails-ai v0.10.1 on PyPI (issue #1473) · Socket Threat Research (GitHub issue), 2026-05-12 · accessed 2026-09-23
  10. ResearchTanStack npm Packages Compromised in Ongoing Mini Shai-Hulud Supply-Chain Attack · Socket, 2026-05-11 · accessed 2026-09-23
  11. ResearchMini Shai-Hulud Strikes Again: TanStack + more npm Packages Compromised · Wiz, 2026-05-12 · accessed 2026-09-23
  12. VendorPostmortem: TanStack npm supply-chain compromise · TanStack, 2026-05-15 · accessed 2026-09-23
  13. ResearchA Mini Shai-Hulud Has Appeared · StepSecurity, 2026-04-29 · accessed 2026-09-23
  14. NewsMini Shai-Hulud Worm Compromises TanStack, Mistral AI, Guardrails AI & More Packages · The Hacker News, 2026-05-12 · accessed 2026-09-23
  15. NewsTanStack, Mistral AI, UiPath Hit in Fresh Supply Chain Attack · SecurityWeek, 2026-05-12 · accessed 2026-09-23

Press brief

In one sentence

Guardrails AI is an open-source safety library that helps AI applications check and filter their outputs. On May 11, 2026, attackers used an upload token stolen from the company's CI pipeline to publish a malicious version 0.10.1 to PyPI, the Python package registry; it was caught and quarantined about two hours later. Researchers say loading this version on Linux downloaded and ran a credential stealer. Several security firms place the incident in that day's Mini Shai-Hulud supply-chain wave, though the vendor itself has not said so.

Key facts

Affected version
0.10.1 only (published 2026-05-11) github.com
Severity
CVSS 3.1 9.6 Critical (CNA: GitHub) nvd.nist.gov
CVE published
2026-06-05 nvd.nist.gov
Clean new release
0.10.2 (released 2026-06-04) pypi.org
Researcher attribution
Mini Shai-Hulud wave / TeamPCP (not vendor-confirmed) github.com

Confirmed

  • A malicious guardrails-ai 0.10.1 was published to PyPI on 2026-05-11 and quarantined about two hours later (vendor advisory).
  • It started with one employee's leaked GitHub PAT, which the attacker used to abuse CI and obtain a PyPI upload token (vendor statement).
  • The vendor says that after reviewing its own system and access logs it found no evidence of user data being exfiltrated through its systems; this covers only the vendor's own systems and does not prove that machines which installed the package were not robbed.

Unconfirmed / disputed

  • The link to Mini Shai-Hulud / TeamPCP comes only from researchers and the press; the vendor only calls it part of a broader campaign.
  • SecurityWeek says the payload targeted password managers and, on systems with Israel or Iran locale settings, played audio and deleted files; no other source confirms this.
  • No source says explicitly whether installing without importing runs the payload.
  • The vendor advisory names only 0.10.0 as safe; the CVE record and NVD also list 0.10.2 and later as safe.

Quotable line

No line of code was buggy this time. The attacker simply got hold of the publishing keys, and even an AI safety guardrail could be swapped out.

Images

Download the share image (PNG) · Attack flow diagram (downloadable)

Please credit "PlainCVE" and link to this page. Full citation format is under "How to cite" below. Found a factual error? Report it.

How to cite this page

This article is CC BY 4.0. Please keep the attribution and link when republishing.

PlainCVE Team (2026). "guardrails-ai 0.10.1 shipped malicious code: a PyPI supply-chain compromise of an AI safety library". PlainCVE. https://plaincve.date/en/vulns/cve-2026-45758-guardrails-ai-pypi-compromise (accessed YYYY-MM-DD)
BibTeX
@misc{cve202645758guardrailsaipypicompromise2026,
  title  = {guardrails-ai 0.10.1 shipped malicious code: a PyPI supply-chain compromise of an AI safety library},
  author = {PlainCVE Team},
  year   = {2026},
  howpublished = {PlainCVE},
  url    = {https://plaincve.date/en/vulns/cve-2026-45758-guardrails-ai-pypi-compromise},
  note   = {Updated 2026-09-24}
}