10月21日に公開されたPHPの重大な脆弱性について、Web担当者が今すぐ確認することを先の記事にまとめました。今回はその続きで、サイトやシステムを管理する立場の方向けです。
情報システム部門の責任者や、Webサイトの管理を任されている管理職の方は、自分でサーバーを触ることは少なくても、「どのシステムから手を付けるか」「止めるべきか」「個人情報は大丈夫か」「制作会社と連絡がつかない」といった判断を、短い時間で求められます。その判断の順番を整理しました。
先に結論：今日やること
- PHPで動いているWebサイト・システムを洗い出す
- バックアップがあるかを確かめる（あれば、すぐに暫定対応に入れる）
- 各システムの制作会社・保守会社に、期限を切って連絡する
- システム影響度とビジネス影響度で、止めるもの・急いで直すものを決める
- 個人情報を扱うシステムは、侵入の痕跡の確認まで依頼する
- 誰が・いつ・何を判断したかの記録を残す
1. 管理者向けの初動
何が起きているか（おさらい）
- PHP本体に、ログインなどの認証なしに外部からプログラムを実行されうる脆弱性が2件見つかりました（CVE-2026-109618 / CVE-2026-109619、通称 php2shell、深刻度はCVSS v4.0で9.2）
- 修正版は 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 です。PHP 8.1以前には、PHP公式の修正版が出ません
- 攻撃の試みはすでに報告されています。10月22日時点では、侵入に成功した事例は確認されていません
まずバックアップを確認する（最優先）
最初に確かめてほしいのが、バックアップです。
バックアップがあれば、PHPを上げて画面が壊れても元に戻せるので、修正にすぐ取りかかれます。侵入されていた場合も、きれいな状態から立て直せます。逆にバックアップがないと、「壊れたら戻せない」ために手が止まり、そのあいだ脆弱な状態が続きます。影響度の判定より先に、次の5点を確認してください。
| 確認すること | なぜ必要か |
|---|---|
| バックアップがあるか（誰が、どこで取っているか） | 制作会社・サーバー会社・自社のどこが取っているのか、誰も把握していないことがよくあります。レンタルサーバーには自動バックアップの機能があることが多いので、保存期間もあわせて確認します |
| ファイルとデータベースの両方があるか | WordPressなどは、どちらか片方だけでは元に戻せません |
| いつの時点のものか（日付の違うものが複数あるか） | 攻撃の試みは修正版の公開前から観測されています。侵入されていた場合、直近のバックアップに不正なファイルが入っているおそれがあるため、遡れる時点が多いほど立て直しやすくなります（どこまで遡れば安全かは、侵入の痕跡の調査で判断します） |
| サーバーとは別の場所に保存されているか | 同じサーバーの中にしかないと、侵入されたときに一緒に消されたり書き換えられたりします |
| 実際に戻せるか（手順・所要時間・費用） | 一度も戻したことがないバックアップは、いざというときに戻せないことがあります。サーバー会社の復元サービスは有料のこともあります |
バックアップがなければ、今すぐ取ってもらいます（ファイルとデータベースの両方）。ただし、すでに侵入されていた場合は、いま取ったバックアップにも不正なファイルが含まれうるので、調査用の記録として扱い、そのまま復元には使いません。具体的な取り方と戻し方はバックアップと復元の手順にまとめています。
システム影響度：技術的にどれだけ危ないか
システムごとに、次の3段階で判定します。判定に必要な情報は、後述の「制作会社・保守会社との連絡疎通」で集めます。
| 影響度 | 当てはまる状態 |
|---|---|
| 高 | インターネットに公開されていて、PHP 8.1以前（公式の修正版なし）、または修正版の適用がいつになるか分からない。あるいは、侵入の痕跡が見つかっている |
| 中 | 修正版が出ている系列（8.2〜8.5）で、まだ適用されていないが、適用の日時が決まっている。または、社内のネットワークからしか使えないが、修正版が未適用 |
| 低 | 修正版を適用済み（制作会社やサーバー会社から書面で確認できている） |
PHP公式は、Apacheに組み込んで動かす「mod_php」構成のリスクが最も高いとしています。制作会社に確認するときは、PHPのバージョンとあわせて動かし方も聞いておきます。なお、PHPを使っていない静的なサイトや、クラウドサービス（SaaS）は、今回の対応の対象外です（SaaSは提供元が対応するので、提供元のお知らせを確認します）。
ビジネス影響度：やられたとき、止めたときに何を失うか
| 影響度 | 当てはまる状態 |
|---|---|
| 高 | 会員・顧客・応募者の個人情報をサーバーに保存している。決済や受注・予約が動いている。社内のほかのシステムや取引先とつながっている |
| 中 | 問い合わせフォームはあるが、送信内容はメールで送るだけで、サーバーには保存していない |
| 低 | 会社案内など、情報を載せているだけで、フォームもない |
ビジネス影響度には、「侵入されたときの被害」と「止めたときの損失」の両面があります。ECサイトのように、被害も大きく、止めたときの損失も大きいシステムほど、止めるかどうかを経営層と一緒に決める必要があります。
2つを掛け合わせて、優先順位を決める
XECINとしての目安は次のとおりです（縦がシステム影響度、横がビジネス影響度）。最終的な判断は、各社のリスクの考え方に合わせて調整してください。
| システム／ ビジネス | 高 | 中 | 低 |
|---|---|---|---|
| 高 | 停止判断 | 停止判断（またはアクセスを絞る） | 当日中に停止か修正 |
| 中 | 当日中に修正（間に合わなければ停止） | 当日中に修正 | 数日以内に修正 |
| 低 | 侵入の痕跡の確認を依頼 | 侵入の痕跡の確認を依頼 | 確認を依頼し、記録を残す |
修正版を適用済みの「低」のシステムでも、適用前に入られていないかの確認は残ります。攻撃の試みは、修正版の公開前から観測されていたと伝えられているためです。
経営層への第一報
判断が必要なことがあれば、状況が全部そろう前に第一報を入れます。次の5行があれば十分です。
件名：【第一報】PHPの重大な脆弱性への対応状況（10月22日 〇時時点）
1. 概要：10月21日、PHP（Webサイト等で使うプログラム言語）に、外部から乗っ取られうる重大な脆弱性が公表された。攻撃の試みも報告されている
2. 当社への影響：PHPで動くシステムは〇件（コーポレートサイト、採用サイト…）。うち個人情報を扱うものは〇件。バックアップが確認できたものは〇件
3. 現在の対応：各システムの制作会社に、修正の状況・バックアップ・侵入の痕跡の確認を依頼済み（回答期限：本日〇時）
4. 判断が必要なこと：〇〇（例：会員サイトを修正が終わるまで一時停止するか）
5. 次回の報告：本日〇時2. 各所の影響を確認する
個人情報のあるなし
侵入されたときに一番重くなるのが、個人情報が絡む場合です。システムごとに、次の場所に個人情報がないかを確認します。
- 問い合わせ・資料請求・採用応募のフォーム（送信内容をメールで送るだけか、サーバーにも保存しているか）
- 会員情報・顧客情報のデータベース
- サーバー上に置いたままのCSVファイルやバックアップファイル
- 決済（カード番号を自社のサーバーで扱うか、決済代行会社の画面に移ってから入力するか）
個人情報保護法では、個人データの漏えい等が発生した、またはそのおそれがあるときに、次のいずれかに当たれば、個人情報保護委員会への報告と本人への通知が義務になります。
- 要配慮個人情報（病歴など）が含まれる
- 不正に使われると財産的な被害が出るおそれがある（クレジットカード番号など）
- 不正の目的をもって行われたおそれがある（不正アクセスなど。人数に関係なく対象です。ウェブサイトが改ざんされ、利用者が入力した個人情報が第三者に送られた場合も含みます）
- 本人の数が1,000人を超える
今回の脆弱性で侵入されていた場合は、3に当たる可能性が高いと考えてください。報告は、発覚したらまず速やかに速報を出し、不正の目的によるおそれがある場合は、発覚日から60日以内に確報を出します。サイバー攻撃による漏えいは、2026年10月1日から、関係省庁で共通の様式でも報告できるようになっています（詳しくは個人情報保護委員会の「漏えい等の対応とお役立ち資料」を参照）。
注意点が2つあります。
- 脆弱性が残っていたというだけで、直ちに報告の対象になるわけではありません。一方で、侵入の痕跡が見つかった場合は、データが抜かれた確証がなくても「おそれ」に当たりうるので、早めに弁護士や調査会社、個人情報保護委員会の窓口に相談してください。
- 制作会社や保守会社にシステムを任せていても、報告するのは原則として自社です。痕跡を見つけたらすぐ自社に知らせてもらうよう、連絡の段階でお願いしておきます。
制作会社・保守会社との連絡疎通
管理者の仕事で一番時間がかかるのが、ここです。連絡する前に、次の3つを手元で確認しておくと話が早く進みます。
- 契約：保守契約はあるか。緊急時の対応やバックアップの取得は契約の範囲か、費用はどうなるか
- サーバーの名義：サーバーやドメインを契約しているのは自社か、制作会社か。制作会社の名義だと、自社では止めることも確かめることもできません
- 管理画面のログイン情報：WordPressやサーバーの管理画面に、自社の誰かが入れるか
連絡は、回答の期限を切って、聞くことを1通にまとめて送ります。
件名：【至急】PHPの脆弱性（CVE-2026-109618 / 109619）への対応状況の確認
株式会社〇〇 ご担当者様
いつもお世話になっております。
10月21日に公表されたPHPの重大な脆弱性について、
貴社に制作・保守をお願いしている下記システムの状況を確認させてください。
対象：〇〇（https://〜）
1. PHPのバージョンと動かし方（Apacheのmod_php／PHP-FPMなど）
2. バックアップの有無（ファイルとデータベースの両方か、取得日時、保存場所、復元にかかる時間）
3. 修正版（8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 以上、またはディストリビューションの修正版）の適用状況と、未適用の場合の予定日時
4. PHP 8.1以前の場合の対応方針（修正の有無、バージョンアップの要否・期間・費用）
5. 侵入の痕跡の確認結果（不審なファイル、見覚えのない管理者アカウント、アクセスログの異常など）
6. 個人情報を保存している場所（データベース、ファイル、メールのみ など）
7. サイトを一時停止する場合の手順と所要時間
本日〇時までに、分かる範囲で一次回答をいただけますと幸いです。
侵入の痕跡が見つかった場合は、その時点ですぐにご連絡ください。期限までに返事がない、連絡がつかない場合は、次の順で動きます。
- 電話でも連絡し、メールを送ったことと期限を伝える
- サーバーの名義が自社なら、サーバー会社のサポートに直接問い合わせる（修正の適用状況、バックアップ、一時停止の方法）
- 修正の見込みが立たず、個人情報を扱うシステムなら、自社の判断で一時停止する
- 制作会社の廃業や担当者の退職で連絡先が分からない場合は、請求書・契約書・ドメインやサーバーの請求先から辿るか、別の会社に調査と修正を依頼する（XECINでも緊急の調査・復旧をお受けしています）
対象バージョンの確認方法
確実なのは、制作会社・保守会社からメールなど書面で回答をもらうことです。自社で確かめる場合は、次の方法があります。
- WordPressの管理画面：「ツール」→「サイトヘルス」→「情報」タブ→「サーバー」の「PHPバージョン」
- レンタルサーバーの管理画面：「PHPバージョン設定」などのメニュー
数字の読み方には注意が必要です。修正版は 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 ですが、Linuxディストリビューションが配布するPHPは、修正を取り込んでもバージョン番号が変わらないことがあります。「バージョンがいくつか」ではなく、**「修正を適用したか」**を聞いてください。技術的な確認方法はWeb担当者向けの記事にまとめています。
確認した結果は、システムごとに1行の表にしておくと、判断と経営層への報告がそのまま進められます。
| システム（記入例） | PHPのバージョン・修正 | バックアップ | 個人情報 | 管理会社 | 判定 |
|---|---|---|---|---|---|
| コーポレートサイト（WordPress） | 8.1・修正なし | あり（サーバーの自動バックアップ、14日分） | 問い合わせのみ（保存なし） | 〇〇制作（担当：△△） | 高×中 → 停止判断 |
| 採用サイト | 8.3・本日適用予定 | 確認中 | 応募者の情報を保存 | 〇〇制作 | 中×高 → 当日中に修正 |
| キャンペーンサイト | PHP不使用（静的） | — | なし | 自社 | 対象外 |
| 社内の勤怠システム | 8.2・適用済み | あり（毎日、別サーバー） | 従業員の情報 | 〇〇システム | 低 → 痕跡の確認を依頼 |
3. 対応フロー：停止 → 修正 → 再公開
停止：止めるかを決め、止める前に記録を残す
優先順位の表で「停止判断」になったシステムは、止めるかどうかをすぐに決めます。止めると決めたら、修正が終わるまで止めます。PHP公式は「更新以外に完全な対策はない」としています。また、WordPress公式は8.2より前のPHPを自前のサーバーで動かしている場合に、EUのセキュリティ機関CERT-EUはすぐに更新できない場合に、それぞれサーバーをオフラインにする・インターネットから切り離すことを検討するよう呼びかけています。
止める前に、その時点のログとファイルを保全してもらいます。すでに侵入されていた場合、その記録が調査と報告の材料になります。復元用のバックアップとは分けて保管し、不正なファイルが含まれている可能性があるので、そのまま復元には使いません。
止め方は、次のどれかです。
- サイト全体をメンテナンス画面に切り替える
- アクセスできる相手を絞る（社内のIPアドレスだけにする、パスワードをかける など）
- サーバー会社の管理画面で、サイトを一時停止する
なお、今回の脆弱性は、アプリケーションの処理が始まる前のリクエストを受け付ける段階で狙われることがあります。問い合わせフォームのページだけを止めても防げません。 止めるなら、PHPが動くページ全体へのアクセスを止めるか、絞ってください。
止めたことは、サイト上でもお知らせします。理由をどこまで書くかは各社の判断ですが、修正が済む前は「メンテナンス」とだけ書く例が一般的です。
【お知らせ】システムメンテナンスに伴う一時停止について
現在、システムメンテナンスのため、〇〇を一時的に停止しております。
ご利用の皆さまにはご不便をおかけし、申し訳ございません。
再開の見込みは、決まり次第このページでお知らせいたします。
お問い合わせ：〇〇（電話・メール）修正：修正版を当て、侵入の痕跡を確かめる
修正の作業は制作会社やサーバー会社が行いますが、管理者は次の3点が終わったことを確認します。
- 戻せる状態の確認：作業の前に、最新のバックアップがあり、戻す手順が決まっていること。バックアップがあれば、PHPを上げて画面が壊れても、すぐに元に戻して原因を調べられます
- 修正版の適用：8.2〜8.5系は修正版へ、8.1以前は8.3以上へ切り替えます。古いPHPから上げると、プラグインやテーマが動かなくなることがあります（PHPを上げたら表示されないときの直し方）
- 侵入の痕跡の確認：攻撃の試みは修正版の公開前から観測されていたため、適用前に入られていないかを確かめてもらいます
- 見覚えのないPHPファイルが増えていないか（画像などのアップロード用フォルダは特に）
- 見覚えのない管理者アカウントが増えていないか
- ページや問い合わせフォームの送信先が書き換えられていないか
- アクセスログに、不審なリクエストやエラーの急増がないか
痕跡が見つかった場合は、管理画面・サーバー・データベースなどのパスワードをすべて変え、侵入される前の時点のバックアップから立て直します（どの時点まで遡るかは調査結果で決めます）。そのうえで、前述の個人情報の報告が必要かを判断します。
再公開：条件がそろってから戻す
次の5つがそろってから再公開します。
- 修正版の適用（または8.3以上への切り替え）を、制作会社からのメールなどで確認した
- 侵入の痕跡の確認結果を受け取った
- 表示・管理画面へのログイン・問い合わせフォームの送信（メールが届くまで）を確認した
- 修正後の状態で、あらためてバックアップを取った
- 不審な動きを見つけたときの連絡先と手順を決めた
再公開したあとも、2週間ほどはログを重点的に見てもらうようお願いしておくと安心です。対応が一段落したら、いつ・誰が・何を判断したかの記録と、棚卸しの表を残しておきます。PHP 8.2のサポートは2026年12月31日に終わるため、2か月後に同じ確認が必要になるシステムが出てきます。
おわりに
重大な脆弱性への対応で、管理者が本当に困るのは、技術そのものより「どこに何があって、バックアップはあるのか、誰に聞けばいいのか分からない」ことだったりします。今回作った棚卸しの表と連絡ルートは、次の脆弱性のときにもそのまま使えます。
もうひとつの選択肢は、守る範囲そのものを減らすことです。ページの配信にPHPを使わない構成なら、今回のような対応の対象から外れます。
XECINでは、案件ごとの要件を見極めたうえで、PHPなど脆弱性への対応が頻繁に必要になる技術を、あえて採用しない方針をとっています。
