PHPを使うウェブサイトでは、サーバー側の修正状況を早急に確認する必要があります。
2026年10月21日、PHPの開発チームは、外部からサーバー上で命令を実行されるおそれのある2件の欠陥を修正した更新版を公開しました。
ログイン情報を知らない相手でも攻撃できる可能性があるため、管理画面のパスワードを強くするだけでは対策が完了しません。
ニュースで目立ったのは、企業や行政機関のサイト停止でした。
ただ、利用者が知りたいのは、自分の情報が漏れたのか、いつサービスを使えるのかという点でしょう。
一方、運営者には、どのサーバーを誰が更新するのかという判断が求められます。
本記事では両者を分け、確認できた経過と今後の見通しを整理します。
PHPは、問い合わせフォームや会員ページなど、サーバー側で処理を行うためのプログラミング言語です。
そのプログラムを実行するソフトウェアもPHPと呼びます。
ブラウザーに画面を表示する前に、必要な情報を取り出したり、入力内容を処理したりする役割を担います。
今回は個別のサイトが書いたプログラムではなく、この実行基盤に問題があります。
PHPを利用するWordPressなどのCMSを導入している場合、サイトの担当者がPHPを直接書いた経験がなくても確認対象です。
WordPress公式も、今回の問題はWordPress固有ではなく、PHPの更新が必要だと案内しています。
対象はCVE-2026-109618とCVE-2026-109619の2件です。
CVEは脆弱性を識別する番号で、両者の深刻度はCVSS v4.0で9.2、Criticalに分類されています。
この点数は危険性の指標であり、攻撃が成功する確率を示すものではありません。
「遠隔コード実行（RCE）」は、外部の相手がサーバー上で意図しない命令を実行できる状態を指します。
成立すれば、PHPを実行するプロセスの権限に応じて、データの閲覧・改ざんや不正プログラムの設置などにつながる可能性があります。
ただし、直ちにサーバーの全権限を奪えるという意味ではありません。実際の被害範囲はアクセス権限やネットワーク構成にも左右されます。
PHP公式は、ウェブリクエストを処理するPHP環境を広くリスクの対象とし、特にApacheのmod_php構成を高リスクと評価しています。
アプリケーションの処理が始まる前に攻撃を成立させた実証があるためです。PHP-FPMなど別の構成も、確認を省いてよい環境には含まれません。
「世界のサイトの多くがPHPを利用している」という普及率と、「実際に攻撃されたサイトの割合」は別の数字です。
今回の影響規模を判断するときは、利用サイト数、未修正の環境数、確認済みの被害件数を混ぜないようにする必要があります。
2件に共通するのは、メモリーや異常終了の扱いです。
メモリーは、処理に使う情報を一時的に置く作業場所と考えると理解しやすいでしょう。
通常は、必要な情報を準備し、処理を終えたら片付けます。
途中でエラーが起きたときにも、この順序が安全に保たれる必要があります。
CVE-2026-109618では、メモリー不足による中断が、内部データの準備途中に割り込む場合があります。
その後の片付けで、不完全なデータを正しいものとして扱うことが問題です。
CVE-2026-109619では、解放したメモリーを指す古い内部状態が残り、同じ処理担当が次のリクエストを受けた際に使ってしまうおそれがあります。
受付担当が、前の来訪者の処理票を片付けたつもりで、その参照先だけを残してしまう状況に近いものです。
次の来訪者の対応で古い参照を使えば、別の情報を正しいものと取り違えます。
実際の攻撃はこの比喩より複雑ですが、通常のアクセスでも通る基礎部分の不整合が危険につながる、という関係です。
PHP Foundationの説明では、メモリー不足に関する問題の兆候は2024年に把握されていました。
しかし、具体的な攻撃経路が明確でなかったことに加え、互換性や性能への影響を伴う修正方針を決められず、対応が停滞しました。
同財団は意思決定と人員不足による構造的な失敗を認めています。
その後、Calif、OpenAI、Wizなどの報告によって攻撃の影響が明らかになりました。
AIを使った調査は、従来は検証に手間がかかった欠陥の発見を助けます。
一方で、発見された問題をどう直すか、既存システムを壊さないかを判断する作業は残ります。
ここから読み取れるのは、AIの導入だけで安全対策が完結するわけではないという点です。
発見が増えるほど、報告の検証、修正、配布まで処理できる保守体制が必要になると考えられます。
海外では政府関連のサイトなどが一時的に公開を停止しました。
EUの関係機関も共同で、PHP利用環境の洗い出しと迅速な更新を要請し、すぐに修正できない公開アプリケーションはネットワークから隔離することを検討するよう勧告しています。
国内でも金融機関や行政機関で一部サービスの停止が報じられています。
ロイターによると、三菱UFJ銀行は投資信託口座開設やNISA利用申し込みなどの一部手続きを停止し、厚生労働省や財務省も一部コンテンツを予防的に非公開としました。
10月22日午前の官房長官会見では、政府機関や重要インフラ事業者に関係する被害の報告は受けていないと説明されています。
この発言は、その時点で報告された範囲についての説明です。世界全体に被害がないという確認にはなりません。
また、サービス停止は安全確認や修正のための判断である場合があり、停止した組織を被害企業として扱うことも不適切です。
10月21日の更新公開を経て、現在は利用中の環境へ修正を届ける段階にあります。
WordPress公式も、ホスティング会社の更新案内を確認するよう促しています。
クラウドを使っていても、自分で用意したコンテナなどは再構築・再配備が必要になる場合があります。
一方、Cloudflareの観測を伝えたロイター報道では、脆弱性の公表後に攻撃の試みが急増したとされています。
この観測は攻撃の活発化を示しますが、試行件数を侵入成功件数に置き換えることはできません。
確認時点では、個々のサービスの復旧状況を一括して「収束」と判断できる段階ではありません。
利用者は各社の公式案内で、停止している機能と再開状況を確かめる必要があります。
サイト運営者は、サーバーの管理画面や保守契約からPHPの管理担当を確認してください。
WordPressの場合、「ツール」→「サイトヘルス」→「情報」→「サーバー」でPHPバージョンを確認できます。
表示された番号は、サーバー会社へ問い合わせる際の手掛かりになります。
更新先は使用中の系列に合わせます。下表は10月21日に公開された修正バージョンです。
Linuxなどの配布元が、元のバージョン番号を大きく変えずに修正を取り込む「バックポート」を提供している場合もあります。
番号だけで未対応と決めず、2件のCVEへの対応を告知で確認しましょう。
PHP公式は7.4・8.0・8.1向けに最小限のソース修正も提供していますが、通常サポートの再開ではありません。
サーバー会社には、対象ドメインのPHP環境が2件とも修正済みか、未対応ならいつ適用するか、完了までどのように公開範囲を制限するかを尋ねると状況を把握できます。
「最新版です」という回答だけなら、どの修正を含むパッケージなのか確認すると判断しやすくなります。
すぐに対応できない公開環境は、担当者と隔離や一時停止を検討します。
CMS上のメンテナンス表示では裏でPHPが動き続けることもあるため、実際に外部から処理へ到達できなくなったかの確認が必要です。
WAFも防御を補助しますが、修正済みPHPへの更新を置き換えるものとして扱うべきではありません。
更新作業ではバックアップと互換性確認を行い、公開中の環境を優先して対応します。
中級者が見落としやすいのは、コマンドラインで確認したPHPと、ウェブサーバーが使うPHPが異なる場合です。
複数の実行環境、別サーバー、検証用サイトも含め、稼働している実体を確認する必要があります。
適用後は必要なプロセス再起動や再配備を完了し、ログイン、問い合わせ、決済など主要機能を点検してください。
加えて、不審なファイル、管理者アカウント、外向き通信などを確認します。
更新は新たな悪用を防ぐための作業であり、すでに侵入されていた場合の調査・復旧は別に必要となります。
今後想定されるのは、更新が遅れた環境を狙う攻撃や、当初気付かなかった侵入の発覚です。
これは起こりうる展開であり、すべてのPHPサイトで被害が発生すると確認されたわけではありません。
特に、旧キャンペーンサイトや公開したままの検証環境は、日常の更新対象から外れやすくなります。
本番を直しても、古いコンテナイメージから再配備すれば未修正環境が戻る可能性があります。
更新した対象と時刻、使用したパッケージ、確認担当を残しておくと、後から原因を切り分けやすくなります。
また、サーバーが別のサービスへ接続する認証情報を持っていれば、侵入時の影響はその範囲にも及びえます。
認証情報の交換は、漏えいの可能性や調査結果に応じて判断し、変更先のサービスとの連携も確かめる必要があります。
担当者は、通常と異なるエラーやプロセス停止、不審なファイル生成、見覚えのないアカウントなどを合わせて確認します。
一つのエラーだけで侵入と断定せず、アクセス履歴や変更時刻を照合することで、誤認と見落としを減らせます。
異常が見つかった場合は、証拠となるログを確保してから保守会社や専門家へ相談してください。
経過を追う際は、PHP公式の追加告知、利用中の配布元・サーバー会社の修正状況、各サービスの復旧案内を確認します。
復旧を急ぐ場合でも、再開できたことと安全確認を終えたことは別の判断として記録するとよいでしょう。
今回の出来事からは、AIで欠陥を見つける速度が上がるほど、利用環境を把握し短時間で更新できる運用の価値が高まると考えられます。
脆弱性が出てから担当者を探す体制では、修正版が用意されても適用まで時間がかかります。
サイト運営者が持ち帰るべき判断軸は、「PHPを使っているか」「誰が更新するか」「稼働環境への適用と点検を確認できたか」です。
まず管理画面や保守会社から現状を確認し、対応完了の根拠を残してください。
サービスの利用者は、停止のニュースだけで情報流出を判断せず、自分が利用する機能の公式案内を確認しましょう。
被害に関する通知が出た場合は、その対象と必要な手続きに沿って行動することが、混乱を避ける近道です。
.png){kind=logo}
