ToolScope

AI動画・音声・画像生成ツールを徹底比較

【エンジニア向け】Node.jsとJavaの2026年10月セキュリティ更新まとめ:Brotli RCE・Oracle CPU・eMudhra中間CA侵害への対応手順

ルートCA Root 中間CA ×8 秘密鍵が256未満 偽のサーバー証明書 を拒否する Node.js 22.23.4 / 24.22.1 26.12.1 Java SE CPU Oct 2026 + CVE-2026-91403 2026年10月 同時期の3つの更新 ① Node.js 脆弱性10件 High 4件(Brotli・TLS・DNS) ② Oracle Java SE 55件 定例CPU+翌日の緊急アラート ③ eMudhra 中間CA侵害 証明書ストアの更新が必要 エンジニア向け 対応ガイド

【エンジニア向け】Node.jsとJavaの2026年10月セキュリティ更新まとめ:Brotli RCE・Oracle CPU・eMudhra中間CA侵害への対応手順

執筆日:2026年10月22日(同日13時ごろまでに公開された公式発表・報道に基づきます)
対象:Node.js 22/24/26系、Oracle Java SE・OpenJDK系ディストリビューション、OSの証明書ストアを使うアプリケーション

この記事でわかること

  • 同じ時期に重なった「Node.jsのセキュリティリリース」「OracleのJava定例更新と緊急アラート」「eMudhraの中間CA侵害」の関係
  • Node.jsの10件の脆弱性の中身と、特に注意すべきBrotliのRCE(CVE-2026-111497)の影響条件
  • Java SEの更新対象と、定例更新の翌日に出た緊急アラート(CVE-2026-91403)の意味
  • ブラウザ以外のランタイムで、侵害された中間証明書をどう扱えばよいか
  • ネット上で出回っている情報のうち、誤り・未確認のもの

先に結論

  • Node.js:22.23.4/24.22.1/26.12.1 へ更新します。20.x・25.x はサポート終了で修正版が出ないため、サポート中の系列へ移行してください。コンテナイメージ、単一実行ファイル(SEA)、スタートアップスナップショットは作り直しが必要です。
  • Java:10月の定例更新(CPU)を当てたうえで、翌日の緊急アラート CVE-2026-91403 の追加修正も当ててください。定例更新で出たばかりの版も、この緊急アラートの対象とされています。
  • OSの証明書ストア:ca-certificates を更新します。curl、Python、Goなど、OSのストアや独自のストアを使うツールも関係します。
  • これらは PHPのphp2shellとは別の問題で、同じ日に重なっただけです。

本文では情報の出どころを区別するため、次のラベルを使います。

公式Node.js・Oracle・IPAなどの発表 報道等報道・企業ブログ・二次情報 筆者筆者の補足・一般的な運用知識(環境に合わせて確認してください)

目次

  1. 全体像:何が、いつ起きたのか
  2. eMudhra中間CA侵害:なぜランタイムの更新が必要なのか
  3. Node.js:10月21日のセキュリティリリース
  4. Java:Oracle CPU(2026年10月)と CVE-2026-91403
  5. Go・curl・Pythonなど、そのほかの環境
  6. 対応の優先順位と手順
  7. 情報の精査:誤り・未確認の情報
  8. 対応チェックリスト
  9. よくある質問
  10. 参考資料

1. 全体像:何が、いつ起きたのか

2026年10月21日前後には、Webの基盤にかかわる更新が立て続けに出ました。PHPのphp2shell(CVE-2026-109618/109619)が最も注目されましたが、Node.jsとJavaにもセキュリティ更新が出ています。さらにその背景には、インドの認証局eMudhraの中間証明書の秘密鍵が簡単に割り出せた、という問題がありました。

対象 内容 php2shellとの関係
Node.js 22・24・26系で脆弱性10件を修正(High 4件)。eMudhra対策も同梱公式 なし。10月14日(UTC)に予告済みの計画的なリリース
Oracle Java SE 四半期ごとの定例更新(CPU)で55件を修正。翌日にeMudhra関連の緊急アラート(CVSS 9.1)公式報道等 なし。CPUはもともと決まっていた定例日
eMudhra 中間CA 8件の秘密鍵が256未満の整数で、すぐに割り出せる状態だった報道等 なし。Node.jsとJavaの更新の共通の背景
タイムライン(日付は発表元の現地時間・UTCを含む) 10/14 Node.js リリースを予告 10/17〜19 eMudhra の鍵を報告 Chrome等がブロック Go が修正版(10/19) 10/20(米国) Oracle CPU Java SE 55件 10/21 Node.js 修正版 IPAがJava注意喚起 PHP 修正版(14:00 UTC) 10/21(米国) Oracle 緊急アラート CVE-2026-91403
図1 10月14日〜21日の主な出来事(各社の発表と報道をもとに筆者が作図)

2. eMudhra中間CA侵害:なぜランタイムの更新が必要なのか

何が起きたのか

インドの認証局eMudhraが運用していた中間CA 8件で、秘密鍵が第三者にすぐ割り出せる状態だったことがわかりました。鍵はP-384の楕円曲線鍵で、本来はとても大きな範囲の乱数でなければなりません。ところが、8件すべての秘密鍵が256未満の整数でした。eMudhraは、2025年4月にHSM上で鍵を生成した際のスクリプトの不備と、似た名前の鍵を取り違えて本番に入れた人為的なミスが原因だと説明しています。報道等

8件のうち6件はTLS(Webサイト)用で、Google・Mozilla・Microsoft・Appleのルートプログラムで信頼されていました。残り2件はMicrosoftが信頼するコード署名用です。この鍵を持つ者は、任意のドメインの証明書を発行できます。つまり、なりすましや通信の傍受・改ざんが可能になります。報道等

日付(UTC等) 出来事報道等
10月17日 研究者がApple・Google・Microsoft・Mozilla・eMudhraに報告。各鍵で署名したメッセージを証拠として提出。同日、Chromeが8件をブロック
10月18日 eMudhraが8件を失効
10月19日 一部をクロス署名していたSectigoが失効を完了。Appleが対応。Goが修正版(1.27.3/1.26.10)を公開
10月20日 Microsoftが対応。Mozillaが公表し、OneCRLでブロック。後にルート「emSign ECC Root CA - G3」の信頼も取り消し

現時点で、この中間CAから不正な証明書が発行された形跡は報告されていません。GoogleはCertificate Transparencyのログにも不正な証明書は現れていないとしています。報道等

ブラウザが対応しても終わらない理由

ブラウザは、独自の仕組み(ChromeのブロックリストやFirefoxのOneCRLなど)で問題の証明書をすぐに止められます。一方、curl、Python、Node.js、Go、Java、パッケージマネージャーなど、ブラウザ以外の多くのクライアントは、既定では証明書の失効を確認しません。eMudhraが失効させても、それだけではこれらのクライアントは問題の中間CAを信頼し続けます。そのため、各ランタイムや証明書ストアの側で「この中間CAを信頼しない」という更新が必要になりました。報道等

偽の証明書をどこで止めるか 侵害された中間CA 鍵を持つ攻撃者が 任意ドメインの 証明書を作れる ブラウザ 独自のブロックリストで遮断済み curl・Python・Node.js・Go・Java 既定では失効を確認しない → 中間CAを信頼し続ける 必要な対応 ランタイムの更新 証明書ストアの更新 (ca-certificates 等)
図2 ブラウザ以外のクライアントでは、ランタイムや証明書ストアの更新が必要になる(報道をもとに筆者が作図)

3. Node.js:10月21日のセキュリティリリース

概要

項目 内容
修正版 v22.23.4(LTS)/v24.22.1(LTS)/v26.12.1(Current)公式
件数 10件。High 4、Medium 3、Low 3。該当数は26系が10件、24系が8件、22系が7件公式報道等
予告 10月14日、oss-securityで「21日ごろに22・24・26系を出す。最高深刻度はHigh」と予告公式
CVSS Node.jsは各CVEのCVSSスコアを公表していない報道等
悪用状況 実際の攻撃は報告されていない(10月22日時点)報道等
サポート終了版 セキュリティリリースのたびに影響を受けるとされ、修正版は出ない。20.x・25.x は移行が必要公式

10件の一覧

CVE 深刻度 内容 対象
CVE-2026-111497 High Brotliデコーダーの範囲外書き込み。リモートコード実行につながりうる 26・24・22
CVE-2026-105483 High 全角数字で書かれたIPアドレスで、TLS証明書のホスト名検証をバイパス 26・24
CVE-2026-106069 High ホストがIPアドレスとして緩く解釈される場合に、TLS証明書のホスト名検証をバイパス 26・24・22
CVE-2026-105482 High dns.resolve がNUL文字を含む名前を切り詰める 26・24・22
CVE-2026-105481 Medium keep-aliveソケットが、リクエスト送信前に書き込まれたレスポンスを処理してしまう 26・24・22
CVE-2026-106072 Medium 非正規のIPv4ホスト名で、証明書のDNS SANによりIPエンドポイントが認証されてしまう 26・24・22
CVE-2026-106074 Medium crypto.randomUUID()・randomInt() のエントロピーキャッシュがスナップショットやSEAに保存され、全プロセスで同じ値が繰り返される 26・24・22
CVE-2026-106070 Low ZIPヘッダー検証の失敗後、ZipFileが攻撃者の制御するプレフィックスバイトを返す 26のみ
CVE-2026-106071 Low Permission Modelで、ワイルドカードの検索によりファイルシステムの権限が過剰に付与される 26のみ
CVE-2026-106073 Low Permission Modelを fs.realpathSync でバイパスできる 26・24・22

出典:Node.js公式の告知公式。説明は筆者が要約しています。

最優先:CVE-2026-111497(Brotli RCE)

Node.jsに同梱されているBrotliデコーダーの脆弱性です。細工したBrotliデータを処理させると範囲外書き込みが起きます。Vercelの告知によると、研究者は未修正の22・24・26系で、プロセスメモリの漏えいとコマンド実行を実証したと報告されています。実行される権限は、Node.jsプロセスと同じです。公式報道等

影響の条件は次のとおりです。

  • Node.js単体が勝手にBrotliデータを展開するわけではありません。攻撃者が制御するBrotliデータを、アプリケーションのコードや利用中のライブラリが展開する場合に影響を受けます。報道等
  • 入口は2つあります。受け取ったリクエストボディと、外部から取得したレスポンスです。後者は、外部のAPIやWebサイトからデータを取ってくる処理です。報道等
  • 外部から取得したレスポンス経由の攻撃は、WAFでは防げません。ランタイムの更新でしか防げないとされています。報道等
  • どのAPIが該当するか、fetch の自動展開が該当するかは、公式告知では明示されていません。報道等

自分のコードでBrotliの展開を使っているかは、次のように探せます。ただし、ライブラリ内部での利用や、HTTPクライアントによる自動展開は、これだけではわかりません。結局は、更新するのが確実です。筆者

# 自分のコードでBrotliの展開APIを使っている箇所を探す例
grep -rnE "createBrotliDecompress|brotliDecompress" --include='*.js' --include='*.ts' --include='*.mjs' --include='*.cjs' src/

# 受け付けるリクエストで Content-Encoding: br を許可しているかも確認する
grep -rniE "content-encoding|'br'|\"br\"" src/

TLSホスト名検証の3件(CVE-2026-105483/106069/106072)

いずれも、IPアドレスの書き方が標準的でない場合に、証明書の検証が甘くなる問題です。たとえば全角数字のIPアドレスや、非正規のIPv4表記です。HTTPS・TLSで内部のAPIやIPアドレス指定の接続先に通信するアプリでは、中間者攻撃のリスクにつながります。報道によると、修正版ではTLSで非正規のIPアドレスを拒否するようになりました。報道等

この変更により、設定ファイルや環境変数に書かれた接続先が非正規の表記になっていると、更新後に接続できなくなる可能性があります。更新前に、接続先の表記を確認しておくと安全です。筆者

SEA・スナップショットを使っている場合(CVE-2026-106074)

単一実行ファイル(SEA)やユーザーランドのスタートアップスナップショットを使って配布しているアプリでは、乱数のキャッシュがスナップショットに保存されます。その結果、すべてのプロセスで crypto.randomUUID() や randomInt() が同じ値を返してしまいます。UUIDをIDやトークンに使っている場合、値の重複や推測につながります。修正版のランタイムで作り直して、再配布する必要があります。公式報道等

依存関係の更新とeMudhra対策

依存関係 更新内容
ca-certs(ルート証明書) eMudhraの中間CA侵害に対応。報道によると、侵害された公開鍵を含むチェーンを3系列とも拒否するようになり、同梱のルート証明書はNSS 3.131.1相当に更新公式報道等
c-ares 1.34.9(26・24・22)報道等
OpenSSL 3.5.9(24・22)報道等
SQLite 3.53.4(22)報道等
undici 8.12.2/7.30.1/6.29.1(26/24/22)報道等

Node.jsは、OSの証明書ストアではなく、ランタイムに同梱した証明書を既定で使います(--use-system-ca などの設定で変えている場合を除く)。そのため、eMudhra対策はNode.js本体の更新で取り込まれます。筆者

確認と更新の手順

# 実行中のバージョンを確認
node -v

# nvm を使っている場合の例(修正版を入れて既定にする)
nvm install 24.22.1
nvm alias default 24.22.1

# コンテナ:ベースイメージを取り直して再ビルドし、中のバージョンを確認
docker build --pull --no-cache -t myapp:patched .
docker run --rm myapp:patched node -v

本番では、PM2・systemd・Kubernetesなどで動くプロセスを、修正版のランタイムで再起動・再デプロイしないと反映されません。CIランナーや開発者のローカル環境も、外部のデータを取り込む処理があれば更新対象です。筆者

PaaSを使っている場合は、事業者の対応を確認します。例として、Vercelは同日に攻撃経路をブロックするWAFルールを全プロジェクトに展開し、管理対象のランタイムを順次更新中としています。ただし、Vercelの外で動かしているバックエンドや自前のコンテナは、利用者が更新する必要があります。Vercel上でNode.js 20.xを使っているプロジェクトは、22.xか24.xへの変更が必要です。報道等

4. Java:Oracle CPU(2026年10月)と CVE-2026-91403

① 10月の定例更新(CPU)

項目 内容
公開日 2026年10月20日(米国時間)。日本では10月21日公式
Oracle全体 1,295件のパッチ。製品間の重複を除いたCVEとしては1,209件公式報道等
Java SE 55件。そのうち49件は認証なしでネットワーク経由で悪用されうる報道等
影響を受ける版(IPA・Oracle記載) Java SE 27、26.0.2、25.0.4.1、21.0.12.1、17.0.20.1、11.0.32.1、8 Update 503、8 Update 503-perf。GraalVM for JDK 17.0.20.1/21.0.12.1、GraalVM Enterprise Edition 21.3.19.1.1 も関連公式
IPA 10月21日に注意喚起。アプリの異常終了や、攻撃者によるPCの制御などのおそれがあるとして、早急な更新を呼びかけ公式
悪用状況 個別の悪用は確認されていない。ただしOracleは、パッチ済みの脆弱性を狙う攻撃が続いており、成功例はパッチ未適用の環境だったと警告公式

Java SEの55件・49件という数字は、複数の報道とTenableの分析で一致しています。ただし筆者は、Oracleのリスクマトリクス本体を直接確認できていません。CVEごとのCVSSは、Oracleの cpuoct2026verbose.html の「Oracle Java SE」の節で確認してください。

② 翌日の緊急アラート CVE-2026-91403

OracleはCPUの翌日、10月21日(米国時間)に、定例外のセキュリティアラート CVE-2026-91403 を出しました。対象はJava SE、GraalVM for JDK、GraalVM Enterprise Editionで、CVSS v3.1のベーススコアは9.1です。公式

報道によると、内容は次のとおりです。報道等

  • JavaのTLS実装(JSSE)で、eMudhraの侵害された中間CA 8件を信頼しないようにする修正
  • 認証なしでネットワーク経由で悪用されうる
  • 前日のCPUで出たばかりの版も対象:Java SE 8u511、8u511-perf、11.0.33、17.0.21、21.0.13、25.0.5、27.0.1、GraalVM for JDK 17.0.21/21.0.13、GraalVM Enterprise Edition 21.3.20
  • Oracleは、サポート対象外の版もおそらく影響を受けるとしている

一部の報道の見出しにある「更新版にも深刻度9.1の脆弱性」は、このことを指しています。つまり、CPUを当てただけでは足りず、緊急アラートの修正まで当てる必要があるということです。

修正版の番号について(要確認)

ある国内ブログは、緊急アラート後の追加修正版を 27.0.1.0.2、25.0.5.0.2、21.0.13.0.2、17.0.21.0.2、11.0.33.0.2 としています。Java 8は8u511が最新で、Java 26には修正版が出ないため25か27へ移行が必要、とも書いています。ただし筆者は、これらをOracleの公式文書で確認できていません。実際に適用する版は、OracleのSecurity Alertから辿れるJava SEのパッチ文書で確認してください。報道等

OpenJDK系ディストリビューションの場合

Eclipse Temurin、Amazon Corretto、Red Hat build of OpenJDK などは、それぞれの配布元が更新を出します。ある国内ブログによると、10月22日9時(JST)の時点で、主要な配布元には10月の更新がまだ出ていなかったとのことです。各配布元の告知を確認してください。報道等

eMudhraの件については、OpenJDKの告知にもとづく報道で、次の対応が示されています。報道等

  • 単体のJDK/JREを使っている場合は、できるだけ早く更新する。更新までは、JDKの lib/security にある blocked.certs を差し替えて、問題の証明書を手動でブロックできる
  • Debian、Fedora、RHEL、UbuntuなどのLinuxパッケージ版は、一般にOSの証明書ストアを使う。そのため ca-certificates の更新で対応できる

blocked.certs の差し替えは、配布元が示した手順とファイルに従って行ってください。手元で書き換えると、JDKの更新時に上書きされたり、整合性が崩れたりする可能性があります。筆者

確認の手順

# 実行中のJavaの版と配布元を確認
java -version
java -XshowSettings:properties -version 2>&1 | grep -E 'java.vendor|java.runtime.version'

# 1台に複数のJavaが入っていないか(Linuxの例)
update-alternatives --list java 2>/dev/null
ls /usr/lib/jvm/ 2>/dev/null

# アプリに同梱されたJRE(jlinkで作ったランタイムなど)も確認対象
find / -type f -name 'release' -path '*jre*' 2>/dev/null | head

アプリケーションサーバー、ビルドツール(Gradle・Maven)、IDE、CI、業務パッケージに同梱されたJREは、OSのJavaとは別に更新が必要なことがあります。Javaの更新後は、動いているJVMプロセスを再起動しないと反映されません。筆者

ライセンスの注意

IPAは、2019年4月16日以降のOracle Javaのリリースはライセンスが変わっていると注意しています。特に商用で利用する組織は、Oracleのライセンス条件を確認し、必要に応じて有償サポートの利用を検討するよう案内しています。Oracle JDKからOpenJDK系へ移行している組織では、どの配布元の更新を待つべきかを把握しておきましょう。公式

5. Go・curl・Pythonなど、そのほかの環境

eMudhraの件は、Node.jsとJavaに限りません。TLSクライアントとして動くものはすべて関係しえます。報道等筆者

環境 対応
Go 10月19日に、該当する証明書チェーンを拒否する修正版 1.27.3/1.26.10 が公開された。Goのバイナリーはランタイムを静的に組み込むため、修正版で再ビルドが必要報道等筆者
curl・OpenSSLを使うツール 多くはOSの証明書ストアを使う。ca-certificates を更新する筆者
Python OSのストアを使う場合は ca-certificates の更新。certifi パッケージの証明書を使う場合は、パッケージの更新状況を確認筆者
Cloudflareのクライアント WARP、1.1.1.1、cloudflared の更新版が公開済み。自前で管理するサーバーや信頼設定は利用者が更新する報道等
コンテナ ベースイメージに入っている証明書ストアは、イメージを作り直さないと更新されない筆者
# Debian / Ubuntu
sudo apt update && sudo apt-get install --only-upgrade ca-certificates

# RHEL系
sudo dnf update ca-certificates

# Alpine(コンテナでよく使われる)
apk upgrade ca-certificates

6. 対応の優先順位と手順

対応の優先順位(筆者の目安) 1 外部の入力・応答を 扱うNode.jsの 本番サービス Brotli RCE 2 インターネットに 面したJavaの サービス CPU+91403 3 証明書ストア Go・Python等の TLSクライアント eMudhra 4 CI・開発環境 配布物(SEA) の作り直し
図3 対応の優先順位の目安(筆者の評価。自社のリスクに合わせて調整してください)
順 対象 やること
1 外部の入力や応答を扱うNode.jsの本番サービス 修正版へ更新し、プロセスを再起動・再デプロイ。20.x・25.x は移行。PaaSは事業者の告知を確認
2 インターネットに面したJavaのサービス CPUと緊急アラートの両方の修正を適用。OpenJDK系は配布元の更新を確認し、それまでは配布元が示す暫定手順を検討
3 OSの証明書ストア、Go・Python等のTLSクライアント ca-certificates の更新、Goバイナリーの再ビルド、コンテナイメージの作り直し
4 CI・開発環境・配布物 CIランナーと開発端末のランタイム更新、SEA・スナップショット・同梱JREの作り直し

7. 情報の精査:誤り・未確認の情報

php2shellと同じ日に重なったこともあり、ネット上には誤った情報や、出典がはっきりしない情報も出回っています。筆者が一次情報と照らし合わせた結果を示します。

出回っている主張 判定 根拠
JavaやNode.jsもphp2shellの影響を受ける 確認できず どの一次情報にも記載がない。両者を並べて扱う記事も、同じ日に重なったことを示しているだけ
Node.jsの更新はphp2shellを受けた緊急対応 誤り 10月14日に予告済みの計画的なリリース
「Node.jsが10件超の高深刻度脆弱性を修正」 誤り 全部で10件、そのうちHighは4件
Node.jsのBrotliの件で、誰でもリモートから乗っ取れる 条件付き 研究者による実証はあるが、実際の攻撃は未報告。攻撃者が制御するBrotliデータを展開する処理がある場合に限られる
HKCERTは「中リスク」なのに、Node.jsは「High」 両方正しい 評価の物差しが異なる。矛盾ではない
Oracleの修正は1,295件/1,209件 両方正しい パッチ数と、重複を除いたCVE数の違い
Java SEは55件、うち49件が認証なしで悪用されうる 二次情報で一致 報道とTenableの分析で一致。Oracleのリスク表本体は筆者が直接確認できていない
Javaは更新版にも深刻度9.1の脆弱性がある 正しい CVE-2026-91403。CVSS 9.1はOracle公式で確認。CPU版が対象であることは報道で確認
Javaの追加修正版は 27.0.1.0.2 など/Java 26は修正なし 要確認 1つの国内ブログのみ。Oracleの公式文書で確認が必要
PHPチームが「前倒しで」14:00にリリースした 誤り PHP公式は予告の時点から14:00 UTCの予定だった

情報を見るときのコツ

今回は、短時間で多くの解説記事が出ました。その中には、生成AIで作られたとみられる記事や、出典が書かれていない記事もありました。対応の判断には、まずNode.jsの公式告知、Oracleのアドバイザリー、IPA・JPCERT/CCなどの一次情報を使い、二次情報は補足として扱うのが安全です。筆者

8. 対応チェックリスト

  • □ Node.jsを使うサービス・CI・開発環境・配布物を洗い出した
  • □ Node.jsを 22.23.4/24.22.1/26.12.1 に更新し、プロセスを再起動・再デプロイした
  • □ Node.js 20.x・25.x の環境について、移行計画を立てた
  • □ Brotliの展開処理(リクエストボディ・外部レスポンス)の有無を確認した
  • □ TLSの接続先に非正規のIPアドレス表記がないか確認した
  • □ SEA・スナップショットで配布しているアプリを作り直した
  • □ Javaの版と配布元(Oracle/OpenJDK系)を、同梱JREも含めて確認した
  • □ Oracle Javaに10月のCPUと CVE-2026-91403 の修正を適用し、JVMを再起動した
  • □ OpenJDK系の配布元の更新を確認した(未提供なら暫定手順を検討した)
  • □ OSの ca-certificates を更新し、コンテナイメージを作り直した
  • □ Goのバイナリーを 1.27.3/1.26.10 以降で再ビルドした
  • □ PaaS・マネージドサービスの対応状況を確認した

9. よくある質問

Q. フロントエンドのビルドにしかNode.jsを使っていません。更新は必要ですか?
必要です。ビルド中に外部からパッケージやデータを取得するので、TLSの検証やeMudhraの件が関係します。Brotliの件も、取得したデータを展開する処理があれば関係しえます。CIランナーと開発端末のNode.jsも更新してください。
Q. Node.jsの前段にWAFやCDNがあれば安全ですか?
リクエスト経由の攻撃はWAFで減らせる場合があります。ただし、Node.jsが外部から取得したレスポンス経由の攻撃は、前段のWAFを通らないため防げません。更新が必要です。
Q. Javaは10月20日のCPUを当てました。まだ何か必要ですか?
必要です。翌日の緊急アラート CVE-2026-91403 は、CPUで出た版も対象とされています。追加の修正を当ててください。
Q. OpenJDK系を使っています。Oracleのアラートは関係ありますか?
eMudhraの件は、JavaのTLS実装が問題の中間CAを信頼してしまうことが原因です。そのため、配布元を問わず関係しえます。各配布元の更新を確認してください。LinuxのパッケージでOSの証明書ストアを使っている場合は、ca-certificates の更新で対応できるとされています。
Q. eMudhraの証明書を使ったサイトにアクセスすると危険ですか?
問題は、侵害された中間CAの鍵で攻撃者が偽の証明書を作れることです。正規にeMudhraの証明書を使っているサイトが危険になるわけではありません。eMudhraは、影響する中間CAからWebサイト向けの証明書は発行していないと説明しています。不正な証明書が発行された形跡も、今のところ報告されていません。
Q. Node.jsのCVSSがわかりません。
Node.jsは今回、各CVEのCVSSスコアを公表していません。深刻度はNode.js独自の区分(High/Medium/Low)で示されています。社内の基準でCVSSが必要な場合は、NVDなどで後から付与されるスコアを確認してください。

10. 参考資料

本記事は2026年10月22日時点の公開情報に基づいています。コマンドと設定は一般的な例で、筆者は実行していません。最新の情報と正確な修正版は、Node.js・Oracle・各配布元の公式告知で確認してください。