Loading story…
Malicious PyPI packages posing as helpers for Astral's legitimate Python package manager uv were used to compromise Windows systems and expose local development environments to the internet. Xygeni tracked the cluster as FauxUV, identifying packages including moon-uv and my-magic-uv-helper that appeared related to the real uv ecosystem documented by Astral, but delivered little legitimate functionality. Instead, the packages abused that trust by referencing authentic uv installer sources to look benign during review.
The payloads launched JupyterLab with authentication disabled, creating an unauthenticated remote code execution environment on the victim host. According to the report, the campaign evolved from install-time execution through setup.py and PowerShell into a pip-uv command that started the exposed JupyterLab instance and, in later versions, opened a reverse tunnel through Pinggy to publish the service on the public internet; commented code also indicated an alternative exposure path using cloudflared. The activity turned a developer workstation into an externally reachable code-execution platform with minimal user awareness.
Trace attribution and downstream blast radius.
2 events from the most recent confirmed update back to the earliest known activity.
On July 10, 2026, Xygeni reported a malicious PyPI campaign tracked as FauxUV that impersonated helpers for Astral's uv package manager. The packages, including moon-uv and my-magic-uv-helper, were described as exposing JupyterLab without authentication and enabling remote code execution on affected Windows systems.
Astral's documentation for the legitimate Python package manager uv was published, establishing the real project later impersonated by malicious PyPI packages.
Vulnerabilities, threat actors, malware, products, organizations, breaches, and observables Mallory has linked to this story. Indicator values are masked here and available in full in the app.
Indicator values are masked on this page. See the values in Mallory Domains, IPs, hashes, and URLs are exportable to your SIEM.
See attribution and downstream blast radius, and whether this package or vendor reaches your builds.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Datadog Security Labs reported that the **TeamPCP** supply-chain campaign compromised the legitimate PyPI package **LiteLLM**, publishing malicious versions `1.82.7` and `1.82.8` that stole credentials, exfiltrated data, established persistence, and in some cases attempted to spread into Kubernetes environments. The campaign also hit **Telnyx** on PyPI and was linked to earlier compromises involving Trivy, npm packages, Aqua Security repositories, and Checkmarx tooling, with researchers concluding that stolen CI/CD and publishing credentials were reused across ecosystems. Datadog warned that LiteLLM `1.82.8` was especially dangerous because a malicious `.pth` file triggered payload execution when the Python interpreter started, while the Telnyx package executed code at import time and retrieved a second-stage payload hidden in a WAV file. Separately, X41 disclosed a high-severity **sandbox escape** in BerriAI LiteLLM affecting the `main-latest` Docker image, where authenticated users could reach arbitrary code execution through the `/guardrails/test_custom_code` API endpoint. The flaw relied on bypassing regex-based restrictions on custom Python guardrail code using string concatenation and CPython bytecode rewriting to recover unrestricted builtins and call `__import__`, allowing commands to run as the LiteLLM process user, which is **root** in the default Docker deployment. X41 assigned the issue **CWE-94** and a **CVSS 4.0 score of 8.7**, and Datadog advised organizations that installed the malicious LiteLLM releases to treat affected hosts and CI jobs as full credential-exposure events, rotate secrets, hunt for persistence and outbound traffic, and rebuild critical systems from known-good images rather than relying only on package rollback.
Jun 30, 2026
Malicious versions `1.82.7` and `1.82.8` of the widely used `litellm` Python package were uploaded to PyPI after attackers used compromised publishing access, turning a popular AI gateway library into a supply-chain malware delivery vehicle. Researchers and project maintainers said the tainted code was absent from the upstream GitHub repository, indicating the compromise occurred in the release pipeline or during package publication. The malware executed on import in `1.82.7`, while `1.82.8` added a `litellm_init.pth` file that triggered on every Python interpreter startup, greatly expanding exposure even beyond direct use of the package. PyPI removed or quarantined the malicious releases, and `1.82.6` was identified as the last known clean version. The payload harvested a broad range of secrets, including cloud credentials, SSH keys, API tokens, Kubernetes service-account tokens, database and CI/CD secrets, `.env` files, shell histories, TLS keys, and cryptocurrency wallet data, then encrypted and exfiltrated the data to attacker-controlled infrastructure including `models.litellm.cloud`. Multiple reports said the malware also attempted Kubernetes lateral movement by enumerating clusters, dumping secrets, and deploying privileged pods across nodes, while establishing Linux persistence through a disguised `systemd` user service that contacted `checkmarx.zone` for follow-on payloads. Researchers linked the intrusion with high confidence to **TeamPCP**, tying it to the earlier Trivy compromise and a broader campaign spanning GitHub Actions, Docker Hub, npm, OpenVSX, and PyPI; organizations that installed and ran the affected versions were urged to assume full credential compromise, rotate secrets, inspect for persistence, and review Kubernetes environments for rogue activity.
Jul 29, 2026
Researchers reported that the **Hades** malware campaign, tied to the broader **Shai-Hulud/Miasma** lineage, poisoned **19 PyPI packages** across **37 malicious releases**, including widely used bioinformatics and science-focused tools. The malicious packages abused Python startup and import mechanisms such as executable `.pth` files and obfuscated `__init__.py` hooks to automatically fetch the **Bun** JavaScript runtime from GitHub and launch an obfuscated stealer payload, often without requiring normal package execution. Investigators said the malware harvested a broad set of secrets from developer workstations and CI/CD environments, including GitHub, npm, PyPI, cloud, Kubernetes, SSH, Docker, and shell-history credentials, while using GitHub repositories, GitHub Actions, and secondary HTTPS channels for exfiltration. Security firms said the operation expands earlier Shai-Hulud tradecraft with **AI-analysis evasion**, hidden prompts intended to mislead LLM-based security tools, payload retrieval from GitHub commits, SSH/SCP-based lateral movement, IDE and AI-assistant backdooring, and destructive components such as a `gh-token-monitor` service. Reporting also linked the campaign to an attempted compromise of the **Pythagora-io/gpt-pilot** project after the maintainer account **LeonOstrez** was breached, although the malicious changes reportedly failed CI checks because formatting and linting rules blocked them. Defenders were urged to rotate exposed secrets, restore from trusted backups, and hunt for indicators including executable `.pth` files, Bun downloads from GitHub, and unusual Python-to-Bun process chains on Linux and macOS systems.
Jun 29, 2026