1. CVE-2026-98432とは何か、まず結論から
CVE-2026-98432は、Linuxの中心部分であるカーネルの、IPv4のTCP接続を受け付ける処理にある欠陥です。Linux 4.4以降が対象で、認証なしにネットワーク経由で狙える可能性があります(piyolog、AlmaLinux公式ブログ)。
専門知識がない方向けの説明
インターネットの通信では、本題の前に「つないでいいですか」という短いあいさつを交わします。今回の欠陥は、このあいさつの最中に起きます。かなり単純化すると、すでに返却して別の用途に回したメモ用紙を、別の担当者がまだ読み続けてしまうような不具合です。これを「use-after-free(解放後使用)」と呼びます。
うまく悪用されると、カーネルの停止やメモリの破壊につながります。Anthropicの実証では、サーバーの最高権限である「root」でコマンドを実行できたとされています。
最初に押さえたい4点
- 急ぐべき人:Linuxサーバーを自分で管理している人、または管理を任せている人です。特にインターネットから直接接続を受けるサーバーが該当します。
- 根本の対策:修正済みカーネルへの更新と再起動です。AWSは、これだけが完全な対策だとしています。
- 悪用の状況:AWSは実環境での悪用を把握していないとしています。米CISAの悪用確認カタログ(KEV)にも、11月2日の確認時点で未掲載です(Rescana)。
- 一般の人:スマホや家庭用PCの利用者に特別な操作を求める公式情報は、今回の調査では確認できませんでした。お名前.comなどの告知も、主な対象はVPSなどのサーバー利用者です。
「悪用されていない」は「急がなくていい」という意味ではありません。あくまで今の時点で報告がないという意味です。修正が出ている環境では、計画的に早めの更新を進めるのが各社共通の案内です。
2. 背景と経緯:10年前のバグとAIによる攻撃実証
原因のコードはLinux 4.4から含まれていました(TuxCare)。修正自体は小さく、解放処理をkfree()からkfree_rcu()に変え、読み手が終わるまで解放を待たせる内容です(piyolog)。
| 日付(2026年) | 出来事 |
|---|---|
| 10月5日 | 修正をカーネルにコミット |
| 10月15日 | CVEを公開 |
| 10月24日 | カーネルのCVEチームがCVSS 9.8を追加 |
| 10月27日 | Anthropicが攻撃の実証を公表 |
| 10月29日 | Goのセキュリティチームが注意を公表(oss-securityへの転送は30日) |
| 10月30日 | Red Hatが速報RHSB-2026-016を公開、AWSが告知2026-160-AWSを公開 |
| 11月1〜2日 | RHEL 8/9/10向けの修正を公開、AlmaLinuxが本番リポジトリへ反映 |
日付は各公表元の表記によるもので、時差により前後する場合があります(出典:piyolog、TuxCare、ma.ttias.be、Red Hat、AWS、AlmaLinux)。
Anthropicが公表した内容と、言えないこと
Anthropicは10月27日の研究記事で、未公開の社内研究用モデルを使い、Chrome、Safari、Android、Windows、Linuxにまたがる5つの攻撃の連鎖を示しました。Linuxの例では、MPTCP(複数の経路を束ねるTCPの拡張)で待ち受けるサーバーが対象です。カーネルのアドレスを漏らす段階に約48分、コマンド実行まで約5分、合計で約53分かかったとしています。
ここで注意したいのは、53分は「AIが欠陥を見つけるまでの時間」ではなく、実証コードの攻撃にかかった時間だという点です。攻撃コードは公開されておらず、カーネルの版や試験の構成も公表されていません(TuxCare)。第三者が同じ攻撃を再現したという報告も、今回調べた範囲では確認できませんでした。AikidoはCloudLinuxのカーネルチームが再現できなかったと伝えていますが、CloudLinuxの一次情報までは確認できていません。
なお、この記事の生成にもAnthropicのClaudeが使われています。そのため、同社の主張は「同社の発表」として扱い、独立に検証された事実とは書いていません。
同じ欠陥で評価が割れた理由
CVSSは10点満点の深刻度の指標です。数字が同じでも、悪用の起きやすさまでは表しません。今回は評価が大きく動きました。カーネルのCVEチームは、競合の両側を攻撃者が誘発できるとして、攻撃の複雑さを「低」と評価し9.8を付けました。一方で、競合に勝つのは難しいとみて、攻撃の複雑さを「高」とした会社もあります。Red Hatの評価は5.9から8.1に上がり、10月30日の速報ではCritical(9.8)になりました。OracleとAmazonは8.1です。Ubuntuは9.8(CVSS 4.0では8.3)、SUSEは8.1(同9.2)としています(TuxCare、piyolog、Red Hat、Aikido)。
3. 最近の動き:Linuxディストリビューションごとの修正状況
カーネル本家の修正は10月中旬までに各系列へ入りました。ただ、利用者に届くのは各ディストリビューションが自社版に取り込んでからです。ここで大きな差が出ました。次の表は主に11月2日時点の状況です。毎日変わるので、実際に作業するときは必ず公式の情報を確認してください。
| OS | 状況 |
|---|---|
| 本家カーネル | 5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56、7.2.10、7.3で修正。4.4〜5.4の系列はサポート終了で修正なし |
| Debian | Debian 12、13ともセキュリティ更新で修正済み |
| Ubuntu | 22.04、24.04、26.04、26.10は修正作業中で未配布。20.04、18.04、16.04は脆弱のまま。14.04は影響なし |
| RHEL | 8.10、9.8、10.2は11月1日に修正(RHSA-2026:93412〜93415)。RHEL 9のリアルタイム版とOpenShift 4は未修正との情報あり。6、7は影響なし |
| AlmaLinux | 11月2日に8、9、10の修正が本番リポジトリへ |
| Rocky Linux | コミュニティ版の修正は未確認(ma.ttias.be)。CIQの有償版には修正版あり |
| Oracle Linux | UEKは10月16日に修正。RHCKは10.2と8.10で修正を確認、7と9は未確認 |
| SUSE | SLES 16.0、SLES 15 SP4〜SP6(LTSS)は修正済み。SP7などは作業中または一部ライブパッチのみ |
| Amazon Linux | 2と2023は修正済み |
出典:ma.ttias.be、Ubuntu、Debian、Rescana、AlmaLinux、CIQ、AWS。
クラウドは「サービスごとに」対応が違う
AWSの告知(11月1日更新)は、今回の難しさをよく表しています。ポイントだけ抜き出します。
- EC2:利用者がカーネルを更新して再起動します。
- Fargate:11月1日以降に起動したタスクが修正対象なので、既存タスクの入れ替えを推奨しています。
- RDS / Aurora:DBのポートをインターネットに公開しないことが前提です。OSパッチは11月3日に提供予定です。
- Lambda:公開されたIPv4 TCPポートがないため影響なしとしています。
- ALBやCloudFrontの配下:AWS側は修正済みですが、後ろのサーバーも30日以内の更新を推奨しています。
- NLBのTCPリスナーなど:問題のパケットを後ろへ転送するので、対象サーバーの更新か暫定策が必要です。
国内では、さくらのクラウドが11月2日に注意喚起を掲載し、お名前.comも10月30日からVPS利用者に対策を呼びかけています。一方、JPCERT/CCのサイトの直近の注意喚起一覧には、11月3日未明の確認時点で本件は見当たりませんでした。
4. するべきこと・しないほうがいいこと(読者別)
A. 一般の人・サーバーを管理していない人
すること
- スマホやPCの自動更新を、ふだんどおり有効にしておきます。
- 利用サービスの短時間のメンテナンスは、対応作業の可能性があると理解しておきます。実際に、自治体サイトの約5分の閲覧停止などの告知がXで共有されていました。
しないほうがいいこと
- 「AIが53分で世界中のLinuxを乗っ取れる」のような短い言い方を、そのまま拡散しないようにします。条件付きの実験であり、実際の攻撃事例ではありません。
- 「修正プログラムを買ってください」のような電話やメールに応じないようにします。本件での便乗詐欺は今回確認できていませんが、PHP2Shellの騒ぎでは同様の手口が出回りました。
- ネットで見かけたコマンドを、意味が分からないまま入力しないようにします。
B. サイト運営者・担当者(非エンジニアを含む)
すること:委託先や提供元に、次の4点を聞きます
- うちのサイトは、OSを自社で管理する契約か、事業者が管理する契約か。
- OSの種類は何で、修正版は出ているか。
- 更新のあと、再起動まで終わっているか。
- 修正版が出ていない場合、どの暫定策をいつまで続けるか。
しないほうがいいこと
- WordPressやPHPの更新で済んだと考えないようにします。今回はOSの中心部の問題です。
- 「パッチを入れました」の報告だけで完了にしないようにします。カーネルは再起動するまで反映されません(お名前.com、AlmaLinux)。
- 確認せずに「うちはクラウドだから大丈夫」と決めないようにします。上の表のとおり、サービスごとに必要な対応が違います。
C. 技術者・サーバー管理者
すること
uname -rで実行中のカーネルを確認し、ディストリビューションのトラッカーの修正版と比べます。- 修正版があれば、更新して再起動し、再び
uname -rで確認します。 ss -tlnpで公開中の待ち受けを、sysctl net.mptcp.enabledとss -MlnpでMPTCPの状況を確認します。Go 1.24以降は対応環境でMPTCPが既定になるので、気づかず使っていることがあります。- 修正版がなければ、ベンダーの手順に沿って、IPオプション付きのIPv4 TCPパケットの破棄を検討します。Red HatとAlmaLinuxがnftablesの手順を公開しています。本番の前に検証環境で確かめ、更新後はルールを削除します。
しないほうがいいこと
- MPTCPの無効化だけで終わりにしない:CIQは単独での無効化を避けるよう明記しています。Goのチームも、MPTCPのないシステムが同様の攻撃を受ける可能性を指摘し、GODEBUGでの無効化を「脆弱な緩和策」と評価しました。既存のソケットにも効きません。
- 本家の版番号と直接比べない:ディストリビューションのカーネルは独自の番号で修正を取り込んでいます(ma.ttias.be)。
- 修正コミットだけを自分で取り込まない:カーネルのCVEチームは、最新の安定版への更新を推奨しています(piyolog)。
- 同じホスト上のプロキシを防御とみなさない:接続を受けるカーネルが脆弱なままです(Aikido)。
- コンテナイメージの更新で安心しない:コンテナは基本的にホストのカーネルを使います。また、緩和ルールはコンテナ間の通信では迂回される場合があります(AlmaLinux)。
- 破棄ルールを無条件に入れない:CIPSOに依存するネットワークや、ルーティングを担うホストでは影響が出ます(AlmaLinux)。
- 出どころ不明の「PoC」を試さない:11月2日時点で、公開された攻撃コードは確認されていません(Rescana)。名乗るだけのコードは、不正なプログラムの可能性もあります。
- 番号を混同しない:同時期にCVE-2026-99999(仮想化環境への影響で、さくらが10月16日に別途公表)など、別のLinuxの脆弱性も話題になっています。対策は同じとは限りません。
5. Xの反応:肯定・否定・中立の割合
Yahoo!リアルタイム検索で、「CVE-2026-98432」「Linuxカーネル 脆弱性」「#脆弱性 Linux」「Anthropic Linux 脆弱性 MPTCP」など複数の語で投稿を集めました(集計:2026年11月3日 04:58 JST、投稿は主に10月末〜11月3日未明)。重複を除いた約180件から、自動投稿、ニュースの転載、記事の宣伝、組織の告知、別の脆弱性の話題を除き、感想や実務の声として読める107件を1件ずつ分類しました。
| 分類 | 件数 | 割合 | 主な内容 |
|---|---|---|---|
| 肯定 | 7件 | 6% | 更新完了の安堵、対応の評価、AI活用への期待 |
| 否定 | 37件 | 35% | 修正の遅れへの不満、疲れ、不安、社内の温度差 |
| 中立 | 63件 | 59% | 修正情報の共有、技術的な検討、作業の報告 |
今回の「否定」は、脆弱性やAIを批判する意見という意味だけではありません。修正の遅れや対応の負担に対する不満や不安も含みます。また、分類はAIによる判断で、迷うものは中立に入れました。検索の仕組みにも偏りがあるので、Xの声全体を表す数字ではなく、傾向の目安として見てください。
最も広まったのは「実務に使える情報」
反応が多かったのは、感情的な投稿よりも実務の情報でした。AWSでは「EC2の中身を更新すればいい」では済まないと注意した投稿が287いいね、83リポストです。RHELの修正カーネルが出始めたという投稿は122いいね、64リポスト、AWSのサービス別の違いを並べた投稿は53いいねでした。攻撃は2段階で計53分という実証内容を要約した投稿も、156いいねを集めています。
投稿の要約:AWSの対応は、EC2の更新だけで終わる話ではない。告知の中身もかなり書き換わってきているので注意したい。
6. 肯定的な反応:更新完了の安堵と丁寧な対応への評価
肯定は7件と少数です。緊急の脆弱性の話題で、喜ぶ投稿が多くならないのは自然でしょう。いいねの数も最大で9件ほどなので、以下は広まった意見というより、目立った論点として紹介します。
論点1:適用を終えた安堵
パッチの適用を終えて「これで安心して眠れる」「明日はサーバーのことを考えずに済む」という声がありました。祝日の前に片付けたいという事情もうかがえます。11月3日は文化の日で、AlmaLinux関連の投稿にも、祝日前の対策を促すものがありました。
論点2:早かった配布元と丁寧な事業者への評価
比較的早く修正を出したOracleのUEKやDebianを評価し、「Debianに戻そうか」と考える投稿がありました。また、図書館向けのサービス事業者が公開した対応報告について、事業者と利用者の関係のモデルケースになるという声もありました。何をどこまで対応したのかを説明する姿勢が評価されています。
投稿の要約:ある事業者の対応報告は、事業者と顧客の関係を考えるうえでモデルケースとして参考になりそうだ。
論点3:防御にAIや知識を生かす動き
カーネルやネットワークの知識を生かして、社内ブログに解説を書いたという投稿もありました。AIについては、Anthropicの発表に驚きつつ、開発現場では「生成の速さより、検査と修正の自動化が差になりそう」という見方が出ています。Anthropic自身も、自分のコードを調べることの重要性を訴えています。AIを怖がるだけで終わらせず、防御にも使うという方向の反応です。
7. 否定的な反応:修正の遅れ、疲れ、現場の温度差
否定は37件で、大きく3つの論点に分かれました。AIそのものを批判する投稿より、現場の負担を訴える投稿のほうが多いのが特徴です。
論点1:修正が届かないことへの不満
最も多かったのが、UbuntuやRocky Linuxの修正を待つ声です。「パッチはまだか」という短い投稿が繰り返され、他社が出そろうなかでUbuntuだけ遅いことに首をかしげる声もありました。暫定策を入れても「すっきりしない」という投稿や、修正を待つ間はサーバーを止めておくという投稿もありました。
投稿の要約:その場しのぎの対策は入れてあるが、やはりすっきりしない。そろそろUbuntuの修正がほしい。
中には、配布を待ちきれず、自分でパッチを当ててビルドするか迷うという投稿もありました。気持ちは分かりますが、前述のとおりカーネルのCVEチームは個別の取り込みを勧めていません。
論点2:続く脆弱性対応への疲れ
「ほぼ毎日脆弱性対応で、さすがにうんざり」「PHP祭りと同じ流れ」「お金にならない問い合わせが増えた」という声が目立ちました。10月に話題になったPHP2Shellの直後だったことも影響しているようです。「OSより先に管理者のライフが尽きそう」という冗談まじりの投稿は、この空気をよく表しています。
論点3:組織内の温度差と、説明の難しさ
否定側で最も反応が多かったのは、社内で警鐘を鳴らしたのは自分だけだったという投稿(42いいね)です。ほかにも「チームが把握していない」「対応の指示が下りてこない」という声がありました。反対に、Windows Serverを使っているのにLinuxの使用有無の報告を求められたという不満もあります。顧客には構成の違いが伝わりにくく、問い合わせ対応に苦労するという投稿もありました。
ほかには「お知らせが来たが、パッチが出ていないのに何をすればいいのか」という戸惑いや、AIが攻撃コードまで作ったことへの率直な怖さも見られました。Xの短い告知だけでは、次の行動まで伝わっていない様子がうかがえます。
8. 反応の分析と、脆弱性への関心の動向
「数字の怖さ」と「条件の細かさ」のずれ
中立の投稿では、見方がはっきり分かれていました。「そう簡単に攻撃は成立しない」「必死に対応したが、Anthropic以外に成功例はないのでは」と冷静に見る声があります。一方で、「再現の条件は本番環境でもありえない話ではなく、攻撃者は前向きに試すだろう」という警戒の声もあります。どちらも、公開情報が少ないなかでの推測です。今は再現の報告も悪用の報告もありませんが、攻撃の詳細も公開されていないので、どちらかに断定するのは難しい段階です。
もう一つ印象的だったのが、「最初の情報だけ見て低リスクと判断し、見送った人も多そう」という投稿です。Red Hatの評価が5.9から9.8まで動いたように、最初に付いた評価を固定して考えると判断を誤ることがあります。公開情報の更新を追う体制そのものが、今回の教訓の一つでしょう。
数字で見る関心の動向
- CVE全体:2025年は過去最多の48,185件でした(トレンドマイクロ)。FIRSTは6月、2026年の予測を約6万6000件に引き上げ、AIによる発見の加速を主な理由に挙げています(@IT、Help Net Security)。
- 高深刻度のCVE:Epoch AIの集計では、主要21組織のHigh/Criticalは6月に約1,550件、7月に約2,500件でした。ただし、@ITはCVEの増加と脆弱性そのものの増加は別だと強調し、AIが原因とも断定していません。
- 実際の悪用:トレンドマイクロは、Linuxカーネルの約5,800件のCVEのうち悪用が確認された割合を約0.02%としています。また、「欠陥が見つかること」と「武器化されること」は別だと述べています。その一方で、悪用までの猶予は短くなっているとも指摘しています。
- Linuxの広がり:W3Techsによると、OSが判明しているWebサイトの63.3%がLinuxです(11月2日)。Linuxサイトのうち判明している配布元ではUbuntuが15.2%で最多で、Ubuntuの修正の遅れに声が集まったことと符合します。ただし77.2%は配布元不明です。
- Xの投稿量:Yahoo!リアルタイム検索の新着順では、「CVE-2026-98432」が543件、「Linuxカーネル 脆弱性」が704件でした。集計の上限や条件があるので、目安にとどまります。
本件に絞った検索量の推移や、対応に要した費用の数値は確認できませんでした。FIRSTの分析で重要なのは、課題が「見つけること」から「優先順位を付けること」に移っているという点です。今回のXでも、CVSSより悪用の実績で判断するという考え方に共感が集まっていました(別の脆弱性の話題で31いいね)。ただし、KEV未掲載を理由に後回しにすると、インターネットに公開したサーバーでは出遅れるおそれがあります。自社の公開範囲と合わせて判断する必要があります。
9. 今後の注目点とまとめ
今後の注目点
- 未修正の製品:UbuntuのLTS各版、RHEL 9のリアルタイム版、OpenShift 4、Rocky Linuxのコミュニティ版がいつ修正されるかです。
- AWSの予定:RDS/AuroraとStorage Gatewayが11月3日から、GameLiftが11月4日まで、EKS Auto Modeが11月6日までの予定です。
- 悪用の状況:KEVへの掲載や、ベンダーからの悪用報告があれば、優先度の判断が大きく変わります。
- 第三者の検証:再現の報告や、MPTCPのないサーバーでの成否は、今いちばん大きな不明点です。Anthropicは「MPTCPが必要な理由」を説明していません(lilting)。
- NVDの分析:確認時点でNVD独自の評価は出ていません。
まとめ
今回の話を短くまとめると、「10年前のバグの修正は小さかったものの、AIによる実証で緊急度の見方が変わり、修正を届ける段階で差が出た」という出来事です。修正そのものより、それを各環境へ届け、再起動まで終えることのほうが大変だという現実が見えました。
- 一般の人:ふだんの更新を続け、強い言葉の情報や便乗の連絡に乗らないこと。
- サイト運営者:OSの管理者は誰か、修正版はあるか、再起動は済んだかを確かめること。
- 技術者:公式情報を基準に更新と再起動を行い、暫定策を修正の代わりにしないこと。
Xでは修正を待つ声や疲れの声が目立ちましたが、広く読まれたのは具体的な手順や状況の共有でした。AIが脆弱性の発見や攻撃の検証を変えつつある今、怖がるだけでなく、何を確認してどう動くのかを落ち着いて共有することが、いっそう大切になりそうです。この記事の修正状況は主に11月2日時点の情報です。実際に対応するときは、必ず各社の最新の公式情報を確認してください。