The LiteLLM supply chain attack is a useful reminder that fixing vulnerable software and establishing whether an organisation has been compromised are two very different things.
In March 2026, malicious versions of the legitimate LiteLLM Python package were published to PyPI following a supply chain compromise. Versions 1.82.7 and 1.82.8 contained malicious code designed to collect and exfiltrate sensitive information from affected environments. This included cloud credentials, SSH keys, API keys, Kubernetes credentials, database information and CI/CD secrets.
The compromised versions have since been removed and LiteLLM has confirmed that subsequent releases are free from the affected component. But for organisations that may have installed one of those versions, that does not necessarily close the incident.
The important question is no longer simply:
“Are we running an affected version?”
It is:
“Was an affected version ever present, did the malicious code execute and, if it did, what happened next?”
What happened in the LiteLLM supply chain attack?
LiteLLM is a widely used Python package that provides a common interface for working with multiple large language model providers.
On 24 March 2026, versions 1.82.7 and 1.82.8 were maliciously published to PyPI as part of a wider supply chain campaign.
The two versions behaved differently.
Version 1.82.7 contained malicious code within LiteLLM’s proxy component and was triggered when the affected proxy module was imported.
Version 1.82.8 went further. It included a malicious Python .pth file. Executable code contained within this type of file can run when the Python interpreter starts, meaning the attacker did not necessarily need the user to actively invoke LiteLLM itself.
Once executed, researchers found that the malware was capable of collecting a broad range of sensitive information, including environment variables, cloud credentials, Kubernetes data, SSH keys, Docker configuration, shell history and CI/CD secrets. It could also establish persistence and communicate with attacker controlled infrastructure.
That changes the response required.
LiteLLM supply chain attack: Three questions organisations need to answer
If one of the affected LiteLLM versions may have entered an environment, investigation should focus on three areas.
1. Was the affected software ever present?
Checking the version currently installed is useful, but it is only a snapshot of the environment today. An affected version may already have been upgraded, removed or replaced. Organisations therefore need to establish whether LiteLLM 1.82.7 or 1.82.8 was ever present across potentially relevant systems.
That could include:
- User devices
- Developer workstations
- Servers
- Containers
- Cloud workloads
- CI/CD infrastructure
- Build environments
- Kubernetes environments
Security teams should therefore consider both current asset information and historical telemetry. The objective is to establish exposure, not simply current vulnerability.
2. Did the malicious code execute?
Finding an affected package establishes that there may have been an opportunity for compromise. It does not, on its own, establish what actually happened. The next stage is targeted threat hunting. For LiteLLM, this means looking for the known behaviours associated with the malicious packages and any subsequent attacker activity. This can include searching endpoint and security telemetry for the malicious Python .pth mechanism, associated files, suspicious Python processes, persistence mechanisms, unusual network connections and activity associated with credential collection.
Version 1.82.8 makes this particularly important because its malicious .pth file was designed to execute when Python started. This is where historical security telemetry becomes extremely valuable. The security question changes from:
“Is the malicious file there?” to “Can we find evidence that this behaviour occurred?”
3. Were stolen credentials subsequently used?
This is arguably the most important part of the investigation. The LiteLLM malware was designed to collect credentials and secrets from the environment in which it executed. Security researchers consequently recommend treating systems that installed the affected versions as potential credential exposure events.
Removing LiteLLM or upgrading the package does not invalidate credentials that may already have been stolen. Investigation therefore needs to move beyond the original device. Depending on the environment, security teams may need to review authentication and activity across:
- Microsoft Azure
- Amazon Web Services
- Google Cloud Platform
- Kubernetes
- GitHub and CI/CD platforms
- Privileged accounts
- Application and API access
- Identity systems
- Secret stores
- Other connected infrastructure
The objective is to understand what credentials were accessible to the affected system and whether there is any evidence that they were subsequently used by an unauthorised party.
This is the difference between vulnerability remediation and incident investigation.
Why simply installing the fix is not enough
Traditional vulnerability management tends to follow a straightforward process. Identify the vulnerable software. Update it. Confirm the vulnerability has been removed.
For many vulnerabilities, that is entirely appropriate. A supply chain compromise can be different.
If malicious software has already executed, the attacker may have moved beyond the original package. Credentials could have been captured. Persistence may have been established. Cloud services may have been accessed. CI/CD credentials could potentially provide access to other systems or development pipelines.
Datadog Security Labs specifically recommends that organisations affected by the LiteLLM compromise investigate persistence, outbound communications, Kubernetes activity and credential exposure, rather than limiting the response to package presence.
This requires a broader view of the environment.
From endpoint alert to wider investigation
An endpoint security platform may provide the first indication that something has happened. But the investigation may need to extend considerably beyond that endpoint. Consider a developer workstation containing an affected package.
The endpoint tells you where the investigation started but the same device could also contain credentials that allow access to cloud platforms, repositories, development environments, applications or infrastructure.
A meaningful investigation therefore needs visibility across multiple security domains. Endpoint activity needs to be considered alongside identity activity. Identity needs to be considered alongside cloud activity. Cloud activity may need to be correlated with application, network and security logs.
This is where a modern Security Operations Centre becomes particularly important.
How an Amicis SOC would approach an incident such as LiteLLM
When credible intelligence about a compromise such as LiteLLM becomes available, the objective is not simply to wait for an endpoint alert.
The first task is to understand potential exposure.
An Amicis SOC investigation would establish whether the affected software had been present within the environment and identify potentially impacted systems. From there, our analysts can carry out targeted threat hunting across CrowdStrike and the telemetry available within Falcon NG-SIEM.
This allows us to investigate known indicators alongside the behaviours associated with the attack. Where potentially malicious activity is identified, the investigation can then expand across endpoint, identity, cloud and other available security telemetry to establish the wider scope of the incident.
Our Cyber Security Operations Platform combines automation with analyst led investigation, helping the SOC analyse suspicious activity, accelerate triage and focus attention where deeper investigation is required. Where compromise is confirmed, affected systems can be contained while exposed credentials are revoked or rotated and the wider impact is assessed.
The objective is to move from intelligence to evidence.
Threat intelligence only becomes valuable when you can act on it
The alert tells you what happened.
The SOC tells you whether it happened to you.
Security teams receive a continuous stream of vulnerability notices, threat intelligence and security advisories.
Knowing that an attack exists is valuable.
Knowing whether it affected your organisation is considerably more valuable.
Incidents such as the LiteLLM supply chain attack demonstrate why organisations need the capability to investigate retrospectively across their environments.
When new intelligence arrives, security teams should be able to establish exposure, search historical telemetry, investigate suspicious behaviour, correlate activity across different security systems and contain compromise where necessary.
That is ultimately the difference between receiving a security notification and having the capability to respond to it.
✓ Establish whether affected software was ever present
✓ Hunt retrospectively across endpoint, identity and cloud activity
✓ Contain compromise and support credential rotation where required.
