3行でいうと

  • Ollamaは初期設定で、自分のパソコンからしか届かない形で待ち受けます。設定1つで外に開きます。
  • 手元の入口（API）に、初期設定で認証がない道具があります。外に開くなら、鍵かプロキシが要ります。
  • 過去の脆弱性には、外に開いていなくても、ウェブページを見るだけで届いた例があります。更新が基本です。
  • 道具・拡張機能・エージェント機能は、AIに手を持たせる設定です。権限は最小にします。

この記事は、実際に使って確かめた記録ではありません。この記事は公式の文書や論文を読んでまとめたものです。脆弱性の数字や件数は、調べた時点の記録です（NVDの検索件数は2026年10月23日、個々の記録の一部は10月8日に読んだもの）。

先に結論

見立てです。個人で使う範囲なら、次の順番で十分だと考えています。

  1. 入口は、自分のパソコンの中（localhost）だけに限る。初期設定のままにする。
  2. 別の端末から使いたいときは、入口を直接開けず、鍵（認証）かVPNを挟む。
  3. 道具の機能（ファイルを読む、コマンドを動かす）は、必要な間だけ入れる。
  4. 道具は更新する。配布元の確認は、前の記事（Hugging Faceから入れる安全）のとおり。

前提：入口とは何か

ローカルのAIの道具は、裏で小さなサーバー（受付係のようなプログラム）を動かします。チャット画面や他のアプリは、そのサーバーに、決まった番号の窓口（ポート）から話しかけます。この話しかけ方の決まりが、API（アプリどうしが会話する取り決め）です。

大事なのは、「どのアドレスで待ち受けるか」（バインド）です。

公式の初期設定

道具 初期の待ち受け 認証 出典で読んだ点
Ollama 127.0.0.1の11434番 ローカルのAPIは不要 FAQに「127.0.0.1の11434番に結びつく。OLLAMA_HOSTで変えられる」とある。認証の文書に「localhostのAPIは認証を要求しない」とある
llama.cpp（llama-server） 127.0.0.1の8080番 既定は鍵なし。--api-keyで設定できる READMEの引数表に、--hostの既定が127.0.0.1、--api-keyの既定が「なし」とある
LM Studio 文書に既定の記載なし 既定では不要。設定で、APIトークンを必須にできる 文書に「既定では認証を要求しない」とあり、Developersページの設定で切り替える。待ち受けの既定は、読んだ文書では確認できませんでした

つまり、初期設定の多くは「自分のパソコンの中なら、鍵はなくていい」という前提です。ここに、0.0.0.0という1行を足すと、前提が崩れます。

外に開くとどうなるか：公開された調査

SentinelLABSとCensysは、ネットから見えるOllamaを293日間にわたって調べ、2026年1月に公表しました。同社のレポートによると、次のとおりです。

調査の限界も、レポートに書かれています。機械ごとの観測回数の偏りが大きく、約13%の機械が観測の約76%を占める、分類の空欄もある、などです。「17万5千台が全部、今も開いている」という意味ではありません。

見立てです。この調査が示すのは、「初期設定が危ない」ではなく、「便利さのために1つ設定を変えた結果、鍵のない入口がネットに出た例が多数ある」ことだと読みました。

外に開かなくても、届いた例

2024年に公表されたCVE-2024-28224は、Ollama 0.1.29より前の版の脆弱性です。NCC Groupの勧告によると、DNSリバインディング（悪意あるサイトが、名前の引き当てを操作して、見ている人のパソコン内の窓口に話しかける手口）で、API全体に不正にアクセスできました。「APIを外に公開していなくても」成り立つ、と書かれています。罠のウェブページを見た人が、対象でした。修正は2024年3月14日の0.1.29です。NCC Groupは、Hostヘッダー（宛先の名前）を許可リストで確かめることなどを、一般的な対策として挙げています。

ここから分かるのは、localhostだけに限るのが「無敵」ではなく、道具を更新することも守りの一部だという点です。

公的な記録を読む：NVD

NVD（米国立標準技術研究所のCVE一覧）で「ollama」を検索すると、2026年10月23日の時点で45件が出ました（10月8日の時点では41件でした）。Ollama本体以外（周辺の道具）も含みます。いくつか、読んだ範囲で挙げます。

番号 公表日 内容（NVDの記述の要約）
CVE-2024-37032 2024-05-31 0.1.34より前。取得するデータの識別値（ハッシュ）の形式を検証せず、../などの文字列を通してしまう。CVSS 8.8（NVD）
CVE-2026-42248 2026-04-29 Windows版。更新ファイルの正しさを検証せず、「検証は常に成功」を返す。サイレント更新がある。確認された範囲は0.12.10〜0.17.5
CVE-2026-102697 2026-09-29 0.14.0以上0.31.2未満。実験的なエージェントモードの承認の仕組みが、セミコロンなどの結合を見落とす。NVDの状態は「分析待ち」

CVE-2026-42248については、ポーランドのCERT Polska（国の緊急対応チーム）も勧告を出しています。同ページには、修正版と回避策の記載は見つかりませんでした。現在の状況は、Ollamaの公式の更新情報で確かめてください。

CVSSは、深刻さを0から10で表す採点です。道具の使い方で現実の危険は変わるので、数字は目安です。

道具を足すほど入口は増える：エージェント機能とプラグイン

llama.cppのサーバー

READMEは、実験的な機能として--tools（ファイルの読み書きやシェルの実行などの内蔵ツール）、--mcp-servers-config、--agentを説明し、それぞれ「信頼できない環境では有効にしない」と書いています。--toolsか--agentを有効にすると、CORS（どのウェブページからの要求を受けるか）の既定が、localhostだけに絞られます。ツールを別の入れ物（DockerやPodman）の中で動かす--tools-runtimeもあります。CORSの表では、公開の場合は「APIキーを設定し、リバースプロキシの後ろに置く」とあります。

llama.cppのSECURITY.mdは、「信頼できないモデルは、コンテナや仮想マシンのような隔離環境で動かす」「信頼できないネットワークに出すなら、RPCバックエンドとllama-serverは使わない」とも書いています。この方針は、公式の文書の説明です。

Open WebUI

Open WebUIの公式文書は、このソフトを「私的で信頼できるネットワーク向け」と説明しています。推奨の置き方は、VPN（WireGuardやTailscale）、ゼロトラストのプロキシ、認証とIP許可つきのリバースプロキシです。ToolsとFunctions（プラグイン）はサーバー上でPythonを動かす機能で、workspace.toolsの権限は、「サーバーへのシェル権限と同じ」「root相当」と扱うべき、と書かれています。

2026年のNVDには、Open WebUIの記録もあります。たとえばCVE-2026-54021（0.9.6未満）は、ログイン済みのユーザーが、管理者の想定しないOllamaの接続先へ要求を向けられた、というものです。見知らぬ人がいきなり入れる話ではなく、「ログインした人の権限の線引き」の問題です。

Open WebUIの文書には、ログアウトしても、Redisがなければ、ログイン用トークンが無効にならないこと（既定で4週間有効）も書かれています。共有の環境では、設定を見直す理由になります。

手元で守るための設定

見立てです。公式文書の内容から、個人利用なら次の順に絞れると思います。

  1. 何も変えない。 OllamaのOLLAMA_HOSTを0.0.0.0にしない。
  2. 別の端末から使いたいときは、VPN（TailscaleやWireGuard）で自宅のネットワークに入る。ルーターのポート開放は、しない。
  3. 鍵を使う。 llama.cppは--api-key、LM Studioは設定のAPIトークン。Ollamaのローカルは鍵がないので、前にプロキシを置く（OllamaのFAQにNginxの例がある）。
  4. ブラウザの拡張機能に許す範囲を絞る。 OllamaのFAQには、拡張機能からつなぐためにOLLAMA_ORIGINSにchrome-extension://*などを足す例があります。「全部の拡張機能」を許す書き方なので、必要な拡張機能だけにします。
  5. 更新する。 上のCVEの多くは、更新で直る類のものです。

つまずきやすい点

気をつけること

出典

更新履歴