# LiteLLM PyPI compromised and Julia resilience to supply-chain attack

**URL:** <https://discourse.julialang.org/t/litellm-pypi-compromised-and-julia-resilience-to-supply-chain-attack/136364>\
**Category:** Package Management\
**Tags:** security\
**Created:** [March 24, 2026, 3:28pm UTC](https://discourse.julialang.org/t/litellm-pypi-compromised-and-julia-resilience-to-supply-chain-attack/136364 "2026-03-24T15:28:26Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![fdekerme](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fdekerme/32/43574_2.png) [@fdekerme](https://discourse.julialang.org/u/fdekerme)\
**Post date:** [March 24, 2026, 3:28pm UTC](https://discourse.julialang.org/t/litellm-pypi-compromised-and-julia-resilience-to-supply-chain-attack/136364/1 "2026-03-24T15:28:26Z")

</div>

Hi everyone,  
It was recently discovered that the _litellm_ package (v1.82.8) was compromised with a malicious `.pth` file that could steal SSH keys, environment variables, and other credentials without requiring an explicit import. **Anybody who has installed this package has likely been compromised and needs to respond accordingly.**

> **[LiteLLM Python package compromised by supply-chain attack](https://news.ycombinator.com/item?id=47501729)**
>
> 356 points —
> 165 comments —
> theanonymousone —
> 12:36 PM - 24 Mar 2026

I was wondering if the Julia package registry doing anything to prevent similar issues? Someone [here](https://news.ycombinator.com/item?id=47503114) proposed that static analysis (to catch obfuscated code or leaked keys) could be used to automatically audits the code.

Best,  
fdekerm

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [March 24, 2026, 8:30pm UTC](https://discourse.julialang.org/t/litellm-pypi-compromised-and-julia-resilience-to-supply-chain-attack/136364/2 "2026-03-24T20:30:31Z")

</div>

Credential compromises are brutal, and these attacks compromised _yet more_ credentials. One somewhat-unique (but not the only) vector here was that PyPI allows the uploads of new `.whl`s to old releases. Julia’s artifacts, on the other hand, are intrinsically tied to each registered release and must be created _before_ registration.

But once credentials are compromised, sophisticated attackers have demonstrated the capability to evade many detection systems. That’s not to say there isn’t more that can be done here; defense-in-depth is vital. Check out RegistryCI.jl for some ideas around more checks here.

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [March 24, 2026, 11:30pm UTC](https://discourse.julialang.org/t/litellm-pypi-compromised-and-julia-resilience-to-supply-chain-attack/136364/3 "2026-03-24T23:30:31Z")

</div>

[The Trivy Supply Chain Compromise: What Happened and Playbooks to Respond](https://www.legitsecurity.com/blog/the-trivy-supply-chain-compromise-what-happened-and-playbooks-to-respond)

[Summary from LiteLLM issue #24518](https://github.com/BerriAI/litellm/issues/24518#issuecomment-4118666370)

This looks a lot bigger than a Python package and wasn’t a dependency per se in my reading of it, wonder how it works.

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [March 25, 2026, 2:59pm UTC](https://discourse.julialang.org/t/litellm-pypi-compromised-and-julia-resilience-to-supply-chain-attack/136364/4 "2026-03-25T14:59:29Z")

</div>

> [@Benny](#):
>
> This looks a lot bigger than a Python package and wasn’t a dependency per se in my reading of it, wonder how it works.

TL;DR: A trivy developer’s credentials were compromised. This was used to compromise the GitHub action plugin trivy-action used by _many_ GitHub repositories. The malicious action payload exfiltrated repository secrets, used to compromise yet more developers/packages through API keys and such. The credentials of LiteLLM’s developer(s) were compromised in this manner, which were then used to publish malicious versions of the package and steal _yet more_ credentials. The attack sophistication decreased (but breadth increased) as it went farther along; the LiteLLM payload was a smash-and-grab.

N.b., immediately upon notification I searched my (and my orgs’ and big Julia orgs’) repositories for `trivy-action` as best as GitHub search allows; fortunately I did not find any repositories impacted by the initial trivy compromise. I encourage folks here to do the same.

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [March 25, 2026, 8:05pm UTC](https://discourse.julialang.org/t/litellm-pypi-compromised-and-julia-resilience-to-supply-chain-attack/136364/5 "2026-03-25T20:05:19Z")

</div>

> [@mbauman](#):
>
> A trivy developer’s credentials were compromised.

And in a previous breach that was evidently incompletely handled. Scary stuff.

[Trivy GitHub Actions Supply Chain Compromise | Snyk](https://snyk.io/articles/trivy-github-actions-supply-chain-compromise/)

[pull\_request\_target Misconfiguration Leads to RCE | Orca Security](https://orca.security/resources/blog/pull-request-nightmare-github-actions-rce/)