COLUMN
コラム
2026年10月26日
2,500社流出、CVSS7.8、パッチ未提供——2026年Kubernetesを襲った「デプロイ後」の脅威と守り方
「コンテナは隔離された箱」という前提が崩れた2026年
Kubernetesのセキュリティ対策というと、多くの現場では「デプロイ前にどれだけ設定を固めるか」に関心が向きがちだ。イメージスキャン、マニフェストのLint、RBACの設計——いずれも重要だが、2026年に表面化した一連の事件が示しているのは、攻撃者の関心がすでに「デプロイ後」に移っているという事実だ。
セキュリティベンダーのWizが20万以上のクラウドアカウントを分析した「Kubernetes Security Report 2025」によれば、新規に作成されたAKSクラスタは作成からわずか18分以内に、EKSクラスタは28分以内に最初の攻撃を受けるという。クラスタを安全に「作る」ことと、それを「守り続ける」ことはまったく別の課題であることが、数字としてはっきり表れている。
こうした流れに現場でどう備えるかを体系的に学びたいエンジニアに向けて、HexabaseはAI駆動開発セミナーを提供している。要件定義からCI/CD、品質ゲートまでを通して学べる実践型のプログラムだ。
2026年に表面化した3つの攻撃パターン
「デプロイ後」を狙う攻撃は、抽象的な脅威ではない。2026年だけでも、具体的な事件としていくつも報告されている。
Copy Fail(CVE-2026-31431) — カーネルの暗号化APIを突く権限昇格
2026年4月に公表された「Copy Fail」は、Linuxカーネルの暗号化APIにあるロジックの欠陥を突く脆弱性だ。CVSSスコアは7.8(高)で、特権を持たないローカルユーザーがroot権限を取得できてしまう。Picus Securityの解説によると、変更がディスクではなくメモリ上のページキャッシュにのみ発生するため、従来のファイル改ざん検知では見抜きにくいという。Ubuntu、Amazon Linux、RHELなど主要ディストリビューションが広く影響を受けた。
Ubuntu AF_UNIX脆弱性(CVE-2026-80521) — パッチ未提供のまま公開された欠陥
同じく2026年に報告されたAF_UNIXソケットのuse-after-free脆弱性(CVSS 7.8)は、コンテナ内のコード実行権限を持つ攻撃者がカーネルメモリを破壊し、コンテナエスケープによってホストのroot権限まで奪取できるというものだ。セキュリティ研究チームDepth Firstの報告では、Ubuntu 22.04/24.04/26.04 LTSが影響を受けるにもかかわらず、修正パッチが未提供のまま実証コードが公開された経緯が示されている。ホストカーネルを共有するコンテナ環境では、こうしたローカルカーネル脆弱性が隔離境界そのものを無効化しうる。
LiteLLMサプライチェーン攻撃 — CI/CDを経由した40分間の侵食
もっとも波及範囲が大きかったのが、AI開発で広く使われるPythonライブラリ「LiteLLM」を巡るサプライチェーン攻撃だ。InfoQの報道によれば、コンテナスキャナー「Trivy」側の脆弱性を突かれたことでLiteLLMの公開パイプラインの認証情報が窃取され、悪意あるバージョンがPyPIに公開された。この悪性パッケージはPyPIのセキュリティチームが検知してから約40分で隔離されたが、その間だけでも数万件のダウンロードが発生し、SSHキーやクラウド認証情報、Kubernetesの設定ファイルまでが窃取対象になった。被害範囲は推定2,500社規模、CI/CDパイプラインにして40万本以上に及んだと報じられている。
なぜ「年1回の診断」ではもう守れないのか
これら3つの事例に共通するのは、「一度安全に作ったはずの環境が、運用を続けるうちに突然危険になる」という構造だ。LiteLLMの被害は40分という公開ウィンドウの中で発生し、Ubuntu AF_UNIX脆弱性は修正パッチが提供されないまま実証コードだけが先に出回った。年1回の脆弱性診断というサイクルでは、こうした時間軸の攻撃にはどうしても後手に回ってしまう。
さらに、コンテナランタイムそのものの脆弱性も継続的に報告されている。たとえばTenableが報告したcontainerdの脆弱性(CVE-2026-47262)は、悪意あるイメージの作成時にメモリを枯渇させ、containerdプロセスそのものを停止に追い込む可能性があるというものだ。Dockerやkubernetesのクライアント側まで影響が及びうる。
こうした「気づいた時にはもう遅い」という構造に対しては、年次の脆弱性スキャンだけでなく、日次での脆弱性スキャンとAIによる修正支援を組み合わせる体制が必要になる。Hexabaseが提供するAI-SecBoxは、まさにこの課題に対応するサービスだ。6種のスキャナーによる毎日の検査に加え、AIが修正案を自動生成して承認待ちの状態まで進めてくれるため、専任のセキュリティ担当者を置けない体制でも「守り続ける」運用が現実的になる。
今日からできる構造的防御チェックリスト
デプロイ後を狙う攻撃に対して、構造的に効く防御策は決して複雑なものではない。実務で優先度が高いものから整理する。
- ノードOSの更新頻度を上げる:週単位・日単位での更新サイクルに見直す。年1回のパッチ適用では、Copy FailのようなCVSS 7.8級の脆弱性が公開されてから実際に塞がるまでの期間が長くなりすぎる
- Seccompプロファイルでシステムコールを制限する: Kubernetes公式ドキュメントが示す通り、コンテナが発行できるシステムコールをあらかじめ制限しておけば、AF_UNIX脆弱性のような手法で想定外のソケット操作が行われても検知・拒否しやすくなる
- 依存関係やCI/CDアクションをハッシュでピン留めする: LiteLLM攻撃のように、バージョン指定だけでは悪意あるリリースを無条件に取り込んでしまう。GitLabが提供する継続的コンテナスキャンのように、新しいパイプライン実行を待たずに既存イメージの脆弱性情報を照合し続ける仕組みも有効だ
- OIDCによる短期クレデンシャルへ移行する: GitHub Actions公式ドキュメントが解説する通り、長期間有効なクラウド認証情報をシークレットとして保持する代わりに、ジョブ単位で失効する短命トークンに置き換えることで、認証情報の窃取リスクそのものを縮小できる
- Secret・ConfigMapを定期的にスキャンする: Google Cloudが提唱するソフトウェアサプライチェーン保護の考え方とも一致するが、完璧な防御を一度に目指すのではなく、小さな対策を積み重ねて継続することが現実的な出発点になる
これらの対策はいずれも「一度やって終わり」ではなく、継続的な運用そのものが価値を持つ。AI-SecBoxが8工程の検証フロー(検出→正規化→トリアージ→修正→レビュー→検証→適用・リリース→再検査)でこの運用をAIに任せられるようにしているのも、同じ発想に基づいている。さらに、修正AIと別のAIが結果を確認し合う二重チェック体制を組み込むことで、人手を増やさずに変更管理と職務分離を両立させている。
修正方針の検討や設計情報のレビューをAIに相談したい場面でも、ソースコードを外部のクラウドAIに送信することに抵抗を感じる現場は多い。そうした場合に備え、ローカルLLMはオンプレミスで完結する構成を提供しており、完全クローズドな環境でコード・設計情報を外に出さずにAI駆動開発を進められる。
まとめ:「作って終わり」から「守り続ける」へ
2026年に相次いだCopy Fail、Ubuntu AF_UNIX脆弱性、LiteLLMサプライチェーン攻撃は、いずれも「デプロイした瞬間が一番安全で、あとは時間とともにリスクが積み上がっていく」という構造を浮き彫りにした。Kubernetesのセキュリティを一度の設計・診断で完結させる発想では、この構造に太刀打ちできない。
ソースコードや脆弱性情報といった機密性の高いデータを外部に出さずに、自社でデータ主権を保ちながら継続的に検査・修正していく——この発想は、特別な大企業だけのものではなくなりつつある。AI-SecBoxのように日次の検査とAI修正を組み合わせる仕組みを整え、修正検討の過程ではローカルLLMで情報を外に出さない体制を併用すれば、専任のセキュリティ担当者がいない組織でも「守り続ける」運用は十分に実現できる。
こうした継続的な防御体制の設計や、AI駆動開発の現場での実践知識を体系的に学びたい方は、AI駆動開発セミナーで要件定義からCI/CDまでの開発ライフサイクル全体を学ぶことができる。自社のKubernetes環境がデプロイ後も安全かどうか不安がある場合は、まずAI-SecBoxの仕組みを確認してみてほしい。