php2shellの修正版の公開後、悪用の観測と更新後に確かめること

PHPは10月21日、認証なしで任意のコードを実行されうる脆弱性2件（通称php2shell）の修正版を出しました。対象のサーバーの見分け方と、更新できないときの緩和策は前の記事に書きました。この記事は修正版の公開から半日ほどで分かったことのうち、更新を終えた人と、これから更新する人が判断に使うものだけを足します。

修正版の公開後に起きていること#

時刻は日本時間です。

日時	出来事
10月21日12時2分	CloudflareがWAFの規則を、WAFを使う全てのプラン（無料を含む）で既定で有効にする
10月21日16時41分	Chainguardが、修正を含むイメージを予定より6時間以上早く公開（PHP Foundationによる）
10月21日23時ごろ	PHPが修正版（8.5.12、8.4.27、8.3.36、8.2.35）を公開
10月21日23時19分	watchTowrが、2件への攻撃の試みを観測していると報告（The Hacker Newsによる）
修正版の公開後	Ubuntuが修正済みのパッケージを公開（USN-8948-1）
10月22日	JPCERT/CCが注意喚起を公開
10月22日朝	Cloudflareの観測で、攻撃の試みが数百万件に達する（The Hacker Newsによる）
10月24日	PHPが3つ目の欠陥（CVE-2026-115560）を、緊急の修正なしで公表（The Registerによる）

watchTowrはFAQで、自社のおとりのサーバー網（ハニーポット）で、2件とも実際の悪用を観測したとしています。The Hacker Newsによると、watchTowrは同じ日の日本時間20時26分の時点では観測していないとしていました。Cloudflareは、情報が予定より早く出回った間に顧客のサイトへの攻撃の通信を観測し、攻撃者が自社の規則を避けるために攻撃の中身を書き換えていたと書いています。

The Hacker Newsの10月23日の記事によると、攻撃の中にはMiraiから派生したボットネット「Potassium」を仕掛けようとするものもありました。Sophosの分析では、DDoSの機能を持つ既知の亜種の更新版です。

一方で、特定のサーバーへの侵入が成功したという報告は、同じ記事の時点でもありません。Sophos、Previdian、SOCRadar、Wordfenceのどれも、成功した例を確認していないとしています。米CISAが公開している、悪用が確認された脆弱性の一覧（KEV）にも、10月25日に見た時点で2件は載っていませんでした。

それでも急ぐ理由は、攻撃の道具がそろっていることです。Krebs on Securityによると、発見者の1社のWizは、Webから遠隔で操作するための裏口（Webシェル）を仕掛ける目的で、大規模に悪用される可能性が高いとみています。Wizはこの脆弱性を2021年のLog4Shellになぞらえ、修正に長くかかる組織が出るともみています。

修正が入ったかを、版の番号でなく変更履歴で見る#

ディストリビューションのPHPは、修正後もphp -vに出る版の番号が変わりません。The Hacker Newsは、Debianの助言に沿って、版の番号ではなくパッケージの変更履歴にCVEの番号があるかで確かめるよう書いています。検証した環境（Ubuntu 24.04.5 LTS、10月22日）でphp8.3-cliを更新すると、次のとおりでした。

$ dpkg-query -W php8.3-cli
php8.3-cli	8.3.6-0ubuntu0.24.04.13
$ php -v | head -1
PHP 8.3.6 (cli) (built: Oct 19 2026 15:16:58) (NTS)
$ zcat /usr/share/doc/php8.3-cli/changelog.Debian.gz | grep -E 'CVE-2026-10961[89]'
    - debian/patches/CVE-2026-109618_109619.patch: Avoid state corruption via
    - CVE-2026-109618
    - CVE-2026-109619

php -vは更新の前と同じ8.3.6のままで、変更履歴に2つのCVEの番号が入っています。RPMのパッケージではrpm -q --changelog <パッケージ名>の出力を同じように検索します。Webで動くPHPは、php8.3-fpmやlibapache2-mod-php8.3のように、CLIとは別のパッケージです。どのパッケージも同じ版になっているかを見てください。

PHPの開発チームが更新を出さない8.1以前でも、ディストリビューションが修正を出していることがあります。Ubuntuは22.04のPHP 8.1を8.1.2-1ubuntu2.28で直しました。UbuntuのCVEのページでは、もっと古い7.4と7.2の修正はUbuntu Proで、7.0と5.5の修正はUbuntu ProのLegacy Supportという追加の契約で提供されています。Ubuntu Proは、個人での利用なら5台まで無料です。

更新しても残る抜け#

The Hacker Newsは、WordPressやLaravelなどのアプリを更新しても、その下で動くPHPは更新されないと注意しています。PHPはサーバーのパッケージ、ホスティング事業者、コンテナのイメージのどれかから来ているので、それぞれで更新が要ります。更新の後はApache、PHP-FPM、常駐するPHPのワーカーを再起動してください。再起動するまで、古いプロセスは修正前のコードで動き続けます。

10月24日には3つ目の欠陥（CVE-2026-115560）も公表されました。The Registerによると、これもコードを実行されうる欠陥ですが、起きるのはセッションの保存形式を実行中に切り替えるような、ほとんど使われない設定のときだけです。そのためPHPは緊急の修正を出さず、次の定期の版で直します。それまでは、php.iniでsession.upload_progress.enabled=0にすれば避けられます。上の修正版に更新しても、この3つ目は直っていません。

ホスティング事業者がPHPを管理している場合は、事業者に修正の適用を確かめてください。製品や機器の中のPHPについては、SANS Internet Storm Centerが各社の対応の情報をまとめています。例に挙がっているのはCisco、OPNsense、pfSense、Palo Alto Networksです。SANSは、PHPを使うオープンソースのファイアウォールやルーターでも更新が続くとみて、Webの管理画面をインターネットに出さないよう求めています。

The Hacker Newsによると、修正版ではメモリに新しい強い上限が加わり、ここに達するとプロセスが終わって、終了時の処理（シャットダウンハンドラー）が動きません。更新した後にmemory_limitとpost_max_sizeがアプリの必要な量と合っているか、見直しておいたほうがよさそうです。緩和策としてmemory_limit=-1を入れていた場合は、更新の後に元へ戻す必要がありそうです。

CloudflareのWAFを使っている場合#

Cloudflareは、php2shellへの保護の内容と設定の確かめ方を、ブログの記事「Cloudflare deploys protections against php2shell vulnerability」で公開しています。

無料のプランでは規則が自動で有効です。有料のプラン（Pro、Business、Enterprise）では、Managed Rulesetがブロックのモードで動いているかの確認をCloudflareは求めています。止めた通信はダッシュボードのSecurity > Security Analytics > Eventsで、規則のIDで絞り込んで見られます。Cloudflareは、WAFは更新の代わりにはならず、更新した後も保護を有効のまま残すよう勧めています。

侵入を疑うときに見るもの#

Wizによると、この攻撃はアプリより下の層で動くので、アプリのログにはほとんど手がかりが残らないことがあります。Wizは次の兆候に注意するよう書いています。

• 見慣れないmultipartのリクエストの直後に、メモリの上限のエラーや、HTTP 500の応答が続く
• 応答のPHPSESSIDのCookieが、異様に大きい、または形が崩れている
• PHPのワーカーが理由の分からない入れ替わりや再起動を繰り返す

SANS Internet Storm Centerが紹介した初期の攻撃コードは、5MBほどの長いファイル名を入れたmultipartのリクエストを送るものでした。SANSは、このコードの動作は不安定でも、本物の攻撃で何を探せばよいかの手がかりになるとしています。

Cloudflareは修正版より前から攻撃の通信を観測しています。予告から更新までのアクセスのログとエラーのログは、消える前に保全しておいたほうがよさそうです。更新を終えたサーバーも同じです。

WizとThe Hacker Newsによると、攻撃者はコードを実行しなくても、PHPのワーカーのメモリを読み出せることが実証されています。そこにはほかのリクエストのパスワード、認証のトークン、APIのキー、証明書が入っていることがあります。上の兆候が見つかったサーバーでは、置いている秘密の値を入れ替える必要がありそうです。