【注意喚起】Ollama for Windowsに永続的RCEを引き起こす脆弱性(CVE-2026-42248 / CVE-2026-42249)

ローカルでLLMを動かす定番ツールとして広く使われているOllamaに、Windowsユーザーへ深刻な影響を与える脆弱性が報告されました。本記事では、その原因を技術的に整理した上で、現時点で取りうる対策方法をまとめます。

セキュリティ研究機関Strigaが2026年4月29日に公開したレポートにより、Ollama for Windowsの自動アップデート機能には、攻撃者にログインのたびに任意コードを実行させ続けるという、極めて危険な欠陥が存在することが明らかになりました。執筆時点(2026年5月)で公式の修正版はリリースされていません。

影響を受ける環境

• 対象: Ollama for Windows バージョン 0.12.10 から最新の 0.22.0 まで(該当範囲のすべてのリリース)
• 影響を受けない環境: macOS版、Linux版
• 割り当てられたCVE:

– CVE-2026-42248: アップデートに対する署名検証の欠如(CVSS 4.0 スコア 7.7 High)

Score	Severity	Version	Vector String
7.7	HIGH	4.0	CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L

– CVE-2026-42249: アップデートメカニズムを介したリモートコード実行(CVSS 4.0 スコア 7.7 High)

Score	Severity	Version	Vector String
7.7	HIGH	4.0	CVSS:4.0/AV:A/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L

macOS版はコード署名検証を実装しているため影響を受けません。Linux版はそもそも該当する自動アップデート機構を持ちません。Windows版に固有の問題です。

何が起きるのか

簡潔に言えば、攻撃者が被害者のアップデート通信に介入できた場合、Windowsのスタートアップフォルダに任意の実行ファイルを書き込み、それ以降ログインのたびに無言で実行させ続けることができる、という脆弱性です。

ペイロード次第で、リバースシェル、ブラウザ保存情報の窃取、SSH鍵の流出、ランサムウェアの投下など、ユーザー権限で可能なあらゆる悪用が実現します。しかも実行はサイレントで行われるため、被害者は侵害に気づきにくいという特徴があります。

原因:3つの欠陥が連鎖している

この脆弱性は、単一のバグというより、本来であれば互いを補完していたはずの3つの実装が「全部欠けている」または「壊れている」という、防御の多層性が崩壊している点にあります。

原因1: HTTPヘッダー値を信頼してファイル保存先パスを構築している(パストラバーサル)

Ollamaのアップデーターは、ダウンロードしたインストーラーをローカルディスク上にステージング(一時保存)します。その保存先パスを、サーバーから返ってきたHTTPレスポンスヘッダーの値をそのまま使って組み立てています。

該当箇所の擬似コードは以下の通りです。

// app/updater/updater.go
etag := strings.Trim(resp.Header.Get("etag"), "\"")
filename := Installer
_, params, err := mime.ParseMediaType(resp.Header.Get("content-disposition"))
if err == nil {
    filename = params["filename"]
}

stageFilename := filepath.Join(UpdateStageDir, etag, filename)

ETag ヘッダーの値と Content-Disposition ヘッダーのファイル名が、サニタイズも検証もされずに filepath.Join に渡されています。Go言語の filepath.Join は相対パス記号 .. を解決しますが、結果が第1引数のディレクトリ配下に留まることを保証しません。

つまり攻撃者が以下のようなヘッダーを返すと、

ETag: "../../../Roaming/Microsoft/Windows/Start Menu/Programs/Startup"
Content-Disposition: attachment; filename="OllamaSetup.exe"

保存先パスは本来のステージングディレクトリを抜け出し、ユーザーの Windowsスタートアップフォルダ に解決されます。ファイル書き込みに先立って MkdirAll が呼ばれているため、必要な中間ディレクトリも自動的に作成されてしまいます。

原因2: ダウンロードしたファイルの署名検証が実装されていない(整合性チェックの欠如)

通常、アップデート機能を備えたソフトウェアは、ダウンロードしたバイナリが正規の発行元によって署名されたものかを必ず検証します。Ollamaも、macOS版ではこの処理を正しく実装しています。

ところがWindows版の検証関数は、わずか1行です。

// app/updater/updater_windows.go
func verifyDownload() error {
    return nil
}

何もせず、無条件に「検証成功」を返します。

この影響は深刻です。本来であれば、パストラバーサルでスタートアップフォルダにファイルが書き込まれたとしても、直後の検証ステップで未署名バイナリが拒否され、os.Remove によって削除されるはずでした。Ollamaのコードを見ると、検証失敗時にはきちんと削除する分岐が書かれています。

if err := VerifyDownload(); err != nil {
    _ = os.Remove(stageFilename)
    return fmt.Errorf("%s - %s", resp.Request.URL.String(), err)
}

しかし verifyDownload が常に nil を返すため、この削除分岐に入りません。攻撃者の書き込んだファイルは、そのまま残り続けます。

原因3: スタートアップフォルダから起動された際にサイレント実行する設計

Ollamaのトレイアプリは、Windowsスタートアップフォルダのショートカット経由で起動されたことを検出すると、隠しモードに切り替わります。STARTF_TITLEISLINKNAME フラグを見て判定しています。

// app/cmd/app/app_windows.go
if info.Flags&STARTF_TITLEISLINKNAME == STARTF_TITLEISLINKNAME {
    linkPath := windows.UTF16PtrToString(info.Title)
    if strings.Contains(linkPath, "Startup") {
        startHidden = true
    }
}

隠しモードで起動されたOllamaは、保留中のアップデートがあれば、/VERYSILENT /SUPPRESSMSGBOXES というインストーラーフラグ付きで、UIを一切表示せずにアップデートを実行します。Ollamaの初回インストール時には、スタートアップフォルダにショートカットがデフォルトで作成されるため、この経路は標準的な使い方の上に成立しています。

連鎖の全体像

これら3つを組み合わせると、攻撃シナリオは以下のように成立します。

1. 攻撃者が、被害者のOllamaが行うアップデートチェック通信に介入する(TLS傍受、DNSハイジャック、hostsファイル改変、OLLAMA<em>UPDATE</em>URL 環境変数の事前書き換えなど)
2. 攻撃者のサーバーが、ETag ヘッダーにパストラバーサル文字列、ボディに任意の .exe を含むレスポンスを返す
3. Ollamaは保存先パスを誤って解決し、Windowsスタートアップフォルダに攻撃者のバイナリを書き込む
4. 署名検証が機能しないため、ファイルは削除されずに残る
5. Ollamaの内部管理はステージングディレクトリ配下しか追跡しないため、書き込まれたファイルはOllamaの管理外となり、永久に居座る
6. ユーザーが次にログインすると、Windowsがスタートアップフォルダ内の全エントリを実行し、攻撃者のバイナリが現ユーザー権限で起動される
7. ファイルがスタートアップフォルダから削除されない限り、毎回のログインで実行が継続する

注目すべきは、1つでも防御が機能していれば全体が成立しなかったという点です。署名検証さえ動いていれば不正なファイルは削除されていましたし、ヘッダーのサニタイズさえあればスタートアップフォルダへの書き込み自体が起きませんでした。

ベンダー対応の状況

Strigaのレポートによれば、報告から公開までの経緯は以下の通りです。

• 2026年1月26日: 監査中に脆弱性を発見
• 2026年1月27日: Ollamaのセキュリティ窓口へ報告
• 2026年3月3日: 応答がないためCERT Polskaへエスカレーション
• 2026年4月27日: CVE番号が予約
• 2026年4月29日: 90日の開示期間経過後に公開

ベンダーは初回の受領確認以降、コミュニケーションを断っているとされています。執筆時点(2026年5月)で最新版の 0.22.0 も同じ脆弱なコードを含んでおり、公式パッチはリリースされていません。

対策

修正版が提供されるまでは、ユーザー側で次の対策を講じる必要があります。優先度の高い順に紹介します。

対策1: 自動ダウンロード機能を無効化する(必須)

最も重要かつ確実な緩和策です。OllamaのSettings UIから Auto-download updates トグルをオフにしてください。

この設定をオフにすると、アップデートチェックのレスポンスをフェッチする処理(updater.go:324)の手前で短絡され、悪意あるヘッダーが読み込まれることもファイルが書き込まれることもなくなります。脆弱性の入り口そのものを塞ぐため、本質的な対策となります。

オフにした後は、アップデートの存在を手動で確認し、公式サイトから直接ダウンロードしてインストールする運用に切り替えてください。

対策2: スタートアップフォルダのOllamaショートカットを削除する

仮に攻撃者バイナリが既にスタートアップフォルダへ投下されていた場合、または対策1だけでは不安な場合の追加策です。

エクスプローラーで以下のパスを開きます。

%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup

このフォルダ内に存在する不審な実行ファイルがあれば削除してください。また、Ollama自身のショートカットもここから削除すれば、サイレントなログイン時実行経路そのものを無効化できます(その代わり、Ollamaを使う際は手動で起動する必要があります)。

対策3: スタートアップフォルダの侵害を確認する

既に被害を受けていないかを確認するため、以下の手順で点検することを推奨します。

1. %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup をエクスプローラーで開く
2. 見覚えのない .exe や、OllamaSetup.exe という名前で配置されているが正規のインストーラーではないファイルがないか確認する
3. 不審なファイルがあれば、デジタル署名を確認する(右クリック → プロパティ → デジタル署名タブ)
4. 署名がない、または発行元が不明なものは削除する

タスクマネージャーの「スタートアップ」タブや、shell:startup をファイル名を指定して実行から開く方法でも、同フォルダにアクセスできます。

対策4: ネットワーク経路の見直し

OLLAMA<em>UPDATE</em>URL 環境変数が意図せず設定されていないかを確認してください。コマンドプロンプトで以下を実行します。

echo %OLLAMA_UPDATE_URL%

何らかの値が出力された場合、悪意あるツールやスクリプトに書き換えられた可能性があります。値を確認の上、不審であれば削除してください。

setx OLLAMA_UPDATE_URL ""

また、信頼できないWi-Fi(空港、カフェ、ホテルなど)でOllamaを起動することは当面避けるのが無難です。ネットワーク経路上の攻撃者がアップデート通信を傍受・改変するシナリオを成立させづらくするためです。VPNの利用も有効な軽減策となります。

対策5: アンインストールを検討する

業務での重要度が低く、しばらく使わなくても支障がない場合は、修正版がリリースされるまでアンインストールしてしまうのが最も確実です。Ollamaを使わない期間にバックグラウンドで通信が発生すること自体を防げます。

修正版のリリース状況を継続的に確認する

公式の修正はOllama GitHubリポジトリのリリースページで告知されることが期待されます。CVE-2026-42248およびCVE-2026-42249への対応がチェンジログで明示されていることを確認してから、アップデートを再開してください。

具体的には、次の3点が修正されているかが確認のポイントになります。

• app/updater/updater.go の filepath.Join 周辺で、ETag および Content-Disposition ヘッダーから取得した値に対するサニタイズ処理(パス区切り文字や .. の検査)が追加されているか
• app/updater/updater_windows.go の verifyDownload が、Authenticodeなど適切な署名検証を実際に行う実装に置き換わっているか
• DoUpgradeAtStartup がインストーラー起動前に再検証を行うようになっているか

まとめ

今回の脆弱性は、HTTPヘッダーへの過度な信頼、署名検証の未実装、サイレント実行設計の3点が連鎖した結果として、極めて悪用しやすい永続的RCEを生み出している事例です。

技術的な観点では、「外部からの入力値はサニタイズする」「ダウンロードしたコードは必ず整合性検証する」「サイレントな自動実行には特に慎重な設計を要する」という、いずれもセキュアコーディングの基本原則が複数同時に破られている点が印象的でした。アップデート機構は本来ユーザーを守るための仕組みですが、その実装を誤ると、むしろ攻撃者にとって理想的な侵入経路となり得るという教訓でもあります。

修正版が出るまでの間は、自動ダウンロードを必ず無効化することを徹底してください。それだけでも、攻撃の連鎖は成立しなくなります。

参考リンク

• Striga: Ollama Updates Itself Into Persistent RCE on Windows
• CVE-2026-42248
• CVE-2026-42249
• CWE-22: Improper Limitation of a Pathname to a Restricted Directory
• CWE-494: Download of Code Without Integrity Check