DEF CON 34: ローカルAIを脅かす10件の脆弱性

ローカルAIは、組織により高いプライバシー、コスト管理、データ主権をもたらしますが、モデルをローカルで実行したからといってセキュリティリスクがなくなるわけではありません。 

DEF CON 34に関連して発表された研究では、多くのローカルAIアプリケーションの基盤として広く採用されている推論エンジン、llama[.]cppに10件の脆弱性が確認されました。

要点

• 研究者はllama[.]cppに10件の脆弱性を確認しました。これには複数の信頼境界に影響を及ぼすuse-after-free、整数オーバーフロー、範囲外メモリアクセスといった欠陥が含まれます。
• 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モデルのメタデータ処理

この調査では、use-after-free（UAF）、整数オーバーフロー、範囲外アクセスといった、おなじみのメモリ安全性の問題に起因する脆弱性が確認されました。 

VulnCheckはこれを受けて、報告された脆弱性に対しCVE-2026-43622からCVE-2026-43632までの識別子を割り当てました（CVE-2026-43625〈CodexBarの脆弱性〉は除く）。

2026年6月時点のビルドb9445およびgguf-v0.19.0に対する評価では、研究者らは10件の脆弱性のうち5件が未修正のままであると報告しています。 

中でも特に深刻だったのは、サーバー側の2件のUAF脆弱性、CVE-2026-43631とCVE-2026-43632で、いずれもCVSSスコア9.2を記録しています。

並行処理の欠陥がローカルAIにメモリ安全性のリスクをもたらす仕組み 

複数の調査結果は、並行処理がありふれたメモリ管理のミスをいかにしてセキュリティ脆弱性へと変えてしまうかを示しています。

Android JNIの並行処理がuse-after-freeのリスクを生む 

旧版のAndroid JNI統合では、複数の操作がグローバルなネイティブポインタを共有していました。 

あるバックグラウンドスレッドが推論を実行している間に、別のスレッドが同じコンテキストを解放してしまう可能性があったのです。 

十分な同期処理がなければ、最初のスレッドはその後、すでに解放済みのメモリにアクセスしてしまう可能性があります。

研究者らは、この状態を悪用し、解放済みメモリを再取得したうえでその後のプログラム実行を操作できたと報告しています。

llama-serverの欠陥が明らかにした、もう一つのuse-after-free状態 

llama-serverでも、これと類似したライフタイム管理の問題が見つかりました。 

–sleep-idle-seconds機能が有効になっている場合、アイドル状態でのリソース解放処理によってモデルや語彙のリソースが解放される一方で、別のワーカーがそれらのリソースを使ってリクエストの処理を継続してしまう可能性がありました。 

これにより、サーバーのインターフェース経由で到達しうる別のUAF状態が生まれていました。

これらの調査結果は、ローカルAIにおける重要なセキュリティ上の留意点を浮き彫りにしています。プロンプトをオンプレミスにとどめておくだけでは、基盤となる推論スタック自体の信頼性が自動的に保証されるわけではないのです。 

llama[.]cppの脆弱性への対処法  

llama[.]cppを利用している組織は、まず自社のAI環境のどこにこのライブラリが存在するかを特定する必要があります。間接的に組み込まれているアプリケーションも含めて確認することが重要です。

llama-serverとAPI公開範囲の強化 

インターネットに公開されているllama-serverの導入環境では、関連するUAF脆弱性の修正が確認されるまで、信頼できないHTTPトラフィックを受け付ける際に–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ワークロードやコンポーネントの潜在的な影響を抑えることによって、こうした保護をさらに強化することができます。