Analyzegear
2026年10月21日（協定世界時。日本時間では21日の深夜）、PHP に「緊急」レベルの脆弱性2件 CVE-2026-109618 / CVE-2026-109619（いずれも CVSS v4.0 で 9.2）の修正版が公開されました。認証なしで任意のコードを実行されうるもので、日本時間の21日夜から22日朝にかけて、国内のサービスでも予防的な停止やメンテナンスが相次ぎました。この記事では、何が問題なのか、自分のサイトに影響があるのか、何をすれば終わりなのかを、確認の手順つきで整理します。（内容は 2026年10月22日時点の公開情報と、当社サーバーでの確認にもとづきます）
先に結論
- 修正版は PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 です。使っている系列を、このバージョン以上に上げてください。
- 影響するのは Web リクエストを処理している PHP です（PHP-FPM・Apache mod_php・php-cgi・FrankenPHP・LiteSpeed）。アプリケーションの作りに関係なく、PHP 本体の問題です。
- レンタルサーバーを使っているなら、まず事業者の告知を確認してください。主なレンタルサーバー各社は、21日夜から22日朝にかけて更新を終えたと告知しています。
- PHP 8.1 以下には公式の修正版がありません。ディストリビューションや事業者によるバックポートの有無を確認し、なければサポート中の系列へ移してください。
- 設定による緩和策はありますが、PHP 公式は「完全な回避策はなく、更新が唯一安全な選択肢」としています。あくまで時間稼ぎです。
何が起きたのか（時系列）
| 日時（日本時間） | できごと |
|---|---|
| 10月20日 | PHP セキュリティチームが、21日14時（UTC）に修正版を公開すると予告 |
| 10月20日 | 公開前（エンバーゴ下）の脆弱性情報が外部に流出。セキュリティ企業 watchTowr が「本物」と確認 |
| 10月21日 22時台 | GitHub のアドバイザリと CVE レコードが公開（予告の23時より前） |
| 10月21日 23時ごろ（14時 UTC） | 修正版 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 がリリース |
| 10月21日夜〜22日朝 | 国内で予防的な停止・緊急メンテナンスが相次ぐ（報道・各社告知によれば BASE、Cygames、pixiv、さくらインターネット、エックスサーバー ほか） |
何が問題なのか
2件とも、PHP がリクエストを処理するときのメモリの扱いに関する不具合です。アプリケーションのコードの書き方とは関係がなく、PHP 本体の問題です。
CVE-2026-109618 ― メモリ不足の処理（RCE via OOM corruption）
PHP はメモリの確保に失敗したとき、処理中のリクエストを途中で投げ出します。このとき内部データが初期化されかけの状態で中断されることがあり、後片付けの処理が「壊れたデータ」を正常なものとして扱ってしまいます。攻撃者が意図的にメモリ不足を起こせると、認証なしでコードを実行されうる、というのが1件目です。
CVE-2026-109619 ― 持ち越される古い状態（RCE via stale global state）
PHP の Web サーバーでは、1つのワーカー（プロセス）が複数のリクエストを順番に処理します。このとき、前のリクエストが使っていたメモリを指したままの状態が残ることがあり、解放済みのメモリを次のリクエストが参照してしまいます。情報の漏えいや、こちらも認証なしのコード実行につながります。
なぜ「緊急」なのか
- 認証がいりません。攻撃者がログインできる状態である必要がありません。
- アプリケーションの作りに関係ありません。自前のコードが堅牢でも、PHP 本体の経路で成立します。
- mod_php がいちばん危険です。アプリケーションのコードが動き出す前に成立しうることが実証されています。
- CVSS v4.0 は 9.2（
AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N）。攻撃の難易度は「高」ですが、成功したときの影響は最大です（機密性・完全性・可用性のすべてが High）。
自分のサイトは影響するか
影響するのは「Web からのリクエストを処理している PHP」です。まず、いま動いている PHP のバージョンを確かめます。
| 環境 | 確認の方法 |
|---|---|
| WordPress | 管理画面 → ツール → サイトヘルス → 情報 → サーバー（「PHP バージョン」の欄） |
| レンタルサーバー | コントロールパネルの「PHP バージョン切替」などの画面。あわせて事業者の障害・メンテナンス告知を確認 |
| VPS・専用サーバー | php -v（CLI）と、Web 側の php-fpm -v / phpinfo()。CLI と Web でバージョンが違うことがあります |
報告によれば、影響を受けるのは PHP 5.4 以降のほぼすべてのバージョンです（少なくとも1件が該当）。「古いから対象外」ということはありません。
いま何をすべきか
1. レンタルサーバーを使っている場合
- 事業者の告知を確認する。主なレンタルサーバー各社は、10月21日夜から22日朝にかけて更新を終えたと告知しています（まとめ記事での集計によると、10月22日朝の時点でさくらインターネット・エックスサーバーなどが適用済み）。
- 自分で PHP のバージョンを選んでいる場合は、選択中の系列を確認する。サポートの切れた系列（8.1 以下）を選んだままだと、事業者が更新していても安全とは限りません。
- 更新の前後で、サイトの表示と問い合わせフォームの送信が正常かを確認しておく。
2. VPS・専用サーバーを自分で運用している場合
- パッケージを更新する（
dnf update php*/apt upgrade php*など）。ディストリビューションの配布版は、バージョン番号が 8.2.35 などに上がらないまま、修正だけが取り込まれている（バックポート）場合があります。ベンダーの告知で「この CVE を修正済み」かを確認してください。 - 更新後にサービスを再起動する。php-fpm や Apache を再起動しないと、稼働中のワーカーは古いままです。
- 更新後に
php -vとphpinfo()の両方でバージョンを確認する。 - PHP 8.1 以下は公式の修正版がありません。ディストリビューションや LTS ベンダーがバックポートしている場合があるため確認し、なければサポート中の系列（8.2 以上）への移行を計画してください。ソースから自前でビルドしている場合に限り、7.4・8.0・8.1 向けの最小限のバックポートが案内されています。移行までの間は、外部に直接さらさない（WAF や VPN の内側に置く）運用にしてください。
3. WordPress サイトの場合
- 今回の脆弱性は PHP 本体の問題で、WordPress やプラグインの更新では直りません。直すのはサーバー側の PHP です。
- レンタルサーバーなら、事業者の対応を確認したうえで、サイトヘルスで PHP のバージョンを見るのがいちばん早い確認方法です。
- 作業の前にバックアップを取る。PHP の系列を上げる場合は、テーマ・プラグインの対応状況も確認する。
当社が使っているサーバーで確認したこと
当社のサイトはエックスサーバー上で動いています。10月22日朝、当社が利用しているサーバー1台で、Web 用の PHP バイナリのバージョンとビルド日時を確認しました。
$ for b in /usr/bin/php-fcgi8.*; do printf "%-22s %s\n" "$b" "$($b -v | head -1)"; done
/usr/bin/php-fcgi8.0 PHP 8.0.30 (cgi-fcgi) (built: Oct 22 2026 04:11:03)
/usr/bin/php-fcgi8.1 PHP 8.1.34 (cgi-fcgi) (built: Oct 22 2026 04:06:47)
/usr/bin/php-fcgi8.2 PHP 8.2.35 (cgi-fcgi) (built: Oct 21 2026 23:09:35)
/usr/bin/php-fcgi8.3 PHP 8.3.36 (cgi-fcgi) (built: Oct 21 2026 23:15:24)
/usr/bin/php-fcgi8.4 PHP 8.4.27 (cgi-fcgi) (built: Oct 21 2026 23:21:41)
/usr/bin/php-fcgi8.5 PHP 8.5.12 (cgi-fcgi) (built: Oct 21 2026 23:28:36)- サポート中の4系列は、修正版（8.2.35 / 8.3.36 / 8.4.27 / 8.5.12）に入れ替わっていました。ビルド日時はいずれも21日23時台でした。
- サポートの切れた 8.0・8.1 も22日4時台に再ビルドされていました。バージョン番号は据え置き（8.0.30 / 8.1.34）のため、修正の取り込み（バックポート）とみられますが、確実なことは事業者の告知でご確認ください。
- これは当社が使っている1台での確認です。同じ事業者でもサーバーによって時刻は異なります。自分のサーバーで同じように確認するのが確実です。
すぐに更新できないときの緩和策（時間稼ぎ）
PHP 公式は「完全な回避策はなく、更新が唯一安全」としています。そのうえで、更新までの間に効く可能性がある設定が案内されています。
| 対象 | 設定 | 補足 |
|---|---|---|
| CVE-2026-109618 | memory_limit=-1（FPM プールや Apache の php_admin_value で管理者側から固定） | メモリ確保の失敗そのものは防げない場合があります |
| CVE-2026-109618 | post_max_size を小さく（アップロードが無いなら 8M 程度、あるなら 32M 程度） | Web サーバー側のリクエストサイズ制限も併用 |
| CVE-2026-109619 | session.upload_progress.enabled=0 | リクエスト解析より前に効かせる必要があります |
| CVE-2026-109619（PHP 8.5） | fatal_error_backtraces=0 | 管理者側から固定する |
| 共通 | コンテナや cgroup によるメモリ制限、リクエストごとに上書きしている無効・非推奨の設定の除去 | サービスを落とさないための歯止めとして |
侵害されていないかの確認
10月21日時点で「これがあれば侵害」と断定できる痕跡（IoC）は確定していないと報告されています。一般的には、次のような点を確認します。
- PHP のプロセスが、不自然な子プロセスを起動していないか（
bash/sh/python/perl/curl/wgetなど）。 - 公開ディレクトリに見覚えのない PHP ファイル（Web シェル）がないか。更新日時でも絞り込めます。
- アクセスログに、同じ URL への大量のリクエストや、異常なサイズのリクエストがないか。
- 英国 NCSC は「アップグレードの前に、侵害されていないかを確認する」ことも求めています。先に上書きすると痕跡が消えることがあります。
攻撃の観測状況は報告元で分かれています。Cloudflare・watchTowr・Patchstack は実際の攻撃や悪用事例を報告している一方、CISA と Huntress は10月21日時点で「観測していない」としています。実証コード（PoC）はすでに出回っていると報告されています。
よくある誤解
| よく聞く話 | 実際 |
|---|---|
| 「WordPress を最新にしたから大丈夫」 | 直すのは PHP 本体です。WordPress の更新では直りません |
| 「攻撃条件が高い（AC:H）から様子見でいい」 | 難易度が高いだけで、成立すれば乗っ取りです。PoC が出回っており、攻撃の観測報告もあります |
| 「CLI でしか PHP を使っていないので無関係」 | Web に出していなければ直接の攻撃面ではありませんが、更新の対象ではあります |
| 「サーバー会社が対応したから何もしなくていい」 | 自分が選んでいる PHP の系列が古いままだと、対象外のことがあります。バージョンを自分で確認してください |
まとめ
- やることは1つです。PHP を 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 以上に上げる（またはベンダーがバックポートしたバージョンにする）。
- 確認は2か所です。Web 側の PHP のバージョンと、更新後の再起動。
- 8.1 以下を使っているなら、移行を計画してください。今回に限らず、同じことはまた起きます。
自社サイトの PHP のバージョンがわからない、更新してよいか判断できない、といった場合はご相談ください。当社では WordPress・Laravel のサイト運用と保守を行っています。
