php2shell の修正版が出ました。上げる版と入れたあとの確認
PHP 本体の重大な脆弱性「php2shell」を直す修正版が、10 月 21 日 23 時に出ました。上げる版の番号と Ubuntu のパッケージの版、入れたあとに確かめることを、前回の記事の続きとしてまとめます。
10 月 21 日 23 時(日本時間)、PHP の修正版が予告どおり公開されました。前回の記事で「修正版と同時に出る」と書いた、対象の範囲と脆弱性の中身も分かっています。
公式の告知と Ubuntu のセキュリティ情報を読んで、上げる版の番号と、入れたあとに確かめることをまとめておきます。
どの版に上げればいいのか
修正版は、サポート中の 4 つの系列に出ました。使っている系列の、この版か、それより新しい版に上げます。
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35。8.2 のサポートは 2026 年 12 月 31 日で終わる |
| 8.1 以前 | 公式の修正版は出ない。ソースから作る人向けに、7.4・8.0・8.1 に修正だけを当てたブランチが公開された |
対象は、Web のリクエストを受ける PHP のすべてです。公式は PHP-FPM、Apache の mod_php、php-cgi、FrankenPHP、LiteSpeed を挙げています。
いちばん危ないとされているのは mod_php です。認証のいらないリクエストで、アプリのコードが動く前に攻撃が成り立つことが確かめられています。
8.1 以前は、OS のパッケージやサーバー会社が独自に修正を入れているかを、それぞれの案内で確かめることになります。上げられるなら、12 月で終わる 8.2 より 8.3 以降を選んでおくと、次の切り替えまでの余裕ができると思います。
OS のパッケージで入れるときは
Ubuntu は、告知と同じ 21 日に修正版のパッケージを出しました(USN-8948-1)。PHP の番号は変わらないので、パッケージの版で見分けます。
| 26.10 | php8.5 の 8.5.9-0ubuntu2.1 |
| 26.04 LTS | php8.5 の 8.5.4-0ubuntu1.5 |
| 24.04 LTS | php8.3 の 8.3.6-0ubuntu0.24.04.13 |
| 22.04 LTS | php8.1 の 8.1.2-1ubuntu2.28 |
22.04 の PHP は 8.1 ですが、Ubuntu が修正を取り込んでいます。公式の修正版が出ない系列でも、OS のパッケージなら直ることがあるんです。
入ったかどうかは、「dpkg -l | grep php」で出てくる版を上の表と比べて確かめます。「php -v」では 8.3.6 のような元の番号しか出ないので、見分けがつきません。
告知が出てから、使っているミラーにパッケージが届くまでには時間がかかることがあります。apt で新しい版が見えないときは、少し待ってから apt update をやり直してみてください。
ほかの置き場所では、次のようになります。
- レンタルサーバー: サーバー会社の案内に沿って、修正済みの版に切り替える
- remi のリポジトリ: 21 日の時点では更新が出ない。公式は OS 標準のパッケージか、ソースからのビルドへの切り替えを勧めている
- Docker の公式イメージ: イメージの PHP が上の版になったのを確かめてから、コンテナを作り直す
入れたあとに確かめること
- PHP の版(OS のパッケージなら、パッケージの版)が変わったか
- PHP-FPM や Apache が、更新のあとに再起動されたか
- よく使うページ、フォームの送信、画像のアップロードが動くか
- つなぎで入れた設定を元に戻したか
パッケージを入れても、動いているプロセスが古いままだと直りません。再起動されたかは、サービスの起動時刻を見ると確かめられます。
更新までの間に入られていないかも、見ておきたいところです。Sansec によると、修正版が出る前の 21 日 16 時台(日本時間)には、Cloudflare が PHP のサイトへの攻撃を観測していました。
点検の手がかりは次のとおりです。WordPress なら、9 月の WordPress の脆弱性の記事 に書いた手順もそのまま使えます。
- 知らない管理者やユーザーが増えていないか
- 画像を置くフォルダに PHP ファイルが紛れていないか
- ログに、PHP のプロセスの異常終了(SIGSEGV など)が増えていないか
メモリを壊す攻撃は、失敗するとプロセスごと落ちることがあります。異常終了の記録は、攻撃を試された跡の手がかりになると思います。
すぐに更新できないときの設定
公式の告知で、2 件の中身が分かりました。どちらも、認証なしで外からコードを実行されるおそれがあります。
| CVE-2026-109618 | メモリが足りなくなって処理が止まると、後始末が作りかけのデータを正しいものとして扱う |
| CVE-2026-109619 | リクエストが使っていた状態が、メモリを解放したあとも残る。同じプロセスが次のリクエストでそれを使ってしまう |
1 件目は、multipart のリクエストの読み取りでメモリを使い切らせる手口が挙げられています。2 件目は、前回の記事で書いた Session Upload Progress が、確認された経路の 1 つでした。
公式は、すぐに更新できない場合の設定も示しました。ただし、完全な対策は更新だけで、これらは攻撃を受ける範囲を狭めるだけだと、はっきり書いています。
| メモリの上限 | memory_limit=-1 にする。アプリから上書きできない場所(PHP-FPM のプール設定の php_admin_value など)で固定する |
| 送信の大きさ | post_max_size を小さくする。アップロードが要らなければ 8M、要るなら 32M |
| Web サーバー | リクエストの大きさ、フィールドの数、multipart のパートの数、ヘッダーの数を制限する |
| Upload Progress | session.upload_progress.enabled=0 にして、すべてのワーカーを再起動する。ini_set() や .user.ini では効かない |
| PHP 8.5 | fatal_error_backtraces=0 にする |
memory_limit=-1 は、PHP が使うメモリの上限をなくす設定です。1 つのリクエストがサーバーのメモリを食いつぶすおそれもあるので、公式はコンテナや cgroup でメモリを制限することもあわせて挙げています。
更新が済んだら、memory_limit は元の値に戻しておきます。つなぎの設定は、修正版を入れるまでの時間稼ぎです。
PHP でサイトを動かしているなら、まずは今の版(OS のパッケージなら、パッケージの版)を確かめてみてください。上の表より古ければ、それがいちばん先にやることです。