コラム

PHPの脆弱性「php2shell」とは?攻撃者にできることと、企業がとるべき対応

  • PHP 脆弱性
  • 脆弱性診断
  • セキュリティ診断
PHPで動くWebサーバーの上に更新を示す循環の矢印があり、保守担当のエンジニアがレンチで作業している。左ではチェックリストを持った発注側の担当者が、サーバーにつながるWebサイト・ECサイト・問い合わせフォームの画面を確かめている

2026年10月21日、PHPの開発チームが、PHP本体に見つかった2件の脆弱性(CVE-2026-109618 / CVE-2026-109619、通称「php2shell」)を修正したバージョンを公開しました※1。 php2shellは、ログインしていない攻撃者が、細工したリクエストを送るだけでWebサーバー上のプログラムを実行できる可能性のある脆弱性(リモートコード実行、RCE)です。 WordPressや業務アプリを更新しても解消せず、PHP本体の更新が必要です。

この記事では、php2shellで想定される被害と、企業がとるべき対応を解説します。

php2shellで攻撃者に何をされるのか

ログインが要らないため、インターネットに公開しているPHPのサイトは、規模や知名度に関係なく狙われる可能性があります。サーバー上でプログラムを実行されると、次のような被害につながることがあります。

  • Webサイトの改ざん: ページを書き換えられ、偽のログイン画面や不正な広告を埋め込まれることがあります
  • 顧客情報の持ち出し: サーバーの設定ファイルからデータベース接続情報を読まれ、会員情報や注文履歴を取得される可能性があります
  • 不正なプログラムの設置: 攻撃者が後日も侵入できる仕組み(バックドア)を設置されることがあります。PHPを更新しても、この仕組みは残る場合があります
  • ほかの攻撃の踏み台: 自社のサーバーが、外部への攻撃や迷惑メール送信に悪用されることがあります

被害は、PHPが読み書きできるファイルやデータの範囲に及びます。同じサーバーに複数のサイトを置いていたり、ほかのシステムの接続情報を保存していたりする場合は、そこまで広がることがあります。

php2shellはどのバージョンに影響するのか

php2shellは、WebサイトやWebシステムを動かしているPHPに影響します。この記事では、同じ系列の修正版へ上げることを「更新」、サポートが続く系列へ移すことを「移行」と呼び分けます。

修正版は次のとおりで、各系列でこれより前のバージョンが対象です※1。

  • PHP 8.5系: 8.5.12
  • PHP 8.4系: 8.4.27
  • PHP 8.3系: 8.3.36
  • PHP 8.2系: 8.2.35

8.1以前のバージョンには、修正版が出ていません(後述)。

自社のどのシステムでPHPが動いているか

自社でPHPのプログラムを書いていなくても、PHPは身近なところで動いています。まず、次のようなシステムが社内にないかを洗い出します。

  • コーポレートサイトやオウンドメディア: WordPressで作ったサイトは、PHPの上で動いています
  • ECサイト: EC-CUBEなど、PHPで作られたECの仕組みを使っている場合があります
  • 問い合わせフォームや予約システム: サイトに後から付け足したフォームが、PHPで動いていることがあります
  • 他社に作ってもらった業務システム: 受発注や会員管理のシステムが、LaravelなどPHPのフレームワークで作られている場合があります

洗い出しでは、システムの名前と、どこのサーバーで動いているかを1行ずつ書き出しておくと、次の「誰が更新するか」の判断に使えます。どの言語で作られているか分からないシステムは、作った会社や保守会社に問い合わせて確かめます。

PHPの更新は誰が行うのか

PHPを更新する担当は、システムをどこに置いているかと、どんな契約を結んでいるかで決まります。

置き場所と契約 更新の担当者 発注側が確かめること
共用のレンタルサーバー サーバー会社 公式のお知らせで、修正版が適用済みかどうか
VPS・クラウド(自社で管理) 自社の担当者 担当者が更新と再起動まで済ませたか
VPS・クラウド(保守会社に委託) 保守会社 保守契約に、PHPやOSの更新が含まれているか
作った会社との保守契約がない 決まっていない 更新を依頼する先が決まっているか

注意が要るのは、表の下の2行です。他社が作ったシステムの保守契約は、範囲が「アプリの不具合の修正」までで、サーバー上のPHPやOSの更新を含んでいない形もあります。弊社が他社の作ったシステムの保守を引き継ぐときも、契約書で最初に確かめるのはこの範囲です。範囲に含まれていなければ、発注側から依頼しない限り、PHPは更新されないまま残ります。

作った会社と連絡が取れないシステムは、新しく保守を頼む会社を決め、そこに更新を依頼します。社内で作った担当者が退職しているシステムの扱いは「退職者が作った社内アプリを、引き継げなくなる前に」で解説しています。

php2shellにどう対応すればよいか

公開しているシステムから更新し、更新したあとに侵入の痕跡まで確かめます。発注側が自分で作業するのではなく、前の節で決めた更新の担当者(サーバー会社・自社の担当者・保守会社)に依頼し、結果を確認します。

1. インターネットに公開しているシステムから更新する

洗い出したシステムのうち、インターネットから誰でも開けるサイトやフォームを優先して更新します。社内ネットワーク内だけで使う業務システムは、次の順番に回します。

2. すぐに更新できないときは、公開を止めるか通信を絞る

改修が必要なシステムや、保守の依頼先が未決のシステムは、すぐに更新できないことがあります。その場合は、更新できるまでの間、サイトの公開を一時的に止めるか、WAF(Webアプリケーションへの攻撃の通信を止める仕組み)で攻撃に使われる通信を絞る対応を、更新の担当者と相談します。ただし、こうした暫定対応で塞げるのは攻撃経路の一部に限られることが多く、更新の代わりにはなりません。

3. 更新できたかを確かめる

サーバーには、コマンド用のPHPと、Webサイトを動かすPHPが別々に入っていることがあります。確認するのは、Webサイトを動かしている側のバージョンと、更新後にWebサーバーを再起動したかです。再起動がないと、古いPHPが動き続けることがあります。 WordPressなら、管理画面の「ツール」→「サイトヘルス」→「情報」で、サイトを動かしているPHPのバージョンを自分でも確認できます。

サーバー会社やOSの提供元によっては、バージョン番号を変えずに修正のみを取り込むことがあります。番号が修正版より古く見えても修正済みのことがあるため、提供元のお知らせで適用状況を確かめます。

4. 更新前に侵入されていないかを調べる

公表から更新までの間、システムは脆弱性を抱えた状態で動いていた可能性があります。更新の担当者に、Webサーバーのアクセスログに不審なリクエストがないか、外部への不審な通信やメール送信の記録がないか、身に覚えのないファイルや管理者アカウントが増えていないかの確認を依頼します。

5. 侵入の痕跡が見つかったら、パスワードや接続情報を変更して復旧する

痕跡が見つかった場合は、サーバーに置いていたパスワード、データベース接続情報、外部サービスのAPIキーをすべて変更します。サイトは、侵入前のバックアップから戻すか、再構築します。痕跡のあるファイルだけを削除すると、別の場所に残ったバックドアを見落とすことがあります。顧客の個人情報が漏えいした可能性がある場合は、個人情報保護委員会への報告と本人への通知が必要になることがあるため、早めに社内の担当部署や専門家に相談します。

サポートが終わったPHPで動いているシステムはどうするか

PHPには系列ごとにサポート期間があり、8.1以前はすでにサポートが終わっています※2。サポートが終わったバージョンには、公式の修正版が配布されません。今回のような脆弱性が見つかっても更新では直せず、サポートが続く系列への移行が必要になります。

8.2のサポートも、2026年12月31日で終わります※2。今回8.2.35へ更新したシステムも、2026年12月31日を過ぎると同じ状況になります。今回の更新で終わりにせず、サポートが続く系列へ移行する計画まで立てておきます。

移行すると、古い書き方のプログラムが動かなくなることがあるため、改修と動作確認の期間を見込みます。

脆弱性診断でどこまで確認できるのか

PHPのバージョンが古いままになっていないかは、サーバーの設定や動いているソフトウェアを調べる診断(プラットフォーム診断)で確かめられます。一方、PHPの上で動くアプリ自体の弱点は、Webアプリケーション診断で確かめます。診断は弱点を見つける作業で、直す作業ではないため、見つかった問題を修正したあとに再診断します。診断の種類と選び方は「脆弱性診断とペネトレーションテストの違い」で整理しています。

まとめ

  1. PHPで動いているシステムと、更新の担当者を決めましょう。
    サイト・フォーム・業務システムを洗い出し、置き場所と契約に応じて誰が更新するかを確定します。
  2. 公開しているシステムから更新しましょう。
    すぐに更新できないシステムは、公開の一時停止や通信を絞ることを更新の担当者と相談します。
  3. 更新後のバージョンと、侵入の痕跡を確かめましょう。
    痕跡が見つかったら、パスワードや接続情報を替え、侵入前のバックアップから戻します。
  4. サポートが続く系列への移行計画を立てましょう。
    改修と動作確認の期間を見込み、8.2のサポート終了(2026年12月31日)も踏まえて進めます。

弊社のマルゴト DXセキュリティでは、他社が作ったシステムも含め、PHPの更新と移行、脆弱性診断から修正・再診断までを支援しています。更新を誰に頼めばよいか分からないシステムがあれば、無料相談からお問い合わせください。

出典

※1 PHP「Releases」(2026年10月21日公開の 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35)

※2 PHP「Supported Versions」

ライター

feeed編集部 / フィード株式会社

フィード株式会社のコラム編集部です。PoC開発・新規事業開発・受託開発の現場で得たことを、発注する側の判断に役立つ形で書いています。

PHPで動くシステムの更新と点検を、まとめて相談しませんか?

弊社では、他社が作ったWebシステムも含め、PHPの更新とサポートが続くバージョンへの移行、脆弱性診断から修正・再診断までを支援しています。どこにPHPが使われているか分からない段階からご相談ください。

関連記事