Forty minutes on PyPI, months of fallout
A malicious update to a popular artificial intelligence (AI) developer tool sat on the Python Package Index (PyPI) for less than an hour in March 2026. Security researchers are still tallying the damage five months later: a public database released this week by CloudSEK links the incident to more than 2,500 organizations and roughly 434,000 exposed continuous integration and continuous delivery (CI/CD) pipeline files.
The tool at the center of it is LiteLLM, an open-source library that developers use to route application programming interface (API) calls across different large language model (LLM) providers - OpenAI, Anthropic and others - through one common interface. It is a foundational piece of plumbing in a lot of AI products: CloudSEK estimates it draws around 95 million downloads a month and turns up in roughly 36% of cloud environments it scanned.
How the attackers got in
The entry point was not LiteLLM itself but a dependency of it. According to CloudSEK and The Hacker News, a group tracked as TeamPCP first compromised Trivy, a widely used open-source security scanner, around March 19, 2026, by force-pushing malicious commits after obtaining an automation token that had leaked and been rotated late - but not revoked in time. LiteLLM's own build pipeline pulled an unpinned copy of Trivy, which gave the attackers a foothold they used to steal LiteLLM's PyPI publishing credentials.
With those credentials, TeamPCP published two trojanized LiteLLM releases, versions 1.82.7 and 1.82.8, on March 24, 2026. They were live for about 40 minutes, roughly 10:39 to 16:00 UTC, before removal. That window was long enough: package registries do not require anyone to notice before a build server somewhere pulls the latest version automatically.
The payload was built to run without anyone importing it. The malicious package planted a file, litellm_init.pth, that Python's interpreter executes automatically on startup - meaning a project that merely had the poisoned version installed could be compromised even if no code ever called it directly.
What the malware took
Once running, the malware - identified in follow-on research as a credential stealer nicknamed SANDCLOCK - harvested a wide net of secrets: Amazon Web Services (AWS), Google Cloud Platform (GCP) and Microsoft Azure credentials, Secure Shell (SSH) keys, Kubernetes tokens, database passwords, CI/CD pipeline secrets, and API keys for AI providers including OpenAI and Anthropic. It encrypted what it collected before exfiltrating it, either to an attacker-controlled domain or to public GitHub repositories.
CloudSEK's August 11 report is the first to put a scale on the exposure: over 2,500 organizations and about 434,000 pipeline files or records. The firm's high-confidence match list names large organizations including NVIDIA, AWS, Cisco, Salesforce, Samsung, Siemens, Volkswagen, Deloitte, X (formerly Twitter), FedEx, Orange and Zscaler as having exposed data tied to the incident. The Hacker News reported on August 12 that a CERT-EU assessment confirmed a European Commission AWS account was compromised, and that security firms Checkmarx and Mercor separately disclosed being affected.
The incident has an official paper trail: CVE-2026-33634 was added to the Cybersecurity and Infrastructure Security Agency's (CISA) Known Exploited Vulnerabilities catalog on March 26, 2026, two days after the malicious releases went out. The Federal Bureau of Investigation (FBI) followed with a FLASH advisory on July 2, warning that credentials stolen during the exposure window remain usable by attackers until they are rotated - a five-month-old breach does not become safe to ignore just because it is old news.
What it means in practice
CloudSEK has published a public lookup tool so organizations can check whether their own systems appear in the exposure dataset, and is urging three concrete steps for anyone who ran LiteLLM 1.82.7 or 1.82.8 during the March 24 window: rotate every credential that system could reach, including AI provider keys, cloud credentials and CI/CD secrets; search your own GitHub organization for suspicious repositories named along the lines of tpcp-docs or docs-tpcp, which the attackers used as exfiltration drop points; and move away from long-lived static tokens toward short-lived credentials wherever your CI/CD setup allows it.
The broader lesson generalizes past this one library. LiteLLM's own supply chain broke because its build process trusted an unpinned dependency - a common pattern in fast-moving AI tooling, where projects pull in scanners, linters and other build-time tools without pinning them to a known-good version. Any team building on top of open-source AI infrastructure should treat its build pipeline's own dependencies with the same scrutiny as the application code it ships, because an attacker only needs to compromise one link that everyone else trusts by default.
