危険重い被害が、日本で広く起きている

PHP2Shell、実際にシェル取得を確認 CISA が KEV 追加

PHP 本体の重大欠陥 CVE-2026-109618/109619(PHP2Shell)が実際に悪用された。ハニーポットで 35 回のシェル取得が記録され、CISA は 10 月 26 日に KEV へ追加。日本でもレンタルサーバー事業者が緊急対応した。

要点

  • 多くの Web サイトを動かしている PHP に重大な欠陥が2件見つかった。ログインなしで外から、サーバーに好きな命令を実行されるおそれがある。
  • 研究者のおとり用サーバーでは、実際に外から命令を実行された記録が残った。米国の CISA は、この2件を「悪用が確認された欠陥」の一覧に加えた。
  • 日本でも一部のレンタルサーバーがサイトを一時止めて修正した。PHP を自分で管理しているサーバーや古い機器は、持ち主が自分で確かめる必要がある。

何が起きたか

PHP は、WordPress をはじめ多くの Web サイトの裏で動いているプログラム言語だ。PHP を開発する The PHP Group は、2026年10月21日、予定していた日本時間23時より早く、修正版を緊急で公開した。欠陥は CVE-2026-109618 と CVE-2026-109619 の2件で、まとめて「PHP2Shell」と呼ばれている。PHP プロジェクトが GitHub に出した告知では、深刻さはどちらも最も重い「Critical」で、点数(CVSS)は10点満点の9.2だ。

怖いのは、攻撃にログインも利用者の操作も要らない点だ。サイト側の対策で防げないのも厄介だ。少なくとも Apache の mod_php の経路では、攻撃は WordPress などのサイトのプログラムが動き出すより前、PHP 自身が要求を受け取る段階で起きると確かめられている。プラグインの更新や管理画面の制限では止められない。PHP プロジェクトの告知によると、Web で PHP を動かす主なやり方(PHP-FPM や mod_php など)はどれも対象に入る。危険度がいちばん高いと名指しされたのは Apache の mod_php だ。ログインのない外からの要求で、攻撃を起こせるとされる。もう1件の CVE-2026-109619 は、先に送った要求と後から送った要求が、サーバー内の同じ処理役に届かないと成り立たない。

どちらの欠陥も、PHP の中でのメモリの扱いの誤りだ。1件はメモリが足りなくなったときの後始末に、もう1件は前の要求の情報が消えずに残ることに原因がある。

悪用は段階を追って確かめられた。セキュリティ企業 watchTowr は、公開当日の21日に悪用を観測したと報告した。Datadog Security Labs のまとめによると、AWS は公開4日前の17日から悪用の試みをつかんでいた。

決め手になったのは10月24日の報告だ。研究者 Adel Karimi が GitHub に出した記録では、この日の協定世界時15時台から19時前にかけて、おとり用の PHP サーバー3台で35回、外から命令を実行された。記録された PHP のエラーは、サイトのプログラムが読み込まれる前の段階で出ていた。Karimi はこの点を、特定の CMS の不具合ではなく PHP 本体の欠陥が突かれたときの特徴に合うと見ている。

米国の CISA(サイバーセキュリティ・社会基盤安全保障庁)は10月26日、2件を KEV(実際に悪用が確認された欠陥の一覧)に加えた。米国の連邦政府機関には、3日後の10月29日までに対処するよう求めている。

影響は Web サイトだけではない。Siemens は10月23日、ネットワーク機器の RUGGEDCOM APE1808 がこの2件の影響を受けると発表した。

日本の利用者への影響

IPA は、修正版が出る前の21日のうちに準備を呼びかけ、22日に注意喚起を出した。調査に関わった Wiz によると、PHP 5.4 以降の版は少なくとも1件の影響を受けるという。IPA の注意喚起もこの見方を紹介している。サポートが切れた PHP 7 系で動く国内サイトも対象に入る。JPCERT/CC も22日に注意喚起を出した。26日の更新では、「悪用できると主張する」実証コードが多数公開されていることと、悪用を試みる通信の報告が相次いでいることを書き加えた。

レンタルサーバーの対応は事業者ごとに違った。ロリポップは、22日の午前3時ごろ、一部のサーバーで利用者サイトの表示を止めた。修正を当て終えるまで、利用者のサイトとデータを守るためだという。設定による暫定の対策だけでは防ぎきれないおそれがあったことと、欠陥を「狙ったとみられるアクセス」を確認していたことも挙げている。再開は同じ日の13時ごろだ。古い PHP 5.3〜7.3 にも、公式の修正をもとに独自の手当てをしたと公表している。heteml の報告では、22日11時24分に利用者サイトの表示を再開した。KAGOYA は、10月23日18時17分の時点で、レンタルサーバーの更新を終えたと公表した。VPS や FLEX の利用者には、PHP の更新を自分で行うよう案内している。FLEX では、一時的な公開停止やアクセス制限も対策に挙げている。

国内の組織が実際に外から命令を実行されたという公表は、本稿の時点で確認できていない。

今すぐやること

  1. 自分のサイトの PHP がどこから来ているかを確かめる。 レンタルサーバーなら事業者の告知を見る。自社のサーバーなら、担当者や制作会社に確認してもらう。版の番号だけでは修正済みか判断できないことがある。
  2. 修正版に更新し、PHP を動かしているサービスを再起動する。 更新しても再起動しなければ、古いまま動き続ける。
  3. すぐに更新できないなら、暫定の対策を入れる。 PHP プロジェクトが案内する設定の変更がある。それも難しければ、IPA が求めるとおり、外からのアクセスを止めるか、サービスを一時止めるかを判断する。
  4. 外から命令を実行された跡がないか、記録を調べてもらう。 JPCERT/CC や Datadog が、見るべきところを示している。
  5. ネットワーク機器や工場・入退室の装置も確かめる。 IPA は、利用者から見えない形で機器に PHP が組み込まれている場合があると指摘している。各メーカーの発表を確かめる。

背景

CVE-2026-109618 の根は、メモリが足りなくなったときの PHP の処理のしかたにある。準備が終わる前のメモリに一瞬触れられる隙間があり、そこで失敗すると壊れた状態が残ってしまう。サイトのプログラムがどれだけ丁寧に書かれていても関係のない欠陥だ。

2件とも、攻撃を成功させるのは簡単ではないとされる。JPCERT/CC の見方では、公開された実証コードをそのまま使っても、相手のサーバーで命令を動かせるとは限らない。PHP の版やメモリの使われ方といった相手側の条件に合わせて、調整する必要があるからだ。それでも公開から3日後には、1日のうちに35回の実行が記録された。

PHP の重大な欠陥が KEV に入るのは初めてではない。2024年の CVE-2024-4577 も KEV に加えられ、日本の組織を狙う攻撃が報じられた。ただし、あれは Windows の特定の設定に限られていた。今回は、Web で PHP を動かすふつうの構成がそのまま対象になる。

PHP 8.1 以前は、PHP プロジェクトの更新の対象から外れている。7.4/8.0/8.1 には最小限の修正が出たが、自分で組み立てられる人向けの救済にとどまる。PHP 7 系で動く日本の中小サイトや古い CMS は、レンタルサーバー側が独自に手当てしたかどうかで明暗が分かれた。自分の PHP の出どころを知らないまま運用を続けるのが、いちばん危ない。

技術者向けの詳細
  • 修正版: PHP 8.5.12/8.4.27/8.3.36/8.2.35(2026-10-21 公開)。2件とも CVSS v4.0 9.2、Attack Complexity: High。7.4/8.0/8.1 は番号付きリリースなし(最小限のソースのバックポートのみ)。
  • 対象の構成: PHP-FPM、Apache mod_php(最も危険)、php-cgi、FrankenPHP、LiteSpeed。
  • 版の確認: php -v は CLI の PHP しか映さない。パッケージで確かめる。
dpkg -l | grep -E '^ii +php'   # Debian/Ubuntu
rpm -qa | grep php             # RHEL 系
  • 配布元の告知で判断: バックポートで番号が据え置きのまま修正済みのことがある。RHEL/AlmaLinux、Ubuntu、remi、cPanel の ea-php、CloudLinux の alt-php など、出どころを先に特定する。
  • 更新後は全ワーカーを再起動: 例 systemctl restart php8.3-fpm、Apache の再起動。
  • 暫定策(PHP プロジェクト。更新だけが完全な対策と明記): CVE-2026-109619 には upload progress 機能を切る(session.upload_progress.enabled=0)。指定は、要求の解析より前に効く場所(php.ini、FPM プール、サーバー設定)で行う。実行時の ini_set() や FPM の .user.ini での指定は当てにできない。変更後は全ワーカーを再起動。PHP 8.5 では fatal_error_backtraces=0 も挙がる。
  • 痕跡(JPCERT/CC): ログでは、過去のレスポンスで発行された PHPSESSID クッキーに、長すぎる値や形の崩れた値がないかを見る。不審な multipart/form-data リクエストがないか、その前後にメモリ上限のエラーや HTTP 500 が出ていないかも見る。プロセスの面では、ワーカーの異常終了や再起動の多発を確かめる。Datadog は、Web ワーカーが sh/bash を起動するプロセスツリーを兆候とした。
  • ハニーポット報告(Adel Karimi、2026-10-24 UTC): 送信元の1つが 13:47 に探索を始め、15:35 に最初のシェル取得。確認されたシェルは 18:57 までに計35回(3台の PHP ターゲット)。PHP 8.4.26、Apache mod_php のワーカー1本、memory_limit 128 MiB。CVE-2026-109618 の経路と整合し、CVE-2026-109619 が使われた証拠はないとしている。
  • KEV: 2026-10-26 追加。BOD 26-04 による FCEB の期限は 10-29。ランサムウェアでの使用は「Unknown」。
  • 産業機器: Siemens SSA-566512(10-23)は RUGGEDCOM APE1808(PAN-OS 10.2/11.1/11.2/12.1/12.2)。
  • 国内: JVNVU#99905564。JPCERT/CC の注意喚起は 10-26 更新。ロリポップは 8.2〜8.5 に公式修正、7.4〜8.1 に提供された修正、5.3〜7.3 に独自修正を適用(10-22 3:09 頃に一部サーバーでサイト表示を停止、13:00 頃再開)。heteml は 10-22 11:24 にサイト表示を再開。KAGOYA はレンタルサーバーの更新完了を 10-23 18:17 時点で公表。

出典

一次情報

報道

参考

記事は、運営者が生成 AI を活用して作成し、内容を確かめたうえで公開しています。 誤りに気づいたら編集方針の連絡先へ。

次に読む

同じタグの記事