社内でLLM（大規模言語モデル）を活用するために、LiteLLMやOllamaといったAIゲートウェイ・推論サーバーを自前で立てている方に向けた内容です。これらを外部公開していると、気づかないうちに暗号資産マイニングの踏み台にされるリスクがあります。
2026年10月、Lumen Black Lotus Labsが「PoeLLM」と名付けたLinuxマルウェアの活動を報告しました。LiteLLM（複数のLLM APIを統一インターフェースで扱えるプロキシ）やOllama（ローカルLLM実行環境）、Gotenberg（PDF変換API）、Gitea（軽量Gitホスティング）、Ivanti Sentryなど、インターネットに公開された管理系・AI系サービスを狙う攻撃です。見覚えのあるツール名が並んでいるなら、対岸の火事では済まされません。
何が起きるのか
攻撃者はまず、LiteLLMやOllamaなど複数のサービスを対象にインターネット上をスキャンし、脆弱なバージョンや設定不備のあるホストを探します。
見つけたエンドポイントに対してエクスプロイト（脆弱性を突く攻撃リクエスト）を送り、PoeLLMというLinux ELFバイナリ（Linux上で実行可能な形式のプログラム）を実行させます。
特徴的なのは、このマルウェアがC2（コマンド&コントロール、攻撃者が遠隔操作するためのサーバー）のIPアドレスを、GitHub上に置かれた一見無害な「詩（poem）」のテキストから導出する点です。検出回避のための難読化手法といえます。
C2経由でリモートシェルを確立したあとは、XMRigやIron minerといった暗号資産マイニングツールを起動し、Kryptexというマイニングプールに接続します。さらに一部の侵害済みサーバーは、次の攻撃対象をスキャンしたりエクスプロイトを配信したりする「作業ノード」として再利用されます。つまり被害者が気づかないうちに、加害側のインフラの一部にされてしまう構図です。
影響は単なるCPU負荷増大にとどまりません。報告では、LiteLLMのようなAIプロキシが保持するトークンやモデル設定、プロンプト履歴、接続情報への二次的なアクセスリスクにも触れられています。マイニングは「目に見える被害」の一部に過ぎず、裏で情報が抜かれている可能性を前提に調査する必要があります。
なぜ起きるのか
原因を分解すると、大きく2つの脆弱性が関わっています。
1つ目はCVE-2026-42271です。これはLiteLLM側の脆弱性で、GitHubのセキュリティアドバイザリGHSA-v4p8-mg3p-g94gとして公開されています。攻撃成立の条件として、攻撃者が有効なプロキシAPIキーを持っている必要がある点は押さえておきたいところです。つまりAPIキーの管理がずさんだったり、過去に漏えいしたキーが生きていたりすると、この脆弱性単体でも突破口になり得ます。
2つ目はCVE-2026-10520です。こちらはIvanti Sentryなど別製品に関わる脆弱性として挙げられています。LiteLLM以外のサービスにも同種の侵入経路が存在することを示しており、「LLM関連ツールだけ気をつければよい」という話ではありません。
そもそもなぜこうした管理系・AI系ツールが狙われやすいのでしょうか。理由の1つは、開発環境や検証環境としてクイックに立ち上げられ、そのまま本番相当のネットワークに置かれてしまうケースがあるためです。Ollamaのデフォルト設定で動かした推論サーバーを、ファイアウォールの設定を詰めないまま公開してしまう、といった状況は想像しやすいのではないでしょうか。LiteLLMも同様に、社内向けのAIゲートウェイのつもりが、実際には外部からポート3000や4000経由でアクセス可能になっていた、という設定ミスは珍しくありません。
自分のプロジェクトが該当するか確認する
まず、該当サービスを運用しているかどうかの棚卸しから始めます。
確認すべき対象は次の通りです。
- LiteLLMをプロキシ・ゲートウェイとして稼働させているか
- Ollamaを推論サーバーとして外部からアクセス可能な状態で動かしているか
- Gotenberg（PDF変換）、Gitea（Git管理）、Ivanti Sentryをインターネット側に公開しているか
- これらのサービスがVPCやオンプレのプライベートネットワークではなく、グローバルIPに紐づいたポートで待ち受けているか
LiteLLMのバージョン確認は、起動しているプロセスやDockerイメージのタグを見るのが早道です。
pip show litellm | grep Version
# もしくはDocker運用の場合
docker inspect <コンテナ名> | grep -i imageバージョンが1.83.7より前であれば、CVE-2026-42271の対象になり得ます。
あわせて、該当エンドポイントへのアクセスログを確認してください。/mcp-rest/test/connection や /mcp-rest/test/tools/list といったパスへのリクエストが外部IPから来ていないか、リバースプロキシやロードバランサのアクセスログで検索するのが確認の第一歩です。
grep -E "mcp-rest/test/(connection|tools/list)" /var/log/nginx/access.logポートの外部公開状況は、サーバー側で直接確認できます。
ss -tlnp | grep -E ":3000|:4000"0.0.0.0やグローバルIPでLISTENしている場合、外部到達性がある状態です。クラウド環境であればセキュリティグループやファイアウォールルールの設定もあわせて確認してください。
対策の手順
該当すると判断した場合、次の手順で対処します。
1. LiteLLMのアップデート。1.83.7以降へ更新します。すぐに更新できない場合の暫定措置として、/mcp-rest/test/connection と /mcp-rest/test/tools/list へのアクセスをWAFやリバースプロキシ側でブロックします。
2. ネットワーク境界の見直し。LiteLLMやOllamaなどのサービスはプライベートネットワークの内側に移し、必要であればVPN経由やIP許可リストでのみアクセスできるようにします。クラウド運用であれば、セキュリティグループの受信ルールを「送信元Any」から社内IPレンジや踏み台サーバー経由に限定する変更が該当します。
3. APIキーのローテーション。CVE-2026-42271の成立条件が「有効なプロキシAPIキーの保有」である以上、漏えいの疑いがあるキーはすべて無効化・再発行します。CI/CDのシークレット管理やGitHub Actionsのsecretsに残っていないかも棚卸し対象です。
4. 侵害済みホストの検知と再構築。見覚えのないELFバイナリ、XMRigやIron minerのプロセス、CPU使用率の急上昇がないかをEDR（エンドポイント検知・対応ツール）やtop・iotopで確認します。該当があれば、設定の修正だけでなくホストの再構築（イメージからの作り直し）を検討してください。中途半端なプロセスkillだけでは、永続化の仕組み（cron登録やsystemdサービスの追加など）が残る恐れがあります。
5. アウトバウンド通信の監視。C2として報告されたポート3778、5001、5002、9999や、Kryptexマイニングプール宛ての通信、GitHub上の特定ファイル（poem由来のC2情報）取得リクエストを、プロキシやDNSログで継続的にチェックする体制を作ります。
6. GitHub関連のMCP連携を使っている場合の注意。LiteLLMはMCP（Model Context Protocol、AIツールが外部リソースと連携するための規格）のテスト用エンドポイントを持っています。この経路が攻撃対象になっている点から、MCP経由の外部連携を設定する際は、テスト用・デバッグ用のエンドポイントを本番環境で開放したままにしないことが大切です。
まとめ
PoeLLMは、LiteLLMやOllamaといった身近なAI運用ツールの設定ミスや未パッチの脆弱性を突いて、暗号資産マイニングと二次攻撃の踏み台を作る手口です。
次の3点は今すぐ確認できます。
pip show litellmや Dockerイメージタグでバージョンを確認し、1.83.7未満なら更新するss -tlnpでLiteLLM・Ollamaのポートが外部公開されていないか確認する- アクセスログで
/mcp-rest/test/connectionなどへの不審なリクエストの有無を確認する
AI開発環境は検証用に手早く立てがちな分、ネットワーク境界の見直しが後回しになりやすい領域です。今回の手順を棚卸しのきっかけにしてもらえればと思います。