結論から言えば、Node.jsを使うサーバやアプリを抱えている組織は、修正版（v26.3.1 / v24.17.0 / v22.23.0）への更新を計画に乗せるべきです。2026年6月18日、Node.js開発チームが12件の脆弱性をまとめて修正しました。クリティカル（緊急）はゼロですが、TLSの認証回避やサービス停止（DoS）につながる「高（High）」が2件含まれており、外部公開しているサービスほど優先度は上がります。
本記事は、Node.js公式のセキュリティリリース情報を一次情報として、情シスが「自社に影響があるか」「どこから手を付けるか」を短時間で判断できるよう要点を整理します。
この記事でわかること
- 今回修正された12件の脆弱性の全体像と、特に注意すべき「高」2件の中身
- 影響を受けるバージョンと、移行すべき修正版バージョン
- 自社のNode.js資産をどう棚卸しし、更新の優先順位をどう付けるか
何が起きたのか？
Node.jsは、サーバサイドのアプリケーションや社内ツール、各種SaaS製品の基盤として広く使われているJavaScript実行環境です。今回、メンテナンス中の3つのリリースライン（22系・24系・26系）に対して、合計12件の脆弱性を修正したセキュリティアップデートが公開されました。
深刻度の内訳は、高（High）が2件、中（Medium）が6件、低（Low）が4件で、クリティカルはありません。とはいえ「クリティカルなし＝急がなくてよい」ではない点に注意が必要です。下で触れるTLS関連の脆弱性は、認証・なりすまし対策の根幹に関わるためです。
影響を受けるバージョンと修正版
サポート中の各リリースラインに、それぞれ次の修正版が用意されています。多くの脆弱性が22・24・26の全ラインに影響します。
| リリースライン | 修正版バージョン |
|---|---|
| Node.js 26系（Current） | v26.3.1 |
| Node.js 24系（LTS） | v24.17.0 |
| Node.js 22系（LTS） | v22.23.0 |
あわせて、同梱ライブラリのOpenSSL（3.5.7）、nghttp2、llhttp、undici なども更新されています。Node.js本体を入れ替えれば、これら同梱コンポーネントの修正も同時に反映されます。すでにサポートが終了した古いライン（20系など）を使い続けている場合、修正が提供されない可能性が高く、より根本的なバージョン移行の検討が必要です。
特に注意すべき脆弱性はどれか？
優先して把握すべきは、深刻度「高」の2件と、TLS／mTLSの認証に関わる「中」です。いずれも、暗号化通信の相手をなりすまされる・通信を止められるといった、対外的な信頼性に直結します。
| CVE | 深刻度 | 概要 |
|---|---|---|
| CVE-2026-48933 | 高 | WebCryptoのAES処理で整数オーバーフローが起き、巨大な入力でプロセスが異常終了（DoS）するおそれ |
| CVE-2026-48618 | 高 | TLSのホスト名処理（Unicodeのドット区切りの扱い）の不備で、ワイルドカード証明書の検証が回避され得る |
| CVE-2026-48934 | 中 | 異なるサーバ名でのセッション再利用により、TLSのホスト名検証がバイパスされる |
| CVE-2026-48928 | 中 | SNIの大文字小文字の扱いの差により、mTLS（相互TLS認証）の認可がバイパスされ得る |
| CVE-2026-48615 | 中 | プロキシ接続のエラーメッセージに認証情報（資格情報）が漏えいする |
| CVE-2026-48619 | 中 | HTTP/2クライアントで、攻撃者が制御するORIGINフレームによりメモリが際限なく増加する |
このほか、HTTP/2のセッション後始末の不備、HTTPレスポンスのキュー汚染（競合状態）、Node.jsの権限モデル（permission model）のバイパスなど、低～中の脆弱性が複数修正されています。権限モデルを使ってファイルアクセスやネットワークを制限している環境では、低であっても自社の前提に関わるため中身を確認しておくと安心です。
情シスの現場目線での課題
正直なところ、この種の「基盤ランタイムの脆弱性」は、情シスにとって一番やっかいな部類です。Node.js本体を直接インストールして運用しているケースだけでなく、社内で動いている業務アプリ、監視ツール、ビルド環境、さらには購入したパッケージ製品の内部にNode.jsが同梱されていることも珍しくありません。「どこで何バージョンが動いているか」を正確に把握できていない組織が大半ではないでしょうか。
限られた人員で、自社開発分はもちろん、ベンダー製品に組み込まれたNode.jsまで追いかけるのは現実的にきつい作業です。だからこそ、闇雲に全部を急ぐのではなく、「外部公開しているか」「TLS／mTLSで認証しているか」という観点で当たりを付け、優先順位を切ることが肝心になります。
情シスはどうすべきか
まずやるべきは、対策の実行そのものより「棚卸し」です。次の順で当たりを付けると、限られた工数でも漏れを減らせます。
- 外部公開しているサービスから確認する：インターネットに面したNode.js製のWebサービス・API。今回のTLS／DoS系の影響を最も受けやすく、優先度が高い区分です。
- TLS・mTLSで認証している通信を洗い出す：クライアント証明書での相互認証やワイルドカード証明書を使っている箇所は、CVE-2026-48618 / 48928 / 48934 の影響評価を行う。
- ベンダー製品の内部利用を問い合わせる：自社で直接更新できない同梱版は、提供元の対応方針（更新提供の有無・時期）を確認する。
更新作業そのものは、本番反映前に検証環境での動作確認をはさむのが定石です。脆弱性の影響評価や社内への展開計画の立て方は、自前でチェックリストを作り込むより、IPAの公的な指針を土台にするのが近道です。中小規模の組織であれば、中小企業の情報セキュリティ対策ガイドラインが、資産管理や脆弱性対応の進め方を体系立てて整理しています。あわせて、利用者・開発者への地道な啓発（古いランタイムを使い続けない、更新を後回しにしない文化づくり）も中長期では効いてきます。
関連記事
- Apache HTTP Server 2.4.68公開 13件の脆弱性を修正（同じ「まとめて更新」型のアップデート対応）
- OpenSSL脆弱性CVE-2026-45447、署名検証でRCEの恐れ（Node.jsが同梱するOpenSSLも今回更新）
- 依存ライブラリの脆弱性更新、研究が示す実態（更新が後回しになりがちな現場の構造）
まとめ
- Node.jsに12件の脆弱性が判明し、2026年6月18日に修正版（v26.3.1 / v24.17.0 / v22.23.0）が公開された。クリティカルはないが、TLS認証回避とDoSにつながる「高」が2件ある。
- 多くが22・24・26の全ラインに影響する。本体を更新すれば同梱のOpenSSL等の修正も同時に反映される。サポート終了ラインは更新提供がなく、移行検討が必要。
- 外部公開サービスとTLS／mTLS認証を使う箇所から棚卸し・更新を進めるのが現実的。影響評価や展開はIPAの公的指針を土台にすると効率がよい。
出典
- Node.js 公式ブログ「June 2026 Security Releases」 https://nodejs.org/en/blog/vulnerability/june-2026-security-releases
- Security NEXT「『Node.js』に12件の脆弱性 – 修正版を公開」 https://www.security-next.com/186198
- IPA「中小企業の情報セキュリティ対策ガイドライン」 https://www.ipa.go.jp/security/guide/sme/index.html
