{"id":60381,"date":"2026-03-26T00:00:00","date_gmt":"2026-03-26T00:00:00","guid":{"rendered":"urn:uuid:f6b39715-a45b-518b-f5cc-78f6f1d15e41"},"modified":"2026-03-26T00:00:00","modified_gmt":"2026-03-26T00:00:00","slug":"your-ai-gateway-was-a-backdoor-inside-the-litellm-supply-chain-compromise","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/your-ai-gateway-was-a-backdoor-inside-the-litellm-supply-chain-compromise\/","title":{"rendered":"Your AI Gateway Was a Backdoor: Inside the LiteLLM Supply Chain Compromise"},"content":{"rendered":"

<\/p>\n

<\/div>\n

The \u2018.pth\u2019 mechanism: A known risk, accepted<\/span><\/p>\n

Python’s .pth file processing is a documented feature, not a bug. Files ending in .pth placed in site-packages are processed automatically every time the Python interpreter starts. CPython core developers have discussed this risk, Issues #113659<\/a> and #78125<\/a>, but treated it as a “won’t fix” because restricting .pth execution would break legitimate use cases.<\/p>\n

Issue #113659 was addressed, and Python versions 3.8 through 3.13 now skip hidden .pth files, which reduces some risk. Although the broader proposal to deprecate or remove .pth code execution entirely (Issue #78125) remains unresolved, these partial mitigations demonstrate ongoing efforts within the CPython community to balance security concerns with backwards compatibility.<\/p>\n

This isn’t the first exploitation: Volexity<\/a> observed .pth abuse in CVE-2024-3400 exploitation.<\/p>\n

The npm track (checkmarx-util-1.0.4) followed an identical pattern but targeted DevSecOps engineers through a fake Checkmarx utility package. It was served directly from attacker-controlled infrastructure at checkmarx.zone rather than the public npm registry, with a postinstall hook triggering automatic execution. Internal timestamps were set to October 26, 1985, the “Back to the Future” date, a deliberate anti-forensic Easter egg from a Western-culture-aware operator.<\/p>\n

From one IP to a multi-ecosystem campaign<\/span><\/p>\n

The GitHub issue gave defenders a starting point. Our analysis began with a single seed IOC, IP address 83.142.209.11, and expanded through five systematic enrichment pivots over 50 minutes, consuming 34 VirusTotal API calls. What emerged was not a single-package compromise but a coordinated, multi-ecosystem supply chain campaign we track as TeamPCP.<\/p>\n

Three supply chain tracks, one actor<\/b><\/p>\n

All three tracks converged on the same encryption scheme (AES-256-CBC + RSA-4096-OAEP), the same credential targets, the same persistence mechanism, and the same C&C infrastructure, confirming a single unified toolchain. The actor embedded their own branding throughout: “TeamPCP” strings in payload code, “tpcp.tar.gz” as the exfiltration archive name, and cultural artifacts like the code comment “ICP y u no radio? ;w;”, an English-language internet-culture reference that would later factor into attribution analysis.<\/p>\n

The credentials harvested from Trivy CI\/CD runners became the keys to subsequent compromises, each expanding the campaign’s reach:<\/p>\n