本文へスキップ
お知らせ PHP Security Alert

PHP に重大な脆弱性「php2shell」。修正版までにやること

PHP セキュリティ
PHP に重大な脆弱性「php2shell」。修正版までにやること

PHP 本体に、外からコードを実行されるおそれのある脆弱性が 2 件見つかりました。修正版は 10 月 21 日 23 時に出ます。それまでに確かめておくことと、修正版の入れ方を、このサイトで準備した手順と一緒にまとめます。

続報:10 月 21 日 23 時に修正版が出ました。上げる版の番号と入れたあとの確認は、続報の記事にまとめています。

10 月 20 日、PHP のセキュリティチームが、重大な脆弱性 2 件を直す修正版を出すと予告しました。公開は日本時間の 10 月 21 日 23 時です。研究者のあいだでは「php2shell」と呼ばれています。

このサイトも PHP で動いているので、今日のうちに準備をしました。公式の告知とセキュリティ会社の解説を読んで分かったことと、修正版が出るまでにやっておくことをまとめておきます。

何が起きる脆弱性なのか

今回の穴は、WordPress やプラグインではなく、PHP 本体にあります。細工したリクエストを外から送られると、サーバーの上で攻撃者のコードを実行される(RCE)おそれがあります。

細かい仕組みは、修正版と一緒に公開される予定です。解説を出している GMO Flatt Security は、メモリを壊す種類の脆弱性だと見ています。関係していそうなのは、セッション機能の「Session Upload Progress」。この機能は、PHP の初期設定で有効になっているんです。

研究者の投稿では、Apache の mod_php でも PHP-FPM でも攻撃が再現したとされています。上で動いていたのは、WordPress・Laravel・Symfony です。PHP でサイトを動かしているなら、作りに関係なく対象だと考えておくのが安全だと思います。

急ぐ理由はもう 1 つあります。悪用できると主張するコードが、すでに出回り始めているんです(Flatt Security、21 日 14 時の追記)。

修正版が出れば、修正の差分から攻撃のしかたを割り出す人も出てきます。セキュリティ会社の Sansec は、公開から 15 分以内に大規模な攻撃が始まると見ています。

対象と、修正版が出る系列

公式の告知に書かれているのは、次のことです。どのバージョンが対象なのかは、修正版と同時に公開されます。

発表10 月 20 日、PHP のセキュリティチーム
修正版の公開10 月 21 日 23 時(日本時間)。詳細が漏れたり悪用が見つかったりすれば、前倒しもある
脆弱性CVE-2026-109618、CVE-2026-109619
深刻度どちらも CVSS v4.0 で 9.2
修正が出る系列8.2、8.3、8.4、8.5
8.1 以前サポートが終わっていて、公式の修正は出ない

PHP 5 系から影響する、という話もネットでは出ています。公式は対象を明かしていないので、今使っている版はぜんぶ対象のつもりで動くのがよいと思います。

8.1 以前を使っているサイトは、修正版が出ても直りません。8.2 以降に上げるしかないので、今のうちに動くかどうかを確かめておきたいところです。

修正版が出るまでにやっておくこと

まずは、自分のサイトの PHP のバージョンを確かめます。レンタルサーバーなら管理画面の PHP の設定で、VPS ならサーバーで「php -v」と打てば分かります。

VPS で Ubuntu や Debian の PHP を使っている場合は、ひとつ注意があります。OS のパッケージは、番号を上げずに修正だけを取り込むんです。たとえば Ubuntu 24.04 の PHP は、修正が何度入っても 8.3.6 のまま。このときは PHP の番号ではなく、OS のセキュリティ情報でパッケージの更新を確かめます。

そのうえで、置き場所に合わせて準備をしておきます。

  • レンタルサーバー: PHP 本体の更新はサーバー会社がします。お知らせのページを見ておき、8.1 以前を選んでいるなら 8.2 以降へ切り替える準備を
  • VPS や自分のサーバー: バックアップを取り、更新のコマンドと、更新したあとに確かめるページを決めておく
  • 使っていない PHP のサイト: 止めるか消す。入口が 1 つ減れば、守る範囲もそれだけ狭くなります

このサイトでも、ここで見落としがありました。試作のまま使っていなかったサイトが、同じサーバーで動いたままだったんです。今日のうちに止めて、片付けました。

修正版が出るまでのつなぎとして、できることもあります。どれも完全ではなく、パッチまでの時間稼ぎです。

  • php.ini で session.upload_progress.enabled = 0 にする。Flatt Security は、これだけでは攻撃を防げず、緩和にとどまると見ています
  • ファイルを送るリクエスト(multipart の POST)を、PHP に届く前に Web サーバーで止める。Syhunt が Apache 向けの設定を公開しています。画像のアップロードなども止まるので、使い方に合わせて
  • 止めても困らないサイトなら、修正版を入れるまで公開を止める

修正版が出たら、すぐに入れる

23 時に修正版が出ると、対象の範囲と修正版の番号が PHP 公式のサイトに載ります。ここからは早さが大事です。

  • レンタルサーバー: サーバー会社の案内に沿って、管理画面で修正済みの版を選ぶ。反映まで少し時間がかかることもあります
  • Ubuntu や Debian のパッケージ: OS のセキュリティ更新を入れて、PHP-FPM や Apache を再起動する。パッケージは公式の公開から少し遅れて出ます
  • 公式のソースや Docker のイメージ: 使っている系列の最新版に上げる

Ubuntu の自動更新は、初期設定だと 1 日 1 回しか動きません。今回は待たずに、出たらすぐ手で入れるのが安全です。

入れたら、PHP のバージョン(OS のパッケージなら、パッケージの版)が変わったかと、よく使うページが表示されるかを確かめます。つなぎで入れた設定は、そのあとで元に戻します。

更新までの間に入られていないかも、見ておきたいところです。知らない管理者が増えていないか、画像を置くフォルダに PHP ファイルが紛れていないか。WordPress なら、9 月の WordPress の脆弱性の記事 に書いた点検の手順がそのまま使えます。

このサイトも、修正版が出たらすぐに入れます。PHP でサイトを動かしている人は、まず今のバージョンと、PHP 本体を誰が更新するのかを確かめてみてください。

share Xでシェア