社内やクラウド上でOllama（ローカルLLMをAPI経由で動かすモデルサーバー）を運用している方に向けた内容です。
Ollamaの特定バージョンに、モデル配布の経路を悪用してホストを乗っ取られる脆弱性が見つかりました。対象バージョンかどうかの確認方法と、パッチが当たるまでの回避策を整理します。
何が起きるのか
今回の脆弱性はCVE-2026-103663として登録され、CERT Polska（ポーランドの国家サイバーセキュリティ機関）が2026年10月8日に公表しました。
影響範囲はOllama 0.34.2から0.35.0未満です。修正版は0.35.0で、発見者はstriga.aiのBartlomiej Dmitruk氏とされています。
脆弱性の分類はCWE-23、いわゆるパストラバーサル（本来アクセスを許可していないディレクトリへ、相対パス指定で侵入する手口）です。攻撃が成立すると、最終的にroot権限でのコード実行に到達します。
モデルサーバーが外部公開されている環境では、攻撃者がHTTP API経由でリモートからサーバーを乗っ取れる可能性があります。社内ネットワークに閉じているつもりでも、踏み台を経由して到達できる構成であれば無関係とは言えません。
なぜ起きるのか
原因を段階的に見ていきます。Ollamaはモデルを推論実行するだけでなく、モデルの実体ファイル（レイヤー）をリモートから取得して保存する機能を持ちます。この取得・保存の処理は、ソフトウェア配布の経路そのものです。
配布経路というのは昔からサプライチェーン攻撃の標的になりやすい場所です。配布の仕組みを乗っ取れば、それを使う全システムに到達できるためです。
Ollamaではこの取得処理を/api/pullエンドポイントが担っています。クライアントがモデルを要求すると、サーバーがレイヤーを取得し、モデルストア（モデルファイルの保存先ディレクトリ）に書き込みます。
問題は、レイヤーのダイジェスト値（ファイルの中身から計算されるハッシュ値）を保存先のファイルパスに変換するdigestToPathという関数にありました。この関数の検証が不十分で、細工されたダイジェスト値を渡すと、本来のモデルストアの外にファイルを書き込めてしまいます。
さらに悪いことに、多くのOllamaのDockerイメージでは、サーバープロセスが/usr/lib/ollamaというランタイムライブラリの保存先に書き込み権限を持っています。
このディレクトリに悪意あるファイルを書き込まれると、サーバーの次回起動時にそのファイルが読み込まれて実行されます。結果としてroot権限でのコード実行が成立します。
つまり攻撃者は、推論処理や既存のモデルファイルに手を出す必要がありません。モデルを配布する正規の経路を通るだけで、権限のあるディレクトリにたどり着けてしまう構造です。
パスの検証漏れというバグ自体は単純です。しかし配布経路というのは、サーバーが通常業務のために持っている書き込み権限をそのまま使える場所にあります。この「位置」の悪さが、単純なバグを全ホスト侵害に変えています。
同種の問題は、アーティファクト（成果物）を取得・保存するあらゆるソフトウェアに起こり得ます。コンテナイメージのレジストリ、パッケージマネージャ、CI/CDのアーティファクトストアなども、保存先パスを決める処理には同じ水準の検証が求められます。
自分の環境が該当するか確認する
まず稼働中のOllamaのバージョンを確認します。
ollama --version出力されたバージョンが0.34.2以上0.35.0未満であれば対象です。Dockerで動かしている場合はコンテナ内で同じコマンドを実行するか、使用しているイメージタグを確認してください。
docker exec <container_name> ollama --versionバージョン管理されたIaC（インフラをコードで定義・管理する仕組み）でデプロイしている場合は、Terraformやdocker-compose.ymlの中でイメージタグをollama/ollama:latestのような可変タグにしていないかも確認してください。latestのまま運用していると、いつのバージョンが動いているか追跡できなくなります。
次に、HTTP APIが外部からどこまで到達可能かを確認します。
curl -s http://<server_host>:11434/api/versionクラウド環境であれば、セキュリティグループやファイアウォールルールでポート11434（Ollamaのデフォルトポート）がどこからアクセス可能になっているかを確認してください。0.0.0.0/0のように全世界に開いている設定は特に優先して見直すべき箇所です。
参考情報として、インターネット公開資産を検索するZoomEyeのエンジンでは、Ollamaの製品フィンガープリントに一致する資産が2026年10月8日時点で607,195件確認されています。ただしこの数字はバージョンを読み取ったものではなく、インストール済みの脆弱なホスト数を直接示すものではありません。あくまで露出規模の目安として捉えてください。
対策の手順
バージョン確認で対象だった場合は、次の手順で対応します。
# バイナリ導入の場合はインストールスクリプトで最新化
curl -fsSL https://ollama.com/install.sh | sh
# バージョンが0.35.0以上になったか再確認
ollama --versionDockerで運用している場合は、イメージタグを固定しつつ0.35.0以降に更新します。
docker pull ollama/ollama:0.35.0
docker compose up -dアップグレードに加えて、次の3点も確認してください。
- APIの到達範囲を、本当に必要なクライアントだけに絞る（セキュリティグループ・リバースプロキシでのアクセス制限）
- サーバープロセスが
/usr/lib/ollamaなど実行時に読み込まれるディレクトリへ書き込み権限を持っていないか確認する - アップグレード後、モデルストアとライブラリディレクトリに見覚えのないファイルがないか確認する
監視の観点では、/api/pullへのリクエストでダイジェスト値に../のような相対パス表記が含まれていないか、WAF（Webアプリケーションファイアウォール）やリバースプロキシのアクセスログで検出するルールを追加しておくと、同種の試行を早期に捉えられます。
障害対応の優先順位としては、まず外部公開しているOllamaインスタンスの洗い出しが先決です。クラウド上で複数チームがそれぞれOllamaを立てている場合、資産管理が追いついていないケースがあり得ます。CMDB（構成管理データベース）やクラウドのタグ運用で、稼働中のモデルサーバーの棚卸しをあわせて実施することをおすすめします。
まとめ
CVE-2026-103663は、Ollama 0.34.2から0.35.0未満に存在するパストラバーサル脆弱性です。
モデル配布の処理がファイルパスの検証不足を抱えており、悪用されるとroot権限でのコード実行に至ります。
まずollama --versionで手元の環境が対象かを確認し、該当すれば0.35.0以降へのアップグレードを進めてください。
アップグレードと並行して、APIの公開範囲の見直しと、サービスプロセスの書き込み権限の棚卸しも実施しておくと、同種の配布経路型の脆弱性に備える体制が整います。