Node.js セキュリティ更新前にできること｜棚卸しとメンテナンス調整

はじめに

Node.js プロジェクトは、2026年11月11日（水）またはその直後に、Node.js 26.x / 24.x / 22.x のセキュリティリリースを公開すると予告しました。予告ページでは各系列の最高深刻度が High とされていますが、2026年11月5日時点では個別の CVE、影響を受ける機能、修正版のバージョン番号は公表されていません。

脆弱性の詳細が分からない段階でも、インフラ担当者が進められる準備はあります。Node.js がどのサーバーでどのバージョンで動いているか、更新するとアプリケーションに影響が出るか、停止を伴う場合に誰と調整するかを事前に整理しておけば、修正版の公開後は影響の判断と作業に集中できます。

筆者は Ubuntu / Linux サーバー上での Node.js アプリケーションの構築やバージョンアップ、セキュリティ更新への対応に携わってきましたが、その中で稼働中のバージョンやインストール先の特定、更新時の互換性の確認に苦労した経験があります。本記事では、その経験に基づく考え方と、公式ドキュメントで確認できる技術的事実を区別しながら、更新前の準備を整理します。

結論として、予告から正式公開までの期間に進めておきたいのは、対象環境の棚卸し、互換性とサービス影響の確認、必要に応じたメンテナンス枠の調整の 3 点です。稼働バージョンは、シェルで実行した node -v の結果で判断せず、実行中のプロセスを起点に、起動設定、インストール元、アプリケーションのランタイム情報を組み合わせて確認することを推奨します。正式公開後は、公開された CVE と影響条件を自社環境に当てはめ、事前に用意した手順で更新の可否と時期を判断します。

Node.js セキュリティリリース予告で判明していること

予告は Node.js 公式ブログに 2026年11月3日付で掲載されました。2026年11月5日時点で確認できる内容は次のとおりです。

参考: Node.js「Wednesday, November 11, 2026 Security Releases」
“Releases will be available on, or shortly after, Wednesday, November 11, 2026.”
（修正版は 2026年11月11日（水）またはその直後に公開されます。）
https://nodejs.org/en/blog/vulnerability/november-2026-security-releases

予告ページには公開時刻とタイムゾーンの記載がありません。日本時間では 11月12日以降に公開を確認することになる可能性もあるため、確認担当者の予定は 11月11日〜12日の両日を想定しておくと調整しやすくなります。

また、同じページでは EOL の系列が常に影響を受けるものとして扱われています。Node.js 20.x や 25.x などの EOL の系列には修正版が提供されないため、これらの環境は「更新」ではなく「サポート中の系列への移行」として、別の計画で扱う必要があります。

現在サポート中の系列とサポート終了予定

2026年11月5日時点の Node.js Releases ページと Release Schedule に基づく、今回の予告対象の系列は次のとおりです。26.x は 2026年10月28日の v26.13.0 で LTS へ移行しました。

参考: Node.js「Node.js Releases」
“Production applications should only use Active LTS or Maintenance LTS releases.”
（本番環境のアプリケーションでは、Active LTS または Maintenance LTS のリリースのみを使用してください。）
https://nodejs.org/en/about/previous-releases

22.x は 2027年4月末にサポート終了を迎える予定です。今回は 22.x の修正版を適用しつつ、24.x 以降への移行時期もあわせて関係者と共有しておくと、次回以降の調整を進めやすくなります。前回（2026年10月）のセキュリティリリースで修正された脆弱性と影響判定は『Node.js 脆弱性（2026年10月）｜影響確認と更新判断』、EOL を迎えた Node.js 20 の扱いは『Node.js 20 EOL と3月のDoS脆弱性への対処手順』で解説しています。

Node.js の稼働バージョンとインストール先を棚卸しする

棚卸しの目的は、修正版が公開されたときに「どのサーバーの、どのプロセスを、誰が、どの方法で更新するか」をすぐに判断できる状態にすることです。バージョン番号だけを集めても、インストール元や起動方法が分からなければ、更新手順と影響を見積もれません。筆者は、セキュリティ情報が公開されてから対象環境を探し始めるのではなく、事前に導入状況とバージョンを把握しておくことが重要だと考えています。

棚卸しで確認する項目

稼働サーバーとアプリケーション

Node.js が動いているサーバー、アプリケーション名、本番・検証などの環境区分を一覧にします。Web アプリケーションだけでなく、社内ツールや運用スクリプトとして Node.js を使っているサーバーも対象に含めます。

稼働中のバージョン

サービスとして実行中のプロセスが使っている Node.js のバージョンです。後述のとおり、シェルで確認したバージョンと一致しない場合があります。

インストール元と配置場所

OS のパッケージ（apt）、Node.js 公式のバイナリ、バージョン管理ツール、コンテナイメージなどの導入方法と、実行ファイルのパスです。修正版の入手先と更新手順は、導入方法によって変わります。

起動方法

systemd のユニット、プロセスマネージャー、cron、コンテナなど、プロセスを起動している仕組みです。再起動の方法と、更新後に新しいバージョンが読み込まれるかどうかに関係します。

担当者

Node.js 本体の更新、アプリケーションの互換性確認と動作確認、利用部門や顧客との連絡を担当する人です。サーバー管理者とアプリケーション担当者が異なる場合は、両方を記録します。

node -v だけでは稼働中の Node.js を判断できない理由

node -v が表示するのは、コマンドを実行したユーザーの環境変数 PATH で最初に見つかった node のバージョンです。サービスとして動いているプロセスは、systemd のユニットに記載されたパスやサービス実行ユーザーの環境で起動されるため、ログインしたシェルとは別の node を使っていることがあります。次のような状態では、node -v の結果とサービスで稼働中のバージョンが一致しません。

• apt で導入した /usr/bin/node と、手動で配置した /usr/local/bin/node が共存している
• バージョン管理ツールでユーザーごとに Node.js を導入し、systemd のユニットには特定バージョンのパスを直接記載している
• Node.js の実行ファイルを更新したが、サービスを再起動しておらず、プロセスが更新前のバイナリで動き続けている
• アプリケーションがコンテナで動いており、ホストとは別の Node.js を使っている

3 つ目は Linux のプロセスの仕組みによるものです。実行中のプロセスは起動時に読み込んだ実行ファイルで動作し続けるため、ファイルを置き換えただけでは稼働中のバージョンは変わりません。Linux のマニュアルでは、/proc/[pid]/exe は実行中のコマンドの実パスを指すシンボリックリンクで、元のパス名が削除された場合は「 (deleted)」が付くと説明されています。

「 (deleted)」は、プロセスの起動後に実行ファイルのパスが削除された状態を示すもので、原因までは示しません。パッケージの更新でファイルが置き換えられた可能性もあれば、手動での削除や別の作業による可能性もあります。表示された場合は、パッケージの更新履歴（/var/log/apt/history.log など）や作業記録と、プロセスの起動日時を照合して原因を判断します。

参考: Linux manual page「proc_pid_exe(5)」
“If the pathname has been unlinked, the symbolic link will contain the string ‘ (deleted)'”
（パス名が削除された場合、シンボリックリンクには「 (deleted)」という文字列が含まれます。）
https://www.man7.org/linux/man-pages/man5/proc_pid_exe.5.html

Ubuntu / Linux で稼働中の Node.js バージョンを確認する手順

以下は、実行中のプロセスを起点に、読み取りのみで Node.js の利用状況を確認する手順です。<PID> や <サービス名> は環境に合わせて置き換えてください。出力形式は OS やバージョンによって異なるため、本記事では出力例を掲載していません。各コマンドの仕様は、Ubuntu 24.04 LTS のマニュアル（ps、systemctl、dpkg、apt-cache）で確認できます。

ps -eo pid,user,lstart,args | grep '[n]ode'

sudo readlink /proc/<PID>/exe

systemctl cat <サービス名>.service

systemctl show -p ExecStart -p User -p WorkingDirectory -p Environment <サービス名>.service

dpkg -S <手順 2 で確認したパス>

apt-cache policy nodejs

ps のコマンドラインや systemctl show の環境変数には、パスワードやトークンなどの機密情報が含まれる場合があります。棚卸しの記録やチケットに貼り付けて共有する際は、該当する値を伏せてから記録してください。

確認方法ごとに分かることと限界

稼働中のプロセスが使っている Node.js のバージョンを、1 つのコマンドで確実に特定する方法はありません。確認方法ごとに分かる範囲が異なるため、組み合わせて判断します。

稼働中のプロセスのバージョンを最も直接的に確認できるのは、アプリケーション自身が出力するランタイム情報です。Node.js の process.version を起動時のログやヘルスチェックの応答に含めている場合は、その値を確認します。このような仕組みがない場合は、実行ファイルのパスに「 (deleted)」が付いていないこと、プロセスの起動日時がパッケージの更新日時より後であることを確認したうえで、パッケージ管理上のバージョンを稼働バージョンとみなします。ランタイム情報の出力を追加するかどうかは、アプリケーション担当者と相談します。

OS 標準のリポジトリの nodejs パッケージを使っている場合、修正はディストリビューション側から提供されます。Node.js プロジェクトの修正版とは提供時期やバージョン表記が異なることがあるため、配布元のセキュリティ情報も確認対象に加えます。外部のリポジトリを使っている場合も、そのリポジトリでの修正版の提供状況を確認します。コンテナで動かしている場合は、ホストではなくコンテナイメージ内の Node.js が対象となるため、ベースイメージのタグと、イメージの再ビルド・再デプロイの手順を記録します。

なお、これらの確認で分かるのは実行環境の情報です。アプリケーションが Node.js のどの機能を使っているかや、今回の脆弱性の影響を受けるかどうかは判断できません。

アプリケーション・依存ライブラリとの互換性を確認する

互換性の確認は、修正版の公開前に「どの範囲の更新なら適用できる見込みか」と「公開後に何をテストするか」を決めておく作業です。互換性を保証する万能な確認コマンドはないため、宣言されている対応範囲、依存関係、テスト手順を組み合わせて判断します。筆者は、Node.js 本体のバージョンだけでなく、アプリケーション、フレームワーク、依存ライブラリとの組み合わせを事前に確認しておく必要があると考えています。

系列内の更新か、系列をまたぐ移行か

セキュリティリリースは、サポート中の系列ごとに修正版として提供されます。同じ系列内の更新であれば、メジャーバージョンが変わる移行より確認範囲を絞れるのが一般的です。ただし、2026年10月のセキュリティリリースでは c-ares などの同梱コンポーネントの更新も含まれていたように、修正版の内容によっては確認範囲が広がるため、影響がないとは言い切れません。

EOL の系列を使っている場合は、適用できる修正版がないため、サポート中の系列への移行が必要です。メジャーバージョンの変更を伴う移行は、今回の予告から公開までの短い期間で完了させる前提にせず、アクセス制限などのリスク低減策とあわせて別の計画として扱うことを推奨します。

互換性の確認観点

engines フィールドは、npm のドキュメントでプログラムが動作する Node.js のバージョンを指定する項目とされています。ただし記載は開発者の宣言であり、テストの範囲を示すものとは限らないため、ベンダーのサポート情報がある場合はそちらを優先して確認します。

ネイティブモジュールは、更新後に再ビルドが必要かどうかが実装方式によって異なります。Node.js のドキュメントでは、Node-API は Node.js のバージョン間で ABI の安定性を保証する一方、V8 や libuv などそれ以外の API はメジャーバージョン間での ABI の安定性を保証しないと説明しています。そのため、Node-API のみを使うアドオンはメジャーバージョンが変わっても再ビルドが不要な設計ですが、それ以外の API を使うアドオンは系列をまたぐ移行で再ビルドが必要になる場合があります。まずはネイティブモジュールの利用有無を確認し、利用している場合は各モジュールの実装方式と対応状況をアプリケーション担当者と確認します。利用の有無は、次のコマンドで .node ファイルを探して確認できます。

find <アプリケーションのディレクトリ>/node_modules -name '*.node' -type f

このコマンドで分かるのは、.node 拡張子のファイルの有無と配置場所です。そのファイルがどの Node.js 向けにビルドされたかや、再ビルドの要否までは判断できません。

検証環境での確認結果を本番環境の判断に使う場合は、両者の Node.js の系列、インストール元、OS のバージョンが一致しているかを先に確認します。差がある場合は、その差を記録したうえで、本番適用時に追加で確認する項目を決めておきます。

npm audit と Node.js 本体の脆弱性対応は別の確認

npm audit は、プロジェクトの依存パッケージを npm レジストリの脆弱性情報と照合するコマンドです。照合の対象は依存パッケージであり、Node.js 本体（ランタイム）の更新要否はこのコマンドの結果では判断できません。npm audit で問題が報告されなくても、セキュリティリリースへの対応は別に判断します。

参考: npm Docs「npm-audit」
“submits a description of the dependencies configured in your project to your default registry”
（プロジェクトで設定された依存関係の情報を、既定のレジストリへ送信します。）
https://docs.npmjs.com/cli/v11/commands/npm-audit/

また、同じドキュメントでは npm audit fix が内部で npm install を実行すると説明されており、依存パッケージが更新されます。Node.js 本体の更新と同じメンテナンスで実施すると、問題が起きた際に原因の切り分けが難しくなるため、本番環境では作業を分けることを推奨します。package-lock.json の削除や依存関係の再生成も、アプリケーション担当者と合意したうえで実施してください。

メンテナンス枠の確保と関係者調整

メンテナンス枠の要否は、更新に伴うサービス停止の有無と、問題が起きたときの影響によって変わります。一律に確保するのではなく構成と更新方法から判断し、必要な場合は修正版の公開前に候補日時と関係者の合意を準備しておきます。筆者は、停止を伴う更新では、顧客や関係者と調整してあらかじめメンテナンス時間を確保しておくことが重要だと考えています。修正版の公開後に調整を始めると、合意を得るまでの時間がそのまま更新までの待ち時間になるためです。

サービス停止の要否を判断する材料

いずれの構成でも、Node.js の実行ファイルを更新しただけでは、プロセスは更新前のバージョンで動き続けます。修正を反映するにはプロセスの再起動が必要なため、停止影響を抑えられる構成でも、再起動のタイミングは作業計画に含めます。

作業時間と事前検証の見積もり

作業時間は、更新作業そのものより前後の確認に左右されます。次の時間を積み上げて、メンテナンス枠の長さを見積もります。

• 更新前のバックアップや状態の記録
• Node.js の更新とプロセスの再起動
• 更新後の稼働バージョンとサービス正常性の確認
• アプリケーション担当者や利用部門による動作確認
• 問題が発生した場合の切り戻しと、切り戻し後の確認

事前検証を実施できる環境がある場合は、修正版の公開後に検証環境で更新し、所要時間と確認項目を実測してから本番の枠を確定すると、見積もりの精度が上がります。検証環境がない場合は、確認項目を減らすのではなく、本番作業の中で動作確認と切り戻し判断の時間を確保します。

切り戻し方法の確認

切り戻しの方法は導入方法によって異なるため、棚卸しで確認したインストール元ごとに、次の点を事前に確認します。

• apt で導入している場合は、更新前のバージョンのパッケージを取得できるか
• 公式バイナリを手動で配置している場合は、更新前のバイナリを残しておくか
• コンテナで動かしている場合は、更新前のイメージを再デプロイできるか
• 切り戻しの判断基準（どの事象が起きたら戻すか）と判断の期限

なお、セキュリティ修正を含む更新を切り戻すと、脆弱性が残った状態に戻ります。切り戻した場合の暫定的なリスク低減策と、再適用の予定もあわせて決めておきます。

事前に決めておく役割と連絡

作業者と判断者が明確でないと、問題が起きたときに対応が止まります。次の役割を事前に決め、連絡先とあわせて記録しておきます。

更新作業の担当

Node.js 本体の更新とプロセスの再起動を実施します。インストール元ごとの手順を把握している担当者を割り当てます。

動作確認の担当

更新後にアプリケーションの主要な機能を確認します。サーバー管理者だけで確認できない場合は、アプリケーション担当者や利用部門に依頼します。

切り戻しの判断者

更新後に問題が見つかった場合に、切り戻すか、原因を調査して継続するかを判断します。作業者と別の担当者にする場合は、作業中に連絡が取れることを確認しておきます。

顧客・関係部署への連絡担当

停止を伴う場合の事前連絡、作業開始・完了の報告、問題発生時の連絡を担当します。

修正版の公開日時や脆弱性の詳細が未確定の段階で連絡する場合は、「11月11日以降に公開予定のセキュリティ更新に伴う作業の候補日」として案内し、正式公開後に作業の要否と日時を確定する二段階の連絡にすると、予定が変わっても調整し直しやすくなります。

更新前チェックリスト

ここまでの確認項目を、棚卸し、互換性、サービス影響、関係者調整の順に一覧にまとめました。確認結果を「記録する内容」の列に沿って残しておくと、次回以降のセキュリティリリースでも同じ記録を更新して使えます。

予告から更新完了までの判断フローとリリース当日の確認

予告から更新完了までの作業は、修正版の公開前に進められる本番環境を変更しない調査・調整と、公開後にしかできない作業に分かれます。公開前の準備を済ませておくことで、公開後は影響の評価と更新の判断に時間を使えます。

更新前から公開後までの判断フロー

公開前の段階はサーバーの情報を参照する調査と関係者との調整が中心で、本番環境への変更は伴いません。修正版の適用や再起動など環境を変更する作業は、アドバイザリの内容と修正版がそろってから実施します。

正式リリース後にアドバイザリで確認する項目

2026年10月のセキュリティリリースでは、予告と同じ URL のページが、修正版の公開後に脆弱性の詳細を含む内容へ更新されました。今回も予告ページを起点に、次の項目を確認します。

• 個別の CVE と、それぞれの深刻度
• 影響を受ける系列とバージョン範囲
• 影響を受ける機能と悪用の条件（特定の API、プロトコル、オプションの利用など）
• 系列ごとの修正版のバージョン番号
• 同梱コンポーネントの更新の有無
• 回避策や緩和策の記載の有無

更新の優先順位は CVSS だけで決めない

CVSS などの深刻度は脆弱性の性質を示す指標ですが、自社環境で悪用が成立するかまでは示しません。優先順位は、深刻度に加えて次の観点を組み合わせて決めることを推奨します。

• 影響を受ける機能を、自社のアプリケーションが使っているか
• 該当サーバーがインターネットや不特定の利用者からアクセスできるか
• 処理するデータの重要度と、停止した場合の業務影響
• 悪用の報告や攻撃コードの公開状況

アプリケーションが影響を受ける機能を使っているかを確認できない場合は、影響を受ける前提で扱うと判断を誤りにくくなります。影響を受けないと判断した環境でも、修正版の適用自体は計画的に進めます。検証環境で問題がなければ、その結果と事前に調整した枠をもとに本番への適用を判断します。

更新後に稼働バージョンとサービス正常性を確認する

更新後は、ファイルが更新されたことではなく、サービスとして動いているプロセスが修正版で稼働していることを確認します。棚卸しで使ったコマンドで、更新前の記録と比較します。

sudo systemctl restart <サービス名>.service

ps -eo pid,user,lstart,args | grep '[n]ode'

sudo readlink /proc/<PID>/exe

systemctl status <サービス名>.service

まとめ

Node.js のセキュリティリリースは、予告から公開までの期間に準備を進めておくことで、公開後の影響判断と更新を短時間で進めやすくなります。脆弱性の詳細が未公表の段階でも、対象環境の棚卸し、互換性とサービス影響の確認、メンテナンスの調整は進められます。

• 11月11日の予告対象は 26.x / 24.x / 22.x で、最高深刻度は High です。
• CVE や修正版の番号は未公表のため、公開後に公式情報で影響を確認します。
• 稼働中のバージョンは node -v ではなく実行中のプロセスを起点に確認します。
• インストール元と起動方法を記録すると、更新手順と影響を見積もれます。
• npm audit の結果と Node.js 本体の更新要否は分けて判断します。
• 停止の要否は構成で変わりますが、修正の反映には再起動が必要です。
• 優先順位は CVSS だけでなく、悪用の条件と自社環境を照合して決めます。

以上、最後までお読みいただきありがとうございました。