PHPに「インターネット級」の高危険度脆弱性が発覚、Web3の「オフチェーンの弱点」はどう補うべきか？

この記事を読むのに必要な時間は 29 分

PHPはCVSS 9.2のリモートコード実行脆弱性2件を緊急修正、バージョン5.4から8.5.11に影響、詳細は事前に漏洩し既に悪用されている。暗号資産業界のドメインの約53%がPHPを使用しており、Web3プラットフォームは早急にアップグレードする必要がある。

原文タイトル：「PHPが"インターネット級"の高危険度脆弱性を露呈、Web3の"オフチェーンの弱点"はどう補うべきか？」
原文著者：SlowMistセキュリティチーム

何が起きたのか

10月21日、PHPプロジェクトは緊急セキュリティアップデートをリリースし、未認証のリモートコード実行(RCE)を引き起こす可能性のあるCVE-2026-109618とCVE-2026-109619の2つの重大な脆弱性を修正した。両者はいずれもCVSS v4.0で9.2点と評価されている。PHP公式は明確に、修正前は外部にWebサービスを提供するすべてのPHPインストールが影響を受ける可能性があると述べている。

10月20日、脆弱性の詳細は公式開示の前にすでに漏洩しており、パッチはまだリリースされていなかった。PHPセキュリティチームは緊急バージョンを当初予定の10月22日から10月21日14:00 (UTC)のリリースへと前倒しせざるを得なかった。

さらに警戒すべきは、攻撃が開示よりも早かった可能性があることだ。Amazon脅威インテリジェンスチームは、10月17日の時点で自社のMadPotハニーポットネットワーク内でphp2shellに対する悪用の試みを観測しており、公開開示より4日早かったと報告している。

SlowMistもPHP公式の予告発表後、いち早くセキュリティリマインダーと推奨事項を発信した。

2つの脆弱性とはそれぞれ何か

CVE-2026-109618（OOMメモリ破損）：PHPのメモリが枯渇すると処理フローが中断され、その時点で手元のデータは半分しか準備されていない状態になる。後片付けのクリーンアップ時に、PHPはこれらの半成品を完全なデータとして扱ってしまい、その結果メモリが混乱する。

CVE-2026-109619（古いグローバル状態）：1つのリクエストの処理が終わり、メモリはすでに解放されているが、関連する状態は「そのままの場所に」残っている。同じワーカープロセスが次のリクエストを引き継ぐ際、正常な初期化の前にこの期限切れの状態を使ってしまう可能性がある。公式は、これを利用してPHP-FPMを攻撃しリモートコード実行を実現できることを確認している。

攻撃経路から見ると、この種の脆弱性の危険な点は、攻撃者がまずサイトのアカウントを取得する必要がなく、ビジネス層のログイン、権限、API Key 認証を突破する必要もないことです。インターネットに公開された PHP アプリケーションに細工されたリクエストを1つ送るだけで、Web サービスプロセスの権限で任意のコードを実行できる可能性があります。

影響範囲：PHP 5.4 から 8.5.11 がすべて影響を受けます。修正バージョンは 8.5.12、8.4.27、8.3.36、8.2.35 です。PHP 8.1 およびそれ以前のバージョンは上流の通常サポートが終了しており、通常のチャネルでパッチが提供されることは期待できません。サポートが継続しているバージョンへ移行すべきです。

なぜ世界中が緊張しているのか？

なぜなら PHP があまりにも普及しているからです。W3Techs の統計によると、サーバー言語を識別できる Web サイトのうち 69.3% が PHP を使用しています。WordPress、WooCommerce、Magento といった馴染みのあるシステムは、その基盤がすべて PHP です。

各国の反応も問題の深刻さを示しています。オランダ国家サイバーセキュリティセンターは予防的に Web サイトを閉鎖しました。韓国大統領府は緊急サイバーセキュリティ会議を開催し、政府はサイバーセキュリティ警報レベルを引き上げました。

また、報道によると、北朝鮮のほぼすべての公式 Web サイト（公式メディアや政府ポータルサイトを含む）が 24 時間以上オフラインになっており、現時点ではこの脆弱性事件との関連は不明です。

Web3 への影響

これは従来の Web サイト運用だけの問題ではありません。Web3 にとって、オンチェーンのコントラクトに脆弱性がなくても、コントラクトを支える多数の「オフチェーン部分」、すなわちフロントエンドページ、API、カストディアルウォレット、署名サービス、エアドロップ受取ページ、運用バックエンド、データサービスなどは、多くが PHP で構築されています（WordPress、WooCommerce、Magento など）。コントラクト自体に脆弱性がないことは、これらの部分が安全であることを意味しません。

SlowMist 傘下の脅威インテリジェンスシステム MistEye の統計によると、スキャンした暗号資産業界関連ドメイン 1488 件のうち、793 件に直接的な PHP フィンガープリントがあり、約 53.3% に相当します。強調しておきたいのは、これは PHP を使用していることを示すだけで、これらのサイトに脆弱性がある、または攻撃されたことを意味するものではありません。

1. プラットフォーム側：いくつかの典型的なリスク経路

フロントエンドが改ざんされ、ユーザーが署名を誘導される。

DeFi、ウォレット系サイト、またはエアドロップページのサーバーが制御された場合、攻撃者はページ内のRPCアドレス、承認対象、コントラクトアドレス、または署名プロンプトを差し替え、正常な取引を悪意のある承認、悪意のあるコントラクトとの相互作用、または偽の入金フローに変えることができる。攻撃者はコントラクトを突破する必要はなく、ユーザー自身に悪意のある承認に署名させるだけでよい。

鍵と認証情報の漏洩。

サーバーが制御された後、攻撃者は設定ファイル、データベースのパスワード、APIトークン、環境変数などを読み取る可能性がある。バックエンドがPHPでノードRPCやホットウォレットサービスに接続している場合、APIキーやセッショントークンが一度漏洩すると、ホットウォレット資産の移動や署名権限の悪用にエスカレートする可能性がある。

管理画面とAPIの乗っ取り。

取引所、NFTマーケットプレイス、クロスチェーンブリッジ、決済ゲートウェイ、ノードサービスプロバイダーには通常、運用管理画面があり、さらにKYC/リスク管理インターフェース、入金アドレスの割り当て、出金審査、チケットシステムなどもある。攻撃者が権限を取得すると、設定の改ざん、ユーザーデータの窃取、高権限アカウントの作成、または業務フローの回避が可能になる。

サプライチェーンを通じた横展開。

PHPプロセスの権限は通常、サーバーの最高権限と同等ではないが、CI/CDキー、コンテナランタイムソケット、データベース認証情報、またはクラウドアクセストークンを読み取ることができれば、攻撃範囲は1台のWebノードからデータベース、ビルドシステム、さらには本番アカウント全体に拡大する可能性がある。

決済プラグインとサードパーティサービス。

Binance Pay、Crypto.com Pay、BitPay、CoinGate、CoinPaymentsなどの暗号資産決済ソリューションにはWooCommerce統合があり、サーバーにパッチが適用されていない場合、深刻な露出リスクがあるとされている。RPC、ブロックエクスプローラー、データ分析プラットフォームなどのサードパーティサービスも、管理画面や運用システムが影響を受けるPHP環境で稼働している場合、侵入経路となり得る。もちろん、RPCノード、スマートコントラクト、ブロックエクスプローラー、ウォレット自体は本質的にPHPに依存するわけではなく、具体的な製品の技術スタックによる。

ただし注意すべきは、サーバーが侵害されたからといって、オンチェーン資産が必ず盗まれるわけではないということだ。Webサービスへの侵入から実際の資金損失に至るまでには、攻撃者が機密認証情報、署名フロー、管理権限、あるいはユーザーインタラクションの环节に接触できるかどうかも見る必要がある。ホットウォレットがWeb層と分離されているか、鍵がHSM/KMSに保管されているか、権限が最小化されているかが、損失の上限を直接左右する。

2. 一般ユーザー：コインを引き出すべきか？

不要だ。

理由は簡単だ：

今回の脆弱性が影響するのは特定の条件を満たすサーバー環境であり、すべてのユーザーのウォレットにリスクがあるわけではない。

ウェブサイトを閲覧し、ウォレットを接続することと、秘密鍵の漏洩は別物だ。脆弱性自体がユーザーのウォレットや署名を直接破ることはできない。

あるプロジェクトがPHPを使っているからといって、それがすでに事故を起こしているわけではない。すべての取引プラットフォームがすでに侵害されたと仮定する理由はなく、それによって全資産を引き出す必要もない。ユーザーが本当に警戒すべきは、自分がアクセスするウェブサイトがすでに侵害されていないかどうかだ。ユーザーはあるウェブサイトにパッチが当たっているかどうかを判断できないため、今回の出来事は一つの注意喚起だ：ウェブサイトのインターフェースを盲信してはならない。攻撃者は世論の熱を利用して、偽のログインページ、偽の補償入口、悪意のあるウォレット接続リクエストを拡散する可能性もある。

プロジェクト公式がウェブサイトやバックエンドの侵害を確認した場合は、公告で開示された実際の影響に基づいて、インタラクションを一時停止すべきか、異常取引を確認すべきか、疑わしい承認を取り消すべきかを判断する。署名秘密鍵やニーモニックが漏洩したことが確認された場合は、鍵漏洩インシデントとして対処する必要があり、パスワードを変更したりウェブサイト接続を切断するだけでは不十分だ。取引ボット、自動実行ツール、クラウドデプロイサービスを利用しているユーザーも、関連サービスが影響を受けるバージョンや認証情報のローテーション通知を発表していないか注意する必要がある。

対応方法

1. プラットフォームとプロジェクト側：

第一歩：資産を洗い出し、できるだけ早くアップグレードする

すべてのパブリックネットワークおよび内部ネットワークのPHP資産を棚卸しする：ホスト、コンテナイメージ、Kubernetesワークロード、レガシーCMS、管理バックエンド、パートナー委託環境、サードパーティプラグイン、マネージドサービス。技術フィンガープリントは手がかりに過ぎず、「脆弱性が確認された」という結論として直接扱うことはできない。

8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 にアップグレードするか、ディストリビューション、クラウドプロバイダー、マネージドサービスプロバイダーが提供する同等のパッチを適用してください。8.1 以前のバージョンを使用している場合は、ベンダーにバックポートを要求するか、速やかに移行してください。「旧環境は安定している」「アプリは頻繁に更新されない」といった理由は、この脆弱性のリスクを軽減するものではありません。

アップグレード後はコンテナイメージを再ビルドし、ローリング再起動またはすべての PHP ワーカープロセスの置き換えを行い、ビルドマシンやコマンドライン上のバージョンだけでなく、本番環境で実際にリクエストを処理しているランタイムのバージョンを確認してください。

ステップ2：すぐにアップグレードできない場合の対処

まず露出面を縮小し、時間を稼ぎますが、これはパッチの代替にはなりません：

パブリックインターネットに露出している PHP アプリケーションを隔離するか、入口レイヤーでネットワーク認証とアクセス制御を追加してください。

不要なファイルアップロードを無効化し、WAF または Web サーバーレイヤーで不要な multipart/form-data リクエストを拒否してください。

一部のセキュリティ推奨事項には、memory_limit=-1 の設定、session.upload_progress.enabled の無効化、PHP 8.5 ではさらに fatal_error_backtraces の無効化も含まれます。これらの設定には業務および可用性上の副作用があるため、事前にテストし、変更のたびにすべての PHP ワーカーを再起動してください。

ステップ3：侵害の有無を確認し、認証情報をクリーンアップする

かつてパブリックインターネットに露出していた影響を受けるサービスについて、ログ、エンドポイント監視、異常なネットワーク接続を組み合わせて調査してください。例えば、PHP プロセスが突然システムコマンドを起動するなどの事例です。侵害の疑いを発見した場合は、まず証拠を保全し、その後インシデント対応プロセスに従って処理してください。

最悪の事態を想定してください：適時にパッチを適用していないサーバーについては、API キー、セッションキー、TLS 証明書、データベースパスワード、クラウドアクセストークン、CI/CD 認証情報、RPC/API Key、Webhook シークレット、サードパーティ Token をローテーションし、異常な使用記録がないか確認してください。

環境内に汚染が確認されたソフトウェアバージョンをインストールまたは実行したことがある場合、アップグレードや再インストールだけではリスクが解消されたとは言えません。認証情報の漏洩や永続化されたバックドアを調査し、必要に応じてクリーンな環境を再構築してください。

ステップ4：資産の制御面を守る

PHPの修正だけが唯一の対応であるべきではない。「1台のWebマシンが侵害されても、資金システムに影響が及ばない」ことをより確実に保証すべきである：

ホットウォレット、集約ウォレット、および重要署名サービスの秘密鍵を、Webノードから完全に分離する。HSM、MPC、専用署名ネットワーク、または最小権限のKMSポリシーを使用する。

Webサービス、署名サービス、オンチェーンノード、データベース、ビルドシステムを、異なるネットワークセグメントとアイデンティティ境界に配置する。

インシデント期間中は、出金、アドレスホワイトリストの変更、管理者権限の昇格、API Keyの作成、リスク管理ルールの変更などの高リスク操作を一時的に厳格化し、必要に応じて人手によるレビューや遅延発効を有効にする。

オンチェーンで自動実行されるサービスは、業務に応じて独立署名、マルチシグ承認、取引限度額制限、緊急停止メカニズムを採用できる。

Webサイトの静的リソース、JavaScriptパッケージ、リバースプロキシ設定、DNS/CDNルール、取引構築サービスを検査し、悪意のあるスクリプトが挿入されたり置き換えられたりしていないことを確認する。

2. 一般ユーザー：

正規の入口を利用する：最近はできるだけブックマークや公式チャネルを通じてプラットフォームにアクセスし、「セキュリティインシデント」の名目で送られてくるリンクに警戒する。

ドメインと画面だけを見ない：見慣れたdAppのドメインであっても、ページスクリプト、取引パラメータ、RPC設定がサーバー側の侵入者によって置き換えられている可能性がある。

署名前に項目ごとに確認する：受取アドレス、対象チェーン、承認额度、呼び出されるコントラクト、取引シミュレーション結果。特にapproveとsetApprovalForAllには注意し、無制限额度の承認にはより慎重になる。

「補償」「移行」「再検証」に警戒する：インシデント期間中は「再ログイン」「ウォレットの再検証」「資産の移行」「補償の受け取り」などの案内が現れる可能性がある。サイト内のポップアップだけで操作せず、プロジェクト公式の複数のチャネルからクロスチェックする。

資産の階層化：大口資産はハードウェアウォレットで保管し、日常的なやり取りには別の上限付きウォレットを使い、定期的に承認を整理する。こうすれば、あるフロントエンドやプラットフォームで問題が起きても、1回あたりの損失には上限がある。

異常があればまず手を止める：異常な署名リクエスト、予期しない承認プロンプト、またはウェブサイトの挙動がおかしいと感じたら、まず一時停止し、公式チャネルを通じて確認する。

最後に伝えたいこと

PHP2Shell のようなログイン不要のリモートコード実行脆弱性は、ひとたび Web 層を突破されると、従来のサーバー侵入がフロントエンドへのポイズニング、なりすまし、署名権限の悪用、ホットウォレットのリスク、さらにはサプライチェーン層での横展開へと発展する可能性がある。

プラットフォームにとって最優先の事項は3つある：修正済みバージョンへのアップグレード、当面パッチを当てられない古い環境の隔離、鍵と資産管理プレーンの監査。アップグレード後は、侵入の痕跡の調査をインシデント対応の一環として行う必要がある。ユーザーにとっては、この期間、ページの見た目を盲信せず、1件ごとに署名する前に少し注意深く確認することだ。ただし過度に恐慌する必要はない：脆弱性が存在することは、資産が必ず脅威にさらされることを意味しないし、サーバーが侵害されても、必ずしもオンチェーンの資金損失につながるわけではない。リスクの大きさを実際に決めるのは、攻撃者がどの認証情報を入手できるか、その認証情報がどれほどの権限を持つか、そしてプロジェクトがどれだけ迅速にこれらの権限を隔離・失効できるかだ。Web3 プロジェクトにとって、セキュリティ構築は攻撃の発生を防ぐ方法を考えるだけでなく、あるコンポーネントが実際に侵害されたときに、影響を局所に限定し、リスクを中核業務や資産に関わる部分へ蔓延させないようにできるかどうかを考える必要がある。