The Hacker News が伝えたのは、Ollama に見つかったかなり厄介な脆弱性です。
ざっくり言うと、攻撃者が細工したファイルを送るだけで、Ollama が自分のメモリの中身を漏らしてしまう可能性がある、という話です。
これは地味に見えて、実はかなり怖いです。
なぜなら「メモリの中身」には、いま動いているサービスの秘密情報の詰め合わせが入っていることがあるからです。たとえば:
こういうものが見えてしまうと、単なるクラッシュよりずっと深刻です。
個人的には、LLM系サービスの事故は“モデルが賢いかどうか”より“周辺の安全設計が甘いかどうか”で決まることが多いと思っていますが、今回もまさにそのタイプです。
今回の問題は、out-of-bounds read と呼ばれるタイプです。
日本語にすると「決められた範囲の外を読んでしまう」バグです。
たとえば、本棚の1番から10番までしか見てはいけないのに、11番目や12番目まで勝手に読みに行ってしまう感じです。
読み取ってはいけない場所まで見に行くので、そこにたまたま残っていたデータが漏れてしまうことがあります。
Ollama の説明では、問題は GGUF model loader にあります。
CVE.org の記述によると、/api/create が攻撃者の用意した GGUF ファイルを受け取り、その中の tensor offset と size が実ファイル長を超えていると、量子化の処理中に heap の外まで読み出してしまうとのことです。
GGUF は GPT-Generated Unified Format の略で、LLM をローカルで動かすためのモデルファイル形式です。
PyTorch の .pt/.pth、safetensors、ONNX みたいな、モデルを保存して読み込むためのファイルだと思えば大きく外れていません。
つまり今回の攻撃は、「モデルファイルを装った細工データ」を食わせることで起きます。
モデルを扱うソフトは、普通のWebアプリよりも「ファイルの読み込み」が重要になるので、こういう攻撃面が増えがちです。ここはLLM時代ならではの厄介さだな、と思います。
記事では、攻撃の流れが3段階で説明されています。
細工した GGUF ファイルをアップロード
/api/create を実行
/api/push で情報を外部へ送る
この最後のステップがいやらしいところです。
単に漏れるだけでなく、漏れた情報を持ち出す導線まで組み立てられているんですね。
Cyera の研究者 Dor Attias 氏によると、攻撃者は AI inference から組織についてかなり色々学べる可能性があるとのことです。
具体的には:
さらに、Ollama を Claude Code のようなツールとつないで使っている場合、影響はもっと大きくなるかもしれないと指摘されています。
というのも、ツールの出力が Ollama サーバーに流れ込み、そのまま heap に残る可能性があるからです。
これはかなり生々しい話です。
LLM を「便利なチャットボット」として見ていると見落としがちですが、実際には秘密情報の通り道にもなり得ます。
個人的には、AIを業務に組み込んだ時点で「何がどこに保存されるか」を一度棚卸ししないと危ない、という典型例だと思います。
記事では、次の対策が勧められています。
ここ、地味ですが重要です。
「最新版にしたから終わり」ではなく、そもそもインターネットに素のまま置かないほうがいい、という話です。
セキュリティ事故って、脆弱性そのものより「公開しっぱなし」「認証なし」「更新されない」の三点セットで大きくなることが多いんですよね。
記事の後半では、別の研究グループ Striga が報告した、Windows版Ollamaの脆弱性も紹介されています。
こちらはメモリ漏えいではなく、persistent code execution、つまり「悪意あるコードを継続的に実行させられる」問題です。
報告されたのは次の2件です。
CVE-2026-42248
CVE-2026-42249
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 が脆弱だとも述べられており、かなり広い範囲に注意が必要そうです。
対策としては、
"%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup"が勧められています。
今回の件で面白いというか、怖いのは、LLMの脆弱性が「モデルそのもの」ではなく「ファイル処理」と「更新機構」に出ている点です。
つまり、AIだから特別に難しいというより、普通のソフトウェア開発でありがちな安全対策の穴が、そのままAI基盤でも致命傷になるということです。
しかも Ollama はかなり広く使われている人気プロジェクトです。
GitHub の star 数も fork 数も多い。だからこそ、1つの脆弱性の波及範囲が大きい。
「便利だからこそ攻撃面も広い」という、オープンソースの宿命がよく出ていると思います。
個人的には、AI関連ツールは今後ますます“中身の賢さ”より“周辺インフラの堅牢さ”が問われると思います。
モデルの性能競争とは別に、認証、隔離、更新、ファイル検証、メモリ安全みたいな基本がちゃんとしていないと、いくら高性能でも安心して使えません。
参考: Ollama Out-of-Bounds Read Vulnerability Allows Remote Process Memory Leak