サイトアイコン 協栄情報ブログ

【AWSセキュリティ速報】CVE-2026-98432（Linuxカーネル TCP Use-After-Free）AWS環境で今週やること

Kuroda

どうも、クラ本の黒田です。
火曜日が祝日になるのは、いつぶりでしょうか。

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リスナーは 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 reboot

AL2023でリリースバージョンを固定している環境は 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.conf

Go 1.24以降でビルドしたアプリは、環境変数で無効化できます。

GODEBUG=multipathtcp=0

ECS/EKSならタスク定義・マニフェストの環境変数に入れるだけなので、これは即日やれます。

2. IPオプション付きパケットをiptablesで落とす

# IHL > 5（IPオプションあり）のパケットをINPUTで破棄
sudo iptables -I INPUT 1 -m u32 --u32 '0>>24&0x0f=6:15' -j DROP

注意点が2つ。

正直、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 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を使っていない内部サーバーまで「今夜中に全部再起動」と言うと、事業側から無理が来るので、優先度を分けて説明するのが現実的です。

チェックリスト

最後に、このまま使えるチェックリストを置いておきます。

洗い出し

対応

確認

おわりに

今回の件で改めて思ったのは、「インターネットに何を晒しているか」を即答できる状態にしておく ことの大事さです。脆弱性そのものより、洗い出しに時間を取られる方がよっぽど痛い。

週末に慌てて describe-security-groups を叩くより、普段からタグと命名規則で「公開ポートを持つサーバー」が一発で絞り込める状態にしておく。前回の命名規則の記事で書いたことが、こういうときに効いてきます。

公式速報は11/1時点でも細かく更新が入っているので（RDSパッチ、GameLift AMI、Ubuntu修正などは「予定」のまま）、作業前に必ず原文を確認してください。

協栄情報では、今回のような緊急対応の棚卸しから、再起動計画の策定、Network Firewall導入まで対応しています。「うちの環境、どこから手をつければいいか分からない」という方は、お問い合わせフォームからご相談ください。

本記事は2026年11月3日時点のAWS公式セキュリティ速報（Bulletin 2026-160-AWS、11/1更新版）をもとに作成しています。最新情報は必ず公式速報をご確認ください。

モバイルバージョンを終了