PHPとNode.js：2026年10月の脆弱性
2026年10月21日に公表されたPHPとNode.jsの脆弱性：CVE、修正版、そして場当たり的にならずにサイトとアプリケーションを守るための検証済みのアップデート手順。
2026年10月21日、私たちはコンテナ、Node.js環境、PHPアプリケーションにまたがる数百のサービスを点検し、外部に公開されているものはすべてその日のうちにアップデートしました。その後、実際に稼働しているプロセスを確認し、アプリケーション環境の隔離されたコピー上で数千件の自動テストを実行し、本番環境のエンドポイントが正しいHTTPレスポンスだけを返すようになるまで監視を続けました。いちばん骨が折れたのは、ランタイムを入れ替えながら、アプリケーション、データベース、請求書の生成、各種カスタマイズを動かし続けることでした。
作業のきっかけは、同じ日に公開された二つの別々の発表でした。PHPの重大な脆弱性と、Node.jsの深刻度の高いセキュリティアップデートです。どちらもアプリケーションを実行するソフトウェアに関わるものです。企業にとっては、プロジェクトのために書かれたコードが何も変わっていなくても、ウェブサイトや業務システムの下の層に問題が潜んでいる可能性がある、ということを意味します。
以下は2026年10月21日時点で確認した状況です。記載したバージョンはこれらのアドバイザリに対する修正版です。後日アップデートする場合は、その後に出たセキュリティリリースも確認してください。
10月26日追記：公表前の攻撃の試み
Amazon Threat Intelligenceは10月17日、MadPotセンサーでPHP2Shellの悪用の試みを検知しました。10月21日の一般公開より4日前のことです。10月21日に公開されたこの調査は、エンバーゴ終了前に複数のインフラからの試みがあったことも報告しています。AWSは、技術的な分析は継続中であり、それらの試みが実際のシステムで成功していたかどうかは判断していないとしています。
これにより、点検で対象とすべき期間が変わります。公開されているサービスについて、AWSは少なくとも10月17日までさかのぼり、ログ、想定外のプロセス実行、ファイルの変更を確認するよう推奨しています。パッチを適用することと、それ以前の侵害の痕跡を探すことは、別々の確認作業です。 10月21日にアップデートを終えたという事実だけでは、それ以前の数日間にシステムが無事だったことの証明にはなりません。
PHPの脆弱性：CVE-2026-109618とCVE-2026-109619
PHPの公式発表では、認証なしでのリモートコード実行につながりうる二つの欠陥が説明されています。RCEとは、実際には、攻撃者がリモートから到達可能な脆弱性を通じてシステム上でコードを実行できてしまうことを意味します。サイトにログインがあっても、アプリケーションが認証情報を確認する前に起こりうる問題はなくなりません。
CVE-2026-109618 は、メモリ枯渇時の処理に関するものです。リクエストの内部データの一部が部分的にしか初期化されないまま残り、クリーンアップの際に有効なものとして扱われることがあります。Apacheとmod_phpの組み合わせで実証されたケースは、アプリケーションのコードが実行される前に発生しえます。公式の分析では、PHP-FPMも影響を受けうるとされていますが、攻撃経路は異なり、この欠陥についてFPMでの完全なエクスプロイトは実証されていません。
一方、CVE-2026-109619 は、前のリクエストのメモリが解放された後もプロセスが保持しうる内部状態に関するものです。後続のリクエストが、すでに無効になったその参照にアクセスできてしまう可能性があります。成立条件はワーカーの挙動や到達可能な処理によって異なります。すべての環境がすでに侵害されていると言うのは誤りですが、修正なしで安全だとみなすのも同じく誤りです。
サイトを運営する立場からすれば、実務上の結論ははっきりしています。CMSやプラグインのアップデートが必要な場合もありますが、これらの欠陥を修正するにはPHPランタイム自体のアップデートも必要です。この問題は、WordPressサイトだけでなく、独自開発の業務システムにも同じように影響しえます。
修正を含むPHPとNode.jsのバージョン
10月21日のアドバイザリについて、各プロジェクトが示しているアップストリームのリリースは次のとおりです。
| ランタイム | ブランチ | 修正リリース |
|---|---|---|
| PHP | 8.2 | 8.2.35 |
| PHP | 8.3 | 8.3.36 |
| PHP | 8.4 | 8.4.27 |
| PHP | 8.5 | 8.5.12 |
| Node.js | 22 | 22.23.4 |
| Node.js | 24 | 24.22.1 |
| Node.js | 26 | 26.12.1 |
この表はPHPのリリースとNode.jsのアドバイザリをまとめたものです。すべてのアプリケーションで最新のメジャーバージョンに飛びつくことを勧めているわけではありません。まず互換性、依存関係、ネイティブ拡張を確認する必要があります。
診断を左右する点がもう一つあります。アップストリームのバージョン番号だけでは、Linuxのパッケージを判断できません。 ディストリビューションは、一見古いベースバージョンを保ったまま修正を適用することがあります。たとえばUbuntu 24.04のPHP 8.3では、CVE-2026-109618とCVE-2026-109619の公式ページで、修正済みパッケージとして8.3.6-0ubuntu0.24.04.13が示されています。リビジョン全体とベンダーのアドバイザリを読む必要があります。同じ理由で、サポートが終了したブランチには注意が必要です。ベンダーが文書化した修正があるか、メンテナンスされているブランチへ移行するかのどちらかが必要です。
外部からの確認にも同じ限界があります。私たちのスイス公共部門セキュリティ調査は、公開データだけを使って約2200の市町村、州、連邦機関を毎日チェックし、サイトがヘッダーで示しているPHPのバージョンを修正リリースと受動的に比較しています。全体像をつかむための有用な手がかりではありますが、診断ではありません。多くのサーバーはバージョンを表示しませんし、ディストリビューションが修正を適用したパッケージは古く見えることがあります。実際に何が動いているかを知るには、サーバーの内部を見る必要があります。
Node.js、Brotli、そして圧縮の裏にあるリスク
Node.jsの10月のアドバイザリには、CVE-2026-111497が含まれています。Brotliデコーダーの欠陥で、深刻度は高とされ、リモートコード実行につながる可能性があります。Brotliはウェブのトラフィックでも使われている圧縮形式です。実際にどこまで影響を受けるかは、攻撃者が制御できる圧縮データをアプリケーションがどの経路で処理しているかによります。Node.jsがインストールされているというだけでは、エクスプロイトが到達可能であることの証明にはなりません。
同じリリースには、DNS、TLS証明書の検証、その他のコンポーネントに関する修正も含まれています。そのため、私たちは対象のランタイムをアップデートし、圧縮、TLSの初期化、暗号処理も確認しました。データを正しく圧縮・展開できるかのテストは新しい環境の互換性を確かめるものであり、パッチが含まれていることの裏付けは、修正済みのバージョンとソフトウェアの検証された入手元から得られます。
Node.js 20のままのアプリケーションについては、メンテナンスされているブランチへの移行を準備しました。ネイティブ拡張は別途テストする価値があります。以前のランタイム向けにコンパイルされたSQLiteモジュールは、メジャーバージョンを変える際に再コンパイルが必要になることがあります。
サーバーをアップデートしてもDockerとPM2は自動的にはアップデートされない理由
実際のインフラでは、システムのPHP、Apacheコンテナ内のPHP、PHP-FPMアプリケーションが使うPHPが同居していることがあります。一つを修正しても、ほかはそのまま残ります。ターミナルでコマンドが返すバージョンも、実際にリクエストを処理しているプロセスのバージョンと照らし合わせる必要があります。
Dockerについては、実際に使われているイメージを確認し、置き換え用のイメージを用意し、データボリュームはそのまま維持しました。latestというタグは、パッチが含まれていることを保証するものではありません。Dockerfileやデプロイ手順が古いベースを選び続けていれば、将来の再ビルドで作業が台無しになることもあります。今回の作業では、ベンダーのパッケージも確認し、必要に応じて公式ソースからチェックサムを検証したうえでランタイムを用意しました。
PM2については、シェルのデフォルトのNodeを変更しても、すでにメモリに読み込まれている実行ファイルは置き換わりません。デーモン、子プロセス、systemdによる監視を確認しました。作業中には、ロールバックや手順の修正も必要になりました。正常に動作する構成にいつでも戻せるようにしておくことも、準備の一部でした。
カスタマイズとデータを失わずにPHPとNode.jsをアップデートする
切り替えの前に、以前のイメージを保存し、テストに必要なデータベースとボリュームのコピーを用意しました。監視システムでは、同じ読み取り専用マウントを使い、数千のPHPファイルとMIBファイルを元のスナップショットと比較しました。請求サービスでは、クローン環境でログイン、顧客と請求書の閲覧、既存PDFのダウンロード、テスト用ドキュメントの生成を試しました。その後、本番環境でサービスの状態とHTTPレスポンスを改めて確認しました。
業務システムのテストスイートは、数千件のテストを失敗なしで完了しました。これらのサービスの最終的な計画的再起動と、請求サービスの最終的な切り替えは、停止なしで行われました。本番エンドポイントの監視は、正しいレスポンスを受け取り続けました。作業全体を通しては試行やロールバックもありましたが、それらはまさにエンドユーザーに影響を与えないために準備しておいたものです。
ヘルスチェックが緑なら、特定のチェックが通っていることはわかります。アプリケーションが使える状態にあるかを知るには、重要な機能のテストも必要です。ログイン、データベース、ドキュメント、ジョブキュー、連携機能などです。これはスイスでのホスティング管理の具体的な一部であり、次の緊急アドバイザリが届く前に体制を整えておくべきものです。
サイトの管理者に聞くべきこと
VPNで保護されたサイトもアップデートが必要ですか？
必要です。VPNは、保護している経路を通じてサービスに到達できる相手を絞り込むものです。修正は、ランタイムの欠陥そのものを取り除きます。役割の異なる対策です。VPNがあれば影響範囲の評価や作業の優先順位づけには役立ちますが、パッチの代わりにはなりません。
WordPress、Laravel、JavaScriptフレームワークをアップデートすれば十分ですか？
今回の脆弱性については、PHPやNode.jsも確認する必要があります。どのバージョンがリクエストを処理しているのか、どのパッケージリビジョンに修正が含まれているのか、再起動後にどんな確認を行ったのかを、委託先に尋ねてください。OSをアップデートした後でも、アプリケーションが自身のDockerイメージ内のランタイムを使い続けていることがあります。
アップデート後のセキュリティを100%保証できますか？
私たちが文書化できるのは、適用した修正、合格したテスト、実施した確認です。それは、ほかのあらゆる脆弱性や以前の侵害がないことを証明するものではありません。たとえば今回の確認では、PHPの切り替え前からあったアプリケーション依存関係の致命的でない警告を、別件として記録しました。セキュリティパッチ、互換性、もともとあった異常を分けて扱うことが、筋の通った判断につながります。
御社でも同じ確認ができます
Webcracyでは、御社のウェブサイトや業務システムでどのバージョンのPHPとNode.jsが動いているかを確認し、修正が適用されているかをチェックし、優先してアップデートすべきサービスを洗い出します。確認した内容、必要な作業、まだ残っている課題をまとめてお渡しします。
アップデート作業そのものもお任せいただけます。バックアップを準備し、データのコピー上で変更をテストし、日々お使いの機能を確認します。事前に作業の日時と進め方を取り決め、事後には変更内容と実施したテストを文書にまとめます。
お使いのシステムと、現在どなたがホスティングを管理しているかをお聞かせください。そこから始めます。必要であれば、現在の委託先とも連携します。
イメージ写真：Taylor Vick（Unsplash）、Unsplashライセンスに基づき使用。写真のデータセンターは今回の作業対象のものではありません。