This is a poisoned bottle on one shelf, not bad plumbing in the whole building
CVE-2026-45758 is not a normal coding flaw in Guardrails AI; it is a malicious PyPI release. The affected population is extremely specific: guardrails-ai==0.10.1, published to PyPI on May 11, 2026, with maintainers saying users who installed that exact version during the short exposure window are affected; 0.10.0 and earlier were called safe, and PyPI later shows 0.10.2 released on June 4, 2026 as the current clean line.
The vendor's CRITICAL 9.6 is fair for a host that actually installed the poisoned artifact, because import-time code execution turns a dependency update into host compromise. But for fleet prioritization across 10,000 hosts, that score overstates reality: this is not internet-reachable, requires your org to have consumed one exact bad package, and was reportedly identified and quarantined within about two hours, which sharply narrows the exposed population.
4 steps from start to impact.
Poisoned dependency gets resolved
guardrails-ai==0.10.1 from PyPI using pip, uv, Poetry, or an indirect lockfile update. Weaponized tool: PyPI package distribution.- Organization uses
guardrails-aidirectly or transitively - Package resolution occurred while the malicious
0.10.1artifact was available - Build controls did not pin hashes or block unapproved versions
- Exact-version requirement: only
0.10.1is affected - Short exposure window before quarantine materially reduced reach
- Many enterprises mirror or approve packages before use, which breaks this step
Import triggers code execution
guardrails/__init__.py, so execution occurs on package import, not necessarily at install time. That matters operationally: the package can sit quietly in an image until an app, notebook, test, or script imports it. Weaponized tool: Python import machinery.- The compromised package is installed
- An application, REPL, notebook, or test imports
guardrails - The runtime is compatible with the malicious logic
- Dormant installs that were never imported may not have executed
- Non-Linux targets may have reduced impact based on reporting about Linux-specific payload execution
- EDR on developer and CI hosts may catch suspicious Python behavior quickly
Second stage is fetched and launched
__init__.py reached out to an external domain, downloaded transformers.pyz, wrote it to /tmp, and executed it with the local Python interpreter on Linux. Because the second stage is remote, attacker behavior can change after publication without republishing the package. Weaponized tool: remote Python payload transformers.pyz.- Outbound network access from the host to attacker infrastructure
- Linux runtime or compatible execution path
- No egress or process-control block on the host
- Egress filtering, proxy enforcement, or DNS sinkholing can stop payload retrieval
- Application allowlisting or EDR may block Python executing temporary artifacts
- If the host never had outbound access, blast radius is reduced
/tmp, outbound requests to the reported domain, and short-lived temp payloads.High-trust dev or CI secrets become the prize
- Affected host contains usable credentials or repository write access
- Attacker payload successfully executed
- Secrets are accessible in environment variables, files, runners, or credential stores
- Strong secret isolation, ephemeral runners, and short-lived tokens cut the blast radius
- MFA helps against reused credentials but does not protect already-issued local tokens
- A laptop with limited local secrets is far less valuable than a shared CI runner
The supporting signals.
| In-the-wild status | Confirmed malicious release, not theoretical. Maintainer advisory says an attacker published guardrails-ai==0.10.1 to PyPI on 2026-05-11; GitHub issue attributes discovery to Socket Threat Research. |
|---|---|
| KEV status | Not in CISA KEV during this assessment. That lowers internet-scale urgency, but it does not make an actually affected host safe. |
| EPSS | 0.00038 (~0.038%) per the user-supplied intel. That is very low predictive exploitation probability, which fits the narrow affected population rather than contradicting the seriousness on impacted hosts. |
| CVSS vector readout | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H means the baseline assumes easy remote abuse with user interaction. In practice the *user interaction* is pulling and importing one poisoned dependency, which is why the fleet-level score comes down. |
| Affected versions | Only guardrails-ai==0.10.1 is listed as affected in the GitHub and GitLab advisories. |
| Fixed / safe versions | Maintainers initially designated 0.10.0 and earlier as safe during quarantine; PyPI now shows 0.10.2 released on 2026-06-04 as the clean current line. |
| Execution behavior | Reporting says malicious code was appended to guardrails/__init__.py and executed on import, then downloaded a remote payload on Linux. This is import-time host compromise, not a passive metadata issue. |
| Exposure population | Narrow by design. This is a library/package compromise, not a remotely reachable service; Shodan/Censys/FOFA-style internet scans do not meaningfully enumerate who is exposed. Your real inventory source is lockfiles, artifact proxies, CI logs, SBOMs, and endpoint package inventories. |
| Disclosure timeline | Maintainer advisory and GHSA were published on 2026-05-12; the user-provided CVE disclosure date is 2026-06-05. Use the May advisory date for incident hunting, not the later CVE catalog date. |
| Reporting / research | Official maintainer advisory plus Socket Threat Research issue reporting are the primary public sources. Campaign-level context was later summarized by the Cloud Security Alliance research note. |
noisgate verdict.
The decisive downward pressure is exposure population: this is not an internet-reachable flaw, it only matters if your org actually pulled one poisoned PyPI artifact during a short window. But if that happened, the impact is still severe because import-time execution on a developer or CI host can immediately expose high-value secrets and code-signing paths.
Why this verdict
- Start from 9.6, then cut for exact-version scope: only
guardrails-ai==0.10.1is affected, not a broad version range. - Cut again for attacker position: this requires the victim to install or resolve the poisoned package; the attacker is piggybacking on software supply chain trust, not reaching you over the network.
- Cut again for short exposure window: maintainers say the malicious release was identified in about two hours and PyPI quarantined it, which materially reduces the fraction of real deployments that ever saw it.
- Do not cut for impact: on a host that imported the package, the reported behavior is remote payload execution on Linux, which is effectively host compromise.
- Do not cut for blast radius on CI: if the affected system is a shared runner or privileged developer workstation, the downstream value of stolen tokens can exceed the single-host impact.
Why not higher?
This is not a wormable network service bug or a broadly reachable remote exploit path. There is no KEV listing, EPSS is very low, and the affected population is sharply narrowed by the exact-version and time-window requirement.
Why not lower?
This was a real malicious package release, not a speculative weakness or lab-only PoC. Any environment that installed and imported the bad artifact should be treated as potentially compromised, which is too serious for MEDIUM or backlog treatment.
What to do — in priority order.
- Block the artifact everywhere — Deny
guardrails-ai==0.10.1in PyPI proxies, artifact repositories, CI allowlists, and policy engines immediately, within hours because this has active exploitation evidence. This stops rehydration from old lockfiles, container rebuilds, and ad hoc notebook installs. - Isolate affected dev and CI hosts — Any host that installed or imported
0.10.1should be treated as potentially compromised immediately, within hours. Prioritize CI runners, build agents, shared notebooks, and developer laptops with package-publish, cloud, or GitHub credentials because those hosts have the highest secondary blast radius. - Hunt for second-stage and secret abuse — Look for Python writing or executing temp payloads, outbound connections to the reported infrastructure, GitHub/org anomalies, and newly used cloud/API tokens immediately, within hours. This matters because uninstalling the package does not prove the attacker did nothing after import.
- Enforce hash-pinned dependency resolution — Require hashes, approved mirrors, and provenance/attestation checks for Python packages within 30 days for the broader control fix aligned to a HIGH finding. This does not undo this incident, but it meaningfully reduces repeat risk from the same class of attack.
WAFor external network vulnerability scanning: this is a dependency compromise, not an internet-facing request/response bug.pip uninstall guardrails-aiby itself: removing the package does not remove any second-stage payload, persistence, or stolen credentials.MFA alone: MFA does not protect already-issued PATs, cloud keys, service tokens, or secrets harvested from a local dev/CI environment.Waiting for your regular patch cycle: the risk is from already-executed malicious code, so calendar-based patching without incident response is the wrong mental model.
Crowdsourced verification payload.
Run this on target developer workstations, CI runners, container images, and build hosts that may have installed Python dependencies. Invoke it with python3 check_guardrails_cve_2026_45758.py; no root is required for the current user context, but broader fleet sweeps across other users or system-wide locations may need elevated rights.
#!/usr/bin/env python3
# check_guardrails_cve_2026_45758.py
# Detect likely exposure to CVE-2026-45758 on a single host.
# Exit codes:
# 0 = PATCHED
# 1 = VULNERABLE
# 2 = UNKNOWN
import os
import sys
from pathlib import Path
try:
from importlib import metadata as importlib_metadata
except Exception:
import importlib_metadata # type: ignore
PACKAGE = "guardrails-ai"
AFFECTED = "0.10.1"
SAFE_EXACT = {"0.10.0", "0.10.2"}
HOME = Path.home()
IOC_PATHS = [
HOME / ".config" / "systemd" / "user" / "gh-token-monitor.service",
HOME / "Library" / "LaunchAgents" / "com.user.gh-token-monitor.plist",
Path("/tmp/transformers.pyz"),
]
def get_version(pkg_name: str):
try:
return importlib_metadata.version(pkg_name)
except importlib_metadata.PackageNotFoundError:
return None
except Exception:
return "ERROR"
def suspicious_paths_present():
found = []
for p in IOC_PATHS:
try:
if p.exists():
found.append(str(p))
except Exception:
pass
return found
def main():
version = get_version(PACKAGE)
found_iocs = suspicious_paths_present()
if version == AFFECTED:
print(f"VULNERABLE: {PACKAGE} {AFFECTED} is installed on this host")
if found_iocs:
print("IOC_PATHS=" + ", ".join(found_iocs))
sys.exit(1)
if found_iocs:
print("VULNERABLE: suspicious campaign-related artifacts found: " + ", ".join(found_iocs))
sys.exit(1)
if version is None:
print(f"UNKNOWN: {PACKAGE} is not installed in this Python environment; check other environments, images, and lockfiles")
sys.exit(2)
if version in SAFE_EXACT:
print(f"PATCHED: {PACKAGE} {version} is a known safe version for this CVE")
sys.exit(0)
# Exact affected version is known; other versions are likely not affected, but stay conservative.
try:
if version != AFFECTED:
print(f"PATCHED: {PACKAGE} {version} is not the known malicious version {AFFECTED}")
sys.exit(0)
except Exception:
pass
print(f"UNKNOWN: unable to confidently assess installed version state for {PACKAGE} ({version})")
sys.exit(2)
if __name__ == "__main__":
main()
If you remember one thing.
guardrails-ai==0.10.1; if you find it anywhere, isolate the host, block the artifact, and begin incident-response triage before treating it as ordinary patch debt. Because there is active exploitation evidence, override the noisgate mitigation SLA and patch / mitigate immediately, within hours; then replace the dependency with 0.10.2 or pin back to 0.10.0 where needed, rebuild affected images and runners, and complete permanent cleanup well inside the noisgate remediation SLA for HIGH findings of ≤180 days—though any actually affected host should be remediated now, not later.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.