まずはキーポイント
- OllamaにCritical級の脆弱性が見つかり、プロセスメモリが外部に漏れる可能性がある
- 影響を受けるのは 0.17.1より前のバージョン
- 脆弱性の名前は CVE-2026-7482、CVSSは 9.1
- 悪意ある GGUFファイル を使うと、Ollamaのメモリから API keys、environment variables、system prompts、会話内容 などが漏れる恐れがある
- 公開されたOllamaサーバーでは、300,000台以上に影響する可能性があるとされている
- 対策は 最新版への更新、ネットワーク公開の制限、認証の追加、Firewallの内側で隔離 など
- さらに別件として、Windows版Ollamaの未修正脆弱性も報告されており、persistent code execution に繋がる可能性がある
何が起きたのか
The Hacker News が伝えたのは、Ollama に見つかったかなり厄介な脆弱性です。
ざっくり言うと、攻撃者が細工したファイルを送るだけで、Ollama が自分のメモリの中身を漏らしてしまう可能性がある、という話です。
これは地味に見えて、実はかなり怖いです。
なぜなら「メモリの中身」には、いま動いているサービスの秘密情報の詰め合わせが入っていることがあるからです。たとえば:
- API keys
- environment variables
- system prompts
- ユーザーの会話内容
- 連携ツールの出力
こういうものが見えてしまうと、単なるクラッシュよりずっと深刻です。
個人的には、LLM系サービスの事故は“モデルが賢いかどうか”より“周辺の安全設計が甘いかどうか”で決まることが多いと思っていますが、今回もまさにそのタイプです。
脆弱性の中身をやさしく言うと
今回の問題は、out-of-bounds read と呼ばれるタイプです。
日本語にすると「決められた範囲の外を読んでしまう」バグです。
たとえば、本棚の1番から10番までしか見てはいけないのに、11番目や12番目まで勝手に読みに行ってしまう感じです。
読み取ってはいけない場所まで見に行くので、そこにたまたま残っていたデータが漏れてしまうことがあります。
Ollama の説明では、問題は GGUF model loader にあります。
CVE.org の記述によると、/api/create が攻撃者の用意した GGUF ファイルを受け取り、その中の tensor offset と size が実ファイル長を超えていると、量子化の処理中に heap の外まで読み出してしまうとのことです。
GGUFってなに？
GGUF は GPT-Generated Unified Format の略で、LLM をローカルで動かすためのモデルファイル形式です。
PyTorch の .pt/.pth、safetensors、ONNX みたいな、モデルを保存して読み込むためのファイルだと思えば大きく外れていません。
つまり今回の攻撃は、**「モデルファイルを装った細工データ」**を食わせることで起きます。
モデルを扱うソフトは、普通のWebアプリよりも「ファイルの読み込み」が重要になるので、こういう攻撃面が増えがちです。ここはLLM時代ならではの厄介さだな、と思います。
攻撃の流れがわりと現実的
記事では、攻撃の流れが3段階で説明されています。
-
細工した GGUF ファイルをアップロード
- ネットワークに公開された Ollama サーバーへ HTTP POST で送る
-
/api/createを実行- モデル作成処理を動かし、out-of-bounds read を発火させる
-
/api/pushで情報を外部へ送る- 漏れたメモリ内容を、攻撃者が管理する registry に流し出す
この最後のステップがいやらしいところです。
単に漏れるだけでなく、漏れた情報を持ち出す導線まで組み立てられているんですね。
何が漏れるのか
Cyera の研究者 Dor Attias 氏によると、攻撃者は AI inference から組織についてかなり色々学べる可能性があるとのことです。
具体的には:
- API keys
- proprietary code
- customer contracts
- そのほか組織の内部情報
さらに、Ollama を Claude Code のようなツールとつないで使っている場合、影響はもっと大きくなるかもしれないと指摘されています。
というのも、ツールの出力が Ollama サーバーに流れ込み、そのまま heap に残る可能性があるからです。
これはかなり生々しい話です。
LLM を「便利なチャットボット」として見ていると見落としがちですが、実際には秘密情報の通り道にもなり得ます。
個人的には、AIを業務に組み込んだ時点で「何がどこに保存されるか」を一度棚卸ししないと危ない、という典型例だと思います。
対策は何をすればいい？
記事では、次の対策が勧められています。
- 最新の修正を適用する
- ネットワークからのアクセスを制限する
- 公開中のインスタンスを監査する
- Firewall の内側に隔離する
-
認証プロキシや API gateway を前段に置く
- Ollama の REST API は、標準では認証がないため
ここ、地味ですが重要です。
「最新版にしたから終わり」ではなく、そもそもインターネットに素のまま置かないほうがいい、という話です。
セキュリティ事故って、脆弱性そのものより「公開しっぱなし」「認証なし」「更新されない」の三点セットで大きくなることが多いんですよね。
もうひとつの話題: Windows版Ollamaの別の脆弱性
記事の後半では、別の研究グループ Striga が報告した、Windows版Ollamaの脆弱性も紹介されています。
こちらはメモリ漏えいではなく、persistent code execution、つまり「悪意あるコードを継続的に実行させられる」問題です。
報告されたのは次の2件です。
-
CVE-2026-42248
- update binary の signature verification がない
- つまり、正しい署名か確認せずに更新を入れてしまう
-
CVE-2026-42249
- path traversal の問題
- 本来の保存先以外に、攻撃者が狙った場所へファイルを書き込める
ざっくりどう危ないのか
Windows版Ollamaは、ログイン時に自動起動し、バックグラウンドで update を確認する仕組みがあります。
これを悪用されると、ログインのたびに攻撃者のコードが走るようにできてしまう可能性があります。
しかも記事によると、OLLAMA_UPDATE_URL を攻撃者側のサーバーに向けるような状況もあり得るとのこと。
また、自動更新はデフォルトで有効だとされています。
正直、この手の「アップデート機構を狙う攻撃」は、かなりいやな部類です。
なぜなら利用者から見ると、更新は普通は“守りの仕組み”だからです。
それが逆に攻撃の入口になると、心理的にも気づきにくい。ここが本当に嫌らしい。
持続性のある攻撃になる理由
記事では、署名確認の欠如だけでもコード実行は起こせるが、次の正規アップデートで上書きされるため永続化しないと説明されています。
一方で path traversal を組み合わせると、実行ファイルを想定外の場所に置けるので、Startup folder に残り続けて persistent な実行が可能になる、という流れです。
CERT Polska は、Ollama for Windows の 0.12.10〜0.17.5 がこの2件の影響を受けるとしています。
また、記事中の引用では 0.12.10〜0.22.0 が脆弱だとも述べられており、かなり広い範囲に注意が必要そうです。
対策としては、
- 自動更新をオフにする
-
Startup folder の Ollama ショートカットを削除する
"%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup"
が勧められています。
この記事から見えること
今回の件で面白いというか、怖いのは、LLMの脆弱性が「モデルそのもの」ではなく「ファイル処理」と「更新機構」に出ている点です。
つまり、AIだから特別に難しいというより、普通のソフトウェア開発でありがちな安全対策の穴が、そのままAI基盤でも致命傷になるということです。
しかも Ollama はかなり広く使われている人気プロジェクトです。
GitHub の star 数も fork 数も多い。だからこそ、1つの脆弱性の波及範囲が大きい。
「便利だからこそ攻撃面も広い」という、オープンソースの宿命がよく出ていると思います。
個人的には、AI関連ツールは今後ますます“中身の賢さ”より“周辺インフラの堅牢さ”が問われると思います。
モデルの性能競争とは別に、認証、隔離、更新、ファイル検証、メモリ安全みたいな基本がちゃんとしていないと、いくら高性能でも安心して使えません。
まとめ
- Ollama には、細工した GGUF ファイルでメモリを漏らせる脆弱性が見つかった
- 影響を受けるのは 0.17.1 より前
- 漏えいすると、API keys などの機密情報が抜かれる可能性がある
- 公開サーバーでは特に危険で、ネットワーク露出を減らすことが重要
- さらに Windows 版では、アップデート機構を悪用した persistent code execution の問題も報告されている
- AIツールは便利だが、安全設計が甘いと情報漏えいの入り口になる
参考:
Ollama Out-of-Bounds Read Vulnerability Allows Remote Process Memory Leak