はじめに

私自身、これまでに数多くのPHPによる大規模システムやWebアプリケーションの開発・保守を手掛けてきました。また、今ご覧いただいている当Webサイト（ブログ）自体もWordPressで構築し、運用しています。

そうした「開発者」かつ「WordPressサイトの運営者」としての実体験と技術的観点から言っても、今回の2026年10月に発覚したPHPの重大な脆弱性（いわゆる「php2shell」等の問題）は、「これまでの脆弱性とは明らかに次元が違う」と強い危機感を抱いています。

事態の深刻さを受け、2026年10月21日夜には高市早苗首相が自身のX（旧Twitter）で「今夜中の対応」を呼びかけ、国家サイバー統括室の情報を案内するという、異例の事態となりました。

Webサイトやシステムの運用を担当されている方、あるいは自社サイトを管理する経営者の方の中には、以下のように感じている方も多いのではないでしょうか。

「脆弱性のニュースなんて普段からよく聞くけれど、今回は何がそんなに違うの？」 「今までも『緊急アップデート』なんて何度もあったじゃないか」

結論から申し上げますと、技術的観点からも過去のケースとは比較にならないほど危険度が高いインシデントです。

「認証なしでサーバーを乗っ取れる（RCE）」「アプリではなく土台のPHP本体の欠陥である」「修正パッチの公開前に情報が流出し、攻撃も始まっていた」という、最悪の要素が3重に重なっています。

本記事では、長年PHPシステムに触れてきたエンジニアの視点から、ITの現場で何が起きているのかを分かりやすく解説し、WordPressユーザーやWeb担当者が「今すぐ取るべき具体的なアクション」について詳しくまとめました。

※記事の性質上、専門用語が多く含まれます。できるだけ分かりやすい説明を心がけておりますが、あらかじめご容赦ください。

1. 過去の脆弱性と何が違うのか？3つの技術的決定打

「過去の脆弱性」と「今回の脆弱性」の決定的な違いは、主に以下の3点に集約されます。

（1）「ログイン不要」で、アプリの認証チェック前にサーバーの奥深くに侵入できる

過去に発生したWebアプリケーションの脆弱性の多くは、以下のようなステップや前提条件が必要でした。

  • 管理画面にログインした後に、特定の操作を行うことで権限を奪取する
  • フォームに特殊な文字列を入力してデータベースを不正操作する（SQLインジェクション等）

つまり、アプリケーション側の「入力チェック」や「ログイン認証」がある程度の防波堤になっていたのです。

しかし、今回の脆弱性（CVE-2026-109618 / CVE-2026-109619等）は、パスワードやログイン（認証）を一切必要としません。 攻撃者が外部から特殊なリクエストを1回送信するだけで、サーバー内部で任意のプログラムを直接実行させることができる「RCE（リモートコード実行）」の性質を持っています。

さらに恐ろしいのは、Webサーバーの構成によっては、私たちが普段使っているWordPressや自社開発アプリの「認証処理コード」が走る前（PHP自体のリクエスト受け取りの最根幹処理）で攻撃が成立してしまう点です。いくらアプリ側で強固なパスワードを設定していても、土台のPHPレベルで素通りしてしまうため、防波堤の意味を成しません。

（2）個別のプラグインではなく「すべての土台（PHP本体）」の欠陥

「WordPressの特定のプラグインに穴があった」「ECサイト構築ツールの特定機能にバグがあった」というレベルの脆弱性であれば、最悪の場合そのプラグインを停止・削除すれば一時的な無効化が可能です。

しかし、今回はWebサイトを動かしているプログラミング言語のエンジンそのもの（PHP本体）の欠陥です。

世界のWebサイトの約7割は何らかの形（WordPress、EC-CUBE、Laravel、独自開発など）でPHPを使用しています。つまり、アプリケーション側がどんなに最新で安全に組まれていても、土台となっているPHPのバージョンが対象であれば、一網打尽にサーバーを乗っ取られる危険性があるということです。影響範囲が文字通り「桁違い」に広範囲に及びます。

（3）修正パッチ公開前の「情報流出」と「ゼロデイ攻撃」の発生

通常、脆弱性が見つかった場合はセキュリティ研究者と開発元が秘密裏に連絡を取り合い、修正プログラム（パッチ）を準備した上で「パッチと公表を同時に行う」のが暗黙のルール（調整済みの脆弱性開示）です。これにより、管理者はパッチを当てるための猶予期間を得ることができます。

しかし今回は、修正版が正式公開される前日（10月20日）に脆弱性の存在が外部に漏れ、さらに公開前の10月17日には、すでに実際の攻撃の試みが観測されていたと報告されています。

その結果、「防衛側がパッチを当てるよりも前に、悪意ある攻撃者が全自動スキャンツールを使って世界中のサーバーへ攻撃を開始する」という最悪の展開（ゼロデイ攻撃）が発生してしまいました。公開後もセキュリティ企業各社から実際の攻撃事例が報告されており、CloudflareなどもWAFで緊急の防御ルールを配備しています。

2. 放置するとどうなるのか？想定される最大被害

「うちは怪しいファイルを置いていないし、個人情報も扱っていないから大丈夫」という考え方は非常に危険です。今回の脆弱性でサーバーが乗っ取られた場合、以下のような被害が発生します。

  1. マルウェア・ランサムウェアの感染源にされる サーバー内のファイルが暗号化されて身代金を要求されるだけでなく、自社のWebサイトを訪問した顧客のPCやスマートフォンにウイルスを感染させる「踏み台」にされます。
  2. 別の攻撃の「踏み台（ボットネット）」に組み込まれる 乗っ取られたサーバーは、他国や他企業への大規模サイバー攻撃（DDoS攻撃など）を実行するマシンとして裏で利用されます。加害者として警察や相手企業から追究されるリスクが生じます。
  3. 機密情報・顧客データの漏洩 データベースにアクセスされ、顧客情報、クレジットカード情報、社内の機密文書、メール履歴などがすべて外部へ流出します。
  4. 検索エンジン（Google等）からのペナルティ・サイト閉鎖 悪質なコンテンツやフィッシングページが勝手に生成され、Googleなどの検索エンジンから「危険なサイト」としてブラックリスト登録され、検索結果から除外されます。

3. なぜ「首相の発信」にまで至ったのか？

技術的な危険度が高いのはもちろんですが、行政や政府がここまで危機感を募らせた背景には、「企業の管理体制の実態」があると筆者は考えています。

PHPは非常に普及している反面、「数年前に作ったまま放置されているWebサイト」「社内にエンジニアがおらず、保守契約も切れている企業サイト」のベースとして最も使われている言語でもあります。

企業や組織のトップが「専門的なことは分からない」と放置している間に、日本国内の膨大なWebサーバーが次々と乗っ取られ、社会インフラやビジネスに大混乱をきたす恐れがありました。

「技術者同士の注意喚起だけでは、現場の意思決定者（経営層・管理職）まで伝わらない」 「経営トップが事態の深刻さを認識し、一刻も早くベンダーや管理者に指示を出さなければ防げない」

こうした背景から、政府機関や首相自身によるダイレクトな注意喚起が行われるという、極めて異例の状況となったのです。

4. Web担当者・経営者が「今すぐ取るべき対策」ロードマップ

では、私たちは具体的に何をすればよいのでしょうか。緊急度の高い順に解説します。

  1. 【緊急度：高】PHP本体の緊急アップデート（パッチ適用）
  2. 【緊急度：高】WAF（Webアプリケーションファイアウォール）の適用・ルール更新
  3. 【緊急度：中】ログの確認と感染チェック（バックドアの有無）
  4. 【緊急度：中】外部委託先・保守会社への確認と運用体制の見直し

ステップ1：PHPの最新セキュリティバージョンへのアップデート

修正版（PHP 8.5.12／8.4.27／8.3.36／8.2.35）以降へ直ちにアップデートしてください。レンタルサーバーを利用している場合は、事業者の対応状況も確認しましょう。PHP 8.1以前はすでに公式サポートが終了しています。7.4〜8.1向けにはソースコードの修正のみが提供されており、7.3以前には修正がありません。古いバージョンを使っている場合は、すぐに最新環境への移行計画を立てる必要があります。

ステップ2：WAF（Web Application Firewall）の導入とルール更新

サーバー本体のアップデートに時間がかかる場合（互換性テストが必要な場合など）の暫定対策として、Cloudflare、AWS WAF、各レンタルサーバー会社が提供する「WAF」の導入・有効化が必須です。 シグネチャ（定義ファイル）が最新に更新されているかを確認し、今回の攻撃パターンをネットワークの入口でブロックする体制を整えてください。

なお、アップデートもWAFもすぐに対応できない場合は、サイトを一時的に停止することも有効なリスク低減策です（首相や英国NCSCも推奨しています）。

ステップ3：不審なファイルやログの調査

すでに攻撃を受けている可能性があるため、以下の確認を行ってください。

  • Webサーバーのアクセスログに、不審なパラメータを含むリクエストが残っていないか
  • PHPの実行権限があるディレクトリ（uploads や tmp など）に見覚えのない .php ファイル（バックドア）が設置されていないか

ステップ4：開発会社・保守ベンダーへの緊急問い合わせ

社内に専門知識を持つエンジニアがいない場合は、サイトの構築・保守を担当しているベンダーへ直ちに連絡を取り、以下の項目を確認してください。

  1. 「今回のPHPの脆弱性（CVE-2026-109618等）に対する影響調査は完了しているか？」
  2. 「PHP本体のアップデート、またはWAFによる緩和策は実施済みか？」
  3. 「サポート切れの古いPHPバージョンを使用していないか？」

まとめ：今すぐ行動を起こすことが最大の防御

今回のPHP脆弱性問題は、「いつか対応すればいい」というレベルのものではありません。攻撃者は全自動化されたプログラムを使って、今この瞬間もインターネット上のすべてのIPアドレスをスキャンし、対策されていないサーバーを探し続けています。

「自社は小さい会社だから狙われない」という考え方は通用しません。攻撃者は会社規模ではなく、「脆弱性が放置されているかどうか」だけを見て自動で攻撃を仕掛けてくるからです。

自社のWebサイト、顧客ポータル、社内システムが最新のPHP環境になっているか、あるいは適切な防御措置（WAF等）が講じられているかを今すぐ確認し、安全なWeb運用を徹底しましょう。

WAI SYSTEMSでは、WordPressサイトのPHPバージョン確認・アップデート対応、WAFの設定、改ざんチェックなどのセキュリティ保守を行っています。「自社のサイトが対象か分からない」「保守会社と連絡が取れない」という方は、まずはお気軽にご相談ください。

放置されたホームページに潜むリスクについては、こちらの記事もあわせてご覧ください。

ホームページは「作って終わり」じゃない！放置サイトに潜む3つのリスクと対策

参考：PHP公式サイト（php.net）
参考：PHP2Shell: Critical PHP vulnerabilities patched, update now!（Help Net Security・英語）

※本記事は2026年10月23日時点の情報に基づいています。最新情報は公式発表をご確認ください。