緊急情報を偶然知る状態から、自社に関係する情報が届く仕組みへ――Node.jsの確認をきっかけに、AIの通知を設定した
Xで見かけた緊急情報をきっかけに、サイト生成に使うNode.jsを確認し、修正版へ切り替えました。自社の利用環境と公式情報を照合するAI通知を10月25日に設定した経緯と、SCS★3を目指す情報収集の一歩を記録します。
2026年10月25日、Xを見ていると、「HTTP2Shell」「大至急確認」という言葉が目に入りました。表示では、約18時間前の投稿でした。
急いで確認した方がよいらしい。でも、自社の何に関係するのかが分かりません。すでに更新されているのか、自分で何かする必要があるのか。投稿を読んだだけでは、そこまで判断できませんでした。
そこで、普段Creerのサイトを作っている別のプロジェクトで、AIに質問しました。当社の構成を知っている場所で、「うちはどうなのか」を確かめたかったからです。
その確認から、サイトを生成する際に使うNode.jsの更新と、重要な情報を自社の環境に照らして知らせる仕組みの設定へ進みました。今回は、10月25日に行った対応と、そこから情報収集の方法を見直した経緯を残します。
少し前には、PHPの重大な脆弱性について、自社サイトと試作環境を分けて確認しました。経緯はPHPの緊急対応を記録した記事と、後日の確認をまとめた記事に書いています。
あのときも、ニュースの重大さを知るだけでは、次の操作は決まりませんでした。どこでPHPが動き、誰が管理し、契約中のサービスに修正が適用されたのか。自社へ置き換えるための確認が必要でした。
今回も同じです。SNSは、専門外の私が情報に気づく入口になりました。ただ、たまたま見かけることを前提にしていては、別の仕事をしている間に重要な情報を見落とすかもしれません。
気づいた後にも、製品名やバージョン、使い方を調べる作業があります。私が欲しかったのはニュースの件数を増やすことより、自社に関係する情報を拾い、最初に何を確かめるかまで分かる状態でした。
静的なサイトでも、作るときにはプログラムが動く
Creerの公式サイトは、手元のパソコンでAstroというWebサイトを作るためのツールを使い、文章を記号で整えるMarkdown形式の原稿などから、静的なHTMLを生成しています。静的なHTMLは、閲覧される前に用意しておくページのデータです。完成したdistフォルダーの中身を、お名前.comの公開先へ手動でアップロードする運用です。
閲覧者にページを届けるため、公開サーバーでこのNode.jsを常時動かしている構成ではありません。一方、手元でサイトを生成するときには、Node.jsというJavaScriptの実行環境を使います。
私にとって普段の作業は「記事を直す」「サイトを作る」というものです。その裏側で、どの場所にある、どの版のNode.jsが動くのかまでは意識していませんでした。
AIと確認すると、その作業では、AIが利用する道具に同梱されたNode.js 24.19.0が使われていました。サイトの見た目や記事の内容を確認していても、生成に使うプログラムの版は、別に確かめる必要があったのです。
今回のNode.js更新を、そのまま「静的サイトを見た人が、このNode.jsの脆弱性から直接攻撃される」という話にはできません。まず見る対象は、手元でNode.jsが動く処理と、その処理が外からどのようなデータを受け取るかです。公開サーバー側の確認は、担当する事業者や構成に沿って進めます。
SNSの呼び名から、公式情報へ戻る
確認の根拠にしたのは、Node.js公式の10月21日付セキュリティ告知です。2026年10月25日の確認時点で、24系では24.22.1などの修正版が案内されています。
告知には複数の問題があり、その一つがBrotliという圧縮形式のデータを展開する処理の脆弱性、CVE-2026-111497です。脆弱性は、外部から悪用されるおそれのあるプログラムの弱点で、CVEは公表された脆弱性を区別するための識別番号です。攻撃者が用意したBrotliデータを、影響を受けるNode.jsの展開処理へ渡す場合に、異常終了や情報漏えい、コード実行につながるおそれがあるとされています。
見るべき条件は「AIを使っているか」だけではありません。どの版を使い、どの処理で、誰から受け取ったデータを扱うかが関係します。今回、当社のサイト生成でその攻撃条件が実際に成立するかまでは検証していません。修正対象の古い版が使われていると分かったため、生成環境を修正版へ切り替えました。
SNSで見た「HTTP2Shell」は、このNode.js公式告知にはない呼び名です。名称とCVEの対応は公式資料で確認できていないため、この記事では識別番号を根拠にしています。
このCVEはNode.jsだけに閉じた問題でもありません。GitHubのセキュリティ情報には、Pythonというプログラミング言語で使うBrotli、brotlicffiという追加部品の影響する版と修正版が掲載され、深刻度を示すCVSS v4の評価は9.2とされています。サービス間の通信を管理する仕組みであるIstioの公式告知も、通信を中継する内部部品EnvoyでBrotli展開を有効にしている場合の更新を案内しています。
サーバーが受け取るデータだけでなく、クライアント側が攻撃者由来の圧縮データを展開する経路も確認対象になり得ます。通信データを取得するツールであるcurlなども、名前だけで一律に判断せず、組み込まれたBrotliの版と使い方を確かめる必要があります。この広がりを知り、サイト用のNode.jsに加えて、手元のほかの環境も点検することにしました。
インストールしただけで終わらせず、使う場所を確かめる
私は公式インストーラーで、Node.js 24.22.1をパソコンへ導入しました。その修正版を使い、原稿などから公開用ファイルを生成する処理（ビルド）が成功するところまで確認しました。
ただ、新しい版を入れた後でも、普段使う起動方法が別のNode.jsを選べば、意図した切り替えになりません。そこでAIと、通常のビルド用・プレビュー用バッチ（一連の操作をまとめて実行するファイル）も見直しました。
変更したのは、別途インストールしたNode.jsを優先して使うこと、起動時に実行ファイルの場所とバージョンを表示することです。手順を記したREADMEにも利用する版と起動方法を残しました。更新前のバッチなどは、バックアップを取っています。
その後、変更したバッチからもNode.js 24.22.1でビルドが成功し、93記事を含むサイトのリンク、一覧、サイトマップを検証したという作業結果の引継ぎを受けました。自分が行ったインストールと、AIから受け取った検証結果を合わせて、今回の切り替えの記録にしています。
ここで手を入れた範囲は、サイト生成に使うNode.jsと、その起動方法です。WindowsやAstro本体の更新、この対応で生成したファイルのサイトへのアップロードは行っていません。
今後また確認するときには、「更新したはず」という記憶だけでなく、起動時に出る場所と版を見られます。今回加えた小さな表示は、そのための手掛かりです。
別のアプリには、別のNode.jsが残っていた
10月25日には続けて、AIとパソコン内の実行ファイルや導入情報を点検しました。この追加点検は読み取りだけで行い、先ほどの切り替え確認とは別に、ビルドの再実行や環境の変更はしていません。
サイト用に導入したNode.jsの実ファイルは24.22.1でした。一方、開発支援や制作関連のアプリに同梱されたNode.jsには、24.19.0のものが残り、その実行元のプロセスも動いていました。同じパソコンでも、別のアプリは別の実行環境を持っています。一か所を更新すれば全部が切り替わる、という関係ではありませんでした。
この版は上流の修正対象と一致するため、各アプリの提供元が修正を取り込んでいるか、旧版への修正適用や更新案内があるかを確認する事項として残しました。アプリ内で外部のBrotliデータを扱う経路までは調べていません。同梱ファイルを自分で置き換えるのではなく、まず製品としての修正状況を確かめます。
Pythonについては、通常の導入先、開発支援ツールの同梱環境、録音用の二つの仮想環境（用途ごとに追加部品などを分けた環境）を見た範囲で、Brotliやbrotlicffiの導入情報は見つかりませんでした。録音用環境は起動エラーがあり、実行版は設定情報による確認です。Windows標準のcurlも、版の表示にBrotli機能やリンク情報はありませんでした。今回は、これらを追加更新する必要があるという証拠は得られていません。
Envoy、Istioや、別のJavaScript実行環境であるBunの利用も、確認範囲では見つかりませんでした。ほかのアプリの内部部品、Windows上でLinuxを動かすWSLや、アプリの実行環境を分けるコンテナの中、外部サーバーやネットワーク機器までは未調査です。
今回の発見は、製品名の一覧だけでなく、実際にどこから何が動いているかを見る意味が分かったことです。通知に使う自社の環境情報も、このような点検結果に合わせて見直す必要があると思いました。
AIで作るものにも、実行環境の管理がある
今回、AIでサイトや道具を作る人にも関係する話だと思いました。AIがコードを書き、実行や確認まで手伝うと、利用者は出来上がった画面や機能に目を向けやすくなります。
生成したサイトやアプリ、開発道具を動かすため、Node.jsなどの実行環境が使われている場合があります。自分で細かな導入作業をしていなくても、作業に使うプログラムは管理の対象になります。
これはNode.jsだけの話ではありません。PHPもAIを使う開発で利用します。当社でも試作環境にPHPがあります。大切なのは、どちらがAI向けかという分け方より、作ったものが何の上で動き、更新を誰が担うのかを知ることだと思います。
AIへ質問するときも、「このニュースは危険ですか」から一歩進めて、「この作業では何を使っていますか」「その実行ファイルはどこにありますか」と聞く。その方が、自社で確認する対象を具体的にできます。今回も、その問いから対応が進みました。
自社環境と照合する通知を、10月25日に設定した
確認が一段落した後、重要な情報を偶然見かける状態を少し変えようと考えました。10月25日に、「Creer環境の緊急情報」というAIの定期確認と通知を有効にしました。
設定した内容は、3時間ごとに公式情報を確認し、当社の環境に関係する重大な新規情報が見つかった場合に、ChatGPTへ通知するというものです。Node.js、Astroと関連する依存プログラム、Windows、Chrome、V-nasClair、お名前.comの利用サービスを対象にしています。
製品名が一致しただけで知らせるのではなく、当社での利用状況、分かっているバージョン、使い方を、公式情報の影響条件と照らし合わせるようにしました。
例えば、同じNode.jsでも、公開サービスとして動かす場合と、手元で静的サイトを生成する場合では、確認する場所が変わります。サービス事業者が修正する部分なら、当社の契約が告知の対象かを見る必要があります。今回人とAIで行った切り分けを、情報を拾う段階にも持たせたいと考えました。
通知では、影響が確定したもの、可能性があり確認を要するもの、対応済みのものを区別し、CVE、公式リンク、最初に確認することを短くまとめる設定にしています。影響条件を判断する材料が足りなければ、分からない点も分かる形で受け取ります。
届いた後に、判断できる通知にしたい
大量の通知が届くと、本当に読むべき情報が埋もれます。そのため、無関係な情報や通常の更新、すでに知らせた内容の重複は送らず、夜間の緊急性が低い連絡も控える設定にしました。
AIに担当してもらうのは、情報を探し、自社との関係を整理して知らせるところです。更新や設定変更、外部への連絡は自動では行わず、通知を読んで必要な対応を人が判断します。対象が絞られ、根拠と確認先が添えられていれば、その後の相談も始めやすくなると思います。
以前、毎朝8時のAIチェックでは当日の発表を拾えなかった記事を書きました。定期的な確認は、調べる時刻によって拾える情報が変わります。今回の3時間ごとの確認も、即時の連絡や全件検知を保証するものではありません。
10月25日時点で確認できたのは、仕組みを設定し、有効にしたことです。通知の実績や検知率、対応がどれだけ早くなったかは、これから見ていきます。実際に届いた内容を見ながら、必要な情報を拾えたか、関係の薄い通知が多くないかを確かめ、対象や条件を調整していくつもりです。
SCS★3を目指す準備を、日々の仕事につなぐ
Creerでは、SCS評価制度の★3を目指す準備を進めています。正式には「サプライチェーン強化に向けたセキュリティ対策評価制度」で、SCSはSupply Chain Securityを指します。
経済産業省の制度案内では、企業の対策状況を共通の基準で評価し、取引先からも確認しやすくする仕組みとして説明されています。2026年10月25日時点で確認した制度案内では、★3は専門家の確認を伴う自己評価、★4は第三者評価という形が示されています。
今回の通知設定は、その準備を支える情報収集の一歩です。これだけで評価基準を満たしたと判断したり、★を取得したと説明したりするものではありません。必要な情報に気づき、自社への影響を確かめ、対応と再確認を残す。その流れを、普段の仕事の中で続けられるようにしたいと思っています。
Creer AI技術室の構想でも、集めた情報を「当社ならどう使えるか」まで考える役割をAIに持たせたいと書きました。今回の通知も、その考えに近いものです。技術室全体の構想が完成したということではなく、必要になった一つの仕事を具体的に設定しました。
今回の入口は、Xでたまたま見た投稿でした。そこから、自社で動くものを確認し、修正版へ切り替え、使う場所と版を再確認した。そして次に情報を知る方法まで見直しました。
この仕組みが実務でどこまで役立つかは、これからです。まずは、自分たちの環境を手掛かりに重要な情報を受け取り、根拠を見て判断できる状態を、小さく育てていこうと思います。