「CVE採番が数カ月放置された」Ollamaの脆弱性が危ない“3つの理由” 30万台に影響か：MITREへのリクエストは未解決、Echoが採番

セキュリティ調査企業Cyeraが、ローカルLLM「Ollama」の重大なメモリ脆弱性を発見した。MITREの数カ月の放置の後、CNAであるEchoが「CVE-2026-7482」として採番して公開した。

[＠IT]

　セキュリティ企業Echoは2026年5月5日（現地時間）、ローカルLLM（大規模言語モデル）オープンソースツール「Ollama」に存在する重大なメモリ脆弱（ぜいじゃく）性「CVE-2026-7482」（共通脆弱性識別子）についての技術解説を公開した。

MITREへのCVEリクエストが未解決でEchoが採番（提供：Echo）

　Ollamaの脆弱性は、セキュリティ企業Cyeraが発見、開示したものだ。MITREへのCVEリクエストが未解決のまま放置されていたことから、CVE採番を許可された登録CNA（CVE Numbering Authority）であるEchoがCVEを採番し、公開した。Echoは同脆弱性のリスクや、CVEがすぐに採番されなかった影響などを解説している。

CVE-2026-7482の概要：エラーを起こさず機密データを抽出

　CVE-2026-7482は、OllamaがGGUF（GPT-Generated Unified Format）モデルファイルを処理する方式に起因するメモリ開示脆弱性だ。サーバはGGUFファイル内に提供されたテンソル次元（データのサイズ指定）を、適切な境界チェックを行わずに信頼してしまう。これにより、特別に細工されたモデルが処理中のメモリ読み取りを操作し、割り当て済みバッファーを超えた領域からデータを取り出せる状態になる。

　露出する可能性があるデータには、環境変数、APIキー、システムプロンプト、さらには他ユーザーの対話の断片までが含まれる。これらのデータは出力アーティファクト（成果物）に紛れ込むため、エラーやクラッシュを起こさず静かに抽出できる。これがこの脆弱性を危険にしている。システムを停止させるのではなく、静かにデータ漏えい状態へと変えてしまう。

Ollamaの脆弱性が特に危険な理由

　Echoは3つの観点から、Ollamaの脆弱性は特に危険だと指摘している。

Ollamaを公開しているケースが多い

　Ollamaは本来ローカル利用を前提として設計されており、認証機能を持たない。しかし実際には、コンテナ環境や複数クライアント利用のためにネットワークが公開されるケースが多い。その結果、認証なしAPIがインターネットに露出した状態になりやすく、約30万インスタンスが公開状態の可能性がある。

修正が緊急に見えなかった

　Ollamaの脆弱性はCyeraからの報告後に比較的速やかに修正されたが、修正を含むリリースはセキュリティアップデートとして提示されなかった。重大な問題に対処したという表示も、深刻度を明示するCVEもなく、多くの運用チームが緊急性を認識できず、アップデートを後回しにした。

CVEがなければ事実上「見えない」

　Cyeraは修正リリース後にMITREへCVEリクエストを提出したが、数カ月の間未解決のまま放置された。その間、脆弱性はスキャンツールや脆弱性フィードに表示されず、自動検出に依存するセキュリティチームには対象システムを特定する手段がなかった。

　CVEがない脆弱性は追跡や優先順位付け、気付くこと自体が難しい。記録が遅れただけでなく、実世界での対応そのものが遅れる結果となった。

Echo介入の経緯

　Cyeraはプロセスを前進させるために、登録CNAであるEchoに支援を求めた。Echoのチームは修正に対する技術検証を独自に行い、CVE-2026-7482を採番した。MITREへの当初のリクエストも取り下げ、エコシステム上の重複登録や不要なノイズを避けた。

　Echoはその後、開示タイムライン、影響を受けるコンポーネント、スコアリング、利用者への実用的なガイダンスを含む完全なCVE記録を公開した。詳細なレベルで情報が公開されることで、漠然としたリスクを、Ollamaの運用チームが理解し対処できるものに変えられる。

　何より重要なのは、脆弱性が「見える」状態になったことだとEchoは強調している。CVEが公開されると、スキャナーが検知でき、プラットフォームが情報を提示でき、組織が実効的に対応できるようになったという。

Ollamaユーザーに求められる対応

　Echoが述べる対処法は、Ollamaを運用しているなら、まずバージョンv0.17.1以降にアップグレードして根本となる脆弱性を排除すること。次に、自分のインスタンスがどの程度露出しているかを精査する。インターネットから到達可能であれば、ネットワーク制御でアクセスを制限するか、セキュアプロキシの背後に配置する。露出の低減はパッチ適用と同等に重要だとしている。

　インスタンスが公開アクセス可能だった場合、機密データが既に漏えいしている可能性も想定すべきだ。認証情報のローテーション、ログの確認、出力の監査を行うことで、潜在的な影響を低減できるとしている。