Node.jsの脆弱性修正でMacのnvmを24.22.1に。入れただけでは、動いているAIのセッションは古い版のままだった

Node.jsの脆弱性修正でMacのnvmを24.22.1に。入れただけでは、動いているAIのセッションは古い版のままだった AI活用術

課題

自分のMacでは、AIのエージェント（Claude Code）のセッションをいくつも同時に開いている。プロジェクトごとに1つずつで、このブログ用、SNSと動画用、アプリ開発用、それから全体をまとめて管理する用。

図を作るスクリプトや、手元だけで見る管理画面のサーバーなど、Node.js（JavaScriptをパソコンやサーバーの上で動かすための実行環境）で動くものもいくつかある。

2026年10月21日、Node.jsからセキュリティの修正が出た。同じ日にはPHPの緊急の修正も出ていて、ブログのPHPを切り替えたのが22日。23日になって、自分はAIに「自分たちには関係なさそうだけど、念のため確認してほしい」と頼んだ。

結果は、関係なさそう、では済まなかった。手元のMacのNode.jsは、修正前の古い版だった。そして新しい版を入れたあとにも、もう1つ見落としやすいところがあった。

解決できるようにすること

自分のMacでNode.jsを使い、AIのエージェントも動かしている人が、Node.jsの修正が出たときに次の4つを自分でできるようにする。

  1. Node.jsが実際にどこで動いているかを、公開しているサービスと手元のMacに分けて洗い出す
  2. nvmで新しい版を入れて、入ったことを確かめる
  3. すでに動いているAIのセッションやサーバーが、本当に新しい版に切り替わったかを確かめる
  4. 全体用のパッケージ、AIが開くシェルのPATH、古い版の消し方でつまずかない

先に結論

  • Node.js公式の修正版は22.23.4・24.22.1・26.12.1。直した脆弱性は10件で、そのうち4件がHigh
  • 公開しているブログ（WordPress、PHP）とアプリの紹介サイト（静的なファイル）は、Node.jsを動かしていなかった。動いていたのは手元のMacで、版はnvmのv24.20.0。修正版より古かった
  • nvmで24.22.1を入れると、新しく開いたターミナルは24.22.1になった。でも、開いたままのAIのセッションと、それと一緒に起動したプログラムは、24.20.0のままだった
  • 25日間動き続けていた手元のサーバーは、起動し直して24.22.1に切り替えた
  • まだ済んでいないこと: AIのセッションの開き直し、動画の書き出しの確認、古い版の削除。古い版は、全部が切り替わるまで消さない（追記: その後のMacの再起動で全部のセッションが切り替わり、古い版は消した。残りは動画の書き出しの確認）

この記事でわかること

  • 公開しているサービスと手元のMacで、Node.jsが動いているかの分け方（図あり）
  • nvmで入れたあとに見る3か所
  • 動いているプロセスが、どの版のnodeを使っているかの調べ方
  • 全体用のパッケージが引き継がれない、AIのシェルはPATHを受け継ぐ、という2つのつまずき
  • 古い版をすぐ消さなかった理由と、まだ済んでいないこと

こう思う人もいるかもしれない。

「新しい版を入れて、node -vが新しい番号になれば、それで終わりでは？」

新しく開いたターミナルでは、たしかにそう見える。ただ、それは「これから起動するもの」の話。すでに動いているAIのセッションやサーバーは、起動したときのnodeを使い続ける。AIのエージェントを開きっぱなしで作業する人ほど、ここで取り残しが出やすい。

10月21日に出た、Node.jsのセキュリティの修正

Node.js公式のお知らせ（Wednesday, October 21, 2026 Security Releases、2026年10月23日に確認）の要点は、次のとおり。

  • 26.x・24.x・22.xの3つの系列に修正版が出た。修正版は26.12.1・24.22.1・22.23.4
  • 直した脆弱性は10件。深刻度の内訳はHigh 4件、Medium 3件、Low 3件
  • c-ares・OpenSSL・Undiciなど、Node.jsが中で使っている部品の更新も含まれる
  • サポートの終わった版（End-of-Life）は、セキュリティの修正が出るたびに常に影響を受ける、と書かれている。修正版が出るのは上の3つの系列だけ

High の4件は、次のとおり。24.xは、この4件すべての対象に入っている。

  • CVE-2026-111497: Brotli（データの圧縮形式の1つ）を展開するときに、範囲外への書き込みが起き、遠隔でのコード実行につながりうる
  • CVE-2026-106069、CVE-2026-105483: TLS（暗号化した通信）の証明書で、接続先のホスト名の確認をすり抜けられる。IPアドレスの変わった書き方（全角の数字など）が通ってしまう
  • CVE-2026-105482: dns.resolveに渡した名前が、NUL文字（目に見えない区切りの文字）のところで切り詰められる

お知らせには、設定で避ける方法は書かれていない。AIの調査の記録にも「回避策なし」とあって、方針は修正版への更新になった。

まず、Node.jsがどこで動いているかを分けた

Node.jsの修正が出たときにたどった順番の図。最初に、Node.jsがどこで動いているかを、公開しているサービスと手元のMacに分ける。ブログ（WordPress、PHP）とアプリの紹介サイト（静的なファイル）はNode.jsを動かしておらず対象外。手元のMacはnvmのv24.20.0で、修正版24.22.1より古く対象。そのあと、新しい版を入れる、既定の版と新しいシェルの版を見る、部品と道具を確かめる、の3つは済み。動いているものを1つずつ起動し直すのは一部まだ、全部が切り替わってから古い版を消すのはまだ

AIが最初にやったのは、Node.jsが実際に動いている場所の洗い出し。結果はこうなった。

  • ブログ: WordPressで、動いているのはPHP。Node.jsは使っていない
  • アプリの紹介サイト: Firebase Hostingに置いた静的なファイル。サーバーの上でNode.jsのプログラムは動いていない
  • 手元のMac: nvm（Node.jsの版を入れ分けて切り替える道具）で入れたv24.20.0。修正版の24.22.1より古い

Macの上でNode.jsを使っていたのは、次のようなもの。

  • このブログの図やアイキャッチ画像を作るスクリプト（画像の処理にsharpという部品を使う）
  • 動画を書き出すスクリプト
  • 全体を管理するプロジェクトの、手元だけで見る管理画面のサーバー。25日間、止めずに動いていた
  • AIのセッションと一緒に起動する、連携用の小さなプログラム

公開しているサービスだけを見れば、たしかに関係なかった。手元のMacまで見て、初めて対象が見つかった。

もう1つ、見落としやすい点がある。公開先のサーバーでNode.jsが動いていなくても、そこへ公開するための道具は手元のNode.jsで動いていることがある。今回でいえば、アプリの紹介サイトを扱うfirebase-tools（Firebaseを操作するコマンド）がそれに当たる。

手元の管理画面のサーバーは、自分のMacの中からしかつながらない設定（localhostだけで待ち受け）になっている。外から直接届く場所ではないので、公開しているサーバーよりは危険が小さいはず、というのがAIの見立て。ただ、TLSやBrotliの問題は、Node.jsが外のサーバーとやり取りするときにも関わりうる。パッケージを取ってくる、APIを呼ぶ、といった処理は手元のスクリプトでもふつうにやる（ここもAIの見立てで、確かめたわけではない）。

自分は、手元のNode.jsを24.22.1に更新して、動いているものを順に起動し直す案を選んだ。

nvmで24.22.1を入れて、3か所を見た

AIがnvmで、公式から24.22.1を入れた。

nvm install 24.22.1

nvmは入れるときに、ダウンロードしたファイルのチェックサム（中身が壊れたり差し替えられたりしていないかを確かめる値）を、公式の値と比べる。今回は一致した。出力に「Checksums matched!」のような行があるかを見ておくといい。

入れたあとに見たのは、次の3か所。

  1. 既定の版: nvm alias defaultで見る。自分の環境は既定がlts/*（入っている中で一番新しいLTS版）で、入れたあとは24.22.1を指すようになった。ここが24.20.0のように番号で固定されていると、新しく開くターミナルも古い版のままになる
  2. 新しいターミナルの版: 新しく開いたターミナルでnode -v
  3. 部品が動くか: sharpのようなネイティブの部品（Node.jsの外で作られた処理を呼び出す部品）を使うスクリプトを、新しい版で1回動かす。自分の環境では、sharpは24.22.1でも動いた

古いv24.20.0は、この時点では消さずに残した。理由はあとで書く。

入れたのに、動いているものは古い版のままだった

新しい版を入れても、動いているものは切り替わらないことを示す表。新しく開いたターミナルは入れた直後から24.22.1。開いたままのAIのセッションと、セッションと一緒に起動する連携用のプログラムは、対応後も24.20.0のままで、開き直しはまだ。25日間動き続けていた手元の管理画面のサーバーは、担当のAIが起動し直して24.22.1になった。図・画像を作るスクリプトは24.22.1の場所を明示して実行。動画の書き出しは未確認。全体用に入れていたfirebase-toolsは旧版にだけあり、npxで使っていたので入れ直していない

ここが、今回の記録でいちばん伝えたいところ。

新しく開いたターミナルは24.22.1になった。でも、作業していたAIのセッションの中でnodeを呼ぶと、24.20.0のままだった。この記録を書いていた、このブログのAIのセッション自身もそうだった。

理由は、PATH（コマンドを探しに行く場所の一覧）にある。nvmは、シェルが起動するときに「この版のnodeの場所」をPATHへ入れる。Claude Codeのセッションは、起動したときのPATHを持ったまま動き続ける。あとから新しい版を入れても、開いたままのセッションが探しに行くのは古い版の場所、ということになる。

同じことは、セッションと一緒に起動する連携用のプログラムにも起きていた。セッションの起動時に立ち上がるので、こちらも24.20.0のまま。切り替えるには、セッションを開き直すしかない。

開き直しは自分の操作になる。今回は、これを後回しにすると決めた。それまでの間、このブログのAIがNode.jsのスクリプトを動かすときは、24.22.1の場所をはっきり指定して使うことにした。

~/.nvm/versions/node/v24.22.1/bin/node スクリプト名.js

一方、25日間動き続けていた管理画面のサーバーは、そのプロジェクトを担当しているAIが24.22.1で起動し直した。古いプロセスは、25日間24.20.0で動いていたもの。起動し直したあとは、ビルドにエラーが無く、応答が「401（認証が必要）」になることを確かめている。このサーバーはログインしないと中を見せない作りなので、401が返るのが正常な状態になる。

SNSと動画のプロジェクトのAIからは、常に動いているNode.jsのプロセスは無い、という返事だった。動画の書き出しは、次に書き出すときにPATHの先頭に24.22.1を置いて、前と同じ絵になるかを確かめる段取りになっている。

動いているものが、どの版を使っているかの調べ方

ここは、今回の記録をもとにAIと整理した一般的な調べ方。記事を書くときに、読むだけのコマンドで、Macでこの方法が使えることをAIが確かめている。

1. 起動した時刻を見る

ps -axo pid,lstart,command | grep "[n]ode"

lstartが起動した時刻。新しい版を入れた時刻より前に起動したものは、古い版を使っている可能性が高い。commandの欄に…/.nvm/versions/node/v24.20.0/bin/nodeのような場所がそのまま出ていれば、版も読み取れる。

2. 実際に読み込んでいるnodeの場所を見る

commandの欄にnodeとしか出ないこともある（PATHから探して起動した場合）。そのときは、1で見つけたプロセスの番号（PID）を使って、実体を見る。

lsof -p <PID> | grep txt

最初のほうの行に、実際に読み込んでいるnodeのファイルの場所が出る。Linuxならls -l /proc/<PID>/exeでも見られる。

3. AIのセッションの中で見る

AIにwhich nodeとnode -vを実行してもらう。同じMacでも、セッションごとに違う答えが返ることがある。今回が、まさにそうだった。

つまずき1: 全体用に入れたパッケージは、新しい版に引き継がれない

nvmでは、npm install -gで入れた全体用のパッケージは、版ごとの場所に入る。新しい版を入れても、自動では引き継がれない。

今回、古い24.20.0にはfirebase-toolsが入っていたけれど、24.22.1には無かった。

困るかどうかを、アプリ開発のプロジェクトのAIに確かめた。そのプロジェクトは、もともとnpx -y firebase-toolsの形で、その都度取ってきて使っていた。だから入れ直しは要らなかった。新しい版で、Firebaseのプロジェクトの作成や設定の取得まで動いたことも確かめている。

全体用のパッケージに頼っている場合は、nvmに次のような機能がある（今回の作業では使っていない）。

# 古い版に入っている全体用のパッケージを見る
nvm exec 24.20.0 npm ls -g --depth=0

# 新しい版を入れるときに、古い版のパッケージを入れ直す
nvm install 24.22.1 --reinstall-packages-from=24.20.0

つまずき2: AIに「新しいシェルで確かめて」と頼んでも、古い版が出る

管理用のプロジェクトのAIは、「新しいシェルなら既定で24.22.1になる」という案内を確かめようとして、まず24.20.0を見た。そこで一度、案内のほうが間違っているのでは、と疑った。

原因は、AIが起動した子のシェルが、セッションのPATHをそのまま受け継いでいたこと。env -iで環境の受け継ぎを切ってから起動し直すと、24.22.1になった。

自分で確かめるなら、たとえば次のような形になる（nvmがどのファイルで読み込まれるかは、シェルの設定によって違う）。

env -i HOME="$HOME" zsh -ic 'which node; node -v'

いちばん素直なのは、ターミナルのアプリで新しいウィンドウを開いてnode -vを見ること。AIの言う「新しいシェル」は、人間が新しく開くターミナルとは別物、と覚えておくと混乱しにくい。

古い版は、すぐに消さなかった

v24.20.0を消すこと自体は決めている。

ただ、先に消すと、開き直していないセッションが古い版の場所でnodeを探しに行って、「nodeが見つからない」になる。開き直していないセッションは、まだ24.20.0の場所を見ているため。

そこで、消すのは全部のセッションを開き直したあと、と決めた。忘れないように、日付を決めないリマインダーとして登録してある。

まだ済んでいないこと

この記事を書いている時点で、次の3つはまだ済んでいない。

  • AIのセッションの開き直し: 自分の操作で、後回しにしている。それまでは、セッションと連携用のプログラムは24.20.0で動いている
  • 動画の書き出しの確認: 次に書き出すときに、24.22.1で前と同じ絵になるかを見る
  • 古い24.20.0の削除: 全部のセッションを開き直したあとに消す

つまり今も、Macの上には修正前のNode.jsで動いているプロセスが残っている。最初は残りの作業が済んでから書く案だったけれど、記事にするなら急いだほうがいい、と自分が判断した。そこで、済んでいない作業は済んでいないまま書くことにした。

追記（2026年10月23日）: その後、Macが再起動したことで、開いていたAIのセッションと連携用のプログラムは、すべて起動し直しになった。確かめると、nodeは24.22.1を指し、24.20.0で動いているプロセスは0本、25日動いていた手元のサーバーも24.22.1で動いていた。条件がそろったので、nvm uninstall 24.20.0で古い版を消した。残っているのは、動画の書き出しの確認だけになる。

確かめられていないこと

  • 攻撃を受けたかどうか: 今回は版を上げて切り替えただけで、何かが起きたかどうかは調べていない
  • 手元のサーバーの危険の大きさ: localhostだけで待ち受けているから危険が小さい、というのはAIの見立てで、確かめたわけではない
  • 修正前の版で、問題のある処理を通っていたか: 手元のスクリプトが、Brotliの展開やTLSの接続を、どの場面で使っていたかは調べていない

チェックリスト

修正が出たら

  1. 公式のお知らせで、修正版の番号と、自分の系列が対象かを見る。サポートの終わった系列には修正版が出ない
  2. Node.jsが動いている場所を、公開しているサービスと手元に分けて書き出す。公開先へ送る道具が、手元のNode.jsで動いていないかも見る
  3. 手元の版をnode -vで見て、修正版と比べる

入れるとき

  1. nvm install <修正版>で入れる。チェックサムの一致の行を見る
  2. nvm alias defaultで、既定が新しい版を指すかを見る
  3. 古い版で入れた全体用のパッケージを書き出す。必要なら入れ直す。npxで使っているなら要らない
  4. ネイティブの部品を使うスクリプトを、新しい版で1回動かす

入れたあと

  1. 動いているNode.jsのプロセスを書き出し、起動した時刻と、使っているnodeの実体を見る
  2. 長く動いているサーバーは起動し直し、応答を確かめる
  3. AIのセッションは開き直す。開き直すまでは、新しい版の場所を明示して使う
  4. 「新しいシェル」の確認は、新しく開いたターミナルか、env -iで受け継ぎを切ったシェルで行う
  5. 全部が切り替わってから、古い版を消す

こんな人に向いている

自分のMacで、Claude CodeなどのAIのエージェントを使い、nvmでNode.jsを入れている人に向いている。特に、セッションや手元のサーバーを開きっぱなしにして、何日も作業を続けている人。「node -vが新しくなったから大丈夫」と思っている人にも、動いているものは別に見る必要がある、という話として役に立つと思う。

まとめ

Node.jsの修正は、公開しているサービスには関係なかった。でも、手元のMacのNode.jsは修正前の版だった。nvmで24.22.1を入れると、新しいターミナルはすぐ切り替わった。一方、開いたままのAIのセッションと、それと一緒に起動したプログラムは、古い版を使い続けていた。長く動いていたサーバーは起動し直して切り替え、セッションの開き直しと古い版の削除は、まだ残っている。

項目内容
結論手元のMacのNode.jsを24.20.0から24.22.1へ更新した。新しいターミナルと、起動し直したサーバーは24.22.1。開いたままのAIのセッションと連携用のプログラムは、記事を書いた時点で24.20.0のまま
教訓新しい版を入れることと、動いているものが切り替わることは別。起動したときのnodeを使い続けるので、動いているものを1つずつ確かめ、全部が切り替わってから古い版を消す
対象読者AIのエージェントを使って、自分のMacでNode.jsを動かしている人

同じ状況に陥ったときの回避策

  • 公開しているサービスだけでなく、手元のMacでNode.jsが動いている場所も書き出す
  • 入れたあとはnode -vだけで終わらせず、動いているプロセスの起動時刻と、nodeの実体を見る
  • AIのセッションは、起動したときのPATHを持ち続ける。開き直すまでは、新しい版の場所を明示して使う
  • AIに「新しいシェル」で確かめてもらうときは、PATHを受け継いでいないかを疑う
  • 全体用のパッケージは引き継がれない。npxで使う形にしておくと、入れ直しが要らない
  • 古い版は、動いているものが全部切り替わってから消す

次に読むなら

参考にした公式の情報（2026年10月23日に確認）

この記事は、筆者が個人で運営しているブログやアプリ開発の作業環境の運用記録（2026年10月23日）と、Node.js公式の公開情報を基に、独自調整したAIが下書きを作成し、筆者が事実確認・編集を行った上で公開しています。

トップへ戻る
タイトルとURLをコピーしました