ローカルAIは、組織により高いプライバシー、コスト管理、データ所有権をもたらすが、モデルをローカルで実行してもセキュリティリスクがなくなるわけではない。
DEF CON 34に関連して発表された研究では、多くのローカルAIアプリケーションの基盤として広く採用されている推論エンジン、llama[.]cppに10件の脆弱性が確認された。
主なポイント
- llama[.]cppに10件の脆弱性が確認された。これには、複数の信頼境界に影響する解放後使用、整数オーバーフロー、範囲外メモリアクセスの欠陥が含まれる。
- llama-serverの2件の脆弱性にはCVSSスコア9.2が付与された。これは、ローカルAI推論サービスを信頼できないトラフィックにさらす組織が受ける潜在的なリスクの大きさを示している。
- ローカルAIはセキュリティリスクをなくさない。プロンプトや機密データを組織のインフラ内に保持する場合でも、推論エンジン、モデル、API、依存関係、周辺インフラを保護する必要がある。
- 組織はllama[.]cppがどこに導入されているかを特定し、露出を抑えるべきだ。インターネットに公開されたAPIの強化、信頼できない入力の検証、脆弱なコンポーネントへのパッチ適用、AIワークロードの分離、不審な活動の監視などが含まれる。
llama.cppとローカルLLM推論を理解する
大規模言語モデル（LLM）の推論とは、学習済みモデルの重みをメモリに読み込み、入力トークンをモデルに通して処理し、1トークンずつ出力を生成するプロセスである。
リモート推論では、プロンプトとデータが外部プロバイダーに送信される。一方、ローカル推論では、ユーザーまたは組織が管理するインフラ上でこれらの処理を実行する。
この違いは、知的財産、機密情報、独自の金融戦略、その他の機密データを扱い、第三者のAIプロバイダーに送信できない組織にとって重要である。
llama.cppとは何か、ローカルAIをどう支えているのか
Llama[.]cppは、このエコシステムにおける重要なコンポーネントとなっている。
主にC/C++で記述されたこのライブラリは、GGUFモデルファイルの読み込み、推論コンテキストの管理、トークン化とモデル計算の実行を担い、他のアプリケーションが利用するインターフェースを提供する。
Ollama、LM Studio、Jan、GPT4Allなどの製品では、バックエンドまたは統合レイヤーとして機能する。
広く採用されていることは、基盤となるエンジンの脆弱性が、下流の多数の実装に影響を及ぼす可能性も意味する。
Llama[.]cppの脆弱性が深刻なメモリ安全性の欠陥を露呈
Cyeraの研究者は、3つの信頼境界に特に注目してllama[.]cppを監査した。
- Android Java Native Interface（JNI）統合
- llama-serverのHTTPライフサイクル
- GGUFモデルメタデータの処理
この調査では、解放後使用（UAF）、整数オーバーフロー、範囲外アクセスなど、よく知られたメモリ安全性の問題に関わる脆弱性が確認された。
VulnCheckは、報告された調査結果に対してCVE-2026-43622からCVE-2026-43632までを割り当てた。ただし、CVE-2026-43625（CodexBarの脆弱性）は除外されている。
2026年6月時点で、ビルドb9445とgguf-v0.19.0を評価した研究者らは、10件の脆弱性のうち5件が依然として未修正だと報告した。
中でも特に重大だったのは、サーバーの解放後使用による2件の脆弱性、CVE-2026-43631とCVE-2026-43632であり、いずれもCVSSスコアは9.2だった。
並行処理の欠陥がローカルAIにメモリ安全性のリスクを生む仕組み
複数の調査結果は、並行処理によって、通常のメモリ管理上のミスがセキュリティ脆弱性へと変わり得ることを示している。
Android JNIの並行処理が解放後使用のリスクを生む
旧版のAndroid JNI統合では、複数の処理がグローバルなネイティブポインターを共有していた。
あるバックグラウンドスレッドが推論を実行している間に、別のスレッドが同じコンテキストを解放できた。
適切な同期がなければ、最初のスレッドが、その後すでに解放されたメモリにアクセスできてしまう。
研究者らは、解放されたメモリを再取得し、その後のプログラム実行を操作することで、この状態を悪用できると報告した。
Llama-serverの欠陥が別の解放後使用状態を露呈
同様のライフタイム管理上の問題がllama-serverにも影響した。
「–sleep-idle-seconds」機能が有効になっていると、アイドル状態の終了処理によって、別のワーカーがそれらのリソースを使ってリクエストの処理を続けている間に、モデルや語彙リソースが解放される可能性があった。
これにより、サーバーインターフェース経由で到達可能な別のUAF状態が生じた。
これらの調査結果は、ローカルAIに関する重要なセキュリティ上の考慮点を示している。プロンプトをオンプレミスに保持しても、基盤となる推論スタックの信頼性が自動的に保証されるわけではない。
llama[.]cppの脆弱性を緩和する方法
llama[.]cppを使用する組織はまず、直接組み込んでいるアプリケーションを含め、AI環境内のどこにこのライブラリが存在するかを把握すべきである。
llama-serverとAPIの公開範囲を強化する
インターネットに公開されたllama-serverの導入環境では、信頼できないHTTPトラフィックを受け入れる場合、関連するUAF脆弱性の修正が確認されるまで–sleep-idle-secondsを有効にしてはならない。
APIを0.0.0.0上で無制限に公開することは避け、リバースプロキシまたは同等のアクセス制御レイヤーによる認証を使って不正アクセスを制限すべきである。
llama.cpp統合と信頼できない入力を保護する
旧版のllama-android[.]cpp JNIラッパーを使用しているAndroid開発者は、ビルドb7446より前のバージョンから移行し、ネイティブコンポーネントで安全でない並行アクセスがないか確認すべきである。
llama_batch_initを使用するアプリケーションは、信頼できない入力をネイティブコードに渡す前に検証すべきである。
同様に、関連するメモリ安全性の脆弱性が解消されるまで、信頼できないソースから状態やKVキャッシュデータを復元することは避けるべきである。
ローカルAIとオープンウェイトモデルを保護する方法
ローカル推論はプライバシーと管理性に大きなメリットをもたらすが、そのメリットを得るにはランタイム自体を保護する責任が伴う。
メモリ破壊、安全でないオブジェクトのライフタイム、悪意のあるモデルファイル、公開された推論APIは、従来のネイティブアプリケーションに見られるものと同程度の攻撃対象領域を生み出す可能性がある。
したがって、オープンウェイトAIを導入する組織は、推論エンジンをセキュリティ上重要なインフラとして扱い、次のような対策を組み込むべきである。
- ローカルAIモデルのインベントリを維持するほか、推論エンジン、依存関係、その他のコンポーネントも管理する。
- 制限し、ネットワークを公開せず、AIワークロードを分離し、機密性の高い本番システムから切り離す。
- 最小権限アクセスを徹底し、推論APIと管理機能に強力な認証を適用する。
- モデルファイルを検証・スキャンするほか、導入前に状態ファイル、依存関係、その他の成果物も確認する。
- セキュリティパッチを速やかに適用し、上流プロジェクトと依存関係を監視して、新たに公表された脆弱性を把握する。
- 推論ワークロードをコンテナ、仮想マシン、その他の分離メカニズムを用いて、適切な場合にサンドボックス化する。
- AIシステムの活動をログに記録・監視し、定期的にインシデント対応計画をテストして、AI関連のセキュリティインシデントをチームが封じ込め、復旧できるようにする。
これらの対策を組み合わせることで、組織はAI関連の脅威への露出を抑えながら、レジリエンスを高めることができる。
結論
llama[.]cppの脆弱性は、ローカルAIに関する重要な現実を浮き彫りにしている。機密データを組織の環境内に保持することでプライバシーと管理性は向上するが、セキュリティリスクがなくなるわけではない。
組織は、データを処理する推論エンジン、モデル、依存関係、インフラを保護し、露出を抑えて、よりレジリエントなローカルAI環境を構築しなければならない。
ゼロトラストは、最小権限アクセスの徹底、信頼性の継続的な検証、侵害されたAIワークロードやコンポーネントによる潜在的な影響の制限によって、こうした保護を拡張できる。