KICS and LiteLLM compromised: two supply chain attacks that confirm a change of scale

Published on March 24, 2026

14 min read

#supply-chain#github-actions#pypi#securite#open-source

Barely time to analyze the Trivy compromise and a new wave of attacks is already hitting other widely used building blocks. This time, two distinct incidents draw attention: the compromise of the GitHub Action tied to KICS/Checkmarx and the publication on PyPI of malicious LiteLLM versions. These two cases are not mere isolated accidents. On the contrary, they show a campaign that changes terrain, reuses the same mechanisms and always targets the same resource: your secrets, your tokens, your runners, your cloud environments and your Kubernetes clusters.

The most worrying part is not only that popular projects were hit. The most worrying part is the very concrete demonstration that today, an attacker no longer needs to compromise your application code to reach you. He only needs to poison a trust link you consume automatically: a GitHub Action, a PyPI package, an image or a tool downloaded from a repository deemed legitimate.

What is this new wave after Trivy?

On 23 March 2026, Wiz and Sysdig documented a new compromise hitting the Checkmarx/KICS ecosystem. According to their analyses, a GitHub Action tied to Checkmarx was poisoned with a credential stealer identical to the one already observed in the Trivy campaign. Sysdig explains that the activity observed in Checkmarx/ast-github-action reuses the same execution chain, the same exfiltration mode and the same objectives as the previous attack. Wiz adds that 35 release tags of the KICS action were hijacked between 12:58 and 16:50 UTC on 23 March 2026.

On 24 March 2026, another alert dropped: versions 1.82.7 and 1.82.8 of the LiteLLM package published on PyPI were trojanized. FutureSearch indicates that version 1.82.8 was published at 10:52 UTC and contained a malicious .pth file named litellm_init.pth, executed automatically at every start of a Python interpreter once the package is installed. The same post later specifies that version 1.82.7 was also compromised.

These two attacks use different vectors, but tell the same story: the attacker no longer merely tries to hit a project. He tries to insert himself into the automatic trust flows of developers and pipelines.

What happened on the KICS side?

In the KICS/Checkmarx case, the attack vector goes through GitHub Actions. Workflows that consumed the action through a mutable tag could pull code now controlled by the attacker. Sysdig details an execution chain very close to the one seen with Trivy: Runner.Worker → bash → setup.sh → curl POST, with exfiltration of an archive named tpcp.tar.gz to a typosquatted domain, here checkmarx[.]zone.

The malware did not stop at a simple theft of environment variables. Sysdig mentions several characteristic behaviours: reading the memory of the runner's processes, requests to the Instance Metadata Service to grab possible temporary cloud credentials, searching for Slack and Discord webhooks in the workspace, then encrypted exfiltration to the attacker's infrastructure. Wiz and Sysdig consider this wave consistent with the activity already attributed to TeamPCP.

In other words, if your workflow used a tag such as @v2, @v2.3.28 or similar, you had a structural weak point: you were trusting a rewritable reference. The code actually executed could change after the fact without any visible modification of your pipeline. Sysdig explicitly recalls that pinning on a commit SHA would have withstood this technique, unlike tags.

What happened on the LiteLLM side?

The LiteLLM case is even more brutal, because it hits PyPI and a Python package very widely used in the AI ecosystem. FutureSearch explains that version 1.82.8 contained a malicious .pth file triggered automatically at Python startup. That is a key point: here, installation alone could be enough to activate the malicious code, without even needing an import litellm. Simon Willison notes moreover that for 1.82.7, the malicious code sat in proxy/proxy_server.py, which this time required an import or an execution of that component to produce the effect.

FutureSearch then describes a malware operating in three stages. First the collection: SSH keys, .env files, AWS, GCP and Azure credentials, Kubernetes configurations, database passwords, shell history, .gitconfig, crypto wallets and any file looking like a secret. Then the exfiltration, encrypted with AES-256-CBC and a 4096-bit RSA public key, to the domain models.litellm.cloud, presented as not legitimate. Finally persistence and lateral movement: if a Kubernetes service account token is available, the malware tries to read the cluster's secrets then to create privileged pods in kube-system in order to install a persistent backdoor on the nodes.

We are therefore no longer at all in the classic scenario of the opportunistic malicious package that just tries to steal a PyPI token or an environment variable. Here, we see malware designed to escalate, survive and pivot through modern environments: developer machines, pipelines, cloud, containers and Kubernetes.

Why are these two incidents probably linked?

The link between KICS and LiteLLM does not rest on intuition alone. Several sources indicate that LiteLLM reuses the same malicious logic as the previous campaign. Wiz directly mentions that the trojanized litellm packages contain "the same functionality as the previous operation", with a new exfiltration domain. GitGuardian also states that, on 24 March, the campaign moved to PyPI and that versions 1.82.7 and 1.82.8 of LiteLLM contained the same infostealer as the one already seen earlier in the campaign.

The pattern is consistent:

same goal: steal secrets, tokens and reusable access;
same exfiltration logic: encrypted archive sent to a domain controlled by the attacker;
same adaptation to context: GitHub Actions for KICS, PyPI for LiteLLM;
same strategy of diverted trust: poison a tool already accepted in build and development chains.

The real lesson is that the attacker does not only exploit a technical flaw. He mostly exploits a posture flaw: the implicit trust granted to anything coming from a popular project, a maintainer account or a well-known ecosystem.

Why are these attacks particularly dangerous?

These two incidents are dangerous for a simple reason: they strike in the right place. Not at the periphery. Not in an obscure dependency. But at the heart of the mechanisms many teams have industrialized:

automatic installation of packages from PyPI;
use of third-party GitHub Actions by simple tag reference;
CI/CD runners able to access build secrets;
cloud environments where the IMDS is reachable;
Kubernetes clusters where service accounts still hold excessive privileges.

When a GitHub Action or a Python package is compromised, it is not just your repository that is exposed. Potentially also:

your GitHub secrets and your PATs;
your temporary or persistent cloud credentials;
your access to image registries;
your PyPI or npm tokens;
your webhooks;
your Kubernetes clusters;
and, in the LiteLLM case, your developer machines and local AI environments.

GitGuardian also recalls that secret exposure keeps growing sharply, with 29 million secrets detected on public GitHub in 2025 according to its 2026 report. This context makes this kind of campaign even more profitable for attackers: the more secrets lie around in build and dev environments, the more the compromise of a single link pays off.

Which defensive mistakes do these incidents expose?

The first mistake is believing that a popular repository or a well-known maintainer is a sufficient guarantee. In both cases, it is precisely that prior reputation that made the attack effective.

The second mistake is confusing a version reference with integrity. A GitHub tag is not proof of immutability. If it can be moved, it can become a weapon. Sysdig insists clearly on this point: pinning by full SHA protects against this class of attack where a mere tag does not.

The third mistake is assuming that an installed package is only dangerous at the moment you explicitly run it. The LiteLLM incident shows exactly the opposite: a .pth file can get code executed as soon as Python starts.

The fourth mistake is thinking the problem is limited to the compromised repository. In reality, the objective is often to pivot: steal a token on a runner, use it to compromise other repositories, poison other actions, move to other ecosystems. That is precisely the scenario put forward by Sysdig to explain the propagation between Trivy and Checkmarx, then echoed by the observations on LiteLLM.

What should you do right away if you are affected?

If you use KICS via GitHub Actions, start by identifying every workflow that references the affected Checkmarx/KICS actions, in particular through tags. Sysdig recommends auditing the runs between 19 and 23 March 2026, searching for indicators such as tpcp.tar.gz, checkmarx.zone or possible tpcp-docs repositories, then rotating every secret reachable by those runners.

If you use LiteLLM, check the installed version immediately. FutureSearch recommends checking pip show litellm, purging the pip or uv caches, searching for litellm_init.pth, then checking any persistence trace such as ~/.config/sysmon/sysmon.py or ~/.config/systemd/user/sysmon.service. In a Kubernetes environment, you must also audit kube-system to spot possible node-setup-* pods. Every credential present on the machine or the cluster must be considered compromised.

What must change for good?

These incidents are not solved with a secret rotation and a post-mortem alone. They impose a change of posture.

1. Reduce implicit trust

Stop treating GitHub, PyPI or a maintainer account as automatically safe zones. They are distribution channels, not guarantees. A popular project can be compromised like any other.

2. Pin GitHub Actions on immutable SHAs

For GitHub Actions, the minimum today is pinning on a full SHA, not on a tag. It is a baseline requirement, not an advanced option.

3. Isolate the runners and limit the secrets

CI/CD runners must be treated as high-risk environments: restricted outbound network, IMDS access restricted or disabled, minimal secrets, ephemeral accounts, frequent rotation and fine-grained logging. Sysdig notably recalls that IMDS access from the runners was used in this campaign to grab cloud credentials.

4. Control dependencies before execution

The real subject is no longer only what you use, but how you introduce it into your chains. Packages, actions, images and third-party tools need prior validation before any execution in a trusted context. Recent incidents show that waiting for execution to react is already too late.

5. Detect behaviour, not only reputation

Sysdig underlines a very important point: the exfiltration domains used were new and could appear "clean" in reputation feeds. Detection must therefore focus on behaviours: IMDS reads from a runner, a binary curl POST to an unexpected domain, abnormal access to Kubernetes secrets, creation of privileged pods, and so on.

What do these attacks say about open source in 2026?

Two excesses must be avoided.

The first would be concluding that open source is the problem. That is not serious. Open source remains at the heart of modern infrastructure, and the transparency of the code also makes it possible to analyze and understand some attacks faster.

The second excess would be carrying on as before on the grounds that "it only happens to others". That is no longer credible either. Recent campaigns show that attackers are very good at identifying high-value trust nodes: popular GitHub Actions, massively used Python packages, security tools, build components, transitive dependencies and AI tooling.

The real question is therefore not "should we still use open source?". The real question is: how much automatic trust do you still accept in your software chain?

Conclusion

The compromises of KICS and LiteLLM confirm a heavy trend: supply chain attacks no longer target only obscure libraries or typosquatted packages. They now strike central tools, used in pipelines, in development environments, in the cloud and in AI stacks.

In the KICS case, the attack exploits the trust placed in a GitHub Action versioned by tag. In the LiteLLM case, it abuses the trust granted to PyPI and to a widely adopted Python package. In both cases, the outcome is the same: secret theft, potential compromise of the environments and the ability to pivot to other systems.

The signal is clear: it is no longer enough to scan your code, sign a few artifacts or add one more tool to the pipeline. You must revisit the overall consumption posture for dependencies, actions, packages and images. The era when you could implicitly trust anything popular, well-starred or simply hosted on GitHub is over.

Watch how you use every open source tool present on GitHub.