---
title: "php2shellの修正版の公開後、悪用の観測と更新後に確かめること"
description: "PHPの脆弱性php2shellは、10月21日の修正版の公開直後から実際の悪用が観測されています。修正が本当に入ったかの確かめ方、更新しても残る抜け、CloudflareのWAFの扱い、侵入を疑うときに見る兆候を、公式と各社の情報からまとめました。"
url: https://udon-dev.com/notes/php2shell-after-patch/
lang: ja
published: 2026-10-25
topic: [security]
tags: ["security", "PHP", "脆弱性", "php2shell", "CVE-2026-109618", "CVE-2026-109619"]
---

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

- 攻撃の試みはCloudflareの観測で数百万件に達し、Mirai系のボットネットを仕掛けようとする攻撃も出た。侵入が成功した報告は、10月23日の時点ではない
- ディストリビューションのPHPは修正後も版の番号が変わらない。パッケージの変更履歴にCVEの番号があるかで確かめる
- アプリを更新してもPHPは更新されない。PHPのパッケージ、コンテナのイメージ、ホスティング事業者のそれぞれで更新し、全てのワーカーを再起動する
- 攻撃はアプリより下で動くので、アプリのログには手がかりが残りにくい。multipartのリクエストの後のメモリのエラーや、異様に大きいPHPSESSIDのCookieが兆候になる。兆候があれば、メモリから読まれうる秘密の値を入れ替える
- 3つ目の欠陥（CVE-2026-115560）は緊急の修正が出ない。特殊な設定でだけ起き、`session.upload_progress.enabled=0`で避けられる

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

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

時刻は日本時間です。

| 日時 | 出来事 |
|---|---|
| 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](https://ubuntu.com/security/notices/USN-8948-1)） |
| 10月22日 | JPCERT/CCが[注意喚起](https://www.jpcert.or.jp/at/2026/at260033.html)を公開 |
| 10月22日朝 | Cloudflareの観測で、攻撃の試みが数百万件に達する（The Hacker Newsによる） |
| 10月24日 | PHPが3つ目の欠陥（CVE-2026-115560）を、緊急の修正なしで公表（The Registerによる） |

watchTowrは[FAQ](https://watchtowr.com/intelligence/php-cve-2026-109618-faq/)で、自社のおとりのサーバー網（ハニーポット）で、2件とも実際の悪用を観測したとしています。[The Hacker News](https://thehackernews.com/2026/10/php-issues-emergency-patches-for-two.html)によると、watchTowrは同じ日の日本時間20時26分の時点では観測していないとしていました。Cloudflareは、情報が予定より早く出回った間に顧客のサイトへの攻撃の通信を観測し、攻撃者が自社の規則を避けるために攻撃の中身を書き換えていたと[書いて](https://blog.cloudflare.com/php-vulnerabilities-waf-protection)います。

[The Hacker Newsの10月23日の記事](https://thehackernews.com/2026/10/php2shell-exploit-attempts-hit-millions.html)によると、攻撃の中にはMiraiから派生したボットネット「Potassium」を仕掛けようとするものもありました。Sophosの分析では、DDoSの機能を持つ既知の亜種の更新版です。

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

それでも急ぐ理由は、攻撃の道具がそろっていることです。[Krebs on Security](https://krebsonsecurity.com/2026/10/widespread-php-flaw-may-cause-many-site-outages-today/)によると、発見者の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`を更新すると、次のとおりでした。

```sh
$ 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のページ](https://ubuntu.com/security/CVE-2026-109618)では、もっと古い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](https://www.theregister.com/security/2026/10/23/theres-a-third-php2shell-bug-but-it-wont-get-an-emergency-fix/5305208)によると、これもコードを実行されうる欠陥ですが、起きるのはセッションの保存形式を実行中に切り替えるような、ほとんど使われない設定のときだけです。そのためPHPは緊急の修正を出さず、次の定期の版で直します。それまでは、`php.ini`で`session.upload_progress.enabled=0`にすれば避けられます。上の修正版に更新しても、この3つ目は直っていません。

ホスティング事業者がPHPを管理している場合は、事業者に修正の適用を確かめてください。製品や機器の中のPHPについては、SANS Internet Storm Centerが各社の対応の情報を[まとめて](https://isc.sans.edu/diary/Critical%20PHP%20Vulnerability%20%28CVE-2026-109618%2C%20CVE-2026-109619%29%20%5Binfocon%20yellow%5D/33440)います。例に挙がっているのは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」で公開しています。

（図: CloudflareのブログのOGP画像。「Cloudflare deploys protections against php2shell vulnerability」の見出しと、雲と盾を組み合わせた絵）
出典：[Cloudflare deploys protections against php2shell vulnerability（Cloudflare）](https://blog.cloudflare.com/php-vulnerabilities-waf-protection)

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

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

Wizによると、この攻撃はアプリより下の層で動くので、アプリのログにはほとんど手がかりが残らないことがあります。Wizは次の兆候に注意するよう[書いて](https://www.wiz.io/blog/php2shell-php-rce)います。

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

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

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

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