10月21日、オランダ国家サイバーセキュリティセンターは独自のウェブサイトをオフラインにしました。WordPressがハックされたからではなく、その下のPHP インタープリタがハックされる可能性があったからです。
その日、PHPプロジェクトはインタープリタ自体の認証されていないリモートコード実行バグ2つの修正をリリースしました。CVE-2026-109618とCVE-2026-109619です。PHPがパブリックリクエストに応答していたサイトはすべてパッチを当てるか、ダークに移行する必要がありました。CDNから静的HTMLを提供していたサイトはリクエストパスにPHPプロセスがなかったため、エッジでパッチを当てるものはありませんでした。Headless WordPressでもバックエンドの更新が必要でしたが、パブリックサイトはアップしたままでした。以下は、タイムライン、アーキテクチャ上の議論、スタックによる決定表、30/60/90日間の計画、今後もPHPにとどまっている場合のチェックリストです。
PHPを実行している場合は、今日これを行ってください。
- 実行中のバージョンが8.5.12、8.4.27、8.3.36、8.2.35、または読んだベンダーバックポートであることを確認し、すべてのワーカーを再起動してください。
- ダッシュボードが何を言っているかではなく、ホスティングコントロールパネルが実際に提供したものを確認してください。
- PHPのini緩和策とWAFルールを、パッチの代用ではなく、パッチへの橋として扱ってください。
- 7.4から8.1では、ホストに、セキュリティチームのソースバックポートを構築したかどうか尋ね、どちらにしてもアップグレードを予約してください。
2026年10月21日に何が起こったのか
タイムラインが重要な理由は、パニックの説明になるからです。Tenableによると、CVE識別子は10月20日にHacker NewsとソーシャルメディアでV出回りました。その日後、PHPセキュリティチームは10月21日14:00 UTCのリリース予定通知を発表し、詳細が公開された場合はより早く配信される可能性があると述べました。Tenableはまた、watchTowr情報を引用して、開示は当初エンバーゴ下の10月22日に設定されていたと報告しています。
PHPセキュリティチームはその後10月21日にアドバイザリを発表しました。タイトルは「セキュリティアドバイザリ:重大なリモートコード実行脆弱性、今すぐ更新してください」(php.netニュースアーカイブ)です。ENISAジョイントステートメントは更新を13:40 UTCとしています。修正されたバージョンはPHP 8.5.12、8.4.27、8.3.36、8.2.35です。
GitHubアドバイザリからの2つのバグ:
- CVE-2026-109618: メモリ不足破損によるリモートコード実行。
- CVE-2026-109619: 古い状態によるリモートコード実行、同じワーカーが処理するリクエスト間のUse-After-Free。
PHPセキュリティチームは両方をCVSS v4.0の9.2と評価しています。Tenableは、watchTowr およびHacker Newsの投稿を含む初期報告の一部が10.0と述べたと指摘しています。すべてのウェブサービングSAPIが対象です:PHP-FPM、Apache mod_php、php-cgi、FrankenPHP、LiteSpeed。OOMアドバイザリはmod_phpが最も露出していることを指摘しています。障害がアプリケーションコードが実行される前にまったく発生するためです。Califは最も古く影響を受けるコードパスがPHP 5.4.0までさかのぼると述べています。発見はWiz、Calif、OpenAIで、AI支援の研究により評価されています。
その後停止が発生しました。ReutersとRTEはオランダ、フィンランド、フランス、オーストラリアの政府サービスがオフラインになったと報告しました。オランダ国家サイバーセキュリティセンターのサイト自体を含みます。CERT-EUはパッチが適用されるまでインターネット向けアプリケーションを隔離することを推奨し、CISAは直ちにパッチを適用するよう促しました。Krebsはクラウドフレアが午前3時02分UTCにWAFルールを導入したと報告しています。Amazon Threat Intelligenceは10月17日の試みを検出し、その後エクスプロイトが広範であると述べました。
エクスプロイテーションについて、情報源は異なり、あなたはそれを知るべきです。PHPファウンデーションは、リリース時に機能的なエクスプロイトを特定していないと述べました。Krebsは機能するエクスプロイトが存在すると専門家が言及したと報告しています。Tenableはバグのエクスプロイトを主張するコードが出回っていたが、それを検証していないと述べました。
パッチを当てるか、オフラインになるべき理由についてのアドバイス
リクエストパスの認証されていないリモートコード実行は、ウェブサーバーがターゲットであることを意味します。ログインはなく、無効にするプラグインもありません。リクエストが到着し、PHPがそれを解析し、バグはすでに動作中です。OOMアドバイザリは、デフォルト入出力とメモリ制限の下でHTTP経由でmod_phpに対して検証された、ウェブワーカーアカウントの認証されていないコード実行の影響を確認しています。
PHPがリストした軽減策は本物で、一時的な対応です。アドバイザリは以下と述べています:
- memory_limitを-1として(
php_admin_value経由で)管理的に設定し、post_max_sizeを保守的に保つ、マルチパートリクエストをフロントエンドでブロックしてください(使用しない場合)。 session.upload_progress.enabled=0を設定します。- PHP 8.5では、
fatal_error_backtraces=0を設定します。 - これらのいずれかの後、すべてのワーカーを再起動します。
同じ勧告は、更新が唯一の完全な修正であることが明白です。ステートの古さバグについては、完全なジェネリック設定の緩和策はまったくありません。PHPコア開発者のGina Peter Banyard氏はTenableに引用され、唯一の緩和策はPHPのパッチまたはアップグレードであると述べました。PHP 8.6リリースマネージャーのJoe Ferguson氏はini設定では救えないと述べています。したがってこのリストは、姿勢ではなく、1午後を乗り切るための橋だと考えてください。
2つの実際的な課題が、バージョンバンプよりも難しくしました。共有ホスティングとコントロールパネルは、独自のスケジュールでPHPパッケージを提供するため、実行していると思われるバージョンが、実際に実行されているバージョンと異なる場合があります。Pleskは、提供するPHPについて独自の通知を発行しました。これは、想定するのではなく読む必要があるページの典型です。
その後、古いブランチ。php.netアドバイザリはPHP 8.1以降がプロジェクトから更新を受け取らなくなり、バックポートについてディストリビューションとLTSベンダーを指しています。セキュリティチームはGitHubで7.4、8.0、8.1の最小限のソースバックポートブランチを公開しましたが、ソースパッチはリリースではありません。誰かが依然としてそれを構築してホストに提供する必要があります。PHP 5.4から7.3は何も得られません。アップグレードしなかった場合、それが10月21日でした。
スケールに関するいくつかの数字。W3Techsは10月22日現在、既知のサーバー側言語を持つWebサイトの69.3%がPHPを使用していることを示しており、そのうち65.3%がバージョン8、26.9%がバージョン7、7.7%がバージョン5です。Censysは258万個のインターネット対応ホストと5490万個のPHPを実行するWebプロパティをカウントしています。これは多くのワーカーを再起動する必要があります。
10月21日には何もすることがなかった人たち
リクエストパスの観点から露出状況を示します。任意のサイトに1つの質問をしてください。訪問者がページを読み込むときに、それに応答するために何のコードが実行されますか。
CDN上の静的HTML
答えが「何もありません。CDNはファイルを返します」の場合、PHP2Shellは公開サイトに触れません。PHPプロセスがリクエストに応答しないため、エッジでパッチを当てる必要がなく、何をもオフラインにする理由もありません。私はgautamkhorana.comをAstroで静的出力で実行しています。Next.jsとSupabaseで構築したHostListは約28,000のプログラムページを持ち、PHPプロセスはありませんでした。30言語で91,000ページ以上を実行するDeluxe Astrologyも同じです。10月21日に誰も電話をかけてきませんでした。
Headless WordPress
Headlessは別の話であり、お世辞を言うより正確でありたいです。WordPressはまだPHPで実行されているため、PHPバックエンドはその日8.5.12、8.4.27、8.3.36、または8.2.35が必要でした。違いはそれがどこに位置するかです。ファイアウォールまたはIPアロウリストの背後にあり、AstroまたはNext.jsによって公開サイトが提供される場合、バックエンドは訪問者のリクエストのパスにありませんでした。パッチは公開の停止ではなく、メンテナンスタスクでした。
はっきり言ってください。これは「ヘッドレスは不可侵」ではありません。バックエンドに到達できる攻撃者は、そのバグに到達することもできます。だからホワイトリストが重要なのです。SSRフレームワークには独自のサーバーランタイムリスクがあり、Next.js、Astro、Nuxtのセキュリティの記事で説明されており、より広い比較はヘッドレス対WordPressセキュリティにあります。ここではどちらも繰り返しません。
1回限りではなく、パターン
これはPHPのリクエストパスが見出しになった最初の時間ではありません。PHP-CGI引数インジェクション、CVE-2024-4577は2024年に発生しました。2012年には古いPHP-CGIバグがありました。現在はPHP2Shell。異なるフロー、同じ形:すべての公開リクエストの前に座っているコードが攻撃され、その下流のすべてが混乱しました。
今、反対方向を切る教訓。Next.jsのReact2Shellは、SSRランタイムが独自のリクエストパス露出を持つことを示しました。JavaScriptサーバーがすべてのページリクエストに応答する場合、パッチの目的では新しいPHPです。WordPressからNext.jsサーバーレンダリングサイトへの移動は、攻撃表面を移動します。それを削除しません。静的出力が強い主張です。SSRはトレードです。
したがって、問題は「どの言語か」ではありませんでした。それは「何のコードが公開リクエストに応答するか」です。そのリストを切り詰めると、次のCVEがどの言語で書かれているかに関わらず、インシデント日数が短くなります。
前向きなポイントもあります。Wizの研究者は、フロー「人間の研究者が実用的に達成できることの端」の長さのチェーンを悪用する必要があり、「フロンティアAIモデルはその障壁を大幅に低減した」と述べました(Krebs)。含意は私のものであり、彼らのものではありません。古いフロー理由をエクスプロイトに変えるのが安くなった場合、すべてのランタイムの開示順序が上がります。このような日がより少なくなるのではなく、より多くの日を計画してください。
10月21日があなたにかかった費用(スタック別)
| スタック | パブリックリクエストパスのPHP? | 10月21日に何をしなければならなかったか | 次のPHP CVEがあなたに与える代償 | 現実的な移行パス |
|---|---|---|---|---|
| 従来のWordPressまたは他のPHP CMS | はい、すべてのページ | PHPを修正版に更新し、すべてのワーカーを再起動するか、サイトが対応できるまで隔離する | 公開サイト上で同じ混乱 | ページタイプごとにHeadlessに移行 |
| Headless WordPress（ファイアウォール背後のPHPバックエンド、Next.jsまたはAstroフロントエンド） | いいえ、バックエンドのみ | バックエンドのPHPにパッチを適用。公開サイトは配信を継続 | ロックダウンされたホスト上のパッチウィンドウ、公開停止なし | 留める。バックエンドをホワイトリスト化した状態で維持 |
| LaravelまたはカスタムPHPアプリ | はい | ランタイムを更新し、ワーカーを再起動し、ホストが提供したものをチェック | 同じ混乱 | 静的またはSSRフロントエンドを前に配置し、ページタイプを段階的に移行 |
| 静的Jamstack（Astro、Next.jsの静的エクスポート、Nuxt generate、Eleventy） | いいえ | エッジでは何もない。ビルドツーリングとオリジンをチェック | エッジでは何もない | 留める |
| SSR付きのNext.jsまたはNuxt | PHPなし。JavaScriptサーバーがリクエストに応答 | PHPについては何もない。独自のランタイムアドバイザリが適用される | 同じ形状の異なるランタイムCVE | リクエストごとのレンダリングが不要なページを静的出力に移す |
クラシックWordPressまたは他のPHP CMS。Drupal、Magento、Joomla、WordPressはすべてPHPで動作しており、CalifはTenable FAQによると、これら4つすべての特定バージョンに対する認証前のリモートコード実行を確認しています。この行が1日全体のコストの大部分を占めていました。
Headless WordPress。パッチは適用しましたが、自分のスケジュールでファイアウォールの背後で。編集者は編集を続けました。訪問者には何も見えませんでした。
LaravelまたはカスタムPHP。従来のCMSと同じリスク露出ですが、1つの問題があります。カスタムアプリ向けの製品勧告を公開している企業はありませんので、インベントリはあなたが管理する必要があります。NCSC-NLのphp2shellリポジトリによると、カスタムPHPアプリケーションはその概要に登録されていません。
Static Jamstack。エッジで対応することはありません。ビルドがCIボックスで動作している場合、訪問者をサーブしていないため、都合のよい時に パッチを適用してください。
Next.jsまたはNuxtでのSSR。PHPもphp2Shellもありません。ただしサーバープロセスはまだリクエストに応答し、React2Shellはこのプロセスにも独自の問題がある日があることを思い出させます。
30/60/90日計画
PHPの公開サーフェスを削除し、編集体験を再構築しないこと。
- 30日までに、ページタイプ(投稿、ランディングページ、商品ページ、アーカイブ)をリストアップし、どれが本当にリクエストごとのロジックが必要か確認します。すべてのホストでPHPバージョンを確認します。オリジンの前にCDNを配置し、管理画面をアローリストに制限します。
- 60日までに、WordPress Content APIから構築された最もトラフィックが多い静的ページタイプ1~2つの、AstroまたはNext.jsフロントエンドを立ち上げます。公開時にリビルドをトリガーします。移動したすべてのURLに対して301リダイレクトを追加します。
- 90日までに、静的にできる残りのページタイプを移行します。PHPオリジンを公開トラフィックから閉鎖し、ビルドプロセスとアローリストに登録された編集者だけがアクセスできるようにします。サーバーが本当に必要なもの(検索、フォーム、アカウント)は、独立してパッチを適用できる小規模で名前の付いたサービスに移動します。
CMSを失わずにPHPの公開サーフェスを削除する
PHPをリクエストパスから削除するためにWordPressを捨てる必要はありません。Headless WordPressは編集者、コンテンツ、執筆と承認のためのプラグインワークフローを保持し、AstroまたはNext.jsがサイトをサーブします。編集者は知っている画面を保ちます。訪問者はCDNからファイルを取得します。
段階的に移行します。ページタイプを選択し、新しいフロントエンドで再構築し、古いURLを301リダイレクトして、次に進みます。管理画面はPHPのままで、アローリストの背後にあります。ホスティングパターンはシンプルです。ロックダウンされたオリジン、前面のCDN、公開時のビルド。
フレームワークの選択について、コンテンツサイトはAstro、サイトがアプリケーション層を必要とする場合はNext.js、Vueチームの場合はNuxt。より深いトレードオフは、静的サイトジェネレーターの比較とHeadless WordPressガイドにあります。
労力について、開始価格だけを使用すると、WordPressからAstroへの移行は7,000ドルから、Headless WordPressの開発は10,000ドルから、従来のCMS移行は5,000ドルから開始します。サイトがアプリケーション層を必要とする場合、WordPressからNext.jsへの移行(10,000ドルから)が適切なルートです。これらは出発点であり、実際の金額はページタイプ、統合、保持したい編集ワークフロー量によります。PHP全体の削除を検討している場合、leave-WordPressページがそのパスをカバーしています。
これを開始する最も安い日は、勧告の翌日ではありません。ただし勧告の翌日は予算が承認される日なので、それを利用してください。
当面PHPにとどまっている場合
サイトの一部は1年から3年間、そのままになります。それで構いません。その間にこれらを実施してください:
- 実行中のPHPバージョンが8.5.12、8.4.27、8.3.36、または8.2.35(またはあなたが通知を読んだベンダーのバックポート)であることを確認し、すべてのワーカーが再起動したことを確認してください。古いワーカーが実行されたままのパッケージアップグレードは何も解決していません。
- ダッシュボードが表示しているものではなく、ホスティングコントロールパネルが実際に提供したものを確認してください。
- PHPが掲載している軽減策は橋渡しとしてのみ適用してください。勧告では、インストールを安全にするものではなく、OOM勧告では
RLIMIT_ASとRLIMIT_DATAに対して警告しており、これらは脆弱なパスをトリガーします。 - 今から7.4から8.1への移行を計画してください。PHPプロジェクトはもう8.1以前の更新をしておらず、あなたは他の誰かのバックポートに依存しています。
- パッチを適用中はサイトをWAFの背後に置いてください。Cloudflare CTOのDane Knecchtはそのルールを「一時的な対応に過ぎない」と呼び、Tenableはそれらが Cloudflare を経由してルーティングされるトラフィックのみをカバーしていることに注意しています。
- ウェブシェルおよび存在すべきでないPHPファイルを監視してください。Wizは大量の悪用によるインストールを予想しているため、アップロードディレクトリと最近変更されたファイルを確認してください。
WordPressにとどまるサイトの場合、月額$150からのWordPressセキュリティケアは継続的なパッチ適用と監視をカバーします。
10月21日からの最も鋭い事実は、バグがすべてのPHP訪問者が触れる唯一の場所に存在したため、何もする必要がなかったサイトはPHPが公開リクエストに応答しなかったサイトだけでした。静的出力がその主張の強い版です。ヘッドレスWordPressはまだそのバックエンドのパッチが必要でしたし、SSRは単に1つのランタイムを別のランタイムと交換するだけです。
FAQ
WordPressはPHP2Shellの影響を受けますか?
WordPressそのものはバグではありません。欠陥はPHPに存在し、WordPressはPHP上で動作するため、パッチが適用されていないPHP上のあらゆるWordPressサイトが危険にさらされていました。Califを引用するTenable FAQは、特定のWordPressバージョンに対する認証前のリモートコード実行が確認されたことを報告しており、それが疑問を解決します。
ヘッドレスWordPressもパッチが必要ですか?
はい。バックエンドはPHPを実行しており、この脆弱性に到達できる攻撃者はバグに到達できます。ヘッドレスが変えるのは露出度です。バックエンドはファイアウォールまたはアローリストの背後に位置しながら、別のフロントエンドが公開側に提供できます。
Next.jsまたはAstroサイトはPHPより安全ですか?
いずれからの静的出力はこのクラスのバグに対してより安全です。なぜなら、サーバー側ランタイムがリクエストに応答しないからです。SSRは交換です。PHPを独自のアドバイザリーを持つJavaScriptサーバーランタイムと交換し、React2Shellが示したように。
WAFは私を保護しますか?
部分的にのみ、そしてしばらくの間だけです。Cloudflareはそのルールを一時的な対応と呼んでおり、Cloudflareを経由するトラフィックのみをカバーしています。WAFはパッチを適用する時間を稼ぎます。これはパッチではありません。
サイトをオフラインにするべきですか?
CERT-EUは修正が利用可能になるまでのインターネット向けアプリケーションの分離を検討することを推奨し、ENISAの共同声明は即座の改善が実行可能でない場合も同じことを述べています。迅速にパッチを適用できればパッチを適用してください。できない場合、分離は妥当な判断です。
どのPHPバージョンが修正されましたか?
PHPアドバイザリーによると、PHP 8.5.12、8.4.27、8.3.36、8.2.35です。
PHP 7.4、8.0、および8.1はパッチが適用されていますか?
リリースでは解決しません。php.netの勧告では、8.1以前は、PHPプロジェクトからの更新を受け取っていないため、セキュリティチームは7.4、8.0、8.1の最小限のソースバックポートブランチを代わりに公開しました。ホストまたはディストリビューションがそれらを構築したかどうかを確認してください。いずれにしても、アップグレードを計画してください。