PHPの脆弱性で、なぜ数日たっても復旧できないのか――長期停止を招く5つの理由
PHPの重大な脆弱性への対応で、Webサービスの停止が相次いでいます。数日たっても再開できない理由は、単に「修正プログラムの適用に時間がかかる」ことだけではありません。
古いシステムを、安全に更新できる状態に保てているか。今回の対応では、この問題が事業継続に直結しています。
本記事では、2026年10月24日に確認した公式発表を基に、判明している事例と、一般的に復旧を難しくする要因を分けて整理します。各社の状況は更新されるため、利用中のサービスについては最新のお知らせをご確認ください。
復旧が長引く主な5つの理由
以下は復旧を難しくする一般的な要因です。停止中のすべての企業に、すべてが当てはまるという意味ではありません。
要因 | 何が起きるか | 復旧時に必要な対応 |
古いPHPやOS | 利用環境に適した修正が得られない場合がある | 修正版の調達、PHPやOSの移行 |
更新による互換性問題 | 既存のプログラムが動かなくなる可能性がある | プログラムの改修と動作確認 |
複雑なシステム構成 | 影響する機能や連携先が多い | 対象の洗い出しと個別の検証 |
侵害の有無の調査 | 攻撃を受けた可能性がある場合、更新だけでは判断できない | ログなどの確認と必要な復旧措置 |
安全確認と再開判断 | 修正後も業務上の正常動作を確認する必要がある | テスト、関係者の確認、再開の判断 |
特に、古い環境で修正の適用が難しい場合、セキュリティ対応がシステム移行や改修を伴う作業になり、停止が長引く可能性があります。
公式発表から分かる、復旧が難しい具体例
BUSINESSぷらら：旧環境ではPHPの変更を伴う対応に
BUSINESSぷららは、10月23日更新のお知らせで、CentOS 6環境にあるPHP 7.2・5.6・5.3・5.1について、対策パッチがないためPHP 7.4に変更し、パッチを適用してWebサービスを再開する方針を示しました。パッチ適用と再開の日程は調整中としています。
ここで注意したいのは、PHP 7.4に変更するだけで対策が完了するわけではないことです。同社の方針は、変更後に脆弱性対策パッチを適用するというものです。
一般に、PHPのバージョン変更では互換性の確認が必要です。データベース接続、ログイン、決済、メール送信など、利用している機能に応じた再テストが生じます。これは一般的な技術上の説明であり、同社がこれらすべてを停止理由として発表したわけではありません。
東京科学大学：対応できる環境と、停止を続ける環境に差
Science Tokyo NOCの10月22日の追記では、WWWサーバ代行サービスのうち、web-o2のPHP 7.2系・7.4系は対応不可とされ、同サーバのサービス停止が案内されています。一方、他の対象サーバでは修正を適用し、サービスを再開しています。
同じ組織でも、稼働環境によって対応が分かれることが分かります。ただし、この事例をもって、すべてのPHP 7.4環境で修正が不可能だとは言えません。
今回の脆弱性「PHP2shell」とは
PHP公式は10月21日、認証なしの遠隔コード実行につながり得る2件の重大な脆弱性、CVE-2026-109618とCVE-2026-109619に対する修正版を公開しました。これらは「PHP2shell」と呼ばれています。
公表された修正版はPHP 8.2.35、8.3.36、8.4.27、8.5.12です。公式は、完全な解決には更新が必要であり、暫定的な設定変更だけでは安全を確保できないと説明しています。
古いバージョンでも、OSの配布元や長期保守の提供元による修正が利用できる場合があります。単にバージョン番号だけで判断せず、提供元の対応状況を確認することが必要です。
IPAも更新を呼びかけています。すぐに対応できない場合は暫定対策を検討し、それが難しい場合は、被害や業務への影響を踏まえてアクセス遮断や一時停止の要否を判断するよう案内しています。
なお、PHP公式は10月23日、セッションのアップロード進捗機能に関する追加情報も公表しています。実際の対策では、21日の修正情報に加えて、その後の案内も確認してください。
再開した企業・組織もある
すべてのサービスが長期停止しているわけではありません。以下は、確認した各発表に記載された状況です。
企業・組織 | 発表時点の状況 |
TKC（10月23日発表） | 会計事務所向けの一部を除き、休止したサービスを再開 |
日本特許情報機構（10月22日発表） | 対象サービスとホームページを再開 |
BUSINESSぷらら（10月23日更新） | 対象環境のパッチ適用・Webサービス再開日程を調整中 |
フェローズ（10月22日12時30分更新） | コーポレートサイトを再開。お仕事情報サイトなどは停止継続と案内 |
サービス停止は、不正アクセスや情報漏えいの発生を意味するものではありません。予防のために停止する場合もあります。停止状況と被害の有無は、分けて読む必要があります。
私が今回、特に問題だと考えること
今回の事例は、脆弱性そのものに加えて、長年積み重なった「技術的負債」が事業継続に影響することを示唆しています。技術的負債とは、先送りした更新や改修が、後になって大きな対応負担として表れることです。
古いシステムを使い続けると、重大な脆弱性が見つかった際に、停止を続けるか、短期間で移行や改修を進めるかという難しい判断を迫られます。担当者や資料が不足していれば、判断や検証にも時間がかかります。
ただし、今回の事例だけで「古いPHPを使う企業は必ず数日停止する」「日本のWebシステム全体が更新できない」と結論づけることはできません。修正の提供状況、構成、更新体制によって対応は異なります。
これから重要になるのは、重大な脆弱性が見つかったときに、どれだけ短時間で安全に更新し、業務を再開できるかです。
これはセキュリティ対策であると同時に、事業継続計画（BCP）の問題でもあります。
企業が今、確認しておきたいこと
PHPやOSの利用箇所、バージョン、保守の提供元を把握しているか。
修正情報を受け取り、適用を判断する担当者が決まっているか。
更新を試せる検証環境と、主要機能の確認手順があるか。
停止時の代替手段、利用者への案内、再開の判断基準が決まっているか。
サポート終了前に移行するための予算と計画があるか。
企業にとってのリスクは、脆弱性が見つかることだけではありません。見つかった脆弱性を、速やかに修正できない状態が続いていることにも目を向ける必要があります。
おそらく、今回のような事件はこれで最後ではありません。AIの進化に伴い、今後はより大規模化、高頻度化するでしょう。それに対応するためには、エンジニアの大幅増強や、エンジニア、経営判断を行える人材を「3交代勤務」で待機させることも必要かもしれません。
※情報確認日：2026年10月24日。事例は各公式発表時点の内容です。実際の対応やサービスの利用可否は、提供元の最新情報をご確認ください。
コメント