← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-45758 · CWE-506 · Disclosed 2026-06-05

Guardrails AI is a Python framework that helps build AI applications

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.

"Only hosts that pulled guardrails-ai 0.10.1 are at risk, but any host that did should be treated as compromised."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Poisoned dependency gets resolved

The attacker does not scan your perimeter; they wait for your build tooling to do the delivery. A developer workstation, CI runner, notebook image, or container build must resolve guardrails-ai==0.10.1 from PyPI using pip, uv, Poetry, or an indirect lockfile update. Weaponized tool: PyPI package distribution.
Conditions required:
  • Organization uses guardrails-ai directly or transitively
  • Package resolution occurred while the malicious 0.10.1 artifact was available
  • Build controls did not pin hashes or block unapproved versions
Where this breaks in practice:
  • Exact-version requirement: only 0.10.1 is affected
  • Short exposure window before quarantine materially reduced reach
  • Many enterprises mirror or approve packages before use, which breaks this step
Detection/coverage: SCA/SBOM and registry/proxy logs are your best coverage here; perimeter vuln scanners provide essentially no visibility.
STEP 02

Import triggers code execution

Socket's reporting, echoed in the maintainer issue, says malicious code was added to 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.
Conditions required:
  • The compromised package is installed
  • An application, REPL, notebook, or test imports guardrails
  • The runtime is compatible with the malicious logic
Where this breaks in practice:
  • 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
Detection/coverage: File-integrity and EDR telemetry can catch unexpected edits under site-packages and Python spawning suspicious follow-on activity.
STEP 03

Second stage is fetched and launched

Third-party technical analysis reports the malicious __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.
Conditions required:
  • Outbound network access from the host to attacker infrastructure
  • Linux runtime or compatible execution path
  • No egress or process-control block on the host
Where this breaks in practice:
  • 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
Detection/coverage: Hunt for Python writing/executing from /tmp, outbound requests to the reported domain, and short-lived temp payloads.
STEP 04

High-trust dev or CI secrets become the prize

Once code runs inside a developer box or CI runner, the real blast radius is the secrets already present there: GitHub PATs, cloud keys, package tokens, model provider API keys, and repo credentials. Campaign-level reporting indicates persistence and destructive follow-on logic were possible in related cases, so defenders should assume the attacker aimed beyond one Python package. Weaponized tool: stolen developer and CI credentials.
Conditions required:
  • Affected host contains usable credentials or repository write access
  • Attacker payload successfully executed
  • Secrets are accessible in environment variables, files, runners, or credential stores
Where this breaks in practice:
  • 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
Detection/coverage: Secret-scanning, Git provider audit logs, cloud IAM anomaly detection, and runner telemetry are higher-value than traditional network scanning for this step.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusConfirmed 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 statusNot in CISA KEV during this assessment. That lowers internet-scale urgency, but it does not make an actually affected host safe.
EPSS0.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 readoutCVSS: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 versionsOnly guardrails-ai==0.10.1 is listed as affected in the GitHub and GitLab advisories.
Fixed / safe versionsMaintainers 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 behaviorReporting 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 populationNarrow 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 timelineMaintainer 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 / researchOfficial 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.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to HIGH (8.2/10)

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.

HIGH Impact on an actually affected host
MEDIUM Population-level exposure estimate across enterprises

Why this verdict

  • Start from 9.6, then cut for exact-version scope: only guardrails-ai==0.10.1 is 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.

05 · Compensating Control

What to do — in priority order.

  1. Block the artifact everywhere — Deny guardrails-ai==0.10.1 in 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.
  2. Isolate affected dev and CI hosts — Any host that installed or imported 0.10.1 should 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.
  3. 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.
  4. 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.
What doesn't work
  • WAF or external network vulnerability scanning: this is a dependency compromise, not an internet-facing request/response bug.
  • pip uninstall guardrails-ai by 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.
06 · Verification

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.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/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()
07 · Bottom Line

If you remember one thing.

TL;DR
By Monday morning, search every dev workstation, CI runner, base image, lockfile, and private mirror for 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

  1. GitHub Advisory Database
  2. Guardrails AI SECURITY_ADVISORY.md
  3. Guardrails AI issue #1473
  4. PyPI project page
  5. GitLab Advisory Database
  6. CISA Known Exploited Vulnerabilities Catalog
  7. Socket package analysis for guardrails-ai 0.10.1
  8. Cloud Security Alliance campaign research note
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.