自社の Web サイトやオンラインストアが WordPress、Magento、Laravel など PHP ベースのシステムで動いているなら、今日中にホスティング会社か技術チームに依頼して、PHP をバージョン 8.5.12、8.4.27、8.3.36、8.2.35 のいずれかに更新し、その後サーバーを再起動してください。PHP プロジェクトは 2026年10月21日にこれらのバージョンを公開し、PHP2Shell と呼ばれる二つの重大な脆弱性を修正しました。どちらも 10 点満点中 9.2 と評価され、攻撃者はパスワードなしであなたのサーバー上でコマンドを実行できます。サウジアラビア国家サイバーセキュリティ庁（NCA）は同日、更新を推奨する「重大」レベルの警告を出し、セキュリティ企業は修正公開の数時間前から悪用の試みを確認していました。

何が起きたのか？

二つの脆弱性は CVE-2026-109618 と CVE-2026-109619 で、プラグインやテーマではなく PHP 言語そのものにあります。ここが重要な違いです。以前の記事「WordPress の修正が攻撃者の地図になった件」では、問題は PHP の上で動くソフトウェアにありました。今回の問題は、それらすべてのソフトウェアが載っている土台にあります。そのため、WordPress を最新にしていても、プラグインが少なくても守られません。

PHP の一つ目のセキュリティ勧告によると、一つ目の脆弱性はリクエストの準備中にメモリが不足したときに発生し、PHP は初期化が途中のデータを残したまま、後でそれを正しいデータとして扱ってしまいます。二つ目の勧告によると、もう一つの脆弱性は、前のリクエストのデータが解放された後も参照が残り、同じプロセスの次のリクエストがそれを使ってしまうものです。どちらの場合も結果は同じで、巧妙に作られた Web リクエストが一つあれば、サーバー上でコマンドを実行できます。

Wiz Research は AI モデルの助けを借りてこれらの脆弱性を発見しました。同社のレポートによると、チームは 2026年8月19日に発見し、8月24日に PHP チームへ報告しました。また、5.4 以降のすべての PHP バージョンが少なくとも一方の影響を受けるとしています。Wiz は、Web サイトの約 70% が PHP で動いていると推定しています。

自社サイトは影響を受けますか？

PHP で動いていて、バージョンが上記より古ければ、影響を受ける可能性が高いです。Wiz は、標準設定の WordPress、Drupal、Joomla で認証なしのリモートコード実行を実証しました。Sansec は分析の中で対象を 11 のプラットフォームに広げており、Magento 2.4.9、WordPress 7.1.2、Laravel 13.11、Symfony 8.1、phpMyAdmin、Nextcloud、WHMCS が含まれます。

PHP のバージョンを確認するには、ホスティングの管理画面（cPanel、Plesk など）を開いて「PHP Version」を探すか、チームに確認してください。注意点は二つあります。

  • 8.1 以前のバージョンはサポートが終了しており、修正は提供されません。PHP のサポート対象バージョン表によると、現在サポートされているのは 8.2、8.3、8.4、8.5 のブランチだけです。
  • 8.2 ブランチ自体も 2026年12月31日、つまり二か月半後にセキュリティサポートが終了します。今更新するなら 8.4 か 8.5 に移行し、近いうちに再度アップグレードする手間を省きましょう。

今日やるべきこと：五つの手順

  1. PHP が動いている場所をすべて洗い出す。 Web サイト、ストア、管理画面、社内システムや顧客ポータル。まだ公開されたままの古いサイトを忘れている企業は少なくありません。
  2. 修正済みバージョンに更新する。 8.5.12、8.4.27、8.3.36、8.2.35 のいずれか。共有ホスティングの場合は、「10月21日の更新は適用済みですか？」と書面でホスティング会社に確認してください。
  3. 更新後に PHP を再起動する。 PHP の勧告によると、再起動していないプロセスは古いコードのまま動き続けるため、更新をダウンロードするだけでは不十分です。
  4. サイトが 8.1 以前で動いている場合は、 今週中にアップグレードを計画し、まずステージング環境のコピーで試してください。古いプラグインが動かなくなることがあります。
  5. ログを確認する。 Wiz は、異常なアップロードリクエストの後に続くメモリ不足エラー、繰り返し発生する HTTP 500 エラー、極端に大きいまたは不正な形式のセッション Cookie（PHPSESSID）を探すよう勧めています。

今日更新できない場合

PHP の勧告は、リスクを下げるものの更新の代わりにはならない一時的な対策を挙げています。session.upload_progress.enabled を 0 にして無効化し、すべてのプロセスを再起動すること、そしてバージョン 8.5 では fatal_error_backtraces を 0 にすることです。サイトでファイルのアップロードを受け付けていないなら、フロントエンドのサーバーで multipart リクエストをブロックすることもできます。

サイトが Cloudflare の背後にある場合、同社はブログで、10月21日 UTC 3:02 からこれらの脆弱性に対するファイアウォールルールを展開したと述べています。公開の約 9 時間前で、無料プランを含むすべてのプランが対象です。ただし Cloudflare 自身も、攻撃者が攻撃内容を変え続けているため、この保護があっても PHP を更新するよう勧めています。

Origami の見解

今回の脆弱性は、サイトのセキュリティが WordPress とプラグインの更新だけでは終わらないことを思い出させてくれます。どのサイトの下にもプログラミング言語、サーバー、設定があり、そのすべてに目を配る人が必要です。企業でよく見かけるのは、何年も前に作られたサイトで、どの PHP バージョンで動いているのか、誰が更新の権限を持っているのか、もう誰も知らないというケースです。もし当てはまるなら、問題はもはや「更新すべきか？」ではなく「今日誰が更新するのか？」です。Origami は Web サイトやシステムを構築し、初日から更新を見守っています。サイトの点検や、停止なしでの PHP アップグレードをご希望なら、お問い合わせください.

出典