litellm - ✅(Solved) Fix [Security]: litellm PyPI package (v1.82.7 + v1.82.8) compromised — full timeline and status [4 pull requests, 116 comments, 37 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

The litellm PyPI package was compromised by an attacker who gained access to the maintainer's PyPI account. Malicious versions were published that steal credentials and exfiltrate them to an attacker-controlled server.

Original detailed analysis: https://github.com/BerriAI/litellm/issues/24512

Hacker News discussion: https://news.ycombinator.com/item?id=47501729

Root Cause

The litellm PyPI package was compromised by an attacker who gained access to the maintainer's PyPI account. Malicious versions were published that steal credentials and exfiltrate them to an attacker-controlled server.

Original detailed analysis: https://github.com/BerriAI/litellm/issues/24512

Hacker News discussion: https://news.ycombinator.com/item?id=47501729

Fix Action

Fixed

PR fix notes

PR #13555: PLTF-330: add timestamp to enterprise JSON logger formatter

Description (problem / solution / changelog)

Description

The enterprise JsonFormatter was missing the timestamp=True parameter, causing LOG_JSON=1 to produce logs without timestamps.

Problem

When running the enterprise server with LOG_JSON=1, log entries were missing the timestamp field. However, LOG_JSON_FOR_CONSOLE=1 correctly included timestamps because it manually adds a ts field in the custom_json_serializer.

This inconsistency occurred because the enterprise setup_json_logger() function created a JsonFormatter without the timestamp=True parameter, unlike the core OpenHands logger which includes it.

Solution

Add timestamp=True to the enterprise JsonFormatter configuration to ensure timestamps are included in JSON logs regardless of which logging mode is used.

Testing

  • Run the enterprise server with LOG_JSON=1 and verify logs now include a timestamp field
  • Run with LOG_JSON_FOR_CONSOLE=1 and verify it still works (will have only ts field)

To run this PR locally, use the following command:

GUI with Docker:

docker run -it --rm   -p 3000:3000   -v /var/run/docker.sock:/var/run/docker.sock   --add-host host.docker.internal:host-gateway   -e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.openhands.dev/openhands/runtime:55500d3-nikolaik   --name openhands-app-55500d3   docker.openhands.dev/openhands/openhands:55500d3

Changed files

  • enterprise/poetry.lock (modified, +16/-1)
  • enterprise/pyproject.toml (modified, +1/-0)
  • enterprise/server/logger.py (modified, +2/-0)
  • enterprise/tests/unit/test_logger.py (modified, +79/-3)

PR #2499: Remove unused litellm dependency from pinned requirements

Description (problem / solution / changelog)

@pankajastro reported that litellm has been quarantined.

I believe litellm is not a direct or transitive dependency of any package in the project (at least my pipdeptree on the local hatch env says so) — it probably was an artefact from the environment where requirements were frozen and copied over from while working on PR https://github.com/astronomer/astronomer-cosmos/pull/2343.

related: https://github.com/BerriAI/litellm/issues/24517 related: https://github.com/BerriAI/litellm/issues/24518 related: https://github.com/BerriAI/litellm/issues/24521

Changed files

  • requirements/requirements-airflow-2.11-dbt-1.11.txt (modified, +0/-1)
  • requirements/requirements-airflow-2.9-dbt-1.11.txt (modified, +0/-1)
  • requirements/requirements-airflow-3.0-dbt-1.11.txt (modified, +0/-1)
  • requirements/requirements-airflow-3.1-dbt-1.11.txt (modified, +0/-1)

PR #642: Pin litellm<=1.82.6 to mitigate security issues

Description (problem / solution / changelog)

Summary

  • Pin litellm<=1.82.6 (last known safe version) to mitigate security issues
  • litellm 1.82.7 and 1.82.8 contain a malicious .pth file that automatically executes a credential-stealing script when Python starts
  • Ref: https://github.com/BerriAI/litellm/issues/24518

Changes

  • pyproject.toml: Update litellm specifier from >=1.73.0,<2.0.0 to >=1.73.0,<=1.82.6
  • uv.lock: Update specifier to match

Test plan

  • Existing unit tests (760 passed)
  • Existing integration test passes
<!-- This is an auto-generated comment: release notes by coderabbit.ai -->

Summary by CodeRabbit

  • Chores
    • Updated dependency version constraints to enhance stability and compatibility.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Changed files

  • pyproject.toml (modified, +1/-1)
  • uv.lock (modified, +1/-1)
RAW_BUFFERClick to expand / collapse

[LITELLM TEAM UPDATES]

  • Compromised packages have been deleted (v1.82.7, v1.82.8)
  • Compromise came from trivvy security scan dependency
  • All maintainer accounts have been rotated (new maintainer accounts: @krrish-berri-2 , @ishaan-berri)
  • Proxy Docker image users were not impacted, all dependencies are pinned on requirements.txt
  • No litellm releases will be out until we have scanned our chain and make sure it's safe

Next Steps

  • Review all berriai repo's for impact
  • Scan circle ci builds to understand blast radius, and mitigate it
  • We've engaged Google's mandiant.security team, and are actively working on this with them

We are actively investigating this issue. Please reach out to us on [email protected], if you have any questions / concerns.


Summary

The litellm PyPI package was compromised by an attacker who gained access to the maintainer's PyPI account. Malicious versions were published that steal credentials and exfiltrate them to an attacker-controlled server.

Original detailed analysis: https://github.com/BerriAI/litellm/issues/24512

Hacker News discussion: https://news.ycombinator.com/item?id=47501729

What happened

  • The maintainer's PyPI account (krrishdholakia) appears to have been hijacked by an attacker (teampcp)
  • The attacker published malicious versions to PyPI that were never released through the official GitHub CI/CD
  • GitHub releases only go up to v1.82.6.dev1 — versions 1.82.7 and 1.82.8 on PyPI were uploaded directly by the attacker

Affected versions

VersionMethodTrigger
1.82.7Payload embedded in litellm/proxy/proxy_server.pyTriggered on import litellm.proxy
1.82.8Added litellm_init.pth (34,628 bytes) + payload in proxy_server.pyAny Python startup — no import needed

Other versions may also be affected and should be audited.

What the malicious code does

  1. Collects: SSH keys, environment variables (API keys, secrets), AWS/GCP/Azure/K8s credentials, crypto wallets, database passwords, SSL private keys, shell history, CI/CD configs
  2. Encrypts: AES-256-CBC + RSA-4096 (hardcoded public key)
  3. Exfiltrates: curl POST to https://models.litellm.cloud/

The exfiltration domain litellm.cloud (NOT the official litellm.ai) was registered on 2026-03-23 via Spaceship, Inc. — just hours before the malicious packages appeared.

Current status

  • PyPI: The entire litellm package has been suspended/removed. All versions currently return "No matching distribution found." We reported the malware to PyPI via the official "Report malware" form.
  • GitHub Issue #24512: Contains the original detailed technical analysis (currently closed by the attacker's spam — see below).
  • Attacker behavior: The attacker appears to be publishing hundreds of spam comments to suppress discussion. If this continues, we recommend moderating via the Hacker News thread linked above.

Recommendations for affected users

  1. Check if litellm_init.pth exists in your site-packages/ directory
  2. Rotate ALL credentials that were present as environment variables or config files on any system where litellm 1.82.7+ was installed
  3. Pin dependencies to exact versions and verify against GitHub releases
  4. Monitor for unauthorized access using any potentially leaked credentials

References

  • Original analysis: #24512
  • Hacker News: https://news.ycombinator.com/item?id=47501729
  • Attacker's exfil domain WHOIS: registered 2026-03-23, Spaceship Inc., privacy-protected
  • litellm_init.pth SHA256: ceNa7wMJnNHy1kRnNCcwJaFjWX3pORLfMh7xGL8TUjg

extent analysis

Fix Plan

To address the compromised PyPI package, follow these steps:

  • Remove malicious packages:
    • Uninstall litellm using pip: pip uninstall litellm
    • Check for and remove litellm_init.pth from your site-packages/ directory
  • Rotate credentials:
    • Update all environment variables and config files that may have been exposed
    • Use a secrets manager to securely store sensitive information
  • Pin dependencies:
    • Use pip-compile to generate a requirements.txt file with exact version pins
    • Verify dependencies against GitHub releases
  • Monitor for unauthorized access:
    • Implement logging and monitoring for suspicious activity
    • Use tools like git diff to detect changes to sensitive files

Example Code

To pin dependencies, use the following code:

import pip-tools

# Compile requirements.txt with exact version pins
pip_tools.compile("requirements.in", output_file="requirements.txt")

To verify dependencies, use the following code:

import pkg_resources

# Get the installed package version
installed_version = pkg_resources.get_distribution("litellm").version

# Check if the installed version matches the expected version
if installed_version != "1.82.6.dev1":
    print("Warning: Installed version does not match expected version")

Verification

To verify that the fix worked:

  • Check that litellm is no longer installed: pip list litellm
  • Verify that litellm_init.pth is removed: ls site-packages/
  • Test that dependencies are pinned correctly: pip-compile --upgrade requirements.in

Extra Tips

  • Regularly audit your dependencies for suspicious activity
  • Use a package manager like pip-tools to manage dependencies
  • Implement a secrets manager to securely store sensitive information
  • Monitor for unauthorized access using logging and monitoring tools

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING