PHP2Shell の脆弱性を受けて会社のサイトを PHP 8.5.12、8.4.27、8.3.36、8.2.35 のいずれかに更新したなら、それは正しい対応ですが、すべてをカバーしているわけではありません。2026年10月23日、PHP プロジェクトは新たな警告を公開し、10月21日の更新では修正されない三つ目の脆弱性 CVE-2026-115560 について知らせました。珍しい構成が必要で、PHP は悪用の可能性は低いとしていますが、一時的な対策は簡単です。今日のうちにチームかホスティング会社に session.upload_progress.enabled を 0 にして PHP を再起動してもらい、10月21日の更新が本当に適用されたことを書面で確認してください。

PHP は10月23日に何を発表したのか？

緊急リリースの二日後、プロジェクトはセッションの「アップロード進捗」追跡について短い情報提供の警告を出しました。これは大きなファイルのアップロードがどこまで進んだかを利用者に表示する機能です。警告によると、この機能は特定のケースでリモートからのコード実行につながる経路になり得ます。修正は緊急更新ではなく次の定期リリースで提供され、その際にこの脆弱性の完全なアドバイザリも公開されます。

経営者にとって重要な点は二つです。第一に、これは別の脆弱性なので、上記四つのバージョンのいずれかを使っているだけでは不十分です。第二に、同じ一時的な対策は10月21日のCVE-2026-109619 のアドバイザリにすでに記載されていました。チームがその時点で適用していれば、新たな対応は不要です。そのまま維持してください。

あなたのサイトは影響を受けるか？

PHP の警告によると、問題が起きるのは次の三つの条件がそろったときだけです。

  • PHP の設定で session.serialize_handler が php_binary または php_serialize になっている。
  • アプリケーションのコードが、セッション開始前に ini_set() で実行時にこれを php に切り替えている。
  • セッションのアップロード進捗追跡が有効のままになっている（初期設定では有効）。

ほとんどのサイトはこのようなことをしていません。問題は、何年も前に作られたシステムや古いプラグインのコードが一行ずつ何をしているか、経営者はほとんど知らないことです。そこで最も安全な選択はこうです。サイトがファイルのアップロード時に進捗バーを表示しないなら、この機能を無効にしても何も壊れず、扉を閉じられます。依存しているなら、コードが実行時にこの設定を変えているかどうかを開発者に確認してください。

三日後の今：10月21日の更新が本当に適用されたか確認する

元の脆弱性 CVE-2026-109618 と CVE-2026-109619 は、今もより大きなリスクです。サウジアラビア国家サイバーセキュリティ庁（NCA）はこれらについて警告 2026-7949 を出し、米国の機関 CISA はすべての PHP システムを洗い出し、インターネットに公開されているものから優先して修正し、すぐに修正できないシステムはオフラインにするよう勧告しました。CISA は公開時点で悪用の成功は確認していないとしていますが、時間が味方だという意味ではありません。

多くの人が見落とす三つの点：

  • リロードではなく再起動。Red Hat の告知は、設定の変更には PHP プロセスの再起動が必要で、リロードだけでは不十分だとしています。
  • Linux サーバーではバージョン番号が異なる場合がある。PHP の告知によると、Linux ディストリビューションは事前にパッチを受け取っているため、修正が適用されていても、たとえば 8.5.12 とは違う番号が表示されることがあります。番号だけでなく、書面での確認をホスティング会社に求めてください。Red Hat は RHEL 8、9、10 がすべて影響を受けると指摘しています。
  • PHP の動かし方でリスクが変わる。PHP プロジェクトは Apache 上の mod_php のリスクが最も高いとし、Red Hat は初期設定の PHP-FPM では実際の悪用はより難しいとしています。難しいことは不可能ではないので、どちらの場合も更新は必要です。

今日ホスティング会社やチームに送る 5 つの質問

  1. 当社の各サイトとシステムではどの PHP バージョンが動いていて、2026年10月21日の修正は含まれていますか？
  2. 更新後、PHP プロセスはリロードだけでなく再起動されましたか？
  3. session.upload_progress.enabled を 0 にしましたか？していないなら、その機能は本当に必要ですか？
  4. 当社のサイトのコードは実行時に session.serialize_handler を変更していますか？
  5. 8.1 以前のバージョンで動いているサイトはありますか？これらのブランチはサポートが終了しており、サポート対象バージョンの表によると 8.2 のセキュリティサポートは2026年12月31日に終わります。

Origami の見方

重大な脆弱性の後に三日で三つの警告が出るのは普通のことです。研究者が言語の一部を掘り下げると、その周辺の問題も見つかるからです。しかし、これは企業についても何かを物語っています。21日にパッチを当てて案件を閉じた人は、23日の警告を見逃します。ここでのセキュリティは継続的なフォローであり、一度で終わる作業ではありません。

サウジアラビアの企業で私たちが目にするのは、難しい問いが「どんな脆弱性か？」ではなく「金曜の朝に PHP の警告を読み、どのサーバーが自社のものか分かっているのは誰か？」だということです。Origami では Web サイトとシステムを構築し、初日からその更新を見守っています。サイトの点検や、サービスを止めずにこれらの設定を適用したい場合は、お問い合わせください。

まとめ

10月21日の更新は欠かせず、今も最も重要です。新しい警告はそれを変えません。今日はそこに低コストの一手を加えてください。必要なければアップロード進捗の追跡を無効にし、PHP を再起動し、ホスティング会社から書面での確認を得ることです。そのうえで、CVE-2026-115560 の最終的な修正を含む PHP の次の定期リリースに注目してください。

出典