>_toolkitbox

~/ / AI記事 / AIの助けで見つかったPHP2Shell: 2026年10月のPHPの重大な脆弱性

AIの助けで見つかったPHP2Shell: 2026年10月のPHPの重大な脆弱性

報道によると、AIモデルの助けで、研究者がPHP本体の重大な脆弱性2件(CVE-2026-109618、CVE-2026-109619)を見つけました。これらは認証なしのリモートコード実行につながり得ます。PHPは2026年10月21日に修正済みバージョンを公開しました。この記事では、公式発表と報道がこれらの脆弱性とAIの関わりについて述べている内容をまとめ、お使いのPHPに修正が入っているかを確認できるようにします。

2026-10-24時点の公式発表と照合しています。このページは公式のアドバイザリではなく、詳細は変わる可能性があるため、末尾の情報源を参照してください。

まず行うこと

  1. PHPを修正済みのリリース(8.5.12、8.4.27、8.3.36、8.2.35)、またはLinuxディストリビューションの修正済みパッケージに更新してください。PHPは、完全な緩和策はなく、更新だけが安全な選択肢だと述べています。
  2. 更新後は、修正済みのコードを読み込ませるために、PHP-FPM、Apache、および長時間動作しているPHPワーカーを再起動してください。更新前に起動したサービスは、まだ古いコードのまま動いています。
  3. PHPがディストリビューションのパッケージ由来の場合は、最初のハイフンより後ろの部分も含めて、パッケージのバージョン全体を確認してください。ディストリビューションは、番号の前半部分を変えずに修正を取り込むことがあります。
  4. すぐに更新できない場合は、下の緩和策を参照してください。PHPは、これらは特定の攻撃経路に対する露出を減らすものの、環境を安全にするものではないと述べています。

何が起きたか

2026年10月21日、PHPは 8.5.12、8.4.27、8.3.36、8.2.35 をリリースしました。これらは2件の重大な脆弱性を修正しており、どちらもCVSS v4.0で9.2と評価されています。

CVE-2026-109618(RCE via OOM corruption と呼ばれています): メモリ不足の処理により、リクエストの内部データが一部しか初期化されていない状態でPHPが中断されることがあり、その後のリクエストのクリーンアップが、不正なデータを有効なものとして扱うおそれがあります。

CVE-2026-109619(RCE via stale global state と呼ばれています): リクエストが所有する内部状態が、それを支えていたメモリが解放された後も残ることがあり、同じワーカーが後から処理するリクエストがその古い状態を使うおそれがあります。

  • CVE-2026-109618 · CVSS 4.0 9.2
  • CVE-2026-109619 · CVSS 4.0 9.2

AIがどう関わったか

The Next Web によると、セキュリティ企業のCalifは、OpenAIが資金を出したPHPのソースコード監査の中で、OpenAIのモデルの助けを得て、8月に最初のバグを見つけました。Wizは、数週間後に、GoogleのGeminiモデルを含むAIツールを使って、独自にこれらの欠陥を見つけたと述べています。

php2shell.com は、Wiz Research、OpenAI Codex Security、Califによる調査として紹介しています。Califは、一般に利用可能なモデルを使ったと述べ、モデルよりもPHPの経緯を知っていたことのほうが重要だったとしています。

同じ記事は、Cloudflareが公開のおよそ9時間前に顧客向けのWAFルールを有効にし、その後に概念実証(proof-of-concept)のエクスプロイトがオンラインで出回ったと伝えています。php2shell.com は、WAFやCDNのルールをPHPの更新の代わりとして扱うべきではないと述べています。

経緯

  1. PHPが、10月21日14:00 UTCに予定している重大なセキュリティリリースを予告しました。
  2. PHP 8.5.12、8.4.27、8.3.36、8.2.35がセキュリティアドバイザリとともにリリースされ、UbuntuがUSN-8948-1を公開しました。
  3. PHPが、CVE-2026-115560として追跡されている、さらに別の可能性の低い攻撃経路について、session.upload_progress.enabled に関する情報提供のアドバイザリを公開しました。

影響を受けるのは誰か

PHPは、PHP-FPM、mod_php を使うApache、php-cgi、FrankenPHP、LiteSpeed を含め、ウェブリクエストを処理するすべてのPHP環境が危険にさらされていると述べています。リスクが最も高いのは mod_php で、認証なしのリクエストがアプリケーションのコードが動く前に攻撃を引き起こせるとしています。

GitHubのアドバイザリは、8.2.35、8.3.36、8.4.27、8.5.12 より前のバージョンを影響ありとしています。Wizが運営しているとされるサイト php2shell.com は、影響を受けるリリースは PHP 5.4 まで遡ると述べています。

PHP 8.1 以前は、PHPプロジェクトからの更新を受けられなくなっています。一部のディストリビューションやLTSベンダーはバックポートした修正を提供しており、PHPはソースからビルドする人向けに、PHP 7.4、8.0、8.1 への最小限のソースのバックポートを提供しました。

修正済みバージョン

そのブランチの修正済みリリース以上のバージョンには、修正が入っています。ディストリビューションのパッケージはパッケージのバージョンで修正済みかどうかが決まるため、UbuntuとDebianについては2つ目の表を使ってください。

PHP本体のリリース

ブランチ最初の修正済みリリース
PHP 8.58.5.12
PHP 8.48.4.27
PHP 8.38.3.36
PHP 8.28.2.35

UbuntuとDebianのパッケージ

ディストリビューションパッケージ修正済みのパッケージバージョン告知
Ubuntu 26.10php8.58.5.9-0ubuntu2.1USN-8948-1
Ubuntu 26.04 LTSphp8.58.5.4-0ubuntu1.5USN-8948-1
Ubuntu 24.04 LTSphp8.38.3.6-0ubuntu0.24.04.13USN-8948-1
Ubuntu 22.04 LTSphp8.18.1.2-1ubuntu2.28USN-8948-1
Debian 12 (bookworm)php8.28.2.35-1~deb12u1DLA-4848-1
Debian 13 (trixie)php8.48.4.27-1~deb13u1DSA-6574-1

表には、公式の告知に載っている内容だけを示しています。ほかのディストリビューションについては、ベンダーのセキュリティ告知を確認してください。

お使いのPHPを確認する

PHPの入手元を選び、バージョンのテキストを貼り付けると、このツールが上の修正済みバージョンと比べます。判定するのは貼り付けたテキストだけです。実際にどのバージョンが動いているかは分からないため、更新後にサービスを再起動したことも合わせて確認してください。

バージョンを表示するコマンド

  • php -v
  • dpkg -l 'php*' | grep ^ii
  • apt-cache policy php8.3-fpm | grep Installed

すべてブラウザ内で処理されます。貼り付けたテキストがアップロードされることはありません。

すぐに更新できない場合

PHPはこれらの対策を挙げています。これらは特定の攻撃経路に対する露出を減らすものの、環境を安全にするものではなく、完全な解決策は更新だけだと述べています。

CVE-2026-109618

  • memory_limit=-1 を設定します。できればFPMプールやApacheの設定の php_admin_value のように、アプリケーションから上書きできない方法で設定してください。下層のメモリ割り当ての失敗が、脆弱な経路に達することはなおあり得ます。
  • post_max_size を低く設定します。ファイルアップロードが不要なアプリケーションでは 8M、アップロードが必要な場合は 32M です。upload_max_filesize は post_max_size より小さくしてください。
  • ウェブサーバーまたはプロキシで、デコード後のリクエストサイズ、入力フィールド数、マルチパートのパート数、ヘッダー数、ネストの深さに制限をかけてください。
  • 可用性の境界として、コンテナまたは cgroup の制限を使ってください。RLIMIT_AS や RLIMIT_DATA は、脆弱なメモリ割り当ての失敗を引き起こすおそれがあるため、使わないでください。

CVE-2026-109619

  • php.ini、FPMプール、またはサーバー設定で session.upload_progress.enabled=0 を設定し、すべてのワーカーを再起動してください。ini_set() や FPM の .user.ini ファイルには頼らないでください。
  • PHP 8.5 では、fatal_error_backtraces=0 を設定し、すべてのワーカーを再起動してください。
  • 初期化の前に診断メッセージを出す、リクエストごとに適用される無効または非推奨の設定を取り除いてください。診断メッセージを隠しても効果はありません。
  • 攻撃者が到達できる致命的エラーや実行タイムアウトを解消してください。

10月23日の情報提供アドバイザリ

PHPは、可能性の低いもう1つのリモートコード実行の経路から完全に保護するため、次の通常のバグ修正リリースまで session.upload_progress.enabled=0 を設定することを勧めています。10月21日のアドバイザリを受けてすでに設定している場合は、そのままにしてください。

PHPによると、この問題が起こり得るのは、特殊な組み合わせの場合に限られます。アプリケーションが設定で session.serialize_handler を php_binary または php_serialize にしており、session_start() の前に ini_set() で実行時に php に切り替え、さらにセッションのアップロード進捗が有効なままの場合です。PHPは、次のリリースでCVE-2026-115560の完全なアドバイザリを公開する予定です。

このページができないこと

  • これは公式のアドバイザリではなく、エクスプロイトの詳細も示していません。権威があるのは、下に挙げた公式の発表とアドバイザリです。
  • システムが攻撃を受けたかどうかは判断できません。php2shell.com は、不審な動きが見当たらないことは、システムが影響を受けていないことの証明にはならないと述べています。
  • 影響の度合いは、バージョン、設定、そして個々の脆弱性によって異なります。緩和策は、アプリケーションの動作に影響する場合があります。

情報源