PHP重大脆弱性で銀行・通信停止、復旧後も残る侵害調査の課題

PHP欠陥が社会インフラ停止へ波及した背景

プログラミング言語PHPの中核部分に二つの重大な脆弱性が見つかり、10月21日の修正版公開を挟んで、銀行、通信、行政、SaaSが相次いでウェブ機能を止めました。多くは攻撃で壊れた「障害」ではなく、侵害を避けながら更新と動作確認を進めるための予防停止です。

Cloudflareによると、PHPは約7割のウェブサイトで利用されています。22日には、みずほ銀行の来店予約や静岡銀行のネットバンクアプリなどが再開しましたが、外部委託先や防災配信を含むシステムでは影響が長引きました。

今回の焦点は、サービスが戻ったかだけではありません。なぜアプリの種類を問わず危険だったのか、復旧後にどこまで遡って侵害を調べるべきかを理解する必要があります。

認証前RCEを招く二つのメモリ安全性欠陥

メモリ不足時に壊れるリクエスト処理

対象はCVE-2026-109618とCVE-2026-109619で、いずれもCVSS v4.0で9.2の「緊急」に分類されました。PHP公式のアドバイザリによると、前者はHTTPリクエストの処理中にメモリ不足が起きると、PHP内部のデータが初期化途中のまま処理を中断し、後始末で不正なデータを正しいものとして扱う欠陥です。

細工した大きなリクエストなどでメモリを圧迫されると、プロセス停止だけでなく、メモリ破壊から任意コード実行へ進む恐れがあります。認証やログインの前に攻撃が成立し得るため、強固なパスワードや多要素認証だけでは防げません。

重要なのは、WordPressのプラグインや銀行アプリ固有の欠陥ではない点です。問題はPHPランタイム自体にあり、Wizの調査では、最新のWordPress、Drupal、Joomla環境でログイン前の遠隔コード実行が実証されました。パスワード、トークン、APIキーなど、PHPプロセス内の機密情報を読み取れる経路も確認されています。

次の通信へ残る解放済みメモリ参照

後者では、致命的エラーでリクエストが中断した後も、解放済みメモリへの参照がPHPの内部状態に残ります。同じワーカープロセスが次の通信を処理した際、その古い参照をたどることで、情報漏えいやメモリ破壊が起こり得ます。

PHP公式はPHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなど、ウェブ要求を処理する全構成を対象に挙げています。アプリのコードが動く前に攻撃できる実証例があるmod_phpは、特にリスクが高い構成とされました。

恒久対策はPHP 8.5.12、8.4.27、8.3.36、8.2.35への更新です。8.1以前はPHP本体のサポートが終わっており、配布元や長期サポート事業者のバックポートを確認するか、対応版へ移行する必要があります。

アップロード制限やWAFは攻撃面を狭めますが、全経路を塞ぐ保証はありません。WordPress.orgも、WordPress本体の更新ではなく、稼働基盤のPHPを更新する必要があると案内しています。

銀行・通信・行政を横断した予防停止の連鎖

決済中枢と周辺ウェブ機能の切り分け

金融分野では影響の大きさを、銀行システム全体の停止と混同しないことが重要です。時事通信の報道によると、三菱UFJ銀行は一部のインターネット取引を止め、みずほ銀行は臨時メンテナンスを実施しました。みずほ銀行の来店予約や静岡銀行のネットバンクアプリは22日に再開しています。

地方銀行でもアプリやカード申し込みが止まる一方、全国銀行協会は国内ほぼ全ての金融機関をつなぐオンラインシステムに影響がないことを確認しました。預金勘定や銀行間決済まで全面停止した事象ではなく、主にインターネット上の申し込みや照会など、周辺機能で予防停止が広がった形です。

auじぶん銀行は23日0時20分に自社の対応作業を終え、同日16時40分時点で関連する不正アクセスや情報漏えいは確認されていないとしました。ただし、委託先のメンテナンスによる一部問い合わせ機能の停止予定は、26日正午まで延長されました。自社が直っても、SaaSやコールセンターなど依存先の復旧を待つ構造が見えます。

連携サービスにも波及しました。Moneytreeは自社システムへの直接影響はないものの、金融機関側の停止に合わせ、21日21時45分ごろから三菱UFJ系や複数の地方銀行系カードのデータ取得を止めました。23日の更新でも再開時期は未定であり、復旧状況は会社単位ではなく、機能単位で見る必要があります。

通信事業者で長引いた防災情報の停止

ソフトバンクはPHP対応で停止したワイモバイルとLINEMOの公式サイトを22日17時30分に再開しました。一方、緊急速報メールでは、地震速報と津波警報を25日9時25分に再開した後も、国や自治体が送る災害・避難情報の停止が続き、26日の作業完了を予定していました。

NTTドコモも同種の防災情報配信を予防的に停止しましたが、25日20時1分にメンテナンスを終えて再開しています。通信回線そのものではなくても、災害時の情報伝達という社会的に重要な周辺サービスへ影響が及んだ点は軽視できません。

法人向けホスティングでは、NTTドコモビジネスが22日18時32分までに全利用者のウェブサービスを再開し、PHPを8.3系最新版へ変更しました。同社は旧版へ戻せず、更新後にサイトの動作が変わる可能性も注意喚起しています。停止時間を短くするだけでなく、互換性試験まで含めた復旧計画が不可欠です。

行政でも東京都が一部サービスを予防停止し、22日時点で都と区市町村、政策連携団体などへの被害は確認していないと説明しました。「被害が出たから停止した」のではなく、「被害を防ぐために止めた」事例が中心です。

復旧後に残る侵害調査と旧版移行の難題

パッチを適用して画面が表示されても、過去の侵害が否定されたわけではありません。AWSの脅威情報では、公開4日前の10月17日に、匿名化ネットワークからPHP2Shellの悪用を試みる通信がハニーポットで観測されました。

公開当日にも異なる基盤から複数の試行があり、修正版公開後は概念実証コードが数時間で現れたといいます。ログ調査は21日の公表時点ではなく、少なくとも17日まで遡るのが妥当です。

確認対象は、不審なPOST要求だけでは足りません。PHPワーカーからの予期しない子プロセス、ウェブ領域のファイル変更、新規アカウント、認証情報の利用履歴、外向き通信まで突き合わせる必要があります。侵害の兆候があれば、APIキーやセッショントークンの失効・再発行も検討します。

もう一つの難題は旧版です。IPAは、更新できない理由としてアプリ改修、資料や担当者の不在、保守契約終了を挙げ、継続体制を確保できなければ機能縮小や廃止も検討するよう求めました。

AIで脆弱性発見と攻撃コード化が速まる局面では、月次や週次の更新目標だけでは遅すぎます。インターネット公開資産は、緊急時に時間単位で隔離・更新できる設計へ改める必要があります。

経営者が直ちに確認すべき三つの備え

第一に、公開サイトだけでなく、製品に内蔵されたPHP、委託先、古いキャンペーンページまで資産台帳へ載せます。第二に、修正版の稼働を実機で確認し、10月17日以降のログと端末・クラウドの検知情報を横断して調べます。第三に、停止時の代替導線、利用者への告知、防災・決済など重要機能の切り離しを手順化します。

一般利用者が端末のPHPを更新する必要は通常ありません。公式サイトで復旧状況を確認し、障害に便乗した更新要求や再認証メールには反応しないことが現実的な備えです。

運営側は「止めないこと」だけを目標にせず、安全に止め、検証して戻せる能力を平時から整えるべきです。今回の連鎖停止は、ソフトウェア資産の可視化と事業継続計画を同じ経営課題として扱う転機になりました。

参考資料:

• PHP公式「Security advisory: Critical remote code execution vulnerabilities」
• IPA「PHPの脆弱性対策について」
• Wiz「PHP2Shell: AI uncovers critical RCE vulnerabilities」
• AWS「PHP2Shellの脆弱性公開前の悪用をMadPotで特定」
• Cloudflare「php2shell vulnerabilityへの保護策」
• ENISA「Joint statement on critical PHP vulnerabilities」
• WordPress.org「Critical PHP Security Release」
• 時事通信「PHP欠陥、広がるサービス停止」
• auじぶん銀行「PHPの脆弱性への対応について」
• Moneytree「一部クレジットカード等のデータ取得の一時停止」
• ソフトバンク「公式サイトのメンテナンスについて」
• ソフトバンク「緊急速報メールの配信停止について」
• NTTドコモ「エリアメールの一部サービス配信再開」
• NTTドコモビジネス「Webサービス一時停止と再開」
• 東京都「PHPの重大な脆弱性に対する対応について」