この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
act_pedit（パケット編集アクション）に、深刻な権限昇格の脆弱性が公表されました。CVE番号はCVE-2026-46331。単なるローカル権限昇格（LPE）にとどまらず、コンテナ内の一般ユーザーがホストのrootを奪いうる「コンテナ脱出」につながる点が、この脆弱性を特別に厄介なものにしています。コンテナは「隔離されているから安全」という前提で運用している現場が大半です。CVE-2026-46331は、その前提そのものに穴を開けます。本記事は、サーバー管理者・情シス・コンテナ運用者が「自環境をどう守るか」を判断できるように、脆弱性の仕組みを必要な範囲で概念的に解説し、検知・パッチ適用・緩和の具体策までを整理する防御・パッチ啓発記事です。攻撃コードや悪用の再現手順は一切扱いません。
先に結論を書きます。最優先は修正コミットを含むカーネルへの更新です。即時更新が難しい場合は、
act_peditモジュールの無効化と、コンテナ側のケーパビリティ剥奪という二段構えで露出面を絞ってください。この記事のポイント
・CVE-2026-46331はnet/schedのact_peditの権限昇格脆弱性
・CoWとページキャッシュの範囲計算不備で読取専用ページが書換可能になる
・CAP_NET_ADMINが名前空間内で付与されコンテナ脱出につながる
・最優先は修正コミット適用カーネルへの更新、暫定はact_pedit無効化
・AppArmor/SELinuxとauditd/Falco検知で多層防御を組む
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
CVE-2026-46331とは何か——まず「何ではないか」を押さえる
同時期の別CVEと混同しないこと
2026年のLinuxカーネルは、ローカル権限昇格の公表が立て続けに起きました。「Copy Fail」（CVE-2026-31431）、「Dirty Frag」（CVE-2026-43284 / 43500）、「Fragnesia」（CVE-2026-46300）、ptrace系の「ssh-keysign-pwn」（CVE-2026-46333）。番号が近く通称も似ているため、現場では取り違えが起きがちです。本記事が扱うのはCVE-2026-46331のみで、これらとは別物です。原因も影響経路も異なるため、棚卸し表でも独立した行として管理してください。CVE-2026-46331の舞台は、カーネルのトラフィック制御（tc）を司るnet/schedサブシステム、その中の
act_peditという「パケットを書き換えるアクション」です。ネットワークのパケット編集機能に潜んだ欠陥が、なぜホストのroot奪取やコンテナ脱出につながるのか。この筋道を理解しておくと、自環境が該当するかどうかの判断が正確になります。影響範囲は「2.6～7.1系」と極めて広い
一次情報の表記では、影響範囲はカーネル2.6～7.1系とされています。厳密には、修正コミット899ee91156e57784090c5565e4f31bd7dbffbc5aを取り込んでいないバージョンが該当します。act_peditは古くから存在するアクションで、欠陥が長期間潜伏していたため、影響を受けるカーネルの幅がとても広いのが特徴です。「うちは枯れた安定版だから大丈夫」という直感が通用しない、という点をまず押さえてください。ベンダー検証環境として、RHEL 10.0 / Debian 13 / Ubuntu 24.04.4 が影響対象として挙げられています。最新のエンタープライズ系ディストロがそのまま並んでいる状況です。なお、CVSSの数値は一次情報に記載がありません。本記事では数値を推測で埋めることはせず、スコアは非公表として扱います。危険度は「コンテナ境界を越えうる権限昇格」という性質から実務的に判断してください。
act_peditとnet/schedの基礎
トラフィック制御(tc)とアクションの仕組み
Linuxカーネルは、ネットワークの帯域制御・優先度制御・パケット整形をトラフィック制御（Traffic Control、tc）という枠組みで実現しています。管理者がtcコマンドで設定する、QoSや帯域制限の基盤です。この枠組みでは、パケットに対して「分類（classifier / filter）」を行い、条件に合致したパケットへ「アクション（action）」を適用します。アクションには、パケットを捨てる、別インターフェースへ転送する、統計を取る、といった種類があり、それぞれが
act_*という名前のカーネルモジュールとして実装されています。act_peditはそのうちの一つです。act_peditは「パケットを書き換える」アクション
act_pedit（packet edit）は、その名の通り通過するパケットの中身を書き換えるアクションです。ヘッダの特定バイトを指定した値に置換する、といった編集を行います。ネットワーク機能としては正当で有用なものです。問題は、このアクションが要求する権限にあります。tcのアクションを設定するにはCAP_NET_ADMINというケーパビリティが必要です。従来「ネットワーク管理権限」は特権の一種と見なされてきましたが、後述するユーザー名前空間の普及によって、この前提が現代のコンテナ環境では崩れています。ここがCVE-2026-46331の勘所です。
脆弱性の本質——CoWとページキャッシュの範囲計算
ここからは、防御の判断に必要な範囲で、なぜ危険なのかを概念として説明します。武器化できる手順ではなく、教科書的な内部構造の理解です。鍵になるのはコピーオンライト（CoW）とページキャッシュの関係です。Linuxはメモリを効率的に使うため、同じ内容のメモリページを複数の文脈で共有し、誰かが書き込もうとした瞬間に初めて実体を複製します。これがCoWです。また、ディスク上のファイルの内容は、一度読み込まれるとページキャッシュとしてメモリ上に保持され、多数のプロセスから共有されます。
/usr/bin/suや/etc/passwdのような重要ファイルも、読み込まれればページキャッシュに載ります。CVE-2026-46331の根本原因は、
act_peditがパケットを編集する際の書き換え範囲の計算に不備がある点にあります。CoWとページキャッシュの境界計算が正しく行われず、本来は書き換え不可であるはずの共有ページキャッシュのページが、書き換え可能なものとして扱われてしまう。読み取り専用として共有されているはずのページに、パケット編集の名目で書き込みが通ってしまう、という設計上の欠陥です。2026年に相次いだ他のLPE（Dirty Frag、Fragnesia）も「本来読むだけのページキャッシュを書き換えられる」という同じ帰結を持っていました。CVE-2026-46331は、その帰結にnet/schedのact_peditという別経路から到達するものだと理解すると位置づけが明確になります。詳しい系譜は当サイトのDirty Frag解説記事とFragnesia解説記事も参照してください。
なぜコンテナの分離境界を越えうるのか
CAP_NET_ADMINとユーザー名前空間
CVE-2026-46331が「ただのLPE」で終わらない理由は、CAP_NET_ADMINとユーザー名前空間の組み合わせにあります。先述の通り、
act_peditを含むtcアクションの設定にはCAP_NET_ADMINが要ります。かつてこれは「rootまたはそれに準ずる特権」を意味しました。ところがユーザー名前空間（user namespace）の登場で状況が変わりました。ユーザー名前空間は、名前空間の内側でだけ有効な「見かけ上のroot」を非特権ユーザーに与える仕組みです。コンテナ内では一般ユーザーが、その名前空間の中に限ってCAP_NET_ADMINを含む各種ケーパビリティを持てるようになります。つまり、コンテナ内の一般ユーザーが、名前空間内の権限として
act_peditを設定できてしまう状況が現代では普通に成立します。多くのディストロがデフォルトで非特権ユーザー名前空間を有効にしているため、特別な設定なしに入口が開いているケースが少なくありません。これが「コンテナ脱出」と呼ばれる理由
ユーザー名前空間が隔離するのは「権限の見かけ」までで、カーネル本体は一つです。ホストもコンテナも同じカーネルを共有しています。CVE-2026-46331の欠陥はact_peditというカーネル内の処理に存在するため、名前空間内の権限で到達できてしまうと、影響はカーネルを通じてホスト全体に波及します。ページキャッシュはホストとコンテナで共有される実体ですから、コンテナ内から重要ファイルのページキャッシュへ影響が及べば、コンテナという「箱」の外側、すなわちホストのrootへ手が届きうる、というのが構図です。「コンテナ内の一般ユーザーがホストのrootを奪う」という見出しは、この分離境界の突破を指しています。マルチテナントでコンテナを貸し出している基盤、CI/CDでビルドコンテナに外部由来のコードを走らせる基盤、共用サーバーで顧客ごとにコンテナを割り当てている基盤——こうした環境では、コンテナ一つの侵害がホスト全体の侵害に直結しうる、という前提で対策を組む必要があります。
なお、実証コード（PoC）が公開されたと報じられていますが、本記事ではその内容や使い方には一切触れません。防御に必要なのは「攻撃が現実的である」という事実認識であり、手順ではないからです。
影響ディストリと公表状況
一次情報にもとづく状況を整理します。本番対応の前には、必ず各ディストロの公式アドバイザリで最新状態を再確認してください。| 項目 | 内容 |
|---|---|
| CVE番号 | CVE-2026-46331（net/sched act_pedit 権限昇格） |
| 影響カーネル | 2.6～7.1系（修正コミット899ee91未取込のもの） |
| 検証環境として挙げられたディストロ | RHEL 10.0 / Debian 13 / Ubuntu 24.04.4 |
| Ubuntu 26.04 | AppArmorが追加防御として機能すると報じられている |
| PoC | 実証コードが公開されたと報道（本記事では扱わない） |
| CVSS | 一次情報に記載なし（本記事では非公表として扱う） |
注目すべきは、Ubuntu 26.04ではAppArmorが追加の防御層として機能すると報じられている点です。これは後述する「MACによる多層防御」の有効性を裏づける材料であり、パッチ適用と併せてMACを効かせておく価値を示しています。
Linux管理者の防御策
1. 修正コミット適用済みカーネルへの更新（最優先）
もっとも確実な対策は、修正コミット899ee91156e57784090c5565e4f31bd7dbffbc5aを取り込んだカーネルへ更新することです。各ディストロが提供するセキュリティ更新を適用してください。適用後は、changelogにCVE番号が含まれることを確認してから再起動枠を取りに行くのが筋の良い進め方です。# 現在のカーネルバージョンを確認 uname -r # RHEL / AlmaLinux / Rocky 系：更新して changelog でCVEを確認 sudo dnf clean metadata && sudo dnf upgrade kernel kernel-core rpm -q --changelog kernel | grep -iE "CVE-2026-46331|act_pedit" # Debian / Ubuntu 系：メタパッケージごと更新して changelog を確認 sudo apt update && sudo apt full-upgrade linux-image-generic zcat /usr/share/doc/linux-image-*/changelog.Debian.gz | grep -i "CVE-2026-46331"
2. 即時更新が難しい場合の暫定緩和：act_peditの無効化
すぐに再起動できない、パッチがまだ届かない、という場合の暫定緩和として、act_peditモジュールの読み込みを止める方法があります。tcのpeditアクションを業務で使っていない環境であれば、無効化しても実害が出にくいはずです。まず使用状況を確認してから止めてください。# 現在ロードされているか確認 lsmod | grep act_pedit # tc でpeditアクションを使っていないか確認（何も出なければ未使用の目安） sudo tc filter show dev eth0 2>/dev/null | grep -i pedit # モジュールをロード拒否に設定（peditを使っていないサーバー限定） printf 'install act_pedit /bin/false\n' | sudo tee /etc/modprobe.d/cve-2026-46331.conf sudo modprobe -r act_pedit
3. コンテナ基盤の緩和：非特権コンテナとCAP_NET_ADMIN剥奪
この脆弱性の「コンテナ脱出」性を断つには、入口であるCAP_NET_ADMINと非特権ユーザー名前空間を絞るのが効果的です。現場では、コンテナに必要以上のケーパビリティを付けたまま運用しているケースがよく見られます。棚卸しの機会にしてください。# コンテナ起動時に不要なCAP_NET_ADMINを剥奪する（Docker / Podman） docker run --cap-drop=NET_ADMIN --cap-drop=ALL your-image podman run --cap-drop=NET_ADMIN your-image # 非特権ユーザー名前空間を無効化（コンテナ基盤で不要な場合のみ） echo "user.max_user_namespaces=0" | sudo tee /etc/sysctl.d/99-userns.conf sudo sysctl --system
user.max_user_namespaces=0はコンテナや一部のSnap / Flatpakで必要になる場合があるため、本番投入前に必ずステージングで挙動を確認してください。可能であれば、rootless（非特権）コンテナ運用への移行と、Seccompプロファイルでの危険なシステムコール制限も併せて検討する価値があります。4. AppArmor / SELinux による多層防御
Ubuntu 26.04でAppArmorが追加防御として機能すると報じられている通り、MAC（強制アクセス制御）を有効にしておくことは、この種の脆弱性に対する実効的な保険になります。SELinuxをEnforcingで、AppArmorをenforceモードで動かしておくと、万一の到達時にも被害範囲を絞れる可能性が高まります。# SELinux が Enforcing かを確認（RHEL系） getenforce # AppArmor の状態を確認（Ubuntu / Debian系） sudo aa-status
5. auditd / Falco / eBPF による異常検知
パッチと緩和に加えて、「怪しい兆候を掴む」検知の層を持っておくと、未パッチ期間の安心感が段違いになります。具体的には、非特権ユーザーによるact_pedit関連モジュールのロード、ユーザー名前空間の生成、tcアクション設定の呼び出しといったイベントを監視対象にします。・auditd：モジュールロードやケーパビリティ利用の監査ルールで痕跡を記録する
・Falco：コンテナ内からのunshareや名前空間生成、権限昇格の疑わしい挙動をルール化する
・eBPF：カーネルイベントを低オーバーヘッドで観測し、異常な呼び出しパターンを掴む
これらの実装は、系譜が近いFragnesiaの検知記事「Fragnesia（CVE-2026-46300）をRHEL系で検知する｜auditd・Falco・eBPFで非特権ユーザーの怪しいXFRM呼び出しを掴む」で、auditdルールとFalcoルールの最小構成を実装ベースで整理しています。監視対象をact_pedit・net/sched側に読み替えれば、そのまま流用できる骨格です。あるユーザーは「パッチ適用までの数日、この検知層があったから落ち着いて更新計画を組めた」と話していました。
なお、同じ2026年のptrace系脆弱性CVE-2026-46333への対応はssh-keysign-pwnの解説記事、Copy Failの系譜はCVE-2026-31431解説記事にまとめています。一連のLPEを横断して棚卸しする際の参照にしてください。
今日やることチェックリスト
今日の作業に落とし込めるチェックリストで締めます。・管理対象サーバーの
uname -rを棚卸しし、修正コミット899ee91を含むカーネルか確認する・パッチ提供済みのディストロは
dnf upgrade kernel / apt upgradeで更新し、changelogでCVE-2026-46331を明示確認する・即時更新が難しいサーバーは、peditアクション未使用を確認のうえ
act_peditをロード拒否に設定する・コンテナ基盤は、不要なCAP_NET_ADMINを剥奪し、非特権ユーザー名前空間の要否を見直す
・SELinuxはEnforcing、AppArmorはenforceで動いているかを確認する
・auditd / Falco / eBPFで、非特権ユーザーの怪しいモジュールロードや名前空間生成を検知する層を用意する
・マルチテナント・CI/CD・共用サーバーなど、外部由来コードがコンテナで動く基盤を最優先で対処する
まとめ：コンテナの「隔離されているから安全」を疑う
CVE-2026-46331が突きつけるのは、コンテナの分離は絶対ではないという現実です。カーネルを共有している以上、カーネル内の欠陥は箱の内外を貫通しうる。ユーザー名前空間が非特権ユーザーに与える「見かけのroot」が、CAP_NET_ADMINを通じてact_peditの欠陥に到達し、ページキャッシュ経由でホストのrootへ届きうる——これがコンテナ脱出の筋道でした。打つべき手は明確です。第一に修正コミットを含むカーネルへの更新、第二に暫定緩和としてのact_pedit無効化、第三にコンテナ側のケーパビリティ剥奪、そしてMACと検知による多層防御。この順で組めば、未パッチ期間も含めて露出面を着実に絞れます。影響範囲が2.6～7.1系と広いだけに、「枯れた安定版だから」という思い込みこそが一番の弱点になります。今日、手元のサーバーとコンテナ基盤の棚卸しから始めてください。
参考
・修正コミット：
899ee91156e57784090c5565e4f31bd7dbffbc5a（このコミットを含まないカーネルが影響対象）・関連：当サイトDirty Frag（CVE-2026-43284 / 43500）解説
・関連：当サイトFragnesia（CVE-2026-46300）解説
・関連：当サイトFragnesia検知（auditd・Falco・eBPF）
「コンテナは隔離されているから安全」——その前提、自信を持って説明できますか？
CAP_NET_ADMIN、ユーザー名前空間、ページキャッシュ、MAC、auditd/Falcoでの検知。これらは記事で読むだけでなく、実機で繰り返し手を動かして初めて「守れる知識」になります。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、セキュリティとコンテナ実務を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
＜PR＞手元に置いて学びを深める1冊
コンテナセキュリティ コンテナ化されたアプリケーションを保護する要素技術
まず無料メルマガで学ぶのが第一歩、加えてCAP_NET_ADMINや名前空間の仕組みまで体系的に押さえたいなら、手元に置くならこの1冊です。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：RHEL 10がXorgを削除｜VFX業界も動いたWayland移行の現実と、現役エンジニアのGUI環境対応
- この記事の属するカテゴリ：Linux情報・技術・セキュリティへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます