技術メモ

ホーム 記事一覧

2026/10/22

PHP と Node.js の 2026年10月セキュリティリリース — 公式発表の要点と対応手順

2026年10月21日、PHP と Node.js が同じ日にセキュリティリリースを公開しました。どちらも Web アプリケーションの土台に使うランタイムなので、公開サーバーを運用しているにとっては同時に対応が必要な回です。

この2つのリリースで何が起きたのかを、各プロジェクトの公式発表に沿って整理します。公式の記載がない推測や断定はせず、参照先 URL もすべて残しました。

2026年10月の主なリリースまとめ

プロジェクト 公開日 修正バージョン 主な内容
PHP 2026年10月21日 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 未認証のリモートコード実行2件（CVSS v4.0 9.2）
Node.js 2026年10月21日 22.23.4 / 24.22.1 / 26.12.1 脆弱性10件（high 4件、medium 3件、low 3件）

PHP は前日の 10月20日に「10月21日 14:00 UTC に重要なセキュリティリリースを公開する」と事前告知を出しています。詳細が漏れた場合や実際の攻撃が確認された場合は、リリースを前倒しする権利を留保すると述べていました。

PHP：未認証のリモートコード実行 2 件

影響を受けるバージョンと修正バージョン

公式の GitHub Security Advisory に記載されている影響範囲と修正版は次のとおりです。

ブランチ 修正前のバージョン 修正版
PHP 8.5 8.5.12 未満 8.5.12
PHP 8.4 8.4.27 未満 8.4.27
PHP 8.3 8.3.36 未満 8.3.36
PHP 8.2 8.2.35 未満 8.2.35

PHP 8.1 およびそれより古いバージョンは、PHP プロジェクトから更新が提供されなくなっています。ソースからビルドする利用者や LTS ベンダー向けに、PHP 7.4・8.0・8.1 の最小限のソースバックポートが公式に公開されています。

また PHP 8.2 は 2026年12月31日にサポート終了（EOL） となります。8.2.35 が 8.2 ブランチ最後のセキュリティリリースなので、8.2 を使っている場合は 8.3 か 8.4 への移行を計画しておくのが妥当です。

影響を受ける環境

公式発表では、以下のように記されています。

Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.

つまり Web リクエストを処理するすべての PHP 環境 が対象で、中でも Apache の mod_php が最も危険とされています。mod_php では、アプリケーションコードが1行も実行される前に未認証のリクエストだけで攻撃が成立すると報告されています。フレームワークのミドルウェアや入力バリデーションでは防げません。

CVE-2026-109618：メモリ不足処理によるメモリ破壊

公式 Advisory（GHSA-w8hw-w9fx-j79w）の要点は次のとおりです。

PHP はメモリ不足（OOM）エラー時に longjmp() を使って現在のコンテキストを中断し、リクエストの処理を終了します。しかし、リクエスト用のメモリが完全に初期化される前に一時的に参照できる状態では、その時点で割り当てが失敗すると PHP が早期終了を正しく扱えず、リクエストメモリを無効な状態のまま残してしまいます。続くリクエストのシャットダウン処理がその無効な状態を読み・分岐するため、リモートコード実行につながります。

攻撃入力としては multipart パーサに関するいくつかの経路が挙げられています。

  • 使用可能な宣言 Content-Length のない multipart リクエストが post_max_size の初期チェックを通過し、符号化されたボディデータを継続して供給できる
  • multipart パート内のヘッダー数に制限がなく、PHP 内部表現は通信上の表現より多くのメモリを使うため、post_max_size の範囲内で memory_limit を枯渇させられる
  • 空のファイルコントロールは max_file_uploads に数えられない一方で通常のファイルメタデータ配列は生成される。ネストしたフィールド名によって生成される配列作業量が増幅される

SAPI ごとの到達性は次のとおりです。

  • Apache mod_php：リクエスト起動に失敗してもシャットダウン処理を無条件に呼び出すため、アプリケーションコードに依存しない攻撃が確認されています
  • PHP-FPM：起動に失敗した子プロセスを終了させるため、ソース解析では脆弱性が支持されるものの、完全な FPM エクスプロイトは実証されていないとされています
  • FrankenPHP：mod_php と同様に無条件にシャットダウン処理を呼び出すため、アプリケーション非依存の攻撃に脆弱である可能性が高いとされています
  • LSAPI：FPM をモデル化しており、アプリケーション依存の攻撃はありうるものの未検証です

パッチの内容としては、OOM 時の longjmp() を削除し、VM の安全なポイントで遅延型のソフト OOM を起動、メモリ使用量が2段目の高いしきい値に達した場合は _exit() による即時ハード OOM に置き換えました。シャットダウン処理が無効な状態を見ることはなくなりました。

CVE-2026-109619：古いグローバル状態が残る件による解放後メモリ参照

公式 Advisory（GHSA-6wmf-4rv5-p3rp）では、PHP が保持する エラー・セッション・オブジェクト・拡張の状態 のようなグローバル状態が、1 件のリクエストが所有するメモリを指し続けていると説明しています。前のリクエストが残した古い状態を次のリクエストが初期化前に読み取ることで、解放後メモリ参照（use-after-free）が発生します。

この脆弱性の発現には 2 つの要素が必要 です。

  1. 生成者（producer）：リクエスト所有の状態を、後のリクエストからも到達できる場所に保存する PHP の処理
  2. 消費者（consumer）：次のリクエストが、通常の初期化より前にその古い状態を読む・解放する・分岐する PHP の処理

公式で確認済みとしている主な組み合わせは次のとおりです。

生成側の代表例

  • PHP 8.5 の fatal_error_backtraces が有効な場合、致命的なエラーのバックトレースがリクエスト所有の状態として保存され、シャットダウン中のリセットが必ず漏れます。これが mod_php での確認済み RCE の根拠とされています
  • セッションのアップロード進行状況（session upload progress）は、通常のモジュール初期化より前にリクエスト所有のセッション・デコーディング状態を初期化します。アップロードの進行中に中断が起こると、そのリセットが実行されずにリクエストのメモリが解放されます

消費側の代表例

  • リクエスト初期化前の INI 診断：初期化時に発生する warning・notice・deprecation が古いエラー状態を消費します。表示やログに出るかどうかとは無関係で、error_reporting の変更・@ の使用・display_errors や log_errors の無効化では防げません。Apache mod_php では .htaccess や Apache の php_value / php_flag / php_admin_* によるディレクトリ単位の設定が php_request_startup() の前に適用されるため、リクエストごとに適用されます。FPM では、nginx や Apache の mod_proxy_fcgi などが PHP_VALUE / PHP_ADMIN_VALUE を渡してリクエスト初期化前に診断を発生させる場合に条件付きで露出します
  • セッションのアップロード進行状況：通常のセッション初期化より先にセッション処理へ到達し、中断されたリクエストが残したセッション・デコーダー状態を消費します。この経路は INI 診断の経路とは独立で、診断ログを伴わなくても到達します。セッションのアップロード進行状況はデフォルトで有効で、アプリケーション側で session_start() を呼ぶ必要はありません

深刻度

2 件とも CVSS v4.0 で 9.2（Critical）、ベクタは CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N です。CWE は CWE-416（解放後メモリ参照）、CWE-755（例外条件の不適切な処理）、CWE-824（未初期化ポインタへのアクセス）、CWE-1325、CWE-1419 が指定されています。

PHP の対応手順

まずバージョンを確認する

php -v

Web サーバー経由で使われている場合は、FPM のバージョンも確認します。

sudo systemctl status php-fpm

アップグレードする

修正版のバージョンは前述の表のとおりです。パッケージ名はディストリビューションや導入方法によって異なるため、実行前に現在インストールされているパッケージ名を確認してください。

# Debian / Ubuntu 系
sudo apt update
sudo apt upgrade php8.3-fpm php8.3-cli

# RHEL / AlmaLinux / Rocky Linux 系
sudo dnf update php php-fpm

更新後は PHP ワーカーを再起動します。再起動しないと古いコードが動き続けます。

sudo systemctl restart php8.3-fpm

すぐに更新できない場合の暫定対策

公式発表は、更新が唯一の完全な解決策だと明記しています。そのうえで、攻撃経路を部分的に狭める以下の対策が提示されています。

CVE-2026-109618 向け

  • memory_limit=-1 を設定する。理想的にはアプリケーションから上書きできない php_admin_value を使い、プール・ディレクトリ・アプリケーション設定で有限値に戻っていないか確認します
  • post_max_size を小さくする。ファイルアップロードが不要なら 8M、必要なら 32M とし、upload_max_filesize は post_max_size より小さく保ちます
  • コンテナや cgroup のメモリ制限を可用性の境界として使う。このとき RLIMIT_AS や RLIMIT_DATA は使用しません（メモリ制限に達した際の mmap() 失敗が脆弱な経路を誘発するため）

CVE-2026-109619 向け

  • session.upload_progress.enabled=0 を設定し、すべてのワーカーを再起動する。php.ini、FPM プール、またはリクエスト解析前に適用されるサーバー設定を使い、ini_set() や FPM の .user.ini には頼りません
  • PHP 8.5 では fatal_error_backtraces=0 を設定し、すべてのワーカーを再起動する
  • リクエストごとに適用される不正または非推奨の設定で、初期化前に診断を発生させるものを削除する
  • 攻撃者が到達できる致命的なエラーと実行タイムアウトを修正する
; php.ini または FPM プール設定
memory_limit = -1
post_max_size = 8M
upload_max_filesize = 4M
session.upload_progress.enabled = 0

; PHP 8.5 の場合のみ
fatal_error_backtraces = 0

FPM プール側で強制する場合は php_admin_value を使います。

; /etc/php/8.3/fpm/pool.d/www.conf
php_admin_value[memory_limit] = -1

ログを確認する

更新前、または更新後に影響がないかを確かめる際は、起動時の設定で一時的にエラーログを有効にして監査します。

log_errors = On
error_reporting = E_ALL

チェックしたいログは次のとおりです。

  • 対象のスクリプトが実行される前に繰り返される warning・deprecation・コアエラー
  • 拡張やサーバーのクリーンアップ段階で出力された診断
  • 致命的なエラー・パースエラー・捕捉されなかったエラー
  • Maximum execution time exceeded

公式は「ログにエラーがないことは安全の証明ではない」と明記しています。ログは静的な設定監査とアプリケーションフローの監査を補う補助材料です。

Node.js：10 件の脆弱性修正

修正バージョン

リリースライン 修正版
Node.js 22.x（LTS） 22.23.4
Node.js 24.x（LTS） 24.22.1
Node.js 26.x（Current） 26.12.1

Node.js プロジェクトは、最高深刻度が HIGH であると明記しています。サポート終了（End-of-Life）バージョンは、セキュリティリリースで常に影響を受ける ため、修正版が提供されません。

修正された脆弱性の一覧

CVE 内容 深刻度 影響バージョン
CVE-2026-111497 Brotli デコーダの境界外書き込みによるリモートコード実行 high 26.x / 24.x / 22.x
CVE-2026-105482 dns.resolve が NUL 文字を含む名前を切り詰める high 26.x / 24.x / 22.x
CVE-2026-105483 IP アドレスが全角数字で書かれた場合の TLS 証明書のホスト名検証バイパス high 26.x / 24.x
CVE-2026-106069 ホストが緩やかに IP アドレスへ解決される場合の TLS 証明書のホスト名検証バイパス high 26.x / 24.x / 22.x
CVE-2026-105481 キープアライブソケットがリクエスト送信前に書かれた応答を処理する medium 26.x / 24.x / 22.x
CVE-2026-106072 正規化されていない IPv4 ホスト名に対する不適切な証明書検証 medium 26.x / 24.x / 22.x
CVE-2026-106074 crypto.randomUUID() と randomInt() のエントロピーキャッシュがスナップショットに保存される medium 26.x / 24.x / 22.x
CVE-2026-106070 ZIP ヘッダー検証の失敗後、Node.js ZipFile が攻撃者制御のプレフィックスバイトを返す low 26.x
CVE-2026-106071 Permission Model のファイルシステム過剰許可（ワイルドカード radix 検索） low 26.x
CVE-2026-106073 fs.realpathSync による Permission Model のバイパス low 26.x / 24.x / 22.x

TLS 関連の 3 件（CVE-2026-105483 / CVE-2026-106069 / CVE-2026-106072）は、共通のパターンです。変わった書き方のアドレスが IP アドレスとして認識されず、証明書検査が DNS 名の判定へフォールスルーするため、ドメイン名に対して発行された証明書が IP エンドポイントへの接続を証明できてしまう、というものです。修正では、正規化されていない IP アドレスを TLS が拒否するようになりました。

CVE-2026-106074 は、起動時のスナップショットや単一実行ファイル（SEA）にエントロピーキャッシュが保存されてしまい、そのスナップショットから起動したプロセスごとに同じ値が繰り返されるという問題です。スナップショットや SEA を配布している場合は、修正済みランタイムで再ビルドが必要か確認してください。

依存関係も更新されている

今回のリリースには、公開されている既知の脆弱性に対応する依存関係の更新も含まれます。

  • c-ares（26.x / 24.x / 22.x）
  • ca-cert（eMudhra の中間認証局の侵害に対応。26.x / 24.x / 22.x）
  • OpenSSL（24.x / 22.x）
  • SQLite（22.x）
  • Undici（26.x / 24.x / 22.x）

Node.js の対応手順

現在動いているバージョンを確認します。

node -v

nvm でバージョンを管理している場合は、インストール済みのバージョンを一覧表示してから更新します。

# インストール済みバージョンの確認
nvm ls

# 修正版へ更新して既定にする
nvm install 24.22.1
nvm alias default 24.22.1

Docker を使っている場合は、ベースイメージのバージョンを固定します。

FROM node:24.22.1

ビルドや再起動も忘れずに行ってください。

npm ci
sudo systemctl restart your-app.service

Brotli の RCE に注意

CVE-2026-111497 は Node.js に同梱されている Brotli デコーダの境界外書き込みで、リモートコード実行につながります。Node.js 自体は Brotli をデコードしません。アプリケーションや使用ライブラリが、攻撃者が制御できる Brotli データ（リクエストボディ、取得するレスポンス）を解凍する構成だけが露出します。

自分のシステムで Brotli の解凍処理があるか確認しておくと、優先度を判断できます。

grep -rn "createBrotliDecompress\|brotliDecompress" src/

具体的な優先順位

Web サーバーの運用であれば、対応はこの順で進めると効率的です。

  1. PHP を更新する（未認証 RCE、mod_php なら攻撃がアプリケーションコード実行前に成立するため最優先）
  2. Node.js を更新する（Brotli の RCE を含む 10 件）
  3. PHP 8.2 の EOL に備えて移行計画を立てておく（2026年12月31日まで）
  4. ログを監査して侵害の有無を確認する

まとめ

2026年10月21日は、PHP と Node.js が同時にセキュリティリリース公開日となりました。PHP は未認証のリモートコード実行を含む Critical な 2 件（いずれも CVSS v4.0 9.2）、Node.js は Brotli デコーダのリモートコード実行を筆頭に 10 件の脆弱性を修正しています。

どちらの公式発表も「更新が唯一の完全な解決策」と明記しています。暫定対策は攻撃経路を部分的に狭めるだけなので、まず更新、そのあとログ確認 という順序が基本です。

掲載内容はすべて各プロジェクトの公式発表をもとにまとめています。判断に迷ったときは、末尾に挙げた一次情報源を直接確認するのが確実です。

出典

PHP（公式）

Node.js（公式）

参考（第三者機関の報告）