boolsee

【Windowsにも深刻度9.8の乗っ取りバグがありました】 先日のLinuxの件を調べていて、Windows側も見ていたら出てきました 「Windowsだけの人は関係ないの？」と思った人向けに書いておきます 先に答えを言うと、Windows Updateを普通に当てている人は何もしなくていいです 8月の更新で直っているので 更新を止めている人だけそのままです こっちは肩の力を抜いて読んでください 1本目は、乗っ取られる方（CVE-2026-62815） Windowsに入っている「MsQuic」という、QUIC（HTTP/3などで使う新しい通信方式）の部品のバグです 細工したパケットを送られるだけで、ログイン無しに遠隔でコードを実行される、つまり乗っ取られるタイプ Microsoftの評価は10点満点の9.8で「緊急」 2026年8月11日の月例更新で修正済みで、悪用された報告はありません Anthropicの発表とは別件で、私も今回調べていて気付きました 2本目は、止められる方（CVE-2026-33096） こっちがAnthropicの10月27日の発表（Claudeの未公開モデルが見つけた穴）に入っていたWindowsの1本です Windowsの中でWebの通信をさばいている「HTTP.sys」のバグで、HTTP/3で数パケット送りつけるだけでサーバーが落ちます（クラッシュして強制再起動がかかる状態） 繰り返されると落ち続けるので、そのサーバーを使う人全員が使えなくなります 乗っ取りではないので評価は7.5 2026年4月14日の月例更新で修正済みです 発表が今になったのは、Anthropicが修正から日数を置いてから詳細を出す方針だからで、新しく見つかった話ではありません 対象範囲 どちらもWindows 11（23H2以降）と、Windows Server 2022 / 2025 Windows 10やServer 2019以前は対象の一覧にありません MacやiPhone、Androidは関係ありません（Windowsの部品の話です） 2本目はHTTP/3で応答しているサーバーが条件で、WindowsのHTTP/3はレジストリ（EnableHttp3）で有効にしないと動かないので、普通のPCや設定をいじっていないサーバーは待ち受けていません 1本目は、私が見た範囲ではMicrosoftの説明に条件の記載が無いので、「更新が当たっているか」で見るのが確実です あとMsQuicはオープンソースで、.NETのHTTP/3はLinux上でも同じ部品（libmsquic）を使います Windows向けのCVEとして出ていますが、Linuxで.NETのHTTP/3を有効にしている人は、libmsquicの更新が出ていないかも見ておいた方が安全です（私はそこまでは確認できていません） やること 普通のPCの人は、設定 → Windows Updateで「最新の状態です」になっていれば2本とも終わりです Windows Serverの人は、2026年8月の月例更新以降が当たっているか確認してください winverのビルド番号の目安は Windows 11 24H2なら26100.9168以上 25H2なら26200.9168以上 Server 2022なら20348.5499以上です 更新を止めている、検証待ちで後回しにしている場合は、少なくとも外に向いているサーバーだけでも先に当ててください 2本目だけなら、HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters のEnableHttp3を0にして再起動するか、UDPの443番を閉じれば理屈上は塞がります HTTP/3を止めてもブラウザはHTTP/2に戻るだけなので、サイトは普通に見られます 1本目はこの手が効くか分からないので、更新一択です どちらも悪用された報告は今のところ見当たりません Linuxの方と違って修正はもう出ているので、こちらは「更新を当てているか」だけの話です 正直、ほとんどの人はもう終わっていると思います

【Linuxカーネルに深刻度9.8（最大級）の脆弱性。WSL2とDockerの人はapt upgradeじゃ直りません】 脆弱性の対応、日々お疲れ様です Chromeに続いて、さらに来ました。今度はLinuxです ただ今回は「全員今すぐ」の話ではないので、先に落ち着いて読んでください 少し長いですが詳しくまとめたので、自分の環境の見出しだけでも読んでもらえると嬉しいです 何の話か CVE-2026-98432というLinuxカーネルのバグです（10月15日公開） 先日書いたChromeの大量修正にも関わっている、Anthropicの10月27日の発表（Claudeの未公開モデルが見つけた穴） その中のLinuxの1本です 2015年から入っていたバグなので、現役のLinuxはほぼ全部該当します CVEの記録上のスコアは10点満点の9.8です 中身 外から細工した接続要求を送りつけられるだけで、ログインも要らずに起きます 接続要求の処理が別のCPUで同時に走った時に、消したはずのメモリを読みに行くバグで、起きた時に一番ありそうなのはサーバーごと落ちる（クラッシュ）です IPv4の話で、IPv6は今回のバグの対象外です 条件が揃えば外からrootでコマンドを実行できるところまでAnthropicは実証したと発表しています ただ報道によるとその条件は「Multipath TCPで待ち受けているサーバー」で、これは複数回線を束ねる拡張で、アプリ側で明示的に使う設定が要るものです 普通の設定のWebサーバーがそのまま当てはまるかは、まだ分かりません 対象は、外に向けて待ち受けているサービスがある機械です Webだけでなく、SSHの22番を開けているだけで該当するので、開発用のVPSもほぼ全部です 逆に、外に向けて何も待ち受けていない機械には刺さる場所がありません AndroidやNAS、ルーター、ラズパイも中身はLinuxですが、考え方は同じで、外に待ち受けを開けていなければ急ぎではなく、修正はメーカー待ちです 温度感は配布元で割れています UbuntuはHigh Red Hatは現実的な被害は落ちるまでという見方でModerate、修正は今後の更新に回しています 悪用された報告は今のところ見当たりません なので「全員今すぐ」ではなく、自分がどのケースか見て、出た修正を当てる、で十分かなと思います クラウドやVPSで公開サーバーを動かしている人 配布元の修正が出たら当てて、再起動（カーネルは再起動して初めて効きます） Debianはもう出ています（12は6.1.190、13は6.12.113） Ubuntuは10月30日時点でも22.04、24.04とも作業中で、今apt upgradeしても当たるものはまだありません 出た時の番号は24.04が6.8.0-149、22.04が5.15.0-203の予定なので、uname -rがそれ以上になれば修正済みです 20.04以前は通常サポートが終わっているので、修正が来るとしてもUbuntu Pro（個人なら5台まで無料）に入っている人だけです Amazon Linux 2023は6.12系と6.18系のカーネルは修正済み、標準の6.1系とAmazon Linux 2はまだです Red Hat系（RHEL、AlmaLinux、Rocky）は配布元の判断で修正が後になるので、下のつなぎで待つ形です 修正が来るまでのつなぎ 公式の回避策は、UbuntuもRed HatもSUSEも出していません その上で、仕組みから言えることが2つあります 1つ目は露出を減らすこと SSHや管理画面は接続元を自分のIPに絞る CloudflareやALBのような前段を挟む場合は、本体側で前段のIP以外を遮断して初めて意味があります（NLBのようにL4で素通しするタイプは別） 2つ目はIPオプションを落とすこと バグが触るのは接続要求に付いていたIPオプションのメモリなので、IPオプション付きのTCPパケットを手前で落とせば、理屈上はこの経路に入りません（nftablesならip hdrlength > 5を条件にdrop） TCPだけに絞るのは、他のプロトコルには正規で付くことがあるからです ufwのような簡易ツールでは書けないので、nftablesかiptablesを直接触れる人向けで、自分の環境で試してからにしてください 有償のライブパッチ（KernelCareなど）はDebian 13向けが先に出ています Ubuntu ProのLivepatchは確認できていません WSL2の人 カーネルはUbuntuの中ではなく、Microsoftが配っています ここがややこしいのですが、Ubuntuの中でapt upgradeしても、カーネルは1ミリも変わりません 更新はPowerShellでwsl --update（かWindows Update） そのあとwsl --shutdownで一度止めると、次の起動から新しいカーネルになります Microsoftは修正入りのカーネル（6.18.58.1）をここ数日で公開していますが、wsl --updateで降ってくる版に入ったかはまだ確認できていません WSLの中でuname -rを打って、6.18.56以上なら修正済み、今配られている6.18.33系や、古いままの6.6系・5.15系なら未修正です （WSL1はLinuxカーネルを使っていないので関係ありません） Dockerの人 コンテナはホストのカーネルをそのまま使うので、コンテナの中で更新しても意味がありません LinuxのサーバーならホストのOSを更新 WindowsのDocker Desktopは標準のWSL2バックエンドならWSL2のカーネルで動いているので、上と同じwsl --update MacのDocker Desktopは自前のカーネルなので、Docker Desktop本体の更新です（修正入りの版が出たかは未確認） OrbStackやColima、Rancher Desktopも同じで、VMのカーネルを配っているのが誰かで決まります Hyper-VやVirtualBox、VMwareの仮想マシンの人 これだけはゲストの中でapt upgradeで合っています（配布元の修正が出てから） 自分のカーネルの番号はuname -rで出ます 修正済みは5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56、7.2.10以上です ただしこれは、WSL2やArch、Amazon Linuxのように上流の番号をそのまま使っている環境向けの目安です Ubuntu、Debian、Red Hat系は番号の付け方が違って上の番号とは比べられないので、配布元の案内（Ubuntuは上に書いた予定の番号）で見てください 自宅のWSL2や仮想マシンは、外から直接つながる構成（ブリッジ接続やポート開放）にしていなければ急ぎではありません ただ「apt upgradeしたから安心」は間違いなので、そこだけ覚えておいてください