ラボまとめコラムニュース
ブログ/記事一覧/Linuxのコンテナ脱出脆弱性CVE-2022-0492が悪用中、CISAが修正を指示
linux-cgroups-cve-2022-0492-container-escape-kev-cover-ja

Linuxのコンテナ脱出脆弱性CVE-2022-0492が悪用中、CISAが修正を指示

Linuxのcgroups v1にあるCVE-2022-0492が実際の攻撃に悪用され、CISAがKEVに追加。release_agentの権限確認欠落でコンテナから脱出・権限昇格が可能です。悪用には特権コンテナ等の条件が必要。カーネル5.17以降への更新と堅牢化を整理します。

ニュース 本日更新
avatar-m-1

堀川 慎

Backend Engineer / AWS / Django / Go

2026.06.038 min0 views
この記事のポイント

Linuxのcgroups v1にあるCVE-2022-0492が実際の攻撃に悪用され、CISAがKEVに追加。release_agentの権限確認欠落でコンテナから脱出・権限昇格が可能です。悪用には特権コンテナ等の条件が必要。カーネル5.17以降への更新と堅牢化を整理します。

Linuxの基幹部分にある古い欠陥が、いま実際の攻撃に使われ始めています。CVE-2022-0492は、コンテナ(アプリを箱に詰めて動かす仕組み)の箱の中から外のサーバー本体へ抜け出せてしまう恐れのある欠陥で、2022年に修正されたものです。米国のCISA(サイバーセキュリティ・社会基盤安全保障庁)は、この脆弱性を「実際に悪用が確認された脆弱性リスト(KEV)」に追加し、政府機関へ期限内の対処を義務づけました。古い欠陥でも、更新されていないサーバーが残っていれば狙われる、という典型でございます。

問題の場所は、Linuxの「cgroups(コントロールグループ)」という、コンテナの土台になっている機能です。ただし、どんなコンテナでも一発で抜け出せるわけではありません。悪用にはいくつかの条件がそろう必要があり、標準的な安全設定がされていれば防げます。本記事では、何が起きるのか、どんな環境が危ないのか、いま何をすべきかを順番に整理します。

欠陥の概要

まず要点を一覧にします。注目すべきは、危険度の数字(CVSS 7.8)より、実際に悪用が確認されてKEV入りしたという事実です。スコアは最高ランクではありませんが、攻撃者が現に使っている以上、対処の優先度は跳ね上がります。

項目内容
整理番号CVE-2022-0492
対象Linuxカーネル
(cgroups v1)5.17より前
何が起きるか権限昇格/
コンテナからの脱出
欠陥の種類権限確認の欠落
(CWE-862)
深刻度CVSS 7.8(高)
AV:L/PR:L
悪用状況悪用確認済み
(CISA KEV登録)
脱出の前提特権コンテナや
安全設定の欠如
対策修正カーネルへ更新
+コンテナの堅牢化

CVSSが7.8にとどまるのは、攻撃にサーバーへのローカルなアクセス(AV:L)が前提だからです。ネット越しに一方的に踏まれるタイプではありません。しかし実際の攻撃では、Webアプリの別の欠陥などでまずコンテナの中に入り込み、そこからこの脆弱性で本体(ホスト)へ抜け出すという連鎖が起こります。KEV入りは、まさにその連鎖が現実に使われていることを意味します。

箱の中の侵入者が、サーバー本体の管理者になる時

怖いのは、攻撃者がたどり着く先が一つのコンテナの中ではなく、それを動かすサーバー本体(ホスト)の管理者権限だからです。ここに値を付けるのは、Webアプリの穴から侵入してコンテナに潜む攻撃者、クラウド基盤を暗号化して身代金を迫るランサムウェア集団、他人のサーバーで仮想通貨を掘るクリプトジャッキング業者です。手にするのは、同じサーバーで動く他社のコンテナの中身、クラウドの接続情報、データベースの資格情報です。コンテナの中からこの脆弱性で抜け出された瞬間、箱ごとに分けていたはずの壁が崩れ、サーバー全体が攻撃者の手に渡ります。

抜け出した先は一段では止まりません。ホストの管理者権限を握れば、攻撃者は同居する全コンテナを覗き、クラウドの認証情報で隣のサーバーや本番環境へ広げます。奪った認証情報はダークウェブで転売され、買い手はそれを足がかりに基盤全体を暗号化して業務を止め、抜いたデータの公開をちらつかせる二重恐喝に持ち込みます。共有基盤なら被害は一社では収まらず、相乗りする各社へ連鎖します。

後始末を背負うのは、基盤を運用するインフラ部門と、構築を請け負った事業者、そして経営です。顧客データが漏れれば、個人情報保護委員会への報告と本人通知の義務が生じ、損害賠償や信用の失墜も残ります。CVSS 7.8という数字に表れないのは、「悪用が確認された」という重みです。理論上の危険ではなく現に使われている手口だからこそ、古い未更新のサーバーが残っていないかを早く確かめられるかが、運用者の安全を分けます。

そもそもcgroupsとコンテナ脱出とは何か

「コンテナ」は、アプリを必要な部品ごと小さな箱に詰めて動かす技術で、DockerやKubernetes、OpenShiftなどで広く使われています。一つのサーバーの上で複数の箱を隔てて動かせるのが利点で、いまのクラウドの土台になっています。その箱を成り立たせている機能の一つが、Linuxのcgroups(コントロールグループ)です。cgroupsは、各コンテナが使えるCPUやメモリの量を区切って管理する仕組みでございます。

「コンテナ脱出」とは、本来は箱の中に閉じ込められているはずのプログラムが、箱の壁を越えてサーバー本体を操作できてしまう状態を指します。箱ごとに分けて安全を保つのがコンテナの前提なので、脱出されると、その前提が根本から崩れます。同じサーバーに相乗りしている他のコンテナも、まとめて危険にさらされるのです。

今回の欠陥が起きたのは、cgroupsのrelease_agentという機能です。これは「このグループの処理が終わったら、指定したプログラムを実行する」という後始末の仕組みですが、本来は管理者だけが設定できるべきものでした。ところがLinuxは、それを設定する人が管理者権限(CAP_SYS_ADMIN)を持っているかの確認を欠いていました。セキュリティ企業Unit 42の解説によれば、修正はわずか8行の権限チェック追加で済むものでした。

CVE-2022-0492の中身:権限確認の欠落と、脱出に必要な条件

NVD(米国の脆弱性データベース)によると、欠陥はcgroups v1の cgroup_release_agent_write 関数にあり、権限のない利用者がrelease_agentを悪用して権限を昇格し、隔離の壁を越えられるものです(CWE-862・権限確認の欠落)。攻撃者は、コンテナ内で新しい名前空間を作って管理者権限を得て、書き込み可能なcgroupファイルシステムをマウントし、悪意あるrelease_agentを仕込んで実行させる、という流れで脱出します。

ただし、誤解してはいけないのは脱出には複数の条件がそろう必要がある点です。Unit 42は、コンテナ脱出が成立する主な条件として、(1) コンテナがroot権限などで動いている、(2) AppArmorやSELinuxによる保護がない、(3) Seccompが無効、(4) ホストで未特権の名前空間が有効、(5) コンテナがv1 cgroupで動いている、を挙げています。逆に言えば、AppArmor・SELinux・Seccompのいずれかが効いていれば、脱出は防げます。多くのコンテナ環境は標準でこうした保護を備えているため、初期設定のまま使っていれば守られている可能性が高いです。

危ないのは、保護を外して動かしている特権コンテナや、安全設定を省いた古い・寛容な構成です。対象はLinuxカーネルの5.17より前で、修正は5.17および各安定版(4.9.301/4.14.266/4.19.229/5.4.177/5.10.97/5.15.20/5.16.6など)で2022年に提供済みです。つまり、きちんと更新を続けている環境はとうに直っており、危ないのは更新が止まったまま残っているサーバーでございます。

悪用は確認されているのか

現時点で分かっていることと、まだ確認できていないことを分けて整理します。

✓ 確認済みの事実

  • CISAが本脆弱性を悪用が確認された脆弱性リスト(KEV)に追加し、期限内の対処を義務づけた
  • cgroups v1のrelease_agentで権限確認が欠落し、権限昇格・コンテナ脱出が可能(NVD
  • 修正はカーネル5.17および各安定版で2022年に提供済み。AppArmor/SELinux/Seccompが有効なら脱出は防げる(Unit 42

? 現時点で未確認のこと

  • ?具体的な攻撃者や被害の規模 ― KEV登録は悪用の事実を示すが、誰がどこを攻撃したかの詳細は公開されていない
  • ?KEVの正確な是正期限 ― 連邦機関向けの期限はCISAのカタログで各自確認が必要

自社の環境が危ないかの早見表

同じLinuxでも、カーネルの更新状況とコンテナの設定でリスクが変わります。下の表で自社の状況を当てはめてください。

環境リスク優先度いま取るべき行動
5.17より前のカーネル+
特権・無防備な
コンテナ
ホスト乗っ取りの
恐れ
最優先
(即時)
カーネル更新+
保護機能の有効化
古いカーネルだが
標準の保護あり
脱出は
防げる
早めにカーネルを
修正版へ更新
更新済みカーネル
(5.17/安定版以降)
本件の
影響なし
通常更新の継続を
確認

最も危ないのは、更新が止まった古いサーバーで、保護を外した特権コンテナを動かしている環境です。クラウドのマネージドなコンテナ基盤を使っている場合は、基盤側で更新されていることが多いですが、自社で管理するノードやオンプレミスの環境は、カーネルのバージョンを自分で点検する必要があります。

インフラ運用者がいま確認すべきこと

最優先は、コンテナを動かしているサーバーのカーネルが、5.17または各ディストリビューションの修正版以降になっているかの確認です。2022年の修正のため、更新を続けていれば直っているはずですが、長く再起動・更新していない古いノードが残っていないかを点検してください。クラウドのイメージやベースイメージが古いまま使い回されているケースも要注意です。

あわせて、コンテナを動かす際の基本の堅牢化を徹底しましょう。具体的には、不要な特権を与えない(特権コンテナを避ける)、AppArmorかSELinuxを有効にする、Seccompを使うことです。これらのいずれかが効いていれば、この脆弱性による脱出は防げます。実際に悪用が確認された脆弱性をまとめて追いたい場合は、CISA KEVの日本語ダッシュボードや、国内向けの2026年上半期の重大な脆弱性まとめもあわせて確認してください。

同じLinuxの基幹部分では、近ごろ権限昇格の欠陥が相次いでいます。クラウド環境でroot権限を奪えるCopy Fail(CVE-2026-31431)もその一つで、土台のカーネルを最新に保つことの重みが増しています。

よくある質問

Q. 2022年の古い脆弱性が、なぜ今あらためて問題なのですか?

A. CISAが「実際に悪用が確認された」としてKEVに追加したためです。修正は2022年に出ていますが、更新が止まったまま残っている古いサーバーが攻撃の標的になっています。古い脆弱性でも、未更新の環境がある限り危険は続きます。

Q. うちのコンテナも、開いただけで乗っ取られますか?

A. いいえ。脱出には複数の条件(特権で動いている、AppArmor/SELinux/Seccompが無効など)がそろう必要があります。標準的な保護が効いていれば、この脆弱性での脱出は防げます。まず自社のコンテナがこれらの保護を使っているかを確認してください。

Q. どのバージョンに更新すればよいですか?

A. Linuxカーネル5.17以降、または各ディストリビューションが提供する修正版(4.9.301/4.14.266/4.19.229/5.4.177/5.10.97/5.15.20/5.16.6など以降)です。利用中のディストリビューションの案内に従って更新してください。

Q. すぐにカーネルを更新できません。暫定策はありますか?

A. コンテナの堅牢化が有効です。特権コンテナをやめ、AppArmorかSELinux、そしてSeccompを有効にしてください。これらのいずれかが効いていれば脱出を防げます。ただし根本対策はカーネルの更新であり、暫定策はあくまで時間稼ぎと考えてください。

まとめ

CVE-2022-0492は、Linuxのcgroups v1にある権限確認の欠落で、コンテナの中からサーバー本体へ抜け出せる恐れのある欠陥です。2022年に修正済みですが、CISAが「実際に悪用が確認された脆弱性」としてKEVに追加し、対処を義務づけました。CVSSは7.8で、悪用には複数の条件がそろう必要があり、AppArmor・SELinux・Seccompといった標準の保護が効いていれば脱出は防げます。危ないのは、更新が止まった古いサーバーで、保護を外した特権コンテナを動かしている環境です。対策は、カーネルを修正版へ更新すること、そして特権を絞り保護機能を有効にすること。古い脆弱性でも、未更新の環境が残っていれば狙われるという、KEVらしい一件でございます。

参照元