【2026年最新】Ollama認証セキュリティ「31%問題」完全ガイド — 100万台スキャンで判明した罠と対策

2026年5月28日

この記事で分かること

「31%問題」の根拠となった4つの独立調査（Cisco Talos / SentinelLABS / Intruder / CVE-2026-7482）の内容
Ollama が認証機能を持たない設計上の理由と、その「ローカル前提」が崩れる瞬間
既知の重大 CVE（特に CVE-2026-7482「Bleeding Llama」）の影響範囲
Nginx / Caddy / Cloudflare Tunnel の3パターンで認証プロキシを実装する手順
公開前に必ず通すべき10項目のセキュリティチェックリスト

「31%問題」の正体 — 4つの調査が同じ結論を出している

「Ollama が無防備に公開されている」という話は単発の煽り記事ではない。少なくとも4つの独立した調査が、同じ問題を異なる角度から検出している。

1. Cisco Talos（2025年9月）— Shodan で 10 分・1,100台

Cisco Talos のセキュリティリサーチャーは、攻撃面マッピング SaaS の Shodan を使って わずか 10 分で 1,100台以上の露出 Ollama エンドポイント を発見した（公開: 2025年9月2日）。1,139台のうち 約 18.8%（214台）がアクセス制御なしにモデルを提供している状態 だった。

2. SentinelLABS + Censys（2026年1月公開・293日間スキャン）— 17.5万台

SentinelOne の研究部門と Censys が共同で 293日間にわたる長期スキャン を実施し、2026年1月29日にレポート「Silent Brothers」を公開した。130カ国で 175,108台の Ollama ホスト が無防備に露出しており、うち 23,000台が常時稼働の中核として全観測の大半を生成していた。

3. Intruder（2026年5月）— 200万台スキャンの「31%」

そして本記事のタイトルにある 31% という数字 は、2026年5月発表の Intruder 調査によるもの。

項目	数値
スキャン対象ホスト	200万台以上
公開 AI サービス検出	100万個
Ollama 検出数	5,200台以上
認証なし応答数	1,652台（31%）
有料 API ラップモデル	518個（全サーバー上）

特に注目すべきが 518モデル という数字。これは「Ollama 風のインターフェースで実際は OpenAI / Anthropic API を呼ぶ」プロキシ運用が広く行われていることを示している。Intruder の報告は「518モデルがフロンティアモデル（GPT-4 等）をラップ」としており、その全てが無認証公開とは限らないが、認証なしホスト 1,652台と組み合わさっている可能性は十分高い。世界中の誰でも オーナーの財布で GPT-4 / Claude を叩ける状態 にあるエンドポイントが、現実に存在している。

4. CVE-2026-7482「Bleeding Llama」— 30万台が情報漏洩リスク

さらに 2026年に公開された CVE-2026-7482（CVSS 9.1）は、Ollama のモデル量子化パイプラインに存在する out-of-bounds heap read 脆弱性。未認証の攻撃者が細工されたファイルを API にアップロードすることで、プロセスメモリの内容（システムプロンプト、ユーザーメッセージ、環境変数、API キー）を読み出せる。SecurityWeek の報告では 30万台以上のインターネット露出サーバーが影響範囲 とされている。

なぜこんなことになるのか — 「ローカル前提」設計の罠

Ollama の公式 Authentication ドキュメントはこう書かれている。

No authentication is required when accessing Ollama’s API locally via http://localhost:11434.

「ローカル接続では認証不要」とだけ書かれており、Ollama 本体には認証機能が組み込まれていない。デフォルトでは 127.0.0.1:11434 にしかバインドしないので、ローカルマシン内のクライアントが叩く分には問題ない。外部公開する場合のアクセス制御は、インフラ層もしくはアプリケーション層で実装することがユーザーに委ねられている。

問題は、ユーザーが「他のマシンからも使いたい」と思った瞬間に発動する。

export OLLAMA_HOST=0.0.0.0:11434
ollama serve

この瞬間、Ollama は 全インターフェース で listening を始める。家庭用ルーターの UPnP がポート 11434 を勝手に開放していたり、クラウド VM のセキュリティグループが 0.0.0.0/0 のままだったりすれば、もう露出は完了している。

そして認証がないため、ポートに到達できる相手は 全員がオーナー権限と同等の操作 ができる。任意のモデルダウンロード、任意のプロンプト実行、カスタム Modelfile によるシステムプロンプト改竄、すべて可能だ。

私は「ローカル LLM」という言葉が次の2つを混同させると思っている。

モデル実行の場所 がローカル（GPU が自分のマシン）
アクセス経路 がローカル（127.0.0.1 にのみバインド）

Ollama は「1」を実現するためのツールだ。「2」を保つかどうかは完全にユーザーの責任である。

攻撃シナリオ — 「自分のは大丈夫」と思っているあなたへ

実際に何が起きるのか。代表的な4パターンを見てほしい。

シナリオ A: 無料 GPU 採掘場としての悪用

最も古典的なパターン。攻撃者は Shodan で port:11434 product:ollama を検索し、認証なしホストを大量に収集する。発見された Ollama サーバーは「無料 LLM プロキシリスト」として共有され、世界中から利用される。

被害: 電気代の増加、クラウド GPU 課金の爆発、通信帯域の枯渇。

シナリオ B: 有料 API キーの間接窃取（518モデル事例）

Intruder 調査が明るみに出した最悪パターン。OpenAI / Anthropic API キーを Ollama のフロントに登録した状態で 0.0.0.0 公開すると、攻撃者は オーナーの財布 で GPT-4 を叩き放題になる。Intruder の調査では「フロンティアモデルをラップした構成」が 518個発見されており、認証なし露出と組み合わさったエンドポイントは深刻なリスク源だ。

攻撃者 → 公開 Ollama → ユーザーの GPT-4 API キーで OpenAI を叩く
                       ↑ ユーザーに月数十万円の請求

シナリオ C: プロンプトインジェクション経由の社内情報漏洩

社内ツールが Ollama を呼んでいる場合、攻撃者は モデル自体を差し替える（悪意ある Modelfile を pull）ことで、社内システムの問い合わせ内容を全て横取りできる。気づかれずに長期間継続する。

シナリオ D: CVE-2026-7482 連携でメモリ窃取

CVE-2026-7482 を使えば 未認証 でメモリ内容を吐き出させられる。社内の重要なプロンプトテンプレート、環境変数の API キー、DB パスワードまで露出する。

既知の重大 CVE（最低でも 0.17.1 へ更新せよ）

CVE ID	通称	CVSS	影響	修正状況
CVE-2024-37032	Probllama	8.8（CISA-ADP）	Path traversal → RCE	0.1.34 で修正
CVE-2025-51471	—	未確定（NVD未提供）	認証バイパス（0.6.7で確認）	GitHub Advisoryは「パッチなし」、Snyk Wolfiでは 0.12.10-r0 以降
CVE-2026-7482	Bleeding Llama	9.1（Cyera） ※	プロセスメモリ漏洩	0.17.1 で修正
CVE-2026-42248	—	8.8（CERT.PL/CVSS 4.0）※※	Windows 自動更新で任意 EXE 実行	パッチ未提供（0.12.10〜0.17.5 で検証済み脆弱、v0.23.0 でも未対応）
CVE-2026-42249	—	8.6（CERT.PL/CVSS 4.0）※※	Windows スタートアップ永続化	パッチ未提供（同上）

※ Bleeding Llama のスコアは発見者 Cyera の公式アドバイザリでは 9.1、SecurityWeek の報道では 9.3 と若干の不一致がある（本記事では一次ソースの Cyera を採用）。
※※ CVE-2026-42248/42249 は NVD で「assessment not yet provided」状態。スコアは CNA（CERT Polska）が提供する CVSS 4.0 ベクター文字列ベースの値。

ollama --version

curl -fsSL https://ollama.com/install.sh | sh

特に注意すべきは Windows 版 Ollama の CVE-2026-42248 / CVE-2026-42249。自動更新の署名検証が実質無効で、ETag ヘッダの Path Traversal と組み合わさることで、任意 EXE が Windows スタートアップに配置される永続化 RCE が成立する。CERT Polska と HelpNetSecurity の報告によれば、本記事執筆時点（2026年5月）で 公式パッチは提供されておらず、v0.23.0 でも未対応。Windows 利用者は 自動更新を無効化 し、Auto-download オプションをオフにすることが暫定的な防御策となる。

Linux / macOS で利用している場合も、CVE-2026-7482 「Bleeding Llama」を修正する 0.17.1 以降への更新は必須 だ。

認証実装の3パターン — 今夜中にどれか実装する

ここからが実践編。Ollama 自体に認証がないので、前段に認証プロキシを置く のが標準解だ。3つのパターンを用意した。自分の環境に合うものを選んでほしい。

パターン 1: Nginx + Bearer Token（API キー方式）

OpenAI SDK と相性が良く、CI/CD や自動化ツールに組み込みやすい。

map $http_authorization $auth_ok {
    default 0;
    "Bearer sk-yourSecretToken123" 1;
    "Bearer sk-anotherToken456"    1;
}

server {
    listen 443 ssl http2;
    server_name ollama.example.com;

    ssl_certificate     /etc/letsencrypt/live/ollama.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ollama.example.com/privkey.pem;

    location / {
        if ($auth_ok = 0) { return 401; }

        proxy_pass         http://127.0.0.1:11434;
        proxy_http_version 1.1;
        proxy_set_header   Host       localhost;  # ★ Ollama は Host ヘッダで弾く
        proxy_set_header   Connection "";

        # ストリーミング応答のため必須
        proxy_buffering    off;
        proxy_read_timeout 600s;
    }
}

Ollama 本体は必ず localhost バインドに戻すこと。

[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"

sudo systemctl daemon-reload && sudo systemctl restart ollama

クライアント側は OpenAI SDK でそのまま叩ける。

from openai import OpenAI
client = OpenAI(
    base_url="https://ollama.example.com/v1",
    api_key="sk-yourSecretToken123",
)

パターン 2: Caddy（最も簡単・自動 HTTPS）

Caddy は Let’s Encrypt 証明書を自動で取得・更新してくれるので、設定が最小限で済む。

ollama.example.com {
    basicauth /* {
        ollama_user $2a$14$xxxxx  # caddy hash-password で生成
    }
    reverse_proxy 127.0.0.1:11434 {
        header_up Host localhost
        flush_interval -1  # ストリーミング応答
    }
}

caddy hash-password  # bcrypt ハッシュ生成

「個人で使うだけだから設定に時間かけたくない」という場合、私はこれを推奨する。

パターン 3: Cloudflare Tunnel + Cloudflare Access（家庭回線でゼロトラスト）

家庭用回線で Ollama を外部公開したいけどポート開放したくない、という人向けの最強構成。

cloudflared tunnel login
cloudflared tunnel create ollama-tunnel

tunnel: ollama-tunnel
credentials-file: /home/user/.cloudflared/xxxx.json
ingress:
  - hostname: ollama.example.com
    service: http://localhost:11434
  - service: http_status:404

cloudflared tunnel run ollama-tunnel

加えて Cloudflare Access ポリシーで「特定の Google アカウントのみ許可」「特定の Email ドメインのみ許可」などを設定できる。ホームルーターのポート開放を一切しないままゼロトラストで公開可能 という点が他にない利点だ。

3パターン比較

パターン	難度	自動 HTTPS	適用シーン
Nginx + Bearer	★★★	別途 certbot	API 提供、CI/CD
Caddy	★	✅ 自動	個人 / 検証環境
Cloudflare Tunnel	★★	✅ 自動	家庭回線 / ゼロトラスト

公開前チェックリスト（10項目）

サーバーを公開する前に、以下を必ず通してほしい。

[ ] Ollama のバージョンが 0.17.1 以上
[ ] ss -tlnp \| grep 11434 の結果が 127.0.0.1 または内部 IP のみ
[ ] 公開する場合、前段に認証プロキシ（Nginx / Caddy / Cloudflare Tunnel）あり
[ ] プロキシ層で TLS（HTTPS） が有効
[ ] 認証情報（Basic / Bearer / OIDC）が設定済み
[ ] クラウドの Security Group / Firewall で 11434 が 0.0.0.0/0 から到達不可
[ ] Docker 利用時、ポート公開が "127.0.0.1:11434:11434" の形式
[ ] レート制限（DoS 対策）を設定
[ ] アクセスログが取得され、定期確認の仕組みあり
[ ] Shodan / Censys で自社 IP が露出していないか確認済み

今この瞬間に自分の露出を確認する方法

curl -s https://ifconfig.me

curl -sS http://YOUR_GLOBAL_IP:11434/api/tags --max-time 5

JSON が返ってきたら、世界中の誰でも同じことをできる状態にあるという意味だ。

ツール	デフォルト bind	内蔵認証	適用シーン
Ollama	127.0.0.1	❌	個人 / 検証
vLLM	localhost (127.0.0.1)	✅（`--api-key`）	本番推論
llama.cpp (server)	127.0.0.1	✅（`--api-key` 対応）	組込み
LM Studio	127.0.0.1	❌	デスクトップ GUI

まとめ

Intruder の調査が暴いた 31% という数字は、決して他人事ではない。むしろ「自分も気づかずに数えられていた側」である可能性が高い。

今日のアクションは4つ。

ollama --version でバージョン確認 → 0.17.1 未満なら CVE-2026-7482 対策のため即アップデート
Windows 版利用者は自動更新を無効化 → CVE-2026-42248/42249 は本記事執筆時点でパッチ未提供のため、Auto-download オプションをオフにして手動更新運用へ
ss -tlnp \| grep 11434 でバインドアドレス確認 → 0.0.0.0 なら認証プロキシを設置（本記事の3パターンから選ぶ）
別ネットワークから curl http://YOUR_IP:11434/api/tags で外部到達性を確認 → JSON が返ってきたら今夜中に対策

「ローカル LLM だから安全」という思い込みを捨て、接続経路のローカル性は別問題 という事実を受け入れることが第一歩だと、私は思う。

【2026年最新】Ollama認証セキュリティ「31%問題」完全ガイド — 100万台スキャンで判明した罠と対策

この記事で分かること

「31%問題」の正体 — 4つの調査が同じ結論を出している

1. Cisco Talos（2025年9月）— Shodan で 10 分・1,100台

2. SentinelLABS + Censys（2026年1月公開・293日間スキャン）— 17.5万台

3. Intruder（2026年5月）— 200万台スキャンの「31%」

4. CVE-2026-7482「Bleeding Llama」— 30万台が情報漏洩リスク

なぜこんなことになるのか — 「ローカル前提」設計の罠

攻撃シナリオ — 「自分のは大丈夫」と思っているあなたへ

シナリオ A: 無料 GPU 採掘場としての悪用

シナリオ B: 有料 API キーの間接窃取（518モデル事例）

シナリオ C: プロンプトインジェクション経由の社内情報漏洩

シナリオ D: CVE-2026-7482 連携でメモリ窃取

既知の重大 CVE（最低でも 0.17.1 へ更新せよ）

認証実装の3パターン — 今夜中にどれか実装する

パターン 1: Nginx + Bearer Token（API キー方式）

パターン 2: Caddy（最も簡単・自動 HTTPS）

パターン 3: Cloudflare Tunnel + Cloudflare Access（家庭回線でゼロトラスト）

3パターン比較

公開前チェックリスト（10項目）

今この瞬間に自分の露出を確認する方法

関連 OSS 比較 — Ollama だけの問題ではない

まとめ

参考リンク

一次ソース・公式

大規模スキャン調査

脆弱性レポート

認証実装ガイド

日本語解説

コメント

コメントするコメントをキャンセル

【2026年最新】Ollama認証セキュリティ「31%問題」完全ガイド — 100万台スキャンで判明した罠と対策

この記事で分かること

「31%問題」の正体 — 4つの調査が同じ結論を出している

1. Cisco Talos（2025年9月）— Shodan で 10 分・1,100台

2. SentinelLABS + Censys（2026年1月公開・293日間スキャン）— 17.5万台

3. Intruder（2026年5月）— 200万台スキャンの「31%」

4. CVE-2026-7482「Bleeding Llama」— 30万台が情報漏洩リスク

なぜこんなことになるのか — 「ローカル前提」設計の罠

攻撃シナリオ — 「自分のは大丈夫」と思っているあなたへ

シナリオ A: 無料 GPU 採掘場としての悪用

シナリオ B: 有料 API キーの間接窃取（518モデル事例）

シナリオ C: プロンプトインジェクション経由の社内情報漏洩

シナリオ D: CVE-2026-7482 連携でメモリ窃取

既知の重大 CVE（最低でも 0.17.1 へ更新せよ）

認証実装の3パターン — 今夜中にどれか実装する

パターン 1: Nginx + Bearer Token（API キー方式）

パターン 2: Caddy（最も簡単・自動 HTTPS）

パターン 3: Cloudflare Tunnel + Cloudflare Access（家庭回線でゼロトラスト）

3パターン比較

公開前チェックリスト（10項目）

今この瞬間に自分の露出を確認する方法

関連 OSS 比較 — Ollama だけの問題ではない

まとめ

参考リンク

一次ソース・公式

大規模スキャン調査

脆弱性レポート

認証実装ガイド

日本語解説

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル