Published on 13 August 2026
A single, unrevoked access token – and suddenly more than 2,500 organisations and over 434,000 automated build processes are potentially left wide open. That's exactly what happened in the LiteLLM incident, which began on 24 March 2026 and is still making waves today. Attackers slipped two tampered versions of a widely used Python library into the official software catalogue, PyPI. Anyone who installed these versions, or even just pulled them automatically, risked having API keys, cloud credentials, SSH keys and database passwords secretly read out and transmitted to an external address.
In this article we explain in plain terms what exactly happened, who may be affected – and what small and medium-sized enterprises (SMEs) with their own website, shop or AI chatbot should now concretely check and do.
The affected component is LiteLLM, a Python library and proxy server that acts as an intermediary between applications and various AI models (such as those from OpenAI, Anthropic or Google). It is very widely used in the developer and AI world.
This is not a classic programming flaw with a CVE number (the standardised identifier for a publicly known security vulnerability), but a so-called supply chain attack – an attack on the software's delivery path. Specifically, two maliciously altered releases of the package were published:
Both versions were uploaded to PyPI, the central repository for Python packages, on 24 March 2026. LiteLLM founders Krrish Dholakia (CEO) and Ishaan Jaffer (CTO) confirmed:
„The compromised PyPI packages were litellm==1.82.7 and litellm==1.82.8.“ (LiteLLM Security Update)
The malware in these packages was designed to harvest credentials: from environment variables, files, as well as cloud, SSH, database, Kubernetes, Git and container access details. This data was transmitted, encrypted, to the domain models.litellm[.]cloud – an address which, according to LiteLLM, does not belong to the official project.
How did the malicious code get into the official packages in the first place? According to LiteLLM and PyPI, a token or a dependency related to the tool Trivy (a security scanner) in the build and publishing environment was abused. The security researchers at CloudSEK describe the chain vividly:
„Trivy, then the LiteLLM build system, then the LiteLLM release: one unrevoked token, three tools deep. That chain is what turns a single credential leak into ecosystem-wide exposure.“ (CloudSEK)
In other words: a single token that was not revoked in time was enough to burrow through three tools all the way into the release – and to turn a single data leak into an ecosystem-wide threat.
Version 1.82.8 was particularly tricky. It contained a file named litellm_init.pth. Such .pth files are processed by Python as soon as the interpreter starts – so the malicious code could run without a developer ever actively including (importing) LiteLLM in their code. For version 1.82.7, LiteLLM confirmed a malicious payload in the file litellm/proxy/proxy_server.py.
The security database OSV (entry PYSEC-2026-2) documents further functions of the malware: among other things it searched .env files, LDAP configurations, shell histories and even crypto wallet keys, attempted to read out cloud metadata tokens and AWS Secrets Manager contents, and set up persistence – that is, mechanisms to remain permanently in the system. Mentioned are a systemd service disguised as a "System Telemetry Service" as well as the creation of a pod in Kubernetes environments. In addition, the code fetched further instructions from checkmarx[.]zone/raw.
Here precision matters – and no panic. During the attack window, PyPI counted over 119,000 downloads of the tampered versions. CloudSEK later reconstructed more than 2,500 potentially exposed organisations and 434,000 potentially exposed CI/CD pipelines (automated build and delivery processes for software).
But: these figures do not prove a successful compromise for every organisation named. CloudSEK itself emphasises this clearly:
„The 2,500+ company and 434,000 pipeline figures describe reconstructed exposure. They should not be read as proof that every listed organization was successfully compromised or that every credential was stolen.“ (CloudSEK)
So three levels must be distinguished: exposed (potentially reachable), likely compromised and confirmed compromised. A confirmed total number of leaked personal data records is not available in the sources reviewed.
For German SMEs, the incident is primarily relevant if their own website, a shop, a customer portal, an AI chatbot or an agency or development environment uses Python, LiteLLM or AI tools built on top of them.
Particularly at risk were:
An important note from PyPI: LiteLLM is usually installed around 15 to 20 million times per week, and an estimated 40 to 50 per cent of these installations were unpinned – meaning they automatically pulled the most recent version each time (and thus, during the attack window, the poisoned one).
Reassurance for two cases: Anyone who used the official LiteLLM Proxy Docker version was, according to the vendor, not affected, because this path pins the dependencies:
„Customers running the official LiteLLM Proxy Docker image were not impacted. That deployment path pins dependencies in requirements.txt and does not rely on the compromised PyPI packages.“ (LiteLLM)
Likewise, a static CMS without Python/LiteLLM is not directly affected by this package. Nevertheless: ask your external web host, your digital agency or your AI service provider for a documented check.
python -m pip show litellm and additionally search requirements*.txt, lockfiles, containerfiles, image manifests as well as build and deployment logs for litellm==1.82.7 or litellm==1.82.8. Important: pip show only shows the currently active environment – search across all environments.pip install litellm, an upgrade, an image build or a transitive (indirectly pulled) LiteLLM dependency run on 24 March 2026? Since the time details from LiteLLM and PyPI differ from each other (LiteLLM: from 10:39 UTC, about 40 minutes; PyPI: 2 hours 32 minutes until quarantine), your log search should cover all of 24 March 2026.site-packages area for litellm_init.pth. LiteLLM gives as an example: find /usr/lib/python3.13/site-packages/ -name "litellm_init.pth". Adjust the path to your Python version. A find is a clear warning sign.models.litellm[.]cloud and checkmarx[.]zone. Additionally watch for unexpected systemd services under the cover name "System Telemetry Service" as well as unknown Kubernetes pods or service accounts.If you found one of versions 1.82.7/1.82.8 or if it was executed, then: a simple update is not enough. Secrets and persistence mechanisms may already have been copied.
litellm_init.pth, if present, and rebuild affected environments from a demonstrably clean base. A mere pip uninstall is no substitute for a proper response to stolen credentials.pip-compile --generate-hashes, uv lock or Pipenv). A mere pip freeze is no secure substitute, because the artefact hashes are missing.uv supports this, for example with exclude-newer.The following assessment is a general explanation and not legal advice.
Important to understand: GDPR relevance does not depend on whether LiteLLM was installed, but on whether the incident caused personal data to be accessed, disclosed, altered or lost without authorisation. The decisive question is: did the secrets reachable by LiteLLM have access to CRM, shop, newsletter, support, database or hosting data with personal references?
If so, the controller must document the incident and carry out a risk assessment without delay. The European Data Protection Board (EDPB) summarises the obligations as follows:
„If your SME acts as a data controller, there are three primary principles regarding data breaches: documentation; notification … within 72 hours, unless it is unlikely to result in a risk to individuals; and communication … where the breach is likely to result in a high risk to individuals.“ (EDPB)
Specifically: a notification under Art. 33 GDPR to the competent supervisory authority is required within 72 hours of becoming aware – unless a risk to data subjects is likely to be improbable. Where a high risk is likely, the data subjects must additionally be informed without delay. A processor – such as an agency or a hosting/SaaS provider – must inform the controller without delay; the reporting channels belong in the contract under Art. 28 GDPR.
Fine risks are always case-dependent. Art. 83 GDPR weighs, among other things, the severity, duration, culpability, mitigation measures and cooperation with the authority; the statutory upper limit is up to 20 million euros or 4 per cent of worldwide annual turnover – whichever is higher. This is not an automatic sanction and no forecast for this incident.
An instructive comparison is the Codecov incident of 2021: at the time, Codecov documented 108 time windows with a tampered build script through which credentials from CI environments could potentially have leaked. The lesson is the same as today: with compromised build artefacts, it is not only the package version that must be checked, but the entire scope of the permissions that were available to the affected process.
The LiteLLM incident forcefully shows that modern attacks no longer target only the publicly visible website, but the invisible supply chain of the software behind it. The actual risk arises from the depth of permissions of the affected Python process – not from the size of your website. CI/CD runners, build servers, Docker builders, developer machines and AI gateways are particularly critical, because that is where many keys converge.
For you as an SME, this means: if you or your service providers use Python and AI tools, systematically check for versions 1.82.7/1.82.8, for the file litellm_init.pth and for suspicious network traffic. If you find indications, act immediately: isolate, rotate secrets, rebuild cleanly and document the data protection trail.
And the correct wording, should your company merely appear in a list: "potentially exposed – validation required", not "successfully hacked". Panic is out of place – but swift, orderly action is exactly right. Because captured credentials can still be misused months later. Anyone who rotates and cleans up now closes the door before someone walks through it.