どうも、クラ本の黒田です。
火曜日が祝日になるのは、いつぶりでしょうか。
10/30（金）の深夜にAWSからセキュリティ速報が出て、週末がだいぶ慌ただしくなった方も多いのではないでしょうか。うちも土曜の朝から「どのインスタンスが対象か」の洗い出しをやっていました。
対象が Linuxカーネル4.4以降 で、攻撃に 認証不要、しかも リモートコード実行（RCE）が研究者によって実証済み。これだけ揃うと「来週でいいか」とはなりません。
この記事では、AWS公式速報（Bulletin ID: 2026-160-AWS、11/1更新版）をもとに、現場で実際に動く順番で整理します。公式速報は随時更新されているので、作業前に必ず原文を確認してください。
📎 公式速報: https://aws.amazon.com/jp/security/security-bulletins/2026-160-aws/
まず、何が起きているのか
CVE-2026-98432 は、LinuxカーネルのIPv4 TCPハンドシェイク処理にあるUse-After-Free（解放済みメモリの参照）の脆弱性です。
攻撃の流れはシンプルで、だからこそ怖い。
攻撃者 ──[IPオプション付きの細工したIPv4 TCPパケット]──▶ 待受ポートを持つLinuxホスト
│
├─ カーネルクラッシュ
├─ カーネルメモリ漏えい
└─ メモリ破壊 → RCE公式速報で押さえておくべき事実を3つ。
| 事実 | 現場での意味 |
|---|---|
| 認証不要・リモートから攻撃可能 | インターネットに晒しているTCPポートがあれば、それだけで条件が揃う |
| MPTCP（Multipath TCP）のリスナーを持つホストに対して、認証なしのRCEが実証済み | MPTCPを使っていなければリスクは下がる。ただし「下がる」であって「ゼロ」ではない |
| AWSは実際の悪用（in the wild）を現時点で確認していない | 今は猶予がある。PoCが出回る前に塞ぐのが勝ち |
「MPTCPなんて使ってないよ」と思った方、Go 1.24以降でビルドしたアプリはデフォルトでMPTCPが有効 になり得ます。公式速報にも GODEBUG=multipathtcp=0 の記載があるので、Go製のサービスを公開している人は要注意です。
対応の優先順位：この順番で動く
全部いっぺんにやろうとすると混乱するので、うちはこの順で進めました。
優先度1：インターネットに直接TCPを晒しているLinux（今日やる）
- NLBのTCPリスナー配下のEC2
- Global Accelerator配下のLinux
- パブリックIPを持ち、SGでインターネットから特定ポートを開けているEC2（踏み台、自前のVPN、ゲームサーバーなど）
- MPTCPを使っているサービス（最優先）
NLBのTCPリスナーは IPオプションごとパケットをターゲットに素通し します。ALBやCloudFrontと違ってAWS側で吸収してくれないので、ターゲットのカーネル更新が必須です。
優先度2：ALB / CloudFront / API Gateway / WAF配下のLinux（30日以内）
これらのサービスは、ベストプラクティスに従っていれば信頼できないソースからのTCP接続を直接受けません。AWS側で基盤に対策を適用中で、即時対応は不要とされています。
ただし公式速報は 「それでも30日以内に配下のインスタンスを更新することを推奨」 と明記しています。「ALBの後ろだから大丈夫」で止まらないこと。VPC内の横展開や、SGの設定ミスで直接到達できるケースは普通にあります。
優先度3：内部向けのLinux（計画的に）
プライベートサブネットにいて外から到達できないサーバーは、通常のメンテナンス窓で更新。ただし、PrivateLinkのエンドポイントサービスやVPC LatticeのL4ターゲットは「社内向け」であってもTCPを受けるので、優先度2相当で扱っています。
AWS環境ごとの対応：公式速報の要点
インフォグラフィックの表を、実際のコマンドや期日まで含めて補足します。
Amazon EC2（Amazon Linux 2 / 2023）
修正済みカーネルは全系統（4.14 / 5.4 / 5.10 / 5.15 / 6.1 / 6.12 / 6.18）で提供済み。
# Amazon Linux 2
sudo yum update kernel && sudo reboot
# Amazon Linux 2023
sudo dnf update kernel --releasever=latest && sudo rebootAL2023でリリースバージョンを固定している環境は 2023.12.20261102 以降に上げないと修正カーネルが降ってきません。 dnf update kernel だけ叩いて「更新なし」と出て安心してしまうパターンがあるので、cat /etc/dnf/vars/releasever か /etc/os-release で固定の有無を確認してください。
対象アドバイザリ: ALAS2-2026-4065、ALAS2KERNEL-5.4-2026-135、ALAS2KERNEL-5.10-2026-137、ALAS2KERNEL-5.15-2026-120、ALAS2023-2026-3365、ALAS2023-2026-3335、ALAS2023-2026-3251
Amazon EC2（Ubuntu / RHEL / Rocky など）
各ディストリビューションの修正カーネルを待って適用・再起動。
注意点として、公式速報のCloud9の項に 「Canonicalはまだ修正カーネルをリリースしていない」（11/1時点）とあります。Ubuntu勢は、ベンダーのアドバイザリを監視しつつ、修正が出るまで後述の暫定緩和策を入れておくのが現実的です。Ubuntuは livepatch が有効なら再起動なしで効く可能性がありますが、速報では「ベンダーが該当livepatchを提供している場合に限る」と条件付きです。
Amazon EKS
| ノード種別 | 対応 |
|---|---|
| マネージドノードグループ / セルフマネージド / Karpenter | EKS最適化AL2023 AMI v20261031 以降にノード更新 |
| Auto Mode | 対応不要。11/6までにグローバル展開完了予定で、NodePoolのdisruption budgetに従って自動入れ替え |
Karpenterを使っている人は、AMIのバージョンを固定していないか（amiSelectorTerms で特定IDを指しているなど）を確認してください。
Amazon ECS
| 種別 | 対応 |
|---|---|
| ECS on EC2 | コンテナインスタンスのカーネル更新＋再起動、または ECS最適化AMI 20261031 で置き換え |
| Fargate | 11/1 9:00 PST（日本時間11/2 2:00）以降に起動したタスク は修正済みプラットフォーム。既存タスクはタスクリタイア設定に従って入れ替わるので、急ぐなら手動で入れ替え |
| ECS Managed Instances | 同時刻以降の新規インスタンスは修正済み。既存は起動から14日で自動ドレイン。急ぐなら手動ドレイン |
Fargateは「AWSが面倒見てくれる」と思いがちですが、既存で動き続けているタスクは古いプラットフォームのままです。長時間動いているサービスタスクは、aws ecs update-service --force-new-deployment で入れ替えるのが早いです。
Bottlerocket
修正済みAMIは11/2から順次提供。最新AMIに更新。
AWS Lambda
影響対象外。Lambdaは公開IPv4 TCPポートを持たないため、攻撃パケットを送り込む経路がありません。AWS側では多層防御として基盤にパッチ適用中。
RDS / Aurora / Neptune / Redshift
| サービス | 対応 |
|---|---|
| RDS / Aurora | DBポートをインターネットに公開していないことを確認。AWS側で緩和策を展開中。DB OSパッチは11/3（本日）提供予定 |
| Neptune | DBポートをインターネットに公開していないことを確認 |
| Redshift | AWS側で緩和策を展開中。クラスターOSパッチは11/2提供 |
RDSで「パブリックアクセス可能: はい」になっているインスタンス、ありませんか。開発環境で手軽に繋ぎたくて有効にしたまま忘れているやつ。今回を機に棚卸ししてください。
その他
| サービス | 対応 |
|---|---|
| Lightsail | EC2と同じ。自分でカーネル更新＋再起動 |
| PrivateLink配下のLinuxターゲット | カーネル更新＋再起動、または暫定緩和策 |
| VPC Lattice のL4（TCP）Linuxターゲット | 同上 |
| Storage Gateway | 11/3から更新提供予定 |
| Cloud9 | 自動更新は入るが、再起動しないと新カーネルが有効にならない |
| GameLift | マネージドフリートは フリート再作成が必要（既存フリートはAMI固定のため）。修正AMIは11/4までに全リージョン提供予定。それまで新規フリート作成は待つこと |
| WorkSpaces | Windowsは影響なし。Linux WorkSpacesはベンダー修正を待って更新＋再起動。デフォルトSGではインバウンドなしなので、SSHなどを開けていなければ露出は低い |
| DMS | 外部からの到達経路なし。多層防御としてAWSが週次メンテ窓で適用。急ぐなら apply-pending-maintenance-action --apply-action os-patch |
すぐに更新できないとき：暫定緩和策
再起動の調整に時間がかかる、Ubuntuの修正がまだ出ていない、という場合の時間稼ぎです。公式速報も「これは完全な修正の代替ではない」と繰り返し書いています。 あくまでカーネル更新までの繋ぎ。
1. MPTCPを無効化する
# 即時反映
sudo sysctl -w net.mptcp.enabled=0
# 永続化
echo "net.mptcp.enabled = 0" | sudo tee /etc/sysctl.d/99-cve-2026-98432.confGo 1.24以降でビルドしたアプリは、環境変数で無効化できます。
GODEBUG=multipathtcp=0ECS/EKSならタスク定義・マニフェストの環境変数に入れるだけなので、これは即日やれます。
2. IPオプション付きパケットをiptablesで落とす
# IHL > 5（IPオプションあり）のパケットをINPUTで破棄
sudo iptables -I INPUT 1 -m u32 --u32 '0>>24&0x0f=6:15' -j DROP注意点が2つ。
- 再起動すると消えます。
iptables-saveなりディストリビューションのツールで永続化すること - Amazon Linux 2023にはiptablesがデフォルトで入っていません。
sudo dnf install iptables-nftなどで入れる必要があります
正直、IPオプション付きのパケットを正規の用途で使っている環境はほぼ無いので、このルールで業務影響が出ることは稀です。ただし「ほぼ」なので、入れる前に自分の環境でIPオプションを使うプロトコル（一部の経路制御やレガシーな監視ツール）が無いかだけは確認を。
3. AWS Network Firewallで落とす
Network Firewallを挟んでいる環境なら、ステートフルルールで一括対処できます。
drop ip any any -> any any (msg:"CVE-2026-98432: drop IPv4 packets carrying IP options (IHL > 5)"; ipv4.hdr; bsize:>20; classtype:bad-unknown; sid:1000001; rev:2;)条件があります。
- ファイアウォールポリシーが strict rule order であること
- このルールグループの優先度番号を、allowルールグループより小さくすること
- ステートレスルールで通したトラフィックはこのルールを通らない
デフォルトオーダーで運用している場合、strict orderへの切り替えは全ルールの評価順が変わるので既存接続が切れる可能性があります。 本番でいきなりやらず、検証環境で試してから。SIDは既存と被らない番号に。
洗い出しのやり方：うちで使ったコマンド
「対象ホストの洗い出し」が一番時間を食います。使ったものを置いておきます。
インターネットから到達可能なTCPポートを持つEC2
# 0.0.0.0/0 からのTCPインバウンドを許可しているSGを列挙
aws ec2 describe-security-groups \
--query 'SecurityGroups[?IpPermissions[?IpProtocol==`tcp` && contains(IpRanges[].CidrIp, `0.0.0.0/0`)]].[GroupId,GroupName]' \
--output tableこれで出たSGがアタッチされているインスタンスが優先度1の候補です。NLBのターゲットグループ配下も忘れずに。
各インスタンスのカーネルバージョンとMPTCP状態
SSM Run Commandで一括取得すると楽です。
uname -r
sysctl net.mptcp.enabled 2>/dev/null || echo "mptcp: not available"
ss -tlnp | grep -i mptcp || echo "no mptcp listener"Amazon Linuxで修正済みか確認
# AL2
yum updateinfo list cves | grep CVE-2026-98432
# AL2023
dnf updateinfo list cves | grep CVE-2026-98432再起動後の確認
# 起動中のカーネルが更新後のものか
uname -r
# 更新したのに再起動していない（＝まだ脆弱）インスタンスの検出に使える
needs-restarting -r # AL2 (yum-utils)
dnf needs-restarting -r # AL2023「yum update kernel は叩いたけど再起動してない」が一番多い抜け漏れです。カーネル更新は再起動して初めて有効。ここだけは念押しします。
再起動計画で揉めないために
技術的には yum update && reboot で終わる話ですが、現場で時間がかかるのは再起動の調整です。
| 構成 | 進め方 |
|---|---|
| Auto Scaling配下 | 修正済みAMIを作ってLaunch Templateを更新 → インスタンスリフレッシュ。無停止でいける |
| ALB/NLB配下で複数台 | ターゲットから1台ずつデタッチ → 更新・再起動 → ヘルスチェック通過後にアタッチ |
| シングル構成 | メンテナンス窓を取るしかない。「RCE実証済み」を説明材料にして、通常より短い調整期間で押し切る |
| ステートフル（DB等） | リードレプリカ／スタンバイから先に。RDSはAWSの緩和策が入っているので、11/3以降のOSパッチをメンテ窓で |
お客様への説明は、「MPTCPのリスナーを公開している場合、認証なしでRCEが実証されている」の一文で大抵通ります。逆に、MPTCPを使っていない内部サーバーまで「今夜中に全部再起動」と言うと、事業側から無理が来るので、優先度を分けて説明するのが現実的です。
チェックリスト
最後に、このまま使えるチェックリストを置いておきます。
洗い出し
- [ ] Linuxカーネルを自社管理しているホストの一覧（EC2 / ECS on EC2 / EKSノード / Lightsail / WorkSpaces Linux / Cloud9）
- [ ] インターネットから到達可能なIPv4 TCP待受ポートの一覧（SG・NLB・Global Accelerator）
- [ ] MPTCPを使っているサービスの有無（
sysctl net.mptcp.enabled、Go 1.24+ アプリ） - [ ] RDS / Neptune / Redshift のパブリックアクセス設定
- [ ] PrivateLink / VPC Lattice のLinuxターゲット
対応
- [ ] 優先度1（公開TCP・MPTCP）：カーネル更新＋再起動、今日
- [ ] 優先度2（ALB等の配下）：30日以内
- [ ] 優先度3（内部）：次回メンテ窓
- [ ] 更新できないホストに暫定緩和策（MPTCP無効化 / iptables / Network Firewall）
- [ ] EKS：AMI v20261031以降、Auto Modeは放置でOK
- [ ] ECS Fargate：長期稼働タスクの強制入れ替え
- [ ] AL2023：releasever固定の確認
確認
- [ ] 再起動後の
uname -rで新カーネルを確認 - [ ]
needs-restarting -rで再起動漏れを検出 - [ ] 公式速報の更新確認（Ubuntu修正、GameLift AMI、RDSパッチの提供状況）
おわりに
今回の件で改めて思ったのは、「インターネットに何を晒しているか」を即答できる状態にしておく ことの大事さです。脆弱性そのものより、洗い出しに時間を取られる方がよっぽど痛い。
週末に慌てて describe-security-groups を叩くより、普段からタグと命名規則で「公開ポートを持つサーバー」が一発で絞り込める状態にしておく。前回の命名規則の記事で書いたことが、こういうときに効いてきます。
公式速報は11/1時点でも細かく更新が入っているので（RDSパッチ、GameLift AMI、Ubuntu修正などは「予定」のまま）、作業前に必ず原文を確認してください。
協栄情報では、今回のような緊急対応の棚卸しから、再起動計画の策定、Network Firewall導入まで対応しています。「うちの環境、どこから手をつければいいか分からない」という方は、お問い合わせフォームからご相談ください。
本記事は2026年11月3日時点のAWS公式セキュリティ速報（Bulletin 2026-160-AWS、11/1更新版）をもとに作成しています。最新情報は必ず公式速報をご確認ください。