- PHPが新たなRCE脆弱性を公表。ただし悪用には、まれで特殊な設定が必要
- php2shellとは異なり、緊急パッチではなく次回の通常リリースで修正される予定
- 研究者によると、php2shellを狙った攻撃は今のところ限定的。それでも、早急かつ広範なパッチ適用が必要
PHPセキュリティチームは、いまや悪名高いこのプログラミング言語で、新たなリモートコード実行（RCE）の脆弱性を発見しました。ただし、悪用が容易ではないため、通常のリリースサイクルを待たずに修正を出す臨時対応は取られません。
同チームは最近、PHPのセッションアップロード進捗に関するバグについて、利用者に注意を促す新たなセキュリティアドバイザリを公表しました。このバグはCVE-2026-115560として追跡されています。アドバイザリによると、悪用が成立するのは「設定とアプリケーションコードが特殊な組み合わせになっている場合」に限られます。
アドバイザリには次のように記されています。「アプリケーションが設定で session.serialize_handler を php_binary または php_serialize に指定し、その後 session_start() を呼び出す前に、実行時に ini_set() で php へ切り替えている必要があります。さらに、セッションアップロード進捗が有効なままになっていることも条件です。実行時にシリアライズハンドラを変更しないアプリケーションであれば、この機能を有効のまま使い続けられます」
つまり、環境にこれらの設定が揃っていなければ、リスクはありません。PHPセキュリティチームは、次回の通常バグ修正リリースまで session.upload_progress.enabled=0 に設定することも推奨しています。チームが「可能性は低い」と説明するこのRCEの攻撃経路から、完全に保護するための措置です。また、この設定はCVE-2026-109619の緩和策としても挙げられていました。そのため、当時すでに適用した利用者は、設定を維持するだけで、ほかの対応は不要としています。
PHP2Shell
CVE-2026-109619は、最近発見されて「php2shell」と名付けられた、深刻度「クリティカル」のRCE脆弱性2件のうちの1つです。控えめに言っても影響が極めて大きいことから、発見は広範なパニックを引き起こしました。
PHPは、Webサイトやウェブアプリの構築に広く使われているプログラミング言語です。一部のアナリストは、インターネット上のWebサイトのおよそ70%がPHPで動いていると主張しています。その中には、銀行、教育、医療、政府機関のサイトも含まれます。PHPセキュリティチームがphp2shellの修正に取り組んでおり、一部のセキュリティ組織がそれを把握していたか、作業に関与していたことも明らかになりました。これらのバグにより、攻撃者はWebサイトを完全に乗っ取れる状態でした。
各組織には、サイバー犯罪者に脆弱性の存在を気づかせないよう、パッチが公開されるまで情報を伏せるよう求めていました。ところが何らかの形で情報が漏れ、Amazon Web Services（AWS）のチームは、パッチ公開予定日の4日前に悪用の試みを確認しました。
リリースの数時間前には、セキュリティ企業ChainguardのCEOが、修正を含むコンテナイメージを公開し、事実上エンバーゴを破る形になりました。セキュリティ業界は、その後に起きたことの責任を同氏に求めています。パッチ公開から数時間のうちに、悪用の試みは数百件から数千件、さらに数百万件へと急増したためです。
PHPセキュリティチームは被害を抑えようと、「事前警告」のアラートを出しました。IT担当チームに対し、準備を整えたうえで、10月21日に予定されていたパッチを待つよう呼びかけたものです。
ASLRに救われる
複数の攻撃者によるとみられるこの大規模な悪用キャンペーンが、広範なパニックを招きました。複数の情報源によると、欧州の医療機関、政府機関、教育機関の企業が、修正版の公開を待つ間、予防措置としてWebサイトを停止しました。しかし、脆弱性の深刻さと、攻撃者が素早く悪用に動いたにもかかわらず、実際に侵害された例はごくわずかでした。
実は、php2shellの悪用は見かけほど容易ではありません。その一因は、アドレス空間配置のランダム化（ASLR）という機能にあるとみられます。このセキュリティ機能は、プログラムのコードやデータがメモリ上に置かれる場所を、実行のたびにランダムに変更します。これが攻撃者の作業を複雑にしているとされています。
Pluto Securityでセキュリティ研究ディレクターを務めるYotam Perkal氏は、次のように述べています。「PHP2Shellは、悪用が簡単ではないようです。悪用の成功例がまだ見られない理由の一つは、確実にコードを実行するには、コードのメモリ上の配置をランダム化するメモリ保護機構ASLRを突破する必要があるからだと考えています。これをリモートから行うのは難しく、出回っている公開PoCの多く（その多くはバイブコーディングで作られたものです）は、実際のシステムでは確実に動作しません」
これは朗報ですが、Perkal氏は、ASLRにできるのはセキュリティチームに少しの猶予を与えることくらいだとみています。「この状況が続くとは考えていません。エクスプロイトは改良されていきます。それに、世の中のPHPサーバーの大半は今もパッチが未適用です。各チームは今すぐパッチを適用し、PHPワーカーを再起動すべきです。ただ、リリース前後の騒動と比べると、現実世界での悪用はこれまでのところかなり限定的に見えます」
