CISAは2026年9月18日、Linuxカーネルの脆弱性2件を KEV(悪用が確認された脆弱性のカタログ)へ追加しました。 対象は CVE-2025-39964(AF_ALGソケットの競合状態)と CVE-2026-53266(ebtables SNATターゲットの境界外書き込み)です。
どちらも修正自体はとっくに出ています。今回のニュースは「新しい穴が見つかった」ではなく、「前から直っていた穴が、実際に攻撃で使われていると確認された」ほうです。
やることは2つです。ディストリビューションのカーネルを更新して再起動すること、そして自分の版に修正パッケージが本当に出ているかを確認することです。後者を飛ばすと、更新したのに直っていない状態を「対処済み」と誤解します。
今すぐ行う対策
- ✓まず自分の版が修正済みかを確認する。 下のリンクにあるディストリビューションのトラッカーで、使っている版とカーネル種別(generic/aws/azure など)の行を見ます。`Fixed` なら更新で閉じます。`Vulnerable` や `work in progress` なら、まだ修正パッケージ自体が出ていません。
- ✓再起動する。 ここが要点です。カーネルは更新しただけでは切り替わりません。再起動するまで、動いているのは古いカーネルのままです。
- ✓再起動できたか確認する。 `uname -r` で現在動いているカーネルを表示し、更新後のパッケージ版と一致しているかを見ます。Debian/Ubuntu 系なら `ls /boot/vmlinuz-*` と見比べると、新しいカーネルが入っているのに古いまま動いている状態に気づけます。
- ✓再起動が必要かを機械的に見る。 Debian/Ubuntu 系は `/var/run/reboot-required` というファイルの有無で判定できます。RHEL 系の `needs-restarting -r` は標準では入っておらず、Red Hatの文書では `yum-utils` パッケージが提供元とされています。先に導入してください。
- ✓すぐ再起動できないサーバーは、ライブパッチの提供有無を契約先で確認する。 提供がある場合でも、適用対象にこの2件が含まれるかはベンダーの告知で確認してください。
- ✓サポートが終了したカーネルを使っていないか確認する。 CISAはCVE-2026-53266について、影響を受ける製品がEoL/EoSの可能性があり、その場合は使用の停止かサポート対象版への移行を推奨すると明記しています。
★更新しても直らない場合がある(執筆時点の状況)
「apt upgrade して再起動したから対処済み」とは限りません。修正パッケージがまだ配布されていなければ、更新しても古いままです。
2026年9月18日時点で、Ubuntu のセキュリティトラッカーは CVE-2026-53266 について、主要なLTSのカーネルを未修正として扱っています。主要パッケージ `linux` の行を見ると、24.04 LTS(noble)と 22.04 LTS(jammy)が「Vulnerable, work in progress」、20.04 LTS(focal)が「Vulnerable」です。26.04(resolute)は `7.0.0-31.31` で修正済み、18.04(bionic)以前は「Not affected」とされています。
ここで挙げたのは `linux` パッケージの状態です。`linux-aws` や `linux-azure` などの種別ごとに状態は異なるので、必ず自分が使っている種別の行を見てください。
この状態の環境では、更新と再起動をしても、この1件は開いたままです。
修正待ちの間にできることは限られています。本記事では、公式が示していない回避策は書きません。カーネルの設定変更やモジュールの無効化を独自に案内すると、別の障害を生みます。
代わりに確認できるのは次の点です。どちらの脆弱性も攻撃元区分はローカルなので、その前提を満たす経路を減らすことが実質的な緩和になります。
- ✓信頼できない相手がコードを実行できる経路を洗い出す。 共有サーバーの一般ユーザー、外部から受け入れているコンテナ、CIのビルド実行環境などが該当します。
- ✓ディストリビューションのトラッカーを定期的に見直す。 `work in progress` は「対応中」という意味なので、日を置くと `Fixed` に変わります。その時点で改めて更新と再起動を行ってください。
- ✓契約しているライブパッチの対象に入るかをベンダーへ確認する。 入る場合は再起動なしで閉じられることがあります。
- ✓サポートが終了した版を使っている場合は、修正が来ない前提で移行を検討する。 CISAもEoL/EoSの可能性に触れ、サポート対象版への移行を推奨しています。
★同じCVEに 3.3 と 7.8 が並んでいる
このスコアの出所を明示します。 CVE-2025-39964 には、NVD上に2つの異なるCVSS v3.1評価が載っています。
・NIST(Primary): 3.3 LOW — `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L`
・kernel.org(CNA・Secondary): 7.8 HIGH — `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`
本記事の `cve_box` にはNISTの3.3を載せています。NVDにおける一次評価だからです。ただし「3.3 LOWだから後回しでよい」という読み方は成り立ちません。
差は影響の見立てにあります。NISTは影響を「可用性にわずか(A:L)、機密性と完全性への影響は無し」と評価し、kernel.org は「機密性・完全性・可用性すべてに高い影響」と評価しています。同じ不具合について、片方は「せいぜい不安定になる程度」、もう片方は「乗っ取りうる」と見ているということです。
そしてCISAは、この脆弱性を実際に悪用が確認されたものとしてKEVへ登録しました。深刻度の数字は「もし悪用されたらどれだけ悪いか」の見積もりであって、「いま悪用されているか」はまったく別の情報です。今回はその別の情報のほうが先に確定しています。
CVE-2026-53266 のほうは評価が割れていません。NVDに載っているCVSSは kernel.org(CNA)の 8.8 HIGH だけで、NISTによる一次評価は入っていません。ベクタは `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H` で、スコープが変更(S:C)、つまり影響が本来の権限範囲を越えうると評価されています。
何が起きるのか
CVE-2025-39964(AF_ALG の競合状態・CWE-362)
AF_ALG は、カーネルの暗号機能をソケット経由で使うための仕組みです。同じソケットに対して2つの書き込みを同時に行うと、データが予測できない順序で混ざり、ソケット内部の状態に不整合が生じます。修正は「書き込みの排他所有を示すフラグを追加して、同時書き込みを禁止する」という内容です。
CVE-2026-53266(ebtables SNAT の境界外書き込み・CWE-787)
ebtables はブリッジ用のパケットフィルタです。SNATターゲットにはARPの送信元ハードウェアアドレスを書き換えるオプションがあり、この書き換えが書き込み可能性を確認しないまま行われていました。CISAのKEVカタログの説明文では、splice で取り込まれたファイルページに裏打ちされた非線形なソケットバッファの断片へ、直接書き込んでしまうとされています。
両方とも攻撃元区分は `AV:L`、つまりローカルです。インターネット越しに、何もしていないサーバーがいきなり乗っ取られる種類のものではありません。
ただし安全という意味ではありません。一般ユーザーが実行できる環境——共有サーバー、コンテナや仮想化のホスト、複数人がログインする開発機——では、ローカルであることが前提として満たされています。また、別の脆弱性やフィッシングで最初の足がかりを取られた後、そこから権限を広げる段として使われるのがこの種の脆弱性の典型です。
ただしKEV入りが示すのは「実際の攻撃で悪用されたこと」までです。攻撃者が何を狙い、どこまで権限を取れたのかといった中身は、KEVの登録だけからは分かりません。公開情報で確定しているのは「使われた」という事実である、と受け取ってください。
修正版:2件は別物なので両方を満たす版が要る
NVDに登録されている、上流(kernel.org)の安定版系列ごとの修正版は次のとおりです。同じ系列でもCVE-2026-53266のほうが新しい版で直っているため、片方だけ満たした版では不十分です。
- ▸5.10 系:CVE-2025-39964 は 5.10.245、CVE-2026-53266 は 5.10.259
- ▸5.15 系:同 5.15.194 と 5.15.210
- ▸6.1 系:同 6.1.154 と 6.1.176
- ▸6.6 系:同 6.6.108 と 6.6.143
- ▸6.12 系:同 6.12.49 と 6.12.94
- ▸6.16 / 6.18 / 7.0 系:CVE-2025-39964 は 6.16.9、CVE-2026-53266 は 6.18.36 および 7.0.13
★ここで多くの人がつまずきます。`uname -r` の数字を、この一覧と直接見比べても判定できません。
主要なディストリビューションは、古い系列のカーネルに修正だけを取り込む(バックポートする)運用をしています。たとえば Ubuntu の `5.15.0-xxx` や RHEL の `4.18.0-xxx` は、上流の 5.15.210 や 4.18 の最新版とは番号が一致しません。それでも修正は入っていることがあります。
判定は、上流の版番号ではなく、使っているディストリビューションの情報で行ってください。下のリンクにある Ubuntu・Debian・Red Hat のセキュリティトラッカーは、CVE単位で「自分の版が対処済みか」を示してくれます。
期限は2026年9月21日
CISAはKEV登録にあたり、対処期限を2026年9月21日としています。これは米国の連邦政府機関に対する指示であって、日本の一般利用者に法的な義務が生じるものではありません。
ただし期限の短さは、CISAがこの2件をどう見ているかの表れです。追加が9月18日で期限が9月21日、つまり3日です。社内でカーネル更新の予定を立てるときの温度感として、この数字は使えます。
- CISA:Known Exploited Vulnerabilities Catalog(2026年9月18日に2件を追加・期限2026年9月21日)↗
- NVD:CVE-2025-39964(NIST 3.3 LOW と kernel.org 7.8 HIGH の両方が掲載)↗
- NVD:CVE-2026-53266(kernel.org 8.8 HIGH)↗
- Ubuntu セキュリティ:CVE-2025-39964(自分の版が対処済みかの確認用)↗
- Ubuntu セキュリティ:CVE-2026-53266↗
- Debian セキュリティトラッカー:CVE-2026-53266↗
- Red Hat:CVE-2025-39964↗
- kernel.org:安定版リリース一覧(上流の系列ごとの最新版)↗
