PHPが「インターネットレベル」の高リスク脆弱性を露呈——Web3の「オフチェーンの弱点」はいかに解決すべきか？
Tapbit Wire原文タイトル：「PHPが『インターネットレベル』の重大脆弱性を露呈：Web3の『オフチェーンの軟弱ポイント』をどう修復するか？」 原著者：SlowMistセキュリティチーム
発生状況
10月21日、PHPプロジェクトは緊急セキュリティ更新を公開し、未認証のリモートコード実行（RCE）を可能にする2つの重大脆弱性CVE-2026-109618およびCVE-2026-109619を修正した。両脆弱性のCVSS v4.0スコアは9.2。PHP公式によると、修正前は外部ウェブサービスを提供するすべての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（古くなったグローバル状態）：リクエスト処理後、メモリは解放されるが関連状態が「残ったまま」になる。同一ワーカープロセスが次回リクエストを処理する際、通常の初期化前にこの期限切れ状態を利用され、PHP-FPMへの攻撃およびリモートコード実行が可能となることが公式に確認されている。
攻撃経路の観点から、この種の脆弱性の危険性は、攻撃者がまずサイトアカウントを取得したり、業務層のログイン・権限・APIキー検証を突破する必要がない点にある。インターネットに公開されたPHPアプリケーションへ悪意のあるリクエストを送信するだけで、ウェブサービスプロセスの権限で任意コードを実行できる。
影響範囲：PHP 5.4～8.5.11まで全て影響を受ける。修正済みバージョンは8.5.12、8.4.27、8.3.36、8.2.35。PHP 8.1以前のバージョンは既に公式サポート終了のため、通常チャネルではパッチ提供は期待できず、サポート中のバージョンへの移行が必要。
なぜ世界中が緊張しているのか？
PHPが極めて普及しているからだ。W3Techsの統計によると、サーバーサイド言語が判明するウェブサイトのうち69.3%がPHPを使用。WordPress、WooCommerce、Magentoなど馴染み深いシステムも、裏側でPHPを基盤として動作している。
各国の反応も問題の深刻さを物語る——オランダ国家サイバーセキュリティセンター（NCSC）は予防的に複数ウェブサイトを停止；韓国大統領府は緊急サイバーセキュリティ会議を開催し、政府はサイバーセキュリティ警戒レベルを引き上げた。
また報道によると、北朝鮮の官公庁メディアや政府ポータルサイトを含むほぼすべての公式ウェブサイトが24時間以上ダウンしており、この事象が当該脆弱性と関連しているかどうかは現時点では不明。
Web3への影響
これは、従来のWebサイトの運用・保守のみに関係する問題ではありません。Web3においても、オンチェーン契約に脆弱性がなくても、フロントエンドページ、API、カストディアルウォレット、署名サービス、エアドロップ申込ページ、運用バックエンド、データサービスなど、契約運用を取り巻く多数の「オフチェーン構成要素」は、PHP（WordPress、WooCommerce、Magentoなど）で構築されることが多くあります。契約自体に脆弱性がなくても、これらの構成要素が安全であるとは限りません。
SlowMist傘下の脅威インテリジェンスシステム「MistEye」の統計によると、同社がスキャンした暗号資産業界関連ドメイン1,488件のうち、793件（約53.3％）が直接的なPHP指紋を有していました。ただし、これは単にPHPが使用されていることを示すものであり、これらのウェブサイトに脆弱性がある、あるいは既に侵害されているという意味ではありません。
1．プラットフォーム側：代表的なリスク経路
フロントエンドの改ざんによるユーザーの署名誘導
DeFiやウォレット系サイト、エアドロップページのサーバーが侵害されると、RPCアドレス、承認対象、コントラクトアドレス、署名プロンプトなどをページ上で置き換えられ、通常の取引が悪意ある承認・悪意あるコントラクトとのやり取り・偽の入金プロセスに変質します。攻撃者はコントラクトそのものを突破する必要はなく、ユーザー自身が悪意ある承認に署名するよう誘導すればよいのです。
鍵および認証情報の漏洩
サーバーが侵害されると、攻撃者は設定ファイル、データベースパスワード、APIトークン、環境変数などを読み取ることが可能です。バックエンドがPHPでノードRPCやホットウォレットサービスに接続している場合、APIキーまたはセッショントークンが漏洩すると、ホットウォレット資産の送金や署名権限の悪用へと拡大する恐れがあります。
バックエンドおよびAPIの乗っ取り
取引所、NFTマーケットプレイス、クロスチェーンブリッジ、決済ゲートウェイ、ノードサービス提供者などは、通常、運用用バックエンドおよびKYC／リスク管理インターフェース、入金アドレス割り当て、出金審査、チケット管理システムなどを備えています。攻撃者が権限を取得すると、設定の改ざん、ユーザー情報の窃取、高権限アカウントの作成、業務フローのバイパスなどが可能になります。
サプライチェーンを通じた横展開
PHPプロセスの権限は、通常サーバー上の最高権限と等しくありませんが、CI/CDキー、コンテナランタイムソケット、データベース認証情報、クラウドアクセストークンなどを読み取れる場合、攻撃範囲は単一のWebノードからデータベース、ビルドシステム、さらには全生産環境アカウントへと拡大する可能性があります。
決済プラグインおよび第三者サービス
Binance Pay、Crypto.com Pay、BitPay、CoinGate、CoinPaymentsなどの暗号資産決済ソリューションは、すべてWooCommerce連携機能を提供しています。パッチ未適用のサーバーは深刻な露出リスクを抱えます。また、RPC、ブロックエクスプローラー、データ分析プラットフォームなどの第三者サービスも、そのバックエンドまたは運用システムが影響を受けるPHP環境で動作している場合、侵入口となる可能性があります。ただし、RPCノード、スマートコントラクト、ブロックエクスプローラー、ウォレット自体は、本質的にPHPに依存しません。これは製品ごとの技術スタックに依存します。
ただし、サーバーが侵害されたからといって、必ずしもオンチェーン資産が盗まれたわけではありません。Webサービスの侵害から実際の金銭的損失へ至るには、攻撃者が機密認証情報、署名プロセス、管理者権限、またはユーザーとのインタラクションポイントにアクセスできるかどうかが鍵となります。ホットウォレットがWeb層から分離されているか、鍵がHSM／KMSに格納されているか、権限が最小限に抑えられているかによって、潜在的な損失の上限が直接的に決まります。
2．一般ユーザー向け：コインを引き出すべきか？
不要です。
理由はシンプルです：
この脆弱性は、特定の条件を満たすサーバー環境に影響を与えますが、すべてのユーザーのウォレットが危険にさらされているわけではありません。
ウェブサイトを閲覧し、ウォレットを接続する行為は、秘密鍵の暴露とは異なります。この脆弱性自体は、ユーザーのウォレットや署名を直接解読することはできません。
プロジェクトがPHPを使用しているからといって、すでに侵害されているわけではありません。すべての取引所が侵害されたと仮定する根拠はなく、ましてやこれを理由に全資産を引き出す必要はありません。ユーザーが真に注意すべきは、訪問先のウェブサイトが実際に侵害されているかどうかです。ユーザーはそのウェブサイトがパッチ適用済みか否かを判断できないため、今回の事象は「ウェブサイトのUIを無批判に信用しない」よう警告するものです。攻撃者は世間の注目を背景に、偽ログインページ、偽補償ポータル、悪意あるウォレット接続要求などを拡散する可能性もあります。
プロジェクトが公式に自社ウェブサイトまたはバックエンドが侵害されたことを確認した場合、ユーザーは公表された実際の影響に基づき、インタラクションの一時停止、異常な取引の確認、疑わしい承認の取消しを判断すべきです。署名用秘密鍵やシードフレーズが漏洩したことが確認された場合は、鍵侵害インシデントとして対応しなければならず、パスワード変更やサイトからの切断だけでは不十分です。トレーディングボット、自動実行ツール、クラウド展開サービスを利用するユーザーも、関連サービスが影響を受けたバージョンや資格情報ローテーションに関する通知を発行していないか注意が必要です。
対応方法
1．プラットフォームおよびプロジェクトチーム：
ステップ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キー、ウェブフックシークレット、サードパーティトークンなどをすべてローテーションし、異常な利用記録がないかも確認してください。
確認済みの侵害済みソフトウェアバージョンが環境にインストールまたは実行されていた場合、単なるアップグレードまたは再インストールではリスクが解消されたとはみなせません。資格情報の漏洩や永続化バックドアの調査に加え、必要に応じてクリーンな環境を再構築してください。
ステップ4：資産管理面の強化
PHPのパッチ適用は単独では不十分です。さらに重要なのは、「侵害されたWebマシンが資金システム全体を巻き込まない」ようにすることです：
ホットウォレット、コレクションウォレット、重要な署名サービスの秘密鍵をWebノードから完全に分離し、HSM、MPC、専用署名ネットワーク、または最小権限のKMSポリシーを活用してください。
Webサービス、署名サービス、オンチェーンノード、データベース、ビルドシステムをそれぞれ異なるネットワークセグメントおよびID境界に配置してください。
インシデント発生時、引き出し、アドレスホワイトリスト変更、管理者権限昇格、APIキー作成、リスク制御ルール変更などの高リスク操作を一時的に厳格化し、必要に応じて手動審査または遅延実行を適用します。
オンチェーンで自動実行されるサービスには、独立署名、マルチシグ承認、トランザクション金額制限、および事業要件に応じた緊急停止機構を導入します。
Webサイトの静的リソース、JavaScriptパッケージ、リバースプロキシ設定、DNS／CDNルール、トランザクション構築サービスを確認し、悪意あるスクリプトが挿入・置換されていないことを検証します。
2．一般ユーザー向け：
公式エントリーポイントを利用：最近はブックマークや公式チャネルからプラットフォームにアクセスし、「セキュリティインシデント」を装ったリンクには注意してください。
ドメインとUIだけを見ない：馴染みのあるdAppドメインでも、ページスクリプト・トランザクションパラメータ・RPC設定はサーバー側で攻撃者により改ざんされている可能性があります。
署名前に1項目ずつ確認：受取アドレス、チェーン、承認金額、呼び出し契約、トランザクションシミュレーション結果です。特にapprove/setApprovalForAllは慎重に、無制限承認はさらに警戒が必要です。
「補償」「移行」「再検証」に注意：インシデント中、「再ログイン」「ウォレット再検証」「資産移行」「補償請求」などの表示が出ることがあります。サイト内ポップアップのみで行動せず、プロジェクトの複数公式チャネルで事前確認してください。
資産を層別管理：大口保有にはハードウェアウォレット、日常利用には限度額付きウォレットを分離し、承認を定期的にクリアします。これにより、フロントエンドやプラットフォームが侵害されても、単一の損失は上限で抑えられます。
異常を察知したらまず停止：不審な署名要求・予期しない承認プロンプト・怪しいWebサイト動作に遭遇した際は、即座に操作を中断し、公式チャネルで確認してください。
まとめ
PHP2Shellのようなログイン不要のリモートコード実行脆弱性がWeb層を突破すると、従来のサーバー侵入がフロントエンド汚染・身分なりすまし・署名権限の悪用・ホットウォレットリスク・サプライチェーンレベルでの横展開へと変化します。
プラットフォーム側の最優先課題は3点：パッチ適用済みバージョンへのアップグレード、現時点でパッチ適用できない旧環境の隔離、鍵および資産制御平面の監査です。アップグレード後は、侵入兆候の探索をインシデント対応の一環として実施してください。ユーザー側は、この期間、ページUIを盲目的に信頼せず、すべてのトランザクション署名前に追加確認を行うよう心がけてください。ただし過度なパニックは禁物です：脆弱性の存在＝資産の直ちなる危険ではありませんし、サーバー侵害＝オンチェーン資金損失を意味しません。リスク規模を真正に決定するのは、攻撃者が取得した資格情報の種類・それらが持つ権限の範囲・プロジェクトによる権限の隔離・取消の迅速さです。Web3プロジェクトにおいて、セキュリティ構築とは攻撃防止策の検討にとどまらず、「万一コンポーネントが侵害された場合、影響を局所的に封じ、コア事業・資産運用への拡散を防げるか？」という視点も不可欠です。
原文リンク
