英語版で読む
技術 約5分で読めます

OllamaのCVE-2026-7482は公開API化したローカルLLMのメモリを読む

Ollama セキュリティ 脆弱性 CVE ローカルLLM LLM
いけさん目次

TL;DR

影響 Ollama 0.17.1未満。/api/create と /api/push に到達できるネットワーク公開構成では、認証なしのメモリ漏えい

対応 Ollama 0.17.1以降への更新。Dockerタグ固定、古いVMイメージ、放置された開発用サーバーの洗い出し

確認 11434/tcp の公開範囲、OLLAMA_HOST=0.0.0.0、リバースプロキシ越しの認証、Ollamaプロセスに載せていた環境変数とAPIキー

OllamaのCVE-2026-7482は、ローカルLLMの「ローカル」という言葉がどこまで信用できるかを突いてきた。
Cyera Researchの開示では、細工したGGUFファイルをOllamaに食わせ、モデル作成とpush機能を使って、Ollamaプロセスのヒープメモリを外へ持ち出せる。
CVSSは9.1。修正は0.17.1に入っている。

GGUFのサイズ宣言を信用しすぎた

問題はGGUFモデルの読み込みと量子化の経路にある。
攻撃者は、実データより大きなtensor offsetやsizeを持つGGUFファイルを用意する。
Ollamaが /api/create でそのファイルを処理すると、量子化の途中で本来のバッファ外まで読みに行く。

修正コミットを見ると、fs/ggml/gguf.go 側でファイルサイズを取得し、各tensorの終端が実ファイルサイズを超えないか検証する処理が追加されている。
server/quantization.go 側にも、読み込んだtensorデータの長さがshapeから期待されるサイズより短い場合にエラーを返すチェックが入った。
つまり、修正の芯は「GGUF内の宣言値をそのまま信じない」ことだ。

攻撃の流れは短い。

flowchart TD
  A["攻撃者が細工済みGGUFを用意"] --> B["/api/blobs でOllamaへ投入"]
  B --> C["/api/create でモデル作成"]
  C --> D["量子化処理が<br/>ヒープ外まで読み取り"]
  D --> E["漏れたメモリが<br/>モデル成果物に混入"]
  E --> F["/api/push で<br/>攻撃者側レジストリへ送信"]

漏れる対象は、クラッシュダンプのように後から拾うものではない。
処理の出力物に混ざったメモリを、Ollama自身のpush機能で外へ運ぶ形になる。
Cyeraは、system prompt、ユーザーの会話、環境変数、APIキー、処理中のコードや文書が入り得ると説明している。

localhost前提が崩れた場所で刺さる

Ollamaを手元のMacで ollama run しているだけなら、攻撃者がAPIに到達できない限りこの脆弱性は刺さらない。
問題は、Ollamaを「ちょっと外から叩けるローカル推論API」にした構成だ。

runZeroは、デフォルトのOllamaは127.0.0.1にbindする一方で、OLLAMA_HOST=0.0.0.0 が実運用で広く使われると整理している。
Cyera側はインターネットに露出したOllamaサーバーを約30万台と見積もっている。
数字の精度より、Ollamaが「個人PC内の推論ランタイム」から「共有AIバックエンド」に化けている点のほうが重い。

このブログでも、ローカルLLMをVPN経由で外部API化する構成を書いた。
あの記事ではLM StudioをTailscale経由でVPSから叩く形にしていて、公開インターネットへモデルサーバーを直接出していない。
今回のOllama脆弱性は、その差がそのまま防御線になる。
外から到達できる 11434/tcp を作ると、モデルサーバーのAPIがWebアプリの管理画面と同じ攻撃面になる。

FastAPI・Chroma・Open WebUI・Ollamaでマルチモーダル日本語RAGをM1 Maxで組んだようなローカルRAG構成でも、Open WebUIやFastAPIの背後にOllamaを置くと、境界は「UIのログイン」だけでは足りない。
UIに認証があっても、Ollama本体のAPIが同じLANやDockerネットワークから丸見えなら、別の経路で触られる。

会話だけでなくプロセスの中身を見る

漏えい調査の対象は、チャット履歴だけではない。
Ollamaプロセスに同居していたものを洗う。

場所見る理由
環境変数OpenAI、Anthropic、GitHub、社内APIのキーを同じプロセス環境に置いていた場合に漏れる
system prompt社内RAGやエージェントの役割設定、禁止ルール、内部URLが含まれることがある
会話断片ほかの利用者の入力、貼り付けたコード、ドキュメント要約がヒープに残る
モデル作成ログ悪意あるGGUF投入やpushの痕跡を追う入口になる

OllamaをClaude CodeやMCPブリッジの背後に置いていた場合は、tool callの入出力も範囲に入る。
OllamaとローカルLLMでMCPサーバーを使うならブリッジが要るで書いた通り、OllamaはMCP hostではなく推論エンジンだが、ブリッジ側はファイル、DB、SaaSトークンを触る。
その結果がプロンプトやtool結果としてOllamaに渡っていれば、Ollamaプロセスのメモリ上にも残り得る。

これは「AIが秘密を出力した」話ではない。
モデルが拒否するかどうか、プロンプトが安全かどうかの手前で、サーバープロセスのメモリ境界が破られている。

0.17.1以降でも公開範囲は直す

0.17.1以降へ更新すれば、今回のGGUF境界外読み取りは塞がる。
ただ、Ollama APIを認証なしで公開してよい理由にはならない。

/api/create はモデルを作る。
/api/push は成果物を外へ送る。
この2つが認証なしで外部から届く構成は、今回のCVEがなくてもかなり強い権限を渡している。

やることは単純だ。
Ollama本体は 127.0.0.1 または閉じたネットワークに戻す。
外から使うならTailscale、WireGuard、mTLS、認証付きリバースプロキシのどれかを挟む。
Docker Composeやsystemdに OLLAMA_HOST=0.0.0.0 が残っていないか見る。
古いDockerイメージをタグ固定で引いているなら、タグごと更新する。

公開されていた期間があるなら、Ollamaプロセスに載せていたAPIキーはローテーション対象にする。
ログに /api/blobs、/api/create、/api/push の不自然な連続がないか確認する。
モデルレジストリへの外向き通信も見たい。
runZeroのような資産探索ツールを使っている環境なら、Ollama製品名や 11434/tcp で棚卸しするのが早い。

参考