サイバーセキュリティ

PHP2Shell:PHPの緊急パッチ公開、だがWordPressサイトはホスティング事業者の対応待ち

その修正はWordPressの下層にあるため、ホスト、Linuxディストリビューション、またはコンテナイメージがそれを配信した際にのみサイトに反映され、かつすべてのPHPワーカーが再起動した後にのみ適用されます。
Adrian Kessler
Googleで追加する

PHP2Shellの修正パッチが公開された。しかし、適用が必要なウェブサイトの大半には、自分で押せるボタンがない。脆弱性があるのはPHPそのもの、つまりWordPressやJoomla、Drupalのページを動かすエンジンであり、CMSやプラグイン、ログイン画面より下の層にある。WordPressを更新しても、この問題は解決しない。修正済みのインタープリターを用意するのは、サーバーの運用者だ。ホスティング会社、Linuxディストリビューションのパッケージ、コンテナイメージなどが該当する。対応が済むまでは、サイトの所有者が何をしても、サイトは待つしかない。

「今すぐパッチを」という見出しが伝え損ねているのは、まさにこの部分だ。PHPチームは自らの役割を果たした。修正を各サーバーに届けられるかどうかは、最も遅いリンクの速度に左右される配布経路にかかっており、公開初日には各リンクの対応状況に大きな差があることが明らかになった。自分のPHPがどこから提供されているか知らないサイト所有者には、どれほど危険にさらされた状態なのかも判断できない。

WordPressを更新しても直らない理由

不具合はインタープリターにあるため、PHPの勧告の対象となるのは、ウェブリクエストを処理するすべての環境だ。PHP-FPMやApacheのmod_phpから、php-cgi、FrankenPHP、LiteSpeedまで含まれる。The Hacker Newsによると、脆弱なバージョンであれば、何もない「Hello World」ページでさえ攻撃される可能性がある。最も深刻なのはmod_phpだ。アカウントを持たない人物からのリクエストひとつで、アプリケーションのコードが実行される前に攻撃が成立しうるため、セキュリティプラグインもログイン画面も、その攻撃を検知できない。

WordPress向けセキュリティ企業Wordfenceは、The Vergeの報道によると、修正は自動アップデートでは適用されないため、PHPの管理責任者を特定する必要があるとサイト所有者に伝えた。Laravel Forgeも、自社のサーバーを利用する顧客に同じ点を説明している。自動セキュリティアップデートではPHPは修正されず、Ubuntuの無人アップグレードが取得するのもUbuntu自身のリポジトリにあるパッケージだけだ。ForgeがPHPのインストールに使うサードパーティーのパッケージは対象外となる。

パッケージの提供元は、足並みをそろえて動いたわけではない。公開当日、サイト管理サービスのmySites.guruは、cPanelのEasyApache 4では勧告から数分以内に修正版ビルドが提供された一方、Laravel Forge自身が依存するUbuntu向けパッケージソースのOndřej SurýのPPAと、Remiのリポジトリにはまだ修正版がなかったと報告した。InMotion Hostingによれば、同社の共用サーバーとWordPressサーバーはCloudLinuxのビルドを待っていた。mySites.guruが監視する稼働中のサイトでは、13:52 UTC時点で修正済みPHPバージョンを報告したものは0.08%だった。

バージョン番号だけでは判断できない

確認は、番号を読むほど単純ではない。Ubuntu、Debian、Red Hatは、上流のバージョン番号を変えずにセキュリティ修正をバックポートする。そのため、修正済みのUbuntu 24.04サーバーでも、パッケージのバージョンは8.3.6と表示される。The Hacker NewsはDebianの情報を引き、バージョン文字列を鵜呑みにせず、パッケージの変更履歴でCVEを確認するよう勧めている。mySites.guruは、もうひとつの落とし穴も指摘する。コマンドラインでphp -vを実行して確認できるPHPバイナリーは、ページ配信に使われているものとは別の場合が多い。サイト自体が報告するバージョンを確認する必要がある。

さらに、パッチを読み込ませなければならない。PHPの勧告とForgeはいずれも、Apache、PHP-FPM、そして長時間稼働するすべてのワーカーを再起動するよう強調している。キュー処理のワーカーなどのバックグラウンドプロセスは、再起動されるまで古いインタープリターを使い続ける。ディスク上のファイルが修正済みでも、状況は変わらない。

公式の修正が提供されない環境

修正版はPHP 8.5.12、8.4.27、8.3.36、8.2.35で、CVSS v4.0で9.2と評価されたCVE-2026-109618とCVE-2026-109619に対応する。PHP 8.1以前について、PHPプロジェクトが提供するのは、PHPを自分でコンパイルする人を対象にした7.4、8.0、8.1向けの最小限のソースコード・バックポートだけだ。一部のベンダーは不足分を補っている。InMotionによると、cPanelは同社の7.4から8.1までのパッケージに修正をバックポートし、CloudLinuxも自社が提供するすべてのバージョンにパッチを適用している。一方、CentOS 7には修正が一切提供されない。

サポートが途切れる古い環境は、決して少数ではない。公開前日、mySites.guruが監視する稼働中のJoomlaおよびWordPressサイトの22.7%はPHP 8.1以前を使用し、16.6%は依然としてPHP 7以前だった。同社は、その一因としてWordPress自体の対応を挙げる。WordPressはPHP 8.3を推奨しながら、すでに長くサポートが終了しているPHP 7.4も互換性のあるバージョンとして掲載している。PHP 8.2には今回のパッチが提供されたものの、セキュリティサポートは2026年12月31日に終了する。

暫定設定で防げること

公開前に広まった回避策、つまりsession.upload_progress.enabled=0の設定は有効だが、対策としては一部にとどまる。PHPによれば、この設定で遮断できるのはCVE-2026-109619につながることが確認されたセッション経由の経路であり、ほかの亜種には効かない。また、php.iniかサーバーまたはプールの設定に記述し、その後、すべてのワーカーを再起動する必要がある。PHP 8.5では、fatal_error_backtraces=0を設定すれば、確認済みの経路をもうひとつ閉じられる。どちらもCVE-2026-109618には対処できない。同脆弱性についてPHPが提案するのは、上書きできないmemory_limit=-1の設定、低いpost_max_sizeの設定、そしてウェブサーバーまたはプロキシでのリクエストサイズ制限だ。PHP自身も、完全な緩和策は存在しないとしている。InMotionによると、WordPress、Joomla、Drupal、Magento、PrestaShopはアップロード進捗機能を使わないため、これを無効にしても問題は起きない。

Cloudflareは全プランでファイアウォールルールを有効にした。同社の最高技術責任者、デイン・クネヒト(Dane Knecht)はこれを暫定措置と呼んでいる。mySites.guruが指摘するように、Cloudflareを経由せず、IPアドレスに直接向かう通信を背後のサーバーが拒否して初めて、このルールは効果を発揮する。

これまでに確認された攻撃

watchTowrによると、同社のハニーポットは公開当日に両方の脆弱性を狙う攻撃を記録し、Cloudflareも、攻撃者が同社のルールをすり抜けようとペイロードを変えているのを確認した。特定のサーバーへの侵入成功を確認した情報源は、まだない。念のためサービスを止めた事業者もある。The Hacker Newsによると、BambooHRはサービスをオフラインにし、DigiDを含むオランダの公共サービスも予防措置として停止した。EUのCERTと英国のNational Cyber Security Centreは、パッチを適用できない組織に対し、脆弱なアプリを隔離するか、オフラインにするよう呼びかけた。

この脆弱性を発見したのは、Wiz Research、カリフ(Calif)、OpenAIのCodex Securityチームだ。PHP Foundationによると、メモリー関連の脆弱性を示す兆候は2024年の監査で見つかっていたものの、修正は数か月にわたって停滞した。同財団はこの遅れを「構造的な失敗」と呼んだ。研究者らによると、AIモデルの助けを借りて、10年前から存在する不具合をおよそ1週間で実際に動作するエクスプロイトへと仕上げた。

PHPが修正を公開するまでには、監査と、数か月にわたる行き詰まり、そして情報漏えいが必要だった。共用ホスティングを使うサイトに残された最後の手段は、サポートへの問い合わせだ。

タグ: , , , ,

Googleで追加する

ディスカッション

0件のコメントがあります。