PHP緊急脆弱性の続報｜公開の4日前から攻撃の試み。サーバーで見つけた落とし穴6つと、ログの見方

PHPの緊急脆弱性2件（CVE-2026-109618・CVE-2026-109619）は、公開の4日前の10月17日から攻撃の試みがあったと Amazon が報告しました。
修正版の公開後は「広く悪用されている」とも書いています。
ログの調べ直しは、公開日ではなく10月17日から始めてください。

この記事は、サーバーを自分で触る人向けの続報です。
公開後にわかったことを短くまとめて、そのあと僕が一晩サーバーの対応をして見つけた落とし穴6つと、ログの見方を書きます。
修正版の番号や更新の順番は、前回の記事にまとめました。

※ 2026年10月22日 昼（日本時間）時点の、PHP公式の告知、Amazon のセキュリティブログ、IPA の注意喚起、各配布元・各社のお知らせをもとに書いています。

公開後にわかったこと

Amazon の脅威インテリジェンスのチームによると、最初の攻撃の試みは10月17日、おとり用のサーバー（ハニーポット）で見つかりました。
10月21日には攻撃を試すプログラム（PoC）がいくつも出回り、一番早いものは日本時間の11時ごろです。
修正版の公開後は、新しい PoC が数時間で出て、すぐに使われたと書かれています。

ただ、その試みが本物のサーバーで成功したかどうかは、まだわかっていません。
Amazon は攻撃元の IP も載せていますが、共有の匿名化の仕組みなので、遮断ではなく調べる材料として使うよう書いています。

• IPA：10月22日に注意喚起。8.1 以前は更新か移行。暫定の対策が難しい時は、外からのアクセスを止めることや一時停止まで判断するよう求めています。
• CISA KEV：10月22日の昼の時点では、2件とも未掲載です。
• PHP 公式：告知の訂正や、追加の修正版はありません（8.5.12・8.4.27・8.3.36・8.2.35 のまま）。

配布元とレンタルサーバーの状況

配布元の修正パッケージは、ほぼ出そろいました。

• 出ている：Amazon Linux 2023（php8.2〜8.5）、RHEL 8・9・10、Rocky Linux 8・9・10、Debian（bookworm・trixie）、Ubuntu（USN-8948-1）、Docker の公式 php イメージ、Ondřej Surý の PPA（8.4 で確認）
• 気をつけたい所：Amazon Linux 2023 の php8.1 と、Amazon Linux 2 の標準の php は「修正の予定なし」。RHEL 9 の php:8.4 のモジュールは、まだ修正が出ていない表示です。AlmaLinux は、この時点で errata を見つけられていません。
• remi：リポジトリには 8.2.35・8.3.36・8.4.27・8.5.12 の RPM が並んでいます。告知の記事はまだ出ていません。

レンタルサーバーは、Xserver（PHP 8.2〜8.5）・さくらのレンタルサーバ・mixhost が修正済み、ConoHa WING が順次適用中、ロリポップ！がメンテナンス中です。
mixhost は、修正を入れても PHP の版の表示は変わらないと書いています（例：8.4.26 のまま）。

配布元のパッケージも同じで、Ubuntu 22.04 の php8.1 は 8.1.2 のままで修正が入っています。
版の数字ではなく、changelog に CVE 番号があるかで見てください。

# RHEL 系
rpm -q --changelog php-cli | grep -E 'CVE-2026-10961[89]'

# Debian・Ubuntu 系（php8.3 の所は使っている版に）
zcat /usr/share/doc/php8.3-cli/changelog.Debian.gz | grep -E 'CVE-2026-10961[89]'

落とし穴1：公開された場所に残った phpMyAdmin

点検で一番多かったのが、これです。
phpMyAdmin も PHP で動くので、今回の穴の入口になりますし、それ以前に誰でもログイン画面を叩けます。

# 公開フォルダの下にあるか
find /var/www -maxdepth 4 -type d -iname '*phpmyadmin*' 2>/dev/null

# 外から見えるか（403 か 404 なら一応は閉じている）
curl -s -o /dev/null -w '%{http_code}' https://example.com/phpmyadmin/; echo

使っていないなら消します。
使うなら公開フォルダの外へ出して、SSH のトンネル越しに使うか、せめて自分の IP だけに絞ります。

落とし穴2：公開フォルダに残った控えのファイル

.bak・_bk・.old・.orig・~ で終わる控えが、公開フォルダに残っていることがあります。
名前の最後が .php の控え（index_bk.php など）は、古いプログラムのまま動きます。
最後が .bak などの控えは、PHP として動かずに中身がそのまま読めてしまいます。

find /var/www -type f \( -name '*.bak' -o -name '*_bk*' -o -name '*.old' -o -name '*.orig' -o -name '*~' \) 2>/dev/null

見つけたら公開フォルダの外へ移して、控えのファイルは Web で配らない設定も入れておきます。

# nginx
location ~* (\.(bak|old|orig)|~|_bk[^/]*)$ { deny all; }

# Apache（.htaccess・mod_rewrite）
RewriteEngine On
RewriteRule (\.(bak|old|orig)|~|_bk[^/]*)$ - [F,NC]

落とし穴3：Basic 認証の「API だけ通す」

ステージングや管理画面に Basic 認証をかけていても、外部の仕組みから呼ばれる API のフォルダだけ誰でも通す設定にしていることがあります。
Apache なら SetEnvIf Request_URI で API の URL に印を付けて、Require env で通す、という書き方をよく見ます。

この「通す範囲」がフォルダ丸ごとだと、そこにあるファイルの受け取り口も誰でも叩けます。
Basic 認証で弾かれたリクエストは、ふつう PHP まで届かないので、鍵がかかっている所は守りになります。
問題は、鍵を外した所です。
外す範囲は、本当に要る URL だけに絞ってください。
ファイルの受け取り口は、アプリ側でもログインを必須にしておくと安心です。

落とし穴4：php -v の版と、mod_php

前回も書きましたが、php -v はコマンド用の PHP の版です。
Web で動いている方は、別に確かめます。

# Apache に PHP が組み込まれているか（mod_php）
apachectl -M 2>/dev/null | grep -i php

# PHP-FPM の版
php-fpm -v      # 配布元によって php-fpm8.3 -v や /usr/sbin/php-fpm -v

mod_php は、公式の告知が一番危ないと書いた動かし方です。
アプリのコードが動く前に攻撃が成り立つので、更新を最優先にしてください。
確かめるために phpinfo() のファイルを置いた場合は、見終わったらすぐに消します（これも公開されたままになりやすいです）。

落とし穴5：session.upload_progress を .user.ini に書いても効かない

公式の暫定策の session.upload_progress.enabled=0 は、php.ini か FPM のプール設定（php_admin_value[session.upload_progress.enabled] = 0）に書いて、PHP を再起動します。
.user.ini や ini_set() では効きません。
公式は全ワーカーの再起動を求めているので、僕は reload ではなく restart にしました。

効いているかは、Web から見た値で確かめます。
僕は ini_get('session.upload_progress.enabled') を出すだけの一時ファイルを、自分の IP からだけ見えるようにして確かめ、すぐに消しました。
この設定は修正後も切ったままにするよう、公式は勧めています。

落とし穴6：更新が来ない古い OS

サポートが終わった OS では、いつもの更新で修正版が入りません。
上に書いた Amazon Linux 2 の標準の php のように、配布元が「修正の予定なし」としているものもあります。
移行の時期を前倒しで決めて、それまでは入口を減らします。

• ファイルの受け取り口が無い URL への multipart の POST を、Web サーバーで止める（設定の例は前回の記事に書きました）
• 公式の暫定策（session.upload_progress.enabled=0・post_max_size を絞る・memory_limit=-1 を管理者側で固定し、ワーカー単位のメモリ制限と組み合わせる）
• WAF を前に置く

IPA が引いている Wiz 社の話では、PHP 5.4 以降は少なくともどちらかの影響を受けるそうです。
「古すぎて対象外」とは考えない方が良いと思います。

ログは10月17日から見る

Amazon の推奨は、少なくとも10月17日からの調べ直しです。
僕は次の順番で見ています。

1. アクセスログで、ファイルの受け取り口が無い URL への POST（とくに multipart）が増えていないか
2. PHP-FPM のエラーログで、ワーカーが落ちた記録（exited on signal 11 など）がまとまって出ていないか
3. 10月17日より後に作られた、見覚えのない PHP ファイルが無いか
4. Web サーバーの実行ユーザーで、見覚えのないプログラムが動いていないか

# 2 の例（ログの場所は環境に合わせて）
grep -E 'exited on signal (11|6)' /var/log/php*-fpm*.log* 2>/dev/null | tail

# 3 の例
find /var/www -type f -name '*.php' -newermt '2026-10-17' 2>/dev/null

Amazon は、フォームの送信の中に PHP_SESSION_UPLOAD_PROGRESS という文字列を含む POST を探すようにも書いています。
通常のアクセスログには送信の中身が残らないので、これは WAF やリクエストの中身を残している所のログで探すことになります。

WAF の対策ルール

• Cloudflare：10月21日から既定で保護（Free プランも）。有料プランは対象のルールがブロックになっているか確かめるよう書いています。
• AWS WAF：PHP application のマネージドルールグループ 2.3 に、CVE-2026-109619 向けのルールが入りました。CVE-2026-109618 向けは Core rule set の本文サイズの制限（8KB 超をブロック）なので、誤検知に気をつけてください。
• Imperva・Fastly：対策を出しています。Fastly は管理画面で有効にする必要があります。

Cloudflare 自身も「あくまで一時しのぎで、PHP の更新が要る」と書いています。
WAF は時間を稼ぐもので、穴をふさぐのは更新だけです。

まとめ

1. 修正版へ更新して、PHP（FPM なら全ワーカー）を再起動する。版の確認は changelog の CVE 番号で。
2. ログは10月17日から見る。
3. phpMyAdmin・控えのファイル・phpinfo() を公開フォルダから片付ける。
4. Basic 認証の「通す範囲」を絞る。
5. 更新できない OS は、移行の時期を決めて、それまでは暫定策と WAF で入口を減らす。

前回の記事（修正版の番号・更新の順番・multipart を止める設定の例）は、こちらです。
PHPの緊急脆弱性CVE-2026-109618の修正版が出た｜確かめるのはphp -vではなく、Webで動いている方の版

一般向けには note と、まる子のチャンネルの動画（3分半）にまとめました。
【続報】PHP の緊急脆弱性｜攻撃の観測と、対応してわかった落とし穴（YouTube）

出典：PHP 公式の告知／Amazon セキュリティブログ（2026-10-21）／IPA の注意喚起（2026-10-22）／Cloudflare ブログ／AWS WAF の変更履歴／Ubuntu／Red Hat／Amazon Linux／mixhost
※調査と下書きは Claude（AI）と一緒に行いました。一次情報の確認、内容の判断、サーバーでの作業と公開は僕が行っています。