いろとり

PHP脆弱性（php2shell）の対応を4つの立場別に整理

最終確認：2026年10月24日（公式のお知らせは、更新されることがあります）

ここ数日、「PHPの脆弱性」という言葉を、ニュースやSNSでよく見かけました。「自分のサイトは大丈夫？」「何をすればいいの？」という疑問も、検索でたくさん並んでいます。公式の案内や専門会社の解説を調べてみました。

先に答えを書くと、やることは立場によって違います。ただ、全員に共通するのは「PHPそのものを修正版に更新する必要がある」という点です。WordPress本体やプラグインを更新しても、PHPの脆弱性はなくなりません。

そもそも何が大変なのか（専門用語なしで）

一言でいうと、ログインなしで、外から、サーバーでプログラムを動かされるおそれがあるという欠陥です。家にたとえると、鍵を開けずに入られる状態です。

  • 鍵がいらない：IDやパスワードを強くしていても、守れません。PHP公式の案内でも、認証は不要とされています。
  • 乗っ取られる範囲が広い：サイトの改ざん、情報の持ち出し、迷惑メールの踏み台などに使われるおそれがあります。
  • 対象が広い：PHP公式の案内では、Webの要求を受けるPHPは、ほぼすべて対象です（PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeed）。とくにmod_phpは、サイトのプログラムが動く前に攻撃が成立する例が示されていて、危険度が最も高いとされています。
  • 「管理画面にIP制限をしているから大丈夫」とは言えません：攻撃は管理画面だけに向かうものではなく、アプリのコードが動く前にも成立しうるためです（これは公式の記述を元にした私の解釈です）。
  • 気づきにくい：入られても、サイトは普通に見えることがあります。

判断の起点：そのシステムに、どんなデータがあるか

即対応か、一日待てるかは、「そのシステムに何があるか」を明らかにしてからでないと、決められません。バージョンの確認と同時に、次のことを確かめます。

見る点問い緊急度が上がる例
データの中身個人情報、決済情報、ログイン情報、取引先の機密はあるか顧客名簿、会員情報、注文・問い合わせの履歴
公開の状況インターネットから直接つながるか誰でも開けるサイト、会員ログインがあるサイト
つながりこのサーバーから、他のシステムやパスワードに到達できるか同じサーバーに複数サイト、データベースや社内との接続
止めたときの影響止めると何が困るか、どこまで止められるか決済・予約の仕組み、重要な業務
侵害されたとき漏えいしたときに、報告や連絡が必要になるか個人データの漏えいのおそれがある場合（法令上の報告が必要になることがあります）

目安としては、次のように考えます（自社の基準がある場合は、そちらを優先してください）。

  • 重要なデータがあり、しかも外部に公開している：最優先。更新を待つ間は、一時停止や、公開範囲の絞り込みも検討します。
  • 重要なデータはないが、外部に公開している：早めに対応。ただし、「つながり」を確かめることが条件です。
  • 社内だけで使っていて、外部からは見えない：優先度は下がりますが、社内の他の端末が感染した場合に狙われます。計画的に更新します。

注意点：データが軽いから待てる、とは限りません。サーバーを乗っ取られると、そこから他のシステムや、保存されているパスワードを狙われるおそれがあります。待てると判断するのは、「データの中身」と「つながり」の両方を確かめたあとにします。

この整理をするには、「いつもの状態で、どのシステムに何があるか」が把握できている必要があります。これは、脆弱性のニュースが出てからでは間に合いません。今回をきっかけに、情報資産の一覧を見直してください。

踏み台にされたとき、誰の責任か

悪いのは攻撃した側です。ただ、自社のシステムが踏み台にされたとき、管理責任がないとは言えません。そのとき問われるのは、「知っていたのに、根拠なく後回しにしなかったか」です。判断の理由と承認の記録が、あなたと組織を守ります。

「知らなかった」「英語でよく分からなかった」は、理由になりにくいです。たとえば、英語圏でルールを知らずに違反しても、「英語が分からなかった」とは言いにくいのと同じです（これはたとえ話です。法的な扱いは、状況と契約で違います）。脆弱性の情報は、英語で先に出ることが多いですが、IPA（情報処理推進機構）など、日本語で案内する窓口もあります。今回も、IPAは10月21日に、PHPを使っているプログラムや製品の棚卸しをするよう、事前に案内しています。自分で読めないなら、読める人やベンダーに届く仕組みを作っておくことが、管理の一部です。

あわせて、情報資産の台帳が「データ」「〇〇システム」というくくりだけでは、「重要なデータはない」という判断自体に根拠がありません。データの種類、分類（重要度）、置き場所、管理者、つながり先まで書いておくことをお勧めします。

攻撃者から踏み台にされたシステムを通って、つながっている先へ進む流れデータが軽くても、つながり先が狙われる攻撃者侵入踏み台にされたシステム「重要なデータはない」と判断して後回しにしたつながっている先社内の他のシステム取引先・委託先のシステム他社・第三者への攻撃管理責任が問われやすいのは、知っていて根拠なく後回しにした場合
攻撃の経路（イメージ）。攻撃者は、重要なデータのないシステムを入口にして、つながっている先へ進むことがあります。

何が起きたのか（調べて分かったこと）

  • 2026年10月21日に、PHPの開発チームが、深刻度の高い脆弱性2件の修正版を公開しました。通称「php2shell」です（CVE-2026-109618、CVE-2026-109619）。
  • 深刻度は、2件とも CVSS v4.0 で 9.2（Critical）と報じられています。認証なしで外部から命令を実行される（リモートコード実行）おそれがある、と説明されています。
  • 修正版は、PHP 8.5.12、8.4.27、8.3.36、8.2.35です。
  • PHP 8.1以前は、公式のサポートが終わっており、通常の修正版が出ていません。専門会社の解説では「安全とは判断できない」とされています。
使っているPHP状況（調査日 10/24）
8.5系8.5.12 以降へ更新
8.4系8.4.27 以降へ更新
8.3系8.3.36 以降へ更新
8.2系8.2.35 以降へ更新（8.2は2026年12月末でサポート終了予定との情報あり）
8.1以前（7.x、5.xを含む）通常の修正版なし。サポートされる系列への移行を検討

出典：PHP公式セキュリティリリース、PHP公式GitHubのアドバイザリ、GMO Flatt Security のブログ（下の参考資料）

分かっていること・分からないこと

分かっていることと、情報が食い違っていることを、分けて書きます。

  • 実際の攻撃：Palo Alto Networks の Unit 42 と Cloudflare は、実際の攻撃を観測した（または、修正版公開の前から攻撃通信を検知した）と発表しています。
  • 公的機関：IPAは、10月21日付の事前注意喚起で、「IPAとして悪用を確認していない」と書いています。また、10月21日版のCISAの「既知の悪用された脆弱性」の一覧には、この2件は載っていない、と解説記事に書かれています。
  • 食い違いの理由は、確認できませんでした。発表の時点や、見ている範囲が違う可能性があります（これは推測です）。
  • 自分のサイトが影響を受けるかどうか：PHP公式の案内（10月21日）では、Webの要求を受けるPHPは、ほぼすべて影響を受けるとされています。1件は「メモリ不足の処理」、もう1件は「前の処理の状態が残ること」が原因です。設定を一部変えても「安全」とは言えない、と公式に明記されています。
  • カナダのサイバーセキュリティセンターは、10月21日付の警報で、概念実証（PoC）が公開されているとしつつ、「実際の攻撃は確認していない」と書いています。状況は変わりうるため、更新を急ぐことを勧めています。
  • 10月23日付で、PHP公式は、セッションのアップロード進捗に関する別の件（CVE-2026-115560）を案内しています。特定の設定とコードの書き方が条件で、次の修正版が出るまで、この機能をオフにすることを勧めています。
  • VulnCheck（10/22時点）は、実際の動きを観測したとしています。同社のおとり用サーバー（ハニーポット）で、複数のIPアドレスからの探索と、中国のIPからの攻撃の試み（1件、成功せず）が記録されたという説明です。GitHubには数百のサンプルコードが現れていますが、本物は少ないとしています。
  • 同社の推計では、インターネットに公開されたPHPサーバーは約260万台。そのうち約42%（約110万台）が、サポート終了の系列で動いているとされています（これは同社の推計です）。
  • 10月21日の夜（21:55）に、高市早苗首相がXで、公開しているウェブサイトでPHPを使っているかの確認と、修正パッチの適用の準備を呼びかけました。適用が困難な場合は、サイトを一時的に停止することもリスクを下げる有効な策と考えられる、と述べています。

SNSで広がった発信（Xより）

ここで紹介するのは、公的な発信、事業者、メディア、情報発信者の投稿です。一般の利用者の「街の声」ではありません。読んだ日：2026年10月24日。

皆様に、今夜に対応して頂きたい大至急のお願いです。

多くのウェブサイトで使用されているPHPに関し、PHPのセキュリティチームが、重大な２件の脆弱性に関する注意喚起を行っています。…— 高市早苗 (@takaichi_sanae) October 21, 2026

高市早苗首相（10/21 21:55）：公開サイトでPHPを使っているかの確認、修正パッチの適用の準備を呼びかけ。困難なときは一時停止も有効な策、という内容です。

さくらインターネット 田中邦裕社長（10/22）：深夜の緊急メンテナンスでPHPを更新したと報告。古いPHPを使う利用者に、最新版を使うよう訴えています。

PHPの重大脆弱性「PHP2Shell」はセキュリティ企業のCalifとWizがAIを用いて発見しOpenAIの枠組みを使って対策したことが判明 pic.twitter.com/esXoy128Ij— GIGAZINE(ギガジン) (@gigazine) October 21, 2026

GIGAZINE（10/22）：この脆弱性は、セキュリティ企業のCalifとWizがAIを使って見つけ、対策もした、と報じています。

情報の灯台（個人・メディア系の発信。数字は未検証）：日本国内の200超のサービスが止まったというまとめと、セキュリティ企業VulnCheckが本番相当の設定で遂行できたという紹介です。

この中で、同じ脆弱性のニュースでも、「公的な呼びかけ」「事業者の対応報告」「メディアのまとめ」の信頼度は同じではありません。公式や事業者の資料を一次情報とし、SNSやまとめの数字は、裏を取ってから使います。また、AIが脆弱性を見つけたという報道は、AIが守る側にも攻める側にも使える、「諸刃の剣」の話とつながります。

立場別に整理

① 利用者（そのサイトやサービスを使っている人）

  • あなた自身がPHPを更新する必要はありません。ただし、使っているサービス（ネットショップ、会員サイト、学校や園の連絡サービスなど）が、メンテナンスで止まったり、再開が遅れたりすることがあります。
  • 実際に、10月21日以降、国内のいくつかのサービスが、緊急メンテナンスや機能停止を案内しています（下の表）。
  • やること：公式のお知らせを見る。メールの「パスワードを変更してください」といった連絡は、本物か確認する（リンクから入らず、公式サイトのブックマークから入る）。
サービス公表されている状況出典・時点
さくらインターネットレンタルサーバ：提供PHPに修正を適用（サポート終了版のうち提供中のものにも）、対応完了。すべての緊急メンテナンスが終了。VPS：サービス提供部分でPHPを使っていないため影響なし（利用者側のPHPは更新を推奨）公式お知らせ（10/23 17:30追記）
ロリポップ！10/22 13:00頃に、お客様のサイト表示を再開。PHP 8.1以下は同社が修正を作成して適用。全バージョンで session.upload_progress を無効化。PHP 8.2以降への切り替えを推奨公式お知らせ
XServerPHP 5.6～8.5は修正パッチ適用完了。5.5以下は独自の修正を作成・検証中二次情報（tency、10/22時点）
ConoHa WING提供中のすべてのPHP（5.6～8.5）に修正を適用。修正を取り込む方式のため、表示されるバージョン番号は変わらない場合がある二次情報（同上、10/22 20:45まで）
BASE／カラーミーショップ緊急メンテナンス完了セキュリティ対策Lab（10/22 16時台）
Movable Type クラウドPHP 8.3.36 へ更新、全顧客環境の対応完了同上
はてなブログPHP未使用のため影響なしと公表同上

（表は10/24に確認。公式のお知らせを元にした行と、二次情報を元にした行があります。最新は各社の公式お知らせで確認してください。ロリポップ！ではサーバー単位でサイト表示を止めたため、PHP 8.2以降のサイトやPHPを使わないサイトも一時的に表示できなくなりました。）

② 担当者（情報システム、サイト管理者）

  1. PHPを使っているサーバーを、洗い出す（自社サーバー、レンタルサーバー、クラウド、コンテナ、外部委託先の環境）。
  2. 使っているPHPのバージョンを確認する。上の表と照らし合わせる。ただし、レンタルサーバーの事業者が、修正を取り込む方式（バックポート）で対応している場合、表示されるバージョン番号が変わらないことがあります。番号だけで「未対応」と判断せず、事業者の公式のお知らせで、対応済みかを確認します。
  3. 修正版に更新し、PHPのプロセスを再起動する。レンタルサーバーなら、管理画面のPHPバージョン設定と、事業者の対応のお知らせを確認する。
  4. 8.1以前を使っている場合は、サポートされる系列への移行を、優先して計画する。
  5. 更新までの間の一時的な対策（WAF、設定変更）は、あくまで暫定です。専門会社の解説では、根本的な対策にはならないと明記されています。
  6. 攻撃を受けていないか、ログを見る（不自然に大きいリクエスト、メモリ不足のエラー、予期しないプロセスの起動など）。クラッシュがなかったことだけでは、侵害がなかったとは言えません。
  7. WordPressの場合：WordPress.org は「WordPress本体の更新は不要」と説明しています。ただし、PHP本体の更新は別に必要です。

一次対処：PHP公式が示す暫定策（これだけでは安全になりません）

PHP公式は、次の対策を「部分的な緩和」としていて、どれも安全を保証しないと書いています。更新までのつなぎとして使います。

  • CVE-2026-109619の緩和：session.upload_progress.enabled=0 を、php.ini、FPMのプール設定、またはリクエストの解析前に効くサーバー設定に書き、PHPのワーカーを全部再起動します。ini_set() と .user.ini では不十分と公式に明記されています。PHP 8.5では、fatal_error_backtraces=0 も設定し、再起動します。
  • CVE-2026-109618の緩和：post_max_size を小さくする（アップロードが不要なら8M、必要でも32M程度）、Webサーバーやプロキシ側でリクエストのサイズ・項目数などを制限する、コンテナなどでメモリの上限をかける。
  • レンタルサーバーでphp.iniを変えられない場合は、事業者の対応を待つか、修正済みのバージョンに切り替えます。

設定が効いているかの確認（3分）

  1. 次の1行だけのファイルを置きます：<?php phpinfo();
  2. ブラウザで開き、session.upload_progress.enabled を探します。Local Value が Off（0）なら有効です。Master Value だけでは足りません。
  3. 確認したら、すぐファイルを削除します。置いたままにすると、サーバーの情報が見えてしまいます。
  4. 画像のアップロードなど、普段の機能が動くかも確認します。

③ 経営者（判断する人）

  • 決めること：誰が責任を持って確認するか、いつまでに、どこまで止めるか（更新までサービスを止めるかどうか）。
  • 聞くこと：自社が使っているPHPの系列と、更新の予定日。委託先・クラウド事業者の対応状況。8.1以前の環境が、まだ残っていないか。
  • 気をつけること：「被害が出ていないから大丈夫」ではなく、更新と、ログの確認の両方が必要です。
  • 個人情報を扱うサイトでは、侵害が疑われる場合の連絡の手順（顧客への連絡、関係機関への相談）を、先に決めておきます。
  • 費用：旧バージョンから移行する場合は、改修費用が必要になることがあります。見積もりは、委託先に早めに依頼します。

④ 委託先・サプライヤー（制作会社、ホスティング、クラウド事業者）の視点

  • 預かっているお客様の環境を、一覧にする（どのPHPの系列で動いているか）。
  • 更新の予定日と、サービスが止まる時間を、お客様に先に連絡する。
  • 8.1以前の環境は、移行の見積もりと、いつまでに行うかを、お客様と相談する。
  • 対応状況の公表（国内の事業者は、すでに、完了や予定を告知しています）。
  • 発注する側（担当者・経営者）は、委託先に、次の3つを聞いておきます：①うちの環境のPHPのバージョン ②更新の予定日 ③更新前のログの確認と保全。

ベンダーの対応を待つ間、利用者はどうすればいいのか

ベンダーに任せている環境でも、対応に時間がかかることがあります。そのとき、利用者は何ができるのでしょうか。

契約している内容によって、ベンダーが動けるまでの時間（リードタイム）は変わります。保守の範囲に含まれるか、問い合わせの順番、作業の枠、再起動の調整などです。この記事で紹介した脆弱性は、公開から攻撃までの時間が短くなりやすいものです。「待つしかない」状態が長く続くのは、リスクになります。

利用者が、最低限できるようにしておきたいこと

これは義務ではありません。ただ、次の一次対処ができる状態にしておくと、待つ間のリスクを減らせます。

  • 自分のサービスが、どの環境（PHPのバージョン）で動いているかを、ベンダーに確認する。
  • ベンダーの公式のお知らせと、連絡先を、すぐ見られるようにしておく。
  • 変更の前に、データやログを保全する（ベンダーに依頼する場合も含む）。
  • 公式が示す暫定策のうち、契約と権限の範囲で、自分で行えるものを把握する。
  • サービスを一時的に止める、または公開範囲を絞る場合の判断基準と、連絡先を決めておく。

ただし、どこまで自分で触ってよいかは、契約と権限で決まります。権限のない設定を変えると、障害や契約上の問題になることがあります。だからこそ、手順を事前に決めておく必要があります。

ベンダーへのお願い

義務ではないのは承知のうえで、ベンダーには、次のことをお願いしたいと思います。

  1. 一次対処の手順書を作ってください。誰が、何を、どの順番で、どこまで行うか。
  2. 利用者が自分でやってよい範囲と、やってはいけない範囲を、書いてください。
  3. その手順を、利用者と一緒に訓練してください。年に1回でも、模擬の連絡と手順の確認を行うだけで、実際のときの動きが変わります。
  4. 緊急時の連絡先と、対応にかかる時間の目安を、事前に示してください。
  5. これらが契約に含まれるのか、別の費用なのかを、明らかにしてください。

手順と訓練がないまま、いざというときに「待つしかない」では、利用者も、ベンダーも困ります。

今日できること

  • 契約書や保守の範囲を、読み直す。
  • 緊急時の連絡先と、対応時間を確認する。
  • 上の「ベンダーへのお願い」を、そのまま質問として送る。

考察：ベンダーに任せていても、管理は残る

今回の件を調べて、私（運営者）が気になったのは、「任せているから大丈夫ではないか」という点です。以下は、公式のお知らせを読んだうえでの、私の考えです。断定ではなく、確認のきっかけとして読んでください。

事業者がやることと、利用者に残ることは、別です。さくらインターネットやロリポップ！は、夜間・未明に、PHPの修正を適用しました。ここは事業者の仕事です。一方、次の3点は、任せていても利用者側に残ります。

  1. いつ止まるかは、自分では決められない。ロリポップ！は、サーバー単位でサイトを止めたため、PHP 8.2以降のサイトや、PHPを使わないサイトも、一時的に表示できませんでした（公式の経緯報告より）。どれだけ準備していても、止まることはありうる、という前提で、お知らせの方法や代わりの連絡手段を、あらかじめ考えておく必要がありそうです。
  2. 対応済みかどうかは、番号だけでは分からない。修正を取り込む方式で対応した事業者では、表示されるバージョンが変わらないことがあるとされています。自分で読み取る力がないと、「未対応」と誤解して不要な変更をしたり、逆に「大丈夫」と誤解したりするおそれがあります。
  3. 待つ間の判断は、利用者の仕事。首相の呼びかけにもあるように、すぐに適用できないときは、一時停止も選択肢になります。その判断を、今日、誰が、何を根拠にするのか。事前に決めていないと、その場で迷います。

だから、ベンダーを使うときには、次のことを確かめておくとよいと考えます。

  • 何を任せていて、何が自分の責任のことか（契約や規約に書いてあるか）
  • 緊急時に、事業者がどう連絡し、どのくらい時間がかかるか
  • 待つ間に、自分ができる一次対処は何か

そして、ベンダーの方には、一次対処の手順を作って、利用者と一緒に訓練してほしいと思います。義務ではありませんが、手順と訓練があれば、利用者も、事業者も、待つ間のリスクを減らせます。

この記事は、公開された情報を元にした一般的な整理です。自分の環境での判断は、契約先の事業者や、専門の方にもご相談ください。

選び方の目安（立場別）

  • 利用者：公式のお知らせを見る。メールのリンクは使わない。
  • 担当者：まずバージョンの洗い出し。8.1以前は移行の計画。
  • 経営者：責任者と期限を決める。委託先に3つの質問をする。
  • 委託先：お客様の環境の一覧と、更新予定の連絡。

よくある疑問

WordPressを最新にしていれば大丈夫？ WordPress.org は、WordPress本体の更新は不要としています。ただ、脆弱性はPHP本体のものなので、PHPの更新が別に必要です。

WAFがあれば安心？ WAFは、更新までの一時的な補完策です。専門会社の解説では、修正の代わりにはならない、とされています。

レンタルサーバーで、自分では何もできないときは？ 事業者の公式のお知らせを確認します。PHPのバージョン設定を選べる場合は、管理画面で、修正済みの系列になっているかを確認します（画面は事業者ごとに違います）。

まとめ

  • 脆弱性は、PHP本体のもの。WordPress本体やプラグインの更新だけでは直りません。
  • 修正版：8.5.12／8.4.27／8.3.36／8.2.35。8.1以前は通常の修正版なし。
  • 実際の攻撃の観測については、情報が食い違っています。更新を先に行い、ログの確認も行います。
  • 立場ごとに、最初にやることは違います（利用者は公式のお知らせの確認、担当者は洗い出しと更新、経営者は責任者と期限、委託先は一覧と連絡）。

参考資料（確認日 2026-10-24）