PHPの緊急脆弱性2件、今夜23時の修正版までに分かっていることと分かっていないこと(更新)

2026年10月21日 15:05

> 【10月22日17時30分追記】
> ・株式会社バルテックが22日、「PHPの脆弱性を標的としたサイバー攻撃」による顧客情報流出の可能性を公表した。国内で被害の公表はこれが初めて。CVE番号は示しておらず、php2shellによるものかは特定されていない。
> ・JPCERT/CCが13時11分に注意喚起を出し、対策の適用とあわせて侵害の有無を調べるよう呼びかけた。IPAも注意喚起を出している。
> ・Amazonは、公開4日前の10月17日にすでに悪用の試みを観測していたと公表した。成功したかは分からないとしている。
> ・ディストリの修正版がそろってきた。Amazon Linux 2023のphp8.2〜8.5、RHEL 8/9/10、Rockyに修正が出ている。
> ・「悪用と実被害」「ディストリとホスティング」の節と、手順のStep 7を書き換えた。国内各社の状況は別の記事にまとめている（影響まとめ記事のリンク）。
>
> 【10月22日12時30分追記】
> ・国内のレンタルサーバーや各サービスの停止・再開の状況は、別の記事にまとめた（影響まとめ記事のリンク）。この記事の該当部分は短くした。
>
> 【10月22日5時追記】
> ・PHP公式が修正版 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 を公開した。予定の23時より早く、日本時間21日22時台に出ている。
> ・CVE-2026-109618とCVE-2026-109619が正式に登録された。原因はメモリ管理の不備で、Session Upload Progressの関与も公式に確認された。
> ・公式は「完全な緩和策はない。更新が唯一の安全な選択」としている。
> ・実被害：22日5時時点で、侵害の成功や被害の公表は国内外とも見つからない。悪用の試みはwatchTowrやCloudflareなどが観測している。
> ・Patchstackの「実攻撃」報告は、同社の続報で「探りの攻撃だけで、侵害の確証はない」に変わった。
> ・Cloudflareは21日の緊急ルールをphp2shell向けと明言した。公表の約9時間前から既定で守っていたという。
> ・「修正版で分かったこと」の節を新設し、原因・影響・WAF・対応手順の各節と図を書き換えた。
>
> 【10月21日18時30分追記】
> ・16時34分（07:34 UTC）、Patchstackが「ホスティング事業者から複数の実攻撃の報告を受けた」と掲載した。事業者からの伝聞で、ほかの裏付けはまだない。時系列と図2に追加した。
> ・CloudflareのWAFについて「WAFは時間を稼ぐ道具」の節と図4を追加した。WAFはパッチまでの時間を稼ぐ層で、パッチの代わりにはならない、というのが調べた結論だ。
> ・対応手順のStep 4に、Cloudflare WAFの設定確認を追加した。
> ・PHP公式は18時30分時点で、修正版を前倒しで公開していない。予定は今夜23時のまま。
>
> 【10月21日15時ごろ初版】

10月21日の朝、PHPに「緊急」レベルの脆弱性が2件あるというニュースが一斉に流れた。CVE番号、リモートコード実行、PHP 5以降に影響。見出しだけ追うと、もう中身まで分かっているように見える。

ところが一次情報をたどると、その時点でPHP公式が言っていたことはかなり少なかった。初版は21日15時ごろ（日本時間）の情報で書き、修正版の公開を受けて22日5時ごろの情報で更新した。

先に結論を書いておく。修正版は21日の夜に出た。8.5.12、8.4.27、8.3.36、8.2.35で、公式は「完全な緩和策はない、更新が唯一の安全な選択」としている。

22日朝の時点で侵害の確認はまだないが、悪用の試みは観測されている。2年前のCVE-2024-4577は、公表から24時間以内に悪用が始まった。まだ更新していないなら、今日のうちに済ませたい。

修正版で分かったこと（22日朝時点）

修正版と公開時刻

PHP公式は21日、セキュリティアドバイザリと修正版4本を公開した。対象は 8.5.12、8.4.27、8.3.36、8.2.35 で、開発中の8.6.0 RC4にも同じ修正が入っている。研究者GossiTheDogの事前の予想どおりの番号だった。

公開は予定の23時より早かった。php.netの告知まわりのコミットは12時59分（UTC）、CVEの公開は13時48分と13時54分だ。日本時間にすると21日22時台になる。ほかの情報源の時刻にも幅がある。

アドバイザリの冒頭はこうだ。

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.

自分の訳では「8.5.12、8.4.27、8.3.36、8.2.35は、認証なしのリモートコード実行につながり得る重大な脆弱性2件を修正する。すべての利用者に今すぐの更新を強く勧める」となる。

事前告知の段階で未確認だったCVE番号とRCEは、ここで公式に確認されたことになる。

原因

CVE番号との対応も確定した。CVE-2026-109618は「RCE via OOM corruption」だ。CVE-2026-109619は「RCE via stale global state」になる。CVSS v4.0はどちらも9.2で、事前告知と同じ値だった。

109618は、メモリ不足（OOM）のときの処理の不備だ。PHPはメモリが足りなくなると、処理を途中で打ち切って後片付けに移る。そのとき初期化されていないメモリが残り、後片付けの処理がそれを読んでしまう。GitHubのアドバイザリによると、multipartのリクエストでOOMを起こさせる経路がある。

109619は、前のリクエストの状態が残る不備だ。リクエスト用のメモリを指したままのグローバルな状態が正しく消されず、次のリクエストがそれを読む。確認された経路の一つが、事前にGMO Flatt Securityが推定していたSession Upload Progressだった。

同社の推定は半分当たっていたことになる。Session Upload Progressの関与は公式に確認された。ただ根本の原因はZendエンジン全体の作りにあり、セッション機能だけの問題ではなかった。

報告者として、CVEのレコードにはCalif.io、Wiz、OpenAIの名前がある。PHP Foundationによると、Califが誤って公開した動画がPoC作りを早めた。Chainguardが修正済みイメージを先行して出したことで、情報の封鎖も破れたという。事前告知のあとに情報が漏れ続けた背景はこのあたりにある。

影響範囲

公式の影響範囲は、サポート中の 8.2.35、8.3.36、8.4.27、8.5.12 より前の版だ。公式は、Webのリクエストを処理するすべての構成に危険があるとしている。

Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

自分の訳では「危険があるのは、Webリクエストを処理するすべてのPHP。PHP-FPM、mod_php、php-cgi、FrankenPHP、LiteSpeedを含む」となる。いちばん危険が高いのはmod_phpで、アプリのコードが動く前に攻撃が成立する実証があるという。

Red Hatは、自社の標準構成であるPHP-FPMでは「実際にはRCEは難しい」としている。評価は「Important」で、CVSS v3.1では8.1だ。構成によって危険度は違うが、更新しなくていい理由にはならない。

EOL版について、公式は「8.1以下はPHPプロジェクトから更新を受けない」と書いている。それでも今回は例外的に、7.4、8.0、8.1向けの最小限の修正をソースのブランチで出した。リリース版としての配布はない。

Wizは、PHP 5.4以降の版が影響を受けるとしている。PHP 5以降というリークの話は、大筋では外れていなかったことになる。

ディストリとホスティング

公式は、Linuxディストリには事前にパッチを渡したとしている。Ubuntuは公開とほぼ同時に修正を出し、22.04のphp8.1にも当てている。Debianも、trixieのphp8.4とbookwormのphp8.2に修正を出した。

22日の夕方までに、ほかのディストリも追いついてきた。Amazon Linux 2023はphp8.2〜8.5に修正を出し、Red HatもRHEL 8/9/10の主要なストリームに修正を出している。Rockyも同様だ。

残っているところもある。Amazon Linux 2023のphp8.1とAmazon Linux 2の標準phpは「No Fix Planned」のままだ。AlmaLinuxは、17時の時点で本番リポジトリへの反映を確認できなかった。

公式のDockerイメージ、Windows版、ondrej PPAには修正版が出ている。

国内のレンタルサーバーやゲーム、EC、金融機関、自治体などでは、予防のための停止が相次いだ。事業者ごとの状況は別の記事にまとめた（影響まとめ記事のリンク）。

WordPress.orgは「WordPress本体の更新は必要ない」としている。直すのはPHPのほうだ。

悪用と実被害

22日11時51分、株式会社バルテックが「不正アクセスによるお客様情報流出の可能性」を公表した。原因は「PHPの脆弱性を標的としたサイバー攻撃」としている。国内で被害を公表したのは、17時の時点でここだけだ。

ただしCVE番号は書かれておらず、php2shellによるものかは特定されていない。影響の範囲は調査中で、約25のサービスを止め、復旧は最短で26日としている。

ほかに侵害を公表した組織は、国内外とも見つかっていない。CISAのKEV（悪用が確認された脆弱性の一覧）にも、17時の時点で載っていない。

悪用の試みは広がっている。Amazonは、公開4日前の10月17日にはハニーポットで悪用の試みを観測していたと公表した。成功したかは分からないとしている。CloudflareのCEOは、試みの数が公開後の数時間で数百万に達したとXに書いたと報じられている。

攻撃コードの公開も進んだ。GitHubには、条件付きでmod_phpのRCEに成功したとする攻撃コードが出ている。作者の主張で、第三者の検証は確認できていない。

JPCERT/CCは13時11分の注意喚起で、対策の適用とあわせて侵害の有無を調べるよう求めた。「痕跡が確認されない場合でも…攻撃を受けていないと断定することはできません」と書いている。被害の報告がないことを、安全と読み替えないほうがいい。

事前告知の段階で、公式が言っていたのは3つだけ

php.netのニュース欄に事前告知が載ったのは、日本時間21日5時32分（20日20:32 UTC）だ。タイトルは「Upcoming Critical PHP Security Release」。本文は7行しかない。大事なところを原文のまま引く。

It is scheduled for Wednesday, 21 October 2026 at 14:00 UTC.
It addresses two critical vulnerabilities, both rated CVSS v4.0 9.2.
Full details, affected versions, and the fixed versions will be published with the release.

自分の訳では「リリースは2026年10月21日（水）14:00 UTC予定。重大な脆弱性2件に対処し、どちらもCVSS v4.0で9.2。詳細、影響バージョン、修正バージョンはリリースと同時に公開する」となる。

14:00 UTCは日本時間の23時だ。ITmedia NEWSの記事には「同日午後2時」とあり、文脈上20日に読めてしまう。正しくは21日の14時（UTC）で、日本だと21日23時になる。

告知には前倒しの条件も書いてある。どちらかの脆弱性の詳細が公になった場合か、実際の悪用の証拠が出た場合だ。実際、修正版は予定より早く出た。

告知の最後は「今から準備を」という呼びかけで終わっている。PHPがこういう事前告知を出すのは珍しい。php.netのニュースを2012年以降で検索した範囲では、事前告知は今回だけだった。

ニュースの数字はどこから来たのか

報道やSNSで広まった情報には、公式告知にないものがいくつか混ざっている。出どころを一つずつ確認した。

CVE番号は公式告知に載っていない

CVE-2026-109618とCVE-2026-109619という番号は、php.netの告知には一度も出てこない。番号を載せたのはCERT-EUの注意喚起（SA2026-018）だ。IPAも「CERT-EUは…注意喚起を公表しています」と、CERT-EU経由として書いている。

さらにさかのぼると、元はHacker Newsの匿名投稿だった。日本時間21日0時20分に投稿されたもので、すでに削除されている。タイトルは「Tell HN: 2x PHP RCE CVEs with CVSS 10.0 Incoming」だった。

投稿者自身、根拠は「source: trust me, bro」程度だと書いていた。15時時点で、MITREにもNVDにもこの2件のレコードはない。番号の表記はIPAやGMO Flatt Securityなどで一致していた。結果的に、この番号は修正版の公開と同時に正式に登録された。

RCEとPHP 5以降も公式ではない

「リモートコード実行の恐れ」は、CERT-EUが「other leaks」によればと前置きして書いたものだ。CVSS 9.2という値から、認証なしのRCEの可能性を読み取っている。PHP公式は攻撃の種類を何も書いていない。

「PHP 5以降の全バージョン」も同じで、CERT-EUが参照元にしているのは研究者Kevin Beaumont（GossiTheDog）の投稿だ。彼は別の投稿で「the vulns date back to versions from 2004 onwards」とも書いている。2004年はPHP 5.0が出た年にあたる。

watchTowrのCEOも「PHP 5, 6, 7, 8に影響すると理解している」と話している。ただ、これも又聞きの情報だ。15時の時点では「可能性が高い」と言える根拠はなかった。修正版の公開後の状況は、前の節に書いたとおりだ。

「外部から遮断を」はCERT-EUの助言

「すぐ更新できないなら外部ネットワークから切り離す検討を」という呼びかけもよく見かける。これもPHP公式ではなく、CERT-EUの助言だ。原文は次のとおり。

Where immediate patching is not feasible, organisations should consider isolating internet-facing applications from public networks until a fix is available.

自分の訳では「すぐにパッチを当てられない組織は、修正が出るまでインターネットに面したアプリを公開ネットワークから隔離することを検討すべき」となる。主語を取り違えると、PHP公式がそこまで言ったように見えてしまう。

修正版の番号も研究者の投稿

「8.5.12、8.4.27、8.3.36、8.2.35が出る」という話もある。これはGossiTheDogが日本時間21日4時45分に投稿したもので、公式の発表ではない。15時時点の最新版は、9月24日に出た8.5.11、8.4.26、8.3.35、8.2.34のままだった。結果として、予想の番号は当たっていた。

時系列（日本時間）

ここまでの動きを日本時間で並べる。カッコ内はUTCだ。

21日 0:20（20日 15:20）：Hacker Newsに匿名投稿。CVE番号、CVSS 10.0、22日18時（CEST）の公表を主張。後に削除
21日 4:35（20日 19:35）：watchTowrがFAQを公開。CEOは脆弱性が実在するとし、CVE-2026-109618を再現済み
21日 4:45（20日 19:45）：GossiTheDogが修正版の番号予想を投稿
21日 5:32（20日 20:32）：php.netに事前告知
21日 5:33（20日 20:33）：CERT-EUがSA2026-018を掲載
20日〜21日：BleepingComputerが報道。研究者Kirill Firsov（FearsOff）が「php2shell」のデモ動画を公開
21日 9:50：ITmedia NEWSが報道
21日 11:12：GMO Flatt Securityがブログで原因の推定と暫定策を公開
21日 13:32：窓の杜が報道
21日：IPAが「【事前準備のお願い】」を掲載。悪用は確認していないとの記載
21日 12:02（03:02）：Cloudflareがphp2shell向けのWAFルールで既定の保護を始める（ブログで後に明言）
21日 16:00：エックスサーバーが予防措置で公式サイトや管理画面を停止
21日 16:34（07:34）：Patchstackが「ホスティングパートナーから複数の実攻撃の報告」と掲載
21日 16:41（07:41）：Chainguardが修正済みイメージを先行公開し、情報の封鎖が破れる
21日 22時台（12:59〜13:52）：PHP公式が修正版とアドバイザリを公開。予定より前倒し
21日 22:48・22:54（13:48・13:54）：2件のCVEが正式に公開
21日 22:56（13:56）：UbuntuがUSN-8948-1で修正版を配布
21日 22:57（13:57）：Patchstackが「探りの攻撃だけで、侵害の確証はない」と更新
21日 23:00（14:00）：当初の公開予定
21日 23:19（14:19）：watchTowrが2件とも悪用の試みを観測したと公表

CVSSの値が食い違っている点にも注意したい。リーク側は10.0、公式は9.2だ。15時時点では悪用の報告はなく（watchTowr）、CISAのKEVにも載っていなかった。

状況が動いたのは夕方からだ。Patchstackが16時34分（07:34 UTC）付で、ホスティング事業者から複数の実攻撃の報告を受けたと書いた。ただ同社は修正版の公開直後、観測しているのは探りの攻撃だけだと更新している。

公開前の原因の推定

この節は、修正版が出る前の推定の記録として残している。公式の原因は「修正版で分かったこと」の節に書いた。

公開前は、公式は原因を何も出していなかった。CERT-EUも「no technical details have been made public」と書いていた。

いちばん具体的だったのはGMO Flatt Securityの記事だ。ext/sessionの「Session Upload Progress」が関わっていると見て、メモリ破壊系のバグと推定していた。この機能はデフォルトで有効になっている。

同社は暫定策として「session.upload_progress.enabled=0」を挙げていた。ただし本人たちが「100%効くとは断言できない」と書いていた。この設定は、のちに公式も109619の緩和策として挙げている。

研究者の投稿では、mod_phpとphp-fpmの両方で再現したとされていた。WordPress、Laravel、Symfonyでの再現報告もあった。デモ動画の環境はUbuntu 26.04のパッケージ版PHP 8.5.4、Apache prefork+mod_phpだった。

GossiTheDogはAppArmorやSELinuxが効くとも投稿していたが、検証された話ではない。

影響が出そうなもの、システム

公式の影響範囲はWebリクエストを処理するすべての構成で、「うちは関係ない」と言える範囲は狭い。PHPが動いている場所を、広めに洗っておいたほうがいい。

規模

W3Techsの10月21日のデータでは、サーバー側の言語が分かるサイトの69.3%がPHPだ。PHPの中の内訳は8系が65.2%、7系が27.0%、5系が7.7%になる。

もう一つ、Malloryの集計をThe Hacker Newsが紹介している。バナーがPHP 8.1以下を示す公開ホストが約88.4万ある、というものだ。これはバナーを数えた値で、実際に影響を受ける数ではない。

サポートが切れたPHP

今サポートされているのは8.2、8.3、8.4、8.5だ。8.2のセキュリティサポートは今年12月31日で終わる。8.1は2025年12月31日、7.4は2022年11月28日、5.6は2018年12月31日にEOLを迎えている。

8.1以下に公式のリリース版は出なかった。7.4、8.0、8.1向けにはソースのブランチで最小限の修正が出たが、自分でビルドするか、ディストリのバックポートを待つことになる。

身近なところでは、Ubuntu 22.04 LTSの標準PHPは8.1だ。上流ではEOLだが、Ubuntuはこれにも修正を出した。Amazon Linux 2023は8.1から8.5まで用意していて、php8.1には修正予定がない。どれを入れたかで扱いが変わる。

WordPressとEC

WordPressやECサイトも、直すのはPHPのほうだ。WordPress本体やプラグインを更新しても直らない。PHPを更新するのは、マネージドホストならホスト側、自前のサーバーなら自分になる。国内のレンタルサーバー各社の対応は、別の記事にまとめた（影響まとめ記事のリンク）。

見落としやすい場所

The Hacker Newsは、cPanelやPleskのような管理パネルも棚卸しの対象に挙げている。アプライアンス製品や、Windows向けソフトに同梱されたPHPも同じだ。

この手の「中でPHPが動いている」ものは台帳から漏れやすい。監視ツールのWeb画面、社内向けの古いCMS、検証用に立てたまま忘れたVMなどだ。コンテナイメージに焼き込まれたPHPも、ホストを更新しただけでは直らない。

2年前、公表から24時間で悪用された

初版では「未確認」を並べたうえで、それでも21日夜のうちに動くべきだと書いた。理由は前例だ。

2024年6月上旬、WindowsでPHPをCGIモードで動かす構成の脆弱性CVE-2024-4577が公表、修正された。Akamaiは公表から24時間以内に悪用の試みを観測している。ランサムウェアのTellYouThePassは48時間以内に悪用した。

日本も無関係ではなかった。IPAは2024年7月5日、国内の複数の組織で悪用され、webshellが置かれたと公表している。2025年1月以降も日本の組織を狙った攻撃が続いたと、Cisco Talosが報告している。

あのときは影響が「Windows+PHP-CGI」に限られていた。今回は公式が、Webリクエストを処理するすべての構成に危険があるとしている。構成で除外できる範囲は前回よりずっと狭い。詳細が出た今、攻撃側も同じ情報を読んでいる。

WAFは時間を稼ぐ道具

こういうときのためにCloudflareのWAFを前に置いておけば、慌てずに済むのではないか。自分もそう考えて、今回の動きと過去の例を調べてみた。

先に結論を書く。入れておく価値はある。今回は実際に、Cloudflareが公表より前から守っていた。それでも「急な対応をしなくて済む」とまでは言えない。WAFでできるのは、パッチまでの時間を安全にすることだ。

今回のCloudflareの動き

Cloudflareは10月21日付で、WAFの緊急リリースを2本出した。有料プラン向けの「Cloudflare Managed Ruleset」と、無料プランでも使える「Free Ruleset」の両方だ。中身は「Anomalous Execution」というルールで、最初からBlockで入っている。

18時の時点では、変更ログにPHPもCVE番号も書かれておらず、今回の件向けかは確かめられなかった。その後、Cloudflareはブログで、このルールがphp2shell向けだと明言した。ルールは7本に増えている。

ブログによると、ルールは公表の約9時間前に配られ、21日3時2分（UTC）から既定で守っていたという。日本時間では21日12時2分だ。攻撃者がルールを避けようとペイロードを変えてくる様子も観測したと書いている。

WordPressのホスティング大手Kinstaは、攻撃をCloudflareの保護で防げているとステータスページに書いた。Akamai、Imperva、Fastlyなども、今回の件向けのルールを出している。今回に限っては、WAFがきちんと時間を稼いだ例と言っていいと思う。

速さは件によって違う

Cloudflareの対応が早かった例として、自分がまず思い出すのは2021年のLog4jの脆弱性（Log4Shell、CVE-2021-44228）だ。公表は2021年12月9日で、最初のWAFルールは翌10日の9時56分（UTC）に出ている。Cloudflareは「free or paid」を問わず全顧客に基本的な防御を入れたと書いていた。

一方で、遅かった例もある。CVE-2024-4577のとき、Cloudflareが緊急ルールを足したのは2024年6月18日だった。公表から約11日後で、悪用は24時間以内に始まっていた。今回は公表より前で、同じPHPの件でも速さはこれだけ違う。

ルールが早く出ても、それで終わりとは限らない。Log4Shellでは、Cloudflare自身のブログが攻撃の変化を書いている。公開から9分後に攻撃が始まり、すぐに文字列の難読化でルールをすり抜ける形に変わった。

WAFs are effective as a measure to help prevent attacks from the outside, but they are not foolproof and attackers are actively working on evasions.

自分の訳では「WAFは外部からの攻撃を防ぐのに有効だが、万全ではない。攻撃者は回避手段を積極的に探している」となる。

Cloudflareの緊急ルールの告知文も同じだ。9月10日分は「origin applications must be urgently updated」と結んでいる。OWASPの仮想パッチの解説も、根本の脆弱性は消えないと書く。今回もPHP公式は「完全な緩和策はない」としている。WAFの提供側も、パッチは要ると言っているわけだ。

プランと前提

無料プランでも、Free Managed Rulesetは最初から有効になっている。対象は「high-impact and widely exploited」な脆弱性で、今回のように無料向けの緊急ルールが出ることもある。

Proプラン（年払いで月20ドル）以上なら、範囲の広いCloudflare Managed Rulesetが使える。こちらは自分でオンにする必要があり、一部のルールは既定で無効だ。WordPressなど、自分の環境に合うルールが有効になっているかは見ておきたい。

いちばん大事なのは前提のほうだと思う。WAFが効くのは、DNSでプロキシ（オレンジ雲）を通した通信だけだ。オリジンのIPが漏れていれば、攻撃者はCloudflareを通らずに直接PHPを叩ける。

公式は、Cloudflare TunnelかAuthenticated Origin Pullsでオリジンを守るよう勧めている。どちらも全プランで使え、公式の評価は「Very secure」だ。CloudflareのIPだけを許可する方法は「Moderately secure」という扱いになっている。

レンタルサーバーとWordPressの場合

エックスサーバー、ロリポップ、さくらのレンタルサーバにもWAF機能がある。ただ、緊急の脆弱性に何日で新しいルールを配るかは、どこも書いていなかった。エックスサーバーは「100%駆除することを保証するものではありません」と明記している。

WordPressのプラグインでは、Wordfenceの無料版はルールの更新が30日遅れる。Patchstackの無料版にはファイアウォールが付かない。今回のような場面で頼るなら、有料版が前提になる。

まとめると、WAFは「急な対応がいらなくなる道具」ではない。急な対応までの数時間から数日を、安全に過ごすための層だ。今回はその層が早くから効いていた。入れるなら、オリジンを直接叩かせない設定とセットで考えたい。

まだなら今日やること

ここからは、セキュリティ運用担当として自分ならこう進める、という話だ。コマンドは一般的な例で、環境に合わせて読み替えてほしい。

まず：棚卸しと緩和

Step 1: PHPが動いている場所を洗い出す

サーバー台帳、クラウドのインスタンス一覧、コンテナのイメージ一覧を突き合わせる。各ホストでは、まずバージョンと動き方を見る。

php -v
ps aux | grep -E 'php-fpm|httpd|apache2'
apachectl -M 2>/dev/null | grep php

mod_phpなのかphp-fpmなのかは、あとの再起動手順に効いてくる。CLIの php -v と、Webで動いているPHPのバージョンが違うこともあるので注意したい。

Step 2: 「自分で直す」か「誰かに直してもらう」かを分ける

ディストリのパッケージなのか、自前ビルドなのか。レンタルサーバーやマネージドホストなら、PHPを更新するのはホスト側になる。同梱製品はベンダーの修正を待つしかない。

ここを分けておくと、何を待ち、何を自分でやるかがはっきりする。ホスト側の対応状況は、お知らせページか問い合わせで確認する。

Step 3: EOLのPHPに印をつける

8.1以下が見つかったら、公式のリリース版は出ない。ディストリのバックポートがあるかを確認する。Ubuntu 22.04のように出ているところもあれば、Amazon Linux 2023のphp8.1のように予定がないところもある。出ないなら、公開を止めるか隔離するかの判断が要る。

Step 4: すぐ更新できないものに緩和策を当てる

公式のアドバイザリには緩和策も載っている。109619向けには、php.iniなどで次の1行を入れ、すべてのワーカーを再起動する。

session.upload_progress.enabled = 0

ini_set() や FPM の .user.ini では効かず、リクエストの解析より前に効く設定にする必要がある。公式は、確認済みのセッション経路は防ぐが、ほかの変種は防げないとしている。PHP 8.5なら fatal_error_backtraces=0 も挙げられている。

109618向けには、post_max_size を小さくする方法や、Webサーバー側でリクエストの大きさを絞る方法がある。ただ公式は「完全な緩和策はない」と書いている。更新までのつなぎだと割り切りたい。

Cloudflareを使っているなら、ここでWAFの設定も見ておく。対象のホスト名がプロキシ（オレンジ雲）になっているか。Managed Rulesetがオンか。21日の緊急ルールがBlockのまま有効か。

見落としやすいのが、ルールセット全体をLogに落とす上書き設定だ。Cloudflareの上書きは、これから追加されるルールにも効く。誤検知対策で昔入れた設定が、今回の緊急ルールまで止めているかもしれない。WAFのログに今回のルールが当たっていないかも、あわせて見ておく。

次に：更新して再起動

Step 5: 公式の情報を読む

目標は 8.5.12、8.4.27、8.3.36、8.2.35 以上だ。ディストリのパッケージは版の番号が上流と違うので、各ディストリのアドバイザリで修正済みの版を確かめる。UbuntuならUSN-8948-1、DebianならDSA-6574-1などだ。

Step 6: 更新して、再起動まで終わらせる

ディストリやホストの更新を当てたら、php-fpmやApacheを再起動する。再起動しないと、古いバイナリのまま動き続ける。

sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2
php -v

サービス名はバージョンやディストリで変わる。コンテナはイメージを作り直してデプロイし直すところまでが更新だ。

そのあと：痕跡を見る

Step 7: ログとファイルを確認する

JPCERT/CCの注意喚起が、侵害を調べる観点を挙げている。異常に長いPHPSESSID、不審なmultipart/form-dataのリクエスト、メモリ上限のエラーやHTTP 500、ワーカーの異常終了だ。少なくとも10月17日以降のログを、この観点で見ておきたい。

CVE-2024-4577のときはwebshellを置かれた事例があった。公開ディレクトリに見覚えのないPHPファイルが増えていないかも確認する。更新しても、すでに入り込まれていたら元には戻らない。

修正版が出たあとで

今回の件で皮肉だと思ったのは、事前告知を出した結果、リークと推測が先に広まったことだ。CVE番号もRCEも修正版の番号も、出どころは公式ではなかった。それでも結果的には、そのほとんどが当たっていた。

未確認の情報を確定扱いしないことと、未確認だからと動かないことは別の話だと思う。棚卸しは真偽に関係なく役に立つし、どこでPHPが動いているかの台帳は次の件でもそのまま使える。

あなたの環境では、PHPが動いている場所をすぐに言えるだろうか。台帳から漏れていた意外な場所や、ホスト側の対応状況など、分かったことがあればコメントで教えてください。

この記事は21日15時ごろの情報で書き、22日17時ごろまでの情報で追記している。PHP公式やIPA、各ディストリの発表を、必ずこの記事より優先してほしい。

参考リンク

公式・公的機関

ディストリ・ホスティング

報道・研究者・セキュリティ企業

Cloudflare WAF

Cloudflare WAFなどの記事
毎回話にでる、Wordpressの代替 EmDashの紹介

#PHP #脆弱性 #セキュリティ #php2shell #WordPress #Cloudflare #サーバー運用 #パッチ管理 #WAF #インシデント対応