2026年10月21日、PHPの重大な脆弱性への対応を巡り、国内ではサービスの一時停止や終了が告知され、高市早苗首相も同日夜に「大至急」の準備を呼びかけた。しかし、修正版を公開するPHP開発元、稼働中のPHPを更新する事業者、アプリを保守する運営者は、必ずしも同じではない。サービス提供者が利用者の作業なしで修正を完了した例がある一方、古いシステムでは十分な対策を取れないとして、サービス終了を決めた例もある。修正版が公開されても、適用からサービス再開までの対応が一様に進まないのはなぜなのか。

AD

23時の修正を待つ間に、サービスを止めるという判断

高市首相は21日夜のX投稿で、PHPの利用状況を確認し、同日23時（日本時間）に公開予定の修正パッチを速やかに適用できるよう準備することを求めた。すぐに適用できない場合は、サイトを一時停止することもリスクを下げる手段になると説明している。修正前の状態でサービスを動かし続けるよりも、外部から攻撃を受ける可能性を減らすことを優先するよう促した形だ。

今回の問題が深刻なのは、サイトへのログインを必要とせず、外部から攻撃されるおそれがあるためだ。PHP開発元の告知によると、脆弱性を悪用されると、認証なしで遠隔からサーバー上のコードを実行される可能性があり、Webリクエストを処理するPHPの構成が影響を受ける。PHPはWebアプリなどをサーバー上で動かすための実行環境であり、サイト運営者がパスワードを変更したり、訪問者がブラウザーを更新したりしても、PHP本体の脆弱性は解消されない。開発元は21日、PHP 8.5.12、8.4.27、8.3.36、8.2.35を公開し、直ちに更新するよう強く推奨した。アプリ側の修正だけで対処を終えるのではなく、実際にWebリクエストを処理しているPHPに修正を適用する必要がある。

国内では、野村インベスター・リレーションズが21日22時からのサービス停止を告知した。対象は「MIR@I」と機関投資家・アナリスト向けIR情報配信サービスで、PHPの重大な脆弱性に対応するため、修正プログラムの適用と安全性の確認を行うとしている。再開時刻は定めず、安全が確認できるまで停止を続ける方針を示した。修正版の公開前にサービスを止めるのは、修正と検証が終わるまで攻撃を受ける可能性を減らすためであり、矛盾した対応ではない。また、サービスが停止したという事実だけで、すでに不正侵入を受けた、あるいは更新に失敗したと判断することもできない。

米国のサイバーセキュリティ・社会基盤安全保障庁（CISA）も21日の注意喚起で、直ちに更新できない組織や、PHP 8.1以前のサポート終了版を利用している組織に対し、修正や更新が完了するまでPHPを使用するシステムをオフラインにするよう求めた。一方、同庁は発表時点で脆弱性の悪用を観測していないとも説明している。つまり、サービス停止は必ずしも被害の発生を意味せず、被害を防ぐための予防措置でもある。ただし、各事業者が首相の投稿を受けて停止を決めたかどうかは、個々の告知からは判断できない。同じ夜に呼びかけとサービス停止が相次いだとしても、両者に直接の因果関係があったとは限らない。

同じサービス停止でも、原因は異なる

今回のPHP修正版が公開される前から、サービスを停止していた企業もある。ソフトバンクの19日付発表によると、同社は一部システムへの第三者による不正アクセスの試みを確認し、17日午前8時から「My SoftBank」などのWebサイトを一時停止した。一方、アプリ版は引き続き利用できると説明している。停止の理由として公表されたのは不正アクセスの試みであり、今回のPHPの脆弱性との関係は示されていない。

マネックス証券も、外部委託先が管理する口座開設システムに対し、不正なアクセスを試みた形跡があったとして、19日から一部の口座開設受付を停止した。20日に公開され、21日に更新された告知では、対象は当該システムを経由する証券総合取引口座の新規開設申し込みに限られると説明している。同社によれば、口座開設の申し込みや事務処理を担うシステムと、開設後の口座情報、残高、取引を管理するシステムは別のものだ。したがって、新規口座開設の受付停止を、証券取引サービス全体の停止と捉えるのは正確ではない。また、同社の告知も今回のPHPの脆弱性との関連を示しておらず、発表日と実際の停止開始日も異なる。

脆弱性との関連について、当初の説明が訂正された例もある。バルテックの訂正文では、情報流出の原因をPHPの脆弱性を狙った攻撃とした第一報について、誤報だったと明言している。実際には同社サービス自体の脆弱性を突かれた事象であり、別途進めていたPHPへの対応と混同したという。したがって、この事例を今回のPHPの脆弱性が悪用された被害として扱うことはできない。

これらの事例は、企業がリスクを抑えるためにサービスへのアクセスを制限したという点では共通している。しかし、すでに確認された不正アクセスの試みへの対処と、新たに公開される脆弱性の修正に備えた停止では、再開に必要な作業が異なる。前者ではアクセスの状況や影響範囲を調査する必要があり、後者では修正プログラムの適用と安全性の確認が中心となる。バルテックの訂正やソフトバンク、マネックス証券の発表を踏まえれば、同時期に起きたサービス停止を、今回のPHPの脆弱性による被害として一括して数えることはできない。また、停止件数だけで企業の更新対応が遅れていると評価するのも適切ではない。早期に停止を決断した結果、一時的に利用できなくなったサービスもあるためだ。

AD

レンタルサーバーで異なるPHP更新の担当

さくらのレンタルサーバのPHP提供ポリシーでは、新しいPHPの系列を提供しても、利用者が設定している旧系列は原則として維持すると説明している。PHPの系列を変更すると、既存のアプリが正常に動かなくなる可能性があるためだ。同社は利用者に対し、アプリの推奨動作環境を調べ、対応するPHPの系列を確認するよう求めている。PHPの更新を一律に進められない背景には、こうした互換性の問題がある。

ここで区別すべきなのが、現在使用しているPHPへのセキュリティ修正と、PHPの系列そのものを変更する作業だ。前者は既存の実行環境の脆弱性を解消するもので、後者はアプリを別のPHP系列へ移行する作業となる。旧系列の利用を維持する方針だからといって、緊急のセキュリティ修正まで利用者がすべて手動で適用しなければならないわけではない。さくらが22日に公表した対応状況では、コントロールパネルから選択できるすべてのPHPバージョンについて対応を完了し、利用者による緊急の作業は不要だと明記している。同時に、今後もセキュリティを維持するため、サポート期間中の最新版への移行を検討するよう案内した。今回の脆弱性を修正する作業と、旧版から新しい系列へ移行する作業を分けているのである。

同様に、Movable Typeでも提供形態によって対応が異なる。シックス・アパートの21日付案内によると、クラウド版では提供者がPHPの修正版公開後に更新を実施する一方、ソフトウェア版とAMI版では利用者にPHPの更新を強く推奨している。さくらのレンタルサーバとMovable Typeの案内を比較すると、今回の対応で誰がPHP本体の更新を担うのかが分かる。

提供形態 PHP本体の更新を担う主体 利用者に求められる対応
さくらのレンタルサーバ 事業者が選択可能な全PHP版への対応完了を告知 今回の緊急作業は不要。ただし、新しいPHP系列へ移行する際にはアプリの動作確認が必要
Movable Typeクラウド版 提供者が修正版公開後に更新を実施すると予告 今回の更新に伴う利用者作業は不要。自動アップデートを無効にしている環境も対象
Movable Typeソフトウェア版・AMI版 利用者側でPHPの更新を実施 自分の運用環境に合わせて更新を手配する必要がある

この表は、各社が今回公表した対応の分担を整理したものであり、すべてのホスティングサービスに当てはまるわけではない。さくらの対応完了は、レンタルサーバーの利用者が必ずしも自ら緊急更新を行う必要はなく、更新が遅れるとも限らないことを示している。提供事業者が修正を一括して適用すれば、利用者ごとにPHP本体を更新する必要はない。

一方、同じMovable Typeでも、クラウド版とソフトウェア版・AMI版では利用者の役割が異なる。製品名だけでは誰がPHPを更新するのか判断できず、契約している提供形態と、事業者が管理する範囲を確認する必要がある。クラウド版では、自動アップデートを無効にしている環境も今回の対応対象とされており、通常の更新設定と緊急時の対応範囲が必ずしも一致しないことも分かる。また、サーバー側の修正が完了したからといって、アプリがどのPHP系列でも正常に動作する保証はない。事業者が管理するPHPの実行環境と、利用者が運用するアプリの互換性は、相互に関係しながらも別々に保守する必要がある。

EOL版に修正があっても、通常の保守が再開するわけではない

PHP開発元は今回、通常のサポートが終了したPHP 7.4、8.0、8.1に対しても、最小限のソースコード修正を用意したと発表した。自らソースコードをビルドして利用する人や、長期サポートを提供する事業者を利用できない人を支援するための措置だ。そのため、サポートが終了した古いPHPには修正が一切提供されない、という理解は正確ではない。ただし、修正済みのソースコードが公開されることと、契約中のサーバーにそのまま適用できる更新パッケージが提供されることは別の問題だ。ソースからビルドする場合は、その作業と運用環境への導入を担う主体が必要になる。共有サーバーの利用者など、自分でPHP本体を管理する権限がない場合、ソースコードを入手しただけでは修正を適用できない。

PHP開発元のサポート方針では、各系列に通常のサポートを2年間提供し、その後さらに2年間、重大なセキュリティ問題への対応を続ける。合計4年間のサポート期間が終わると、EOL（End of Life、サポート終了）を迎える。PHP 8.1以前の系列は、すでにこの通常の更新対象から外れている。ただし、PHP開発元は、一部のLinuxディストリビューションや長期サポート事業者が、旧版にセキュリティ修正を移植して提供する場合があるとも説明している。今回の修正内容も配布元に事前提供されており、利用者には各ベンダーの更新パッケージを確認するよう案内した。

したがって、PHP開発元によるサポートが終了しているという理由だけで、個々のサーバーが今回の脆弱性に対して未修正だとは断定できない。重要なのは、実際に稼働しているPHPをどの事業者が供給し、その環境に今回の修正が適用されたかという点だ。上流の新しいPHP系列へ移行する方法と、配布元が旧系列に修正を移植する方法では、更新の仕組みが異なる。PHPのバージョン番号だけでなく、利用している環境への修正適用状況を確認する必要がある。

一方、今回特別にソースコードの修正が提供されたからといって、旧系列の通常サポートが再開されたわけではない。次に別の脆弱性が見つかった場合も、同様の措置が取られる保証はない。今回の緊急修正で当面の危険を減らすことと、継続的に保守されるPHP系列へ移行することは、別々に進めるべき課題である。さくらのPHP提供ポリシーでも、セキュリティサポートが終了した旧版を引き続き提供する場合がある一方、重大な脆弱性が判明した場合は予告なく提供を終了することがあると説明している。古いアプリを動かせる期間が延びたとしても、将来の脆弱性に対する修正手段まで保証されるわけではない。

AD

古いシステムを、誰が保守し続けるのか

ワールドクエストは21日、サービスを同日付で終了すると発表した。PHPの深刻な脆弱性が発表されたことを受け、古い仕組みで動いているため十分な対策を取れず、利用者の情報を守ることを優先したと説明している。一時停止して修正後に再開するのではなく、サービスの継続そのものを断念した例だ。ただし、告知ではPHPのバージョンやサーバーの契約内容、保守契約の状態などは明らかにされていない。そのため、特定の旧版PHPやレンタルサーバーの利用、保守契約の終了が直接の原因だったと断定することはできない。公表された情報から分かるのは、運営者が既存のシステムでは十分な対策を取れないと判断したことまでである。

アプリの保守状況は、PHP本体のサポートとは別に確認する必要がある。例えば、Movable Typeの製品ライフサイクル方針では、EOLを迎えた製品について、メンテナンスやバグ修正、セキュリティパッチの提供など、すべての対応を終了すると定めている。クラウド版を除けば、EOL後も製品を使い続けること自体は可能だが、セキュリティリスクが残るため、同社はEOL前に現行版へ移行するよう強く推奨している。また、同社は通常のメンテナンスを終了するEOM（End of Maintenance）と、すべてのサポートを終了するEOLを区別している。EOM後も重大なセキュリティ問題には同社の判断で対応する場合があるが、EOLになるとそうした対応も終了する。現在もサイトが正常に動いているというだけでは、保守を受けられる製品かどうかは分からない。

同方針では、年間メンテナンスを継続していれば、EOMを迎えた版を利用していても、アップグレードに関するサポートを受けられるとしている。保守契約は、現在のバージョンを使い続けるためだけでなく、新しい版へ移行する際の支援にも関わる。実際にどこまで支援を受けられるかは、製品のサポート期限と契約条件を合わせて確認しなければならない。

PHP本体とアプリの保守期限が異なれば、必要な対応も変わってくる。PHPの修正版が提供されていても、アプリを新しいPHP系列に対応させるための改修が必要な場合、その作業をPHP開発元が引き受けるわけではない。さくらがPHP系列の変更前にアプリの動作環境を確認するよう求めているのも、この互換性を利用者側で確かめる必要があるためだ。つまり、PHPのセキュリティ修正とアプリの改修は、担当者も作業内容も異なる場合がある。

「保守切れ」という言葉も、PHP開発元によるサポートの終了、アプリ製品のサポート終了、個別に結んだ保守委託契約の終了を区別する必要がある。PHPやアプリ製品のサポート期限は開発元の公開情報から確認できるが、個別の保守委託契約については契約内容を調べなければ分からない。今回サービスを停止した企業について、こうした契約が切れていたと一律に推測することはできない。

緊急パッチが公開されても、古いシステムの移行やアプリの改修まで自動的に解決するわけではない。PHP本体の更新担当者が決まっていても、アプリの改修と動作確認を誰が担うのか明確でなければ、サービスを安全に再開する判断は難しくなる。ワールドクエストの事例から内部事情の詳細を推測することはできないものの、十分な対策を取れないと判断した場合、サービスの継続を断念する選択もあり得ることを示している。

サービス再開の判断に必要な情報

情報処理推進機構（IPA）の事前告知では、PHPがWebアプリだけでなく、ソフトウェア製品やネットワーク機器の内部でも使用される場合があると説明していた。こうした製品では、利用者がPHPの使用状況を把握できないこともある。IPAは、マニュアルや製品提供元のセキュリティ情報を確認し、把握できる範囲で利用状況を洗い出すよう求めている。ただし、利用中のすべての製品についてPHPを使用しているか個別に確認することまでは求めておらず、判断できないものは提供元の情報を注視するよう案内した。利用者が自ら確認できる範囲と、製品提供者の対応を待つ必要がある範囲を区別した説明である。

企業が対応を進める場合も、PHPを使用しているシステムの一覧を作るだけでは十分ではない。さくらやMovable Typeの事例が示すように、同じPHPでも提供形態によって更新を担う主体が異なるためだ。各システムについて、実行環境を提供する事業者と、実際に更新作業を担当する組織や担当者を明らかにする必要がある。そのうえで、今回の修正を適用すればよいのか、別のPHP系列への移行も必要なのかを判断する。PHP本体の修正が完了しても、系列変更に伴うアプリの互換性確認まで終わったとは限らない。反対に、さくらのように提供者が緊急対応を完了したと明示している環境では、利用者が独自にPHP本体を修正する必要はない。

経営側が把握すべきなのは、停止したサイトの数だけでなく、それぞれのサービスを再開するために何が残っているかという点だ。PHPの修正適用を待っているのか、アプリの移行と動作確認が必要なのか、それとも別の不正アクセスの試みを調査しているのか。同じサービス停止でも、再開を左右する作業と担当組織は異なる。首相の呼びかけは更新準備を急ぐ必要性を広く伝えたが、個々のシステムの管理権限や保守契約の範囲を変えるものではない。

重要なのは、修正プログラムを入手するだけでなく、PHP本体の更新とアプリの確認を誰が担い、どの条件を満たせばサービスを再開できるのかを明確にすることだ。緊急時に初めて担当者や契約範囲を調べるのではなく、平時から更新と動作確認の責任分担を定めておく必要がある。次の「大至急」の対応を確実に進められるかどうかは、こうした日常の保守体制にかかっている。