本記事は、Cisco Talos の公式ブログ記事「Two critical RCEs in PHP core」の翻訳です。
Cisco Talos は、PHP コアに存在する2件の認証不要のリモートコード実行（RCE）脆弱性「php2shell」の公表を追跡しています。これらの脆弱性は通常の HTTP リクエストによって引き起こされ、アプリケーションのコードが実行される前に悪用される可能性があります。PHP 5.4 以降のすべてのビルドが影響を受けます。
脆弱性の発見には、関係者の情報から、人工知能（AI）とその関連技術が重要な役割を果たしたと考えられます。今回の事例も、こうした技術が業界に変化をもたらしていることを示しています。特に、公表される脆弱性が相次ぐなか、組織のパッチ適用プロセスへの影響が顕著です。
Cisco のお客様は、Cisco Talos Network Intrusion Prevention（SNORT®）シグネチャ 67359 および 67360 によって保護されています。これらのルールは、オープンソース版をご利用のお客様向けに Community Ruleset でも公開されています。詳細は、以下の推奨事項、検知方法、対応範囲に関する情報をご覧ください。
詳細
CVE-2026-109618 と CVE-2026-109619 は、どちらも CVSS v4.0 のスコアが 9.2 の重大な脆弱性です。
- CVE-2026-109618： メモリ不足の処理によって、内部のリクエストデータが一部しか初期化されていない状態で PHP の処理が中断されると発生します。その後のリクエストのクリーンアップ処理が、不正なデータを有効なものとして扱う可能性があります。
- CVE-2026-109619： 参照先のメモリがすでに解放された後、通常の初期化処理によってリセットされる前に、古い内部状態が再利用されると発生します。
影響
影響が及ぶ可能性のある範囲は非常に広く、PHP を利用するエコシステム全体に及びます。脆弱性は PHP コアにあるため、影響を受けるバージョンで動作するアプリケーションは危険にさらされる可能性があります。対象には、WordPress、Drupal、Magento、Shopware、WooCommerce、Laravel のほか、cPanel や Plesk を通じてホストされている PHP サイトも含まれます。古いバージョン系列の多くは今後修正を受けられないため、サポート対象のバージョンへできるだけ早くアップグレードすることを推奨します。
Talosは、脅威アクターによる脆弱性の悪用を定期的に調査しています。国家の支援を受ける脅威アクターやその関連グループ、ランサムウェアグループ、その他金銭目的のグループは、いずれも RCE の悪用を試みます。Talos は、PHP アプリケーションを実行しているシステムにパッチが適用されていない場合、あらゆる業種が悪用の危険にさらされると評価しています。
PHP 8.1 以前はサポートが終了しています。PHP 8.2 のセキュリティサポートも 2026年12月31日 に終了します。オープンソースの情報に基づく Talos の初期推定では、パッチを受け取れないPHP システムが相当数（約50％）存在します。組織でPHP 8.1以前を使用している場合、Talos は PHP 8.2 以降への速やかなアップデートを強く推奨します。PHP 8.1 以前向けのパッチはありません。
Talos はこれらの CVE の影響を継続して監視しています。2026年10月21日14:00 UTC（米東部時間午前10時）時点では、実環境での悪用は確認されていません。
推奨事項と検知に関するガイダンス
Talos は、すべての PHP ユーザーに対し、修正済みのリリースへのアップグレードを強く推奨しています。包括的な保護を提供できる中間的または一時的な対策はありません。ただし、PHP の案内によると、以下の対策で特定の攻撃経路への露出を減らせる可能性があります。
CVE-2026-109618
- memory_limit=-1 を設定します。可能であれば、PHP-FPM のプールや Apache の設定にある php_admin_value など、アプリケーションから上書きできない方法で設定してください。また、プール、ディレクトリ、アプリケーションの設定によって有限の制限値が再設定されていないことを確認してください。この設定により、制御可能なPHPメモリ制限に起因する失敗は取り除けますが、根本的なメモリ割り当て失敗によって脆弱な処理に到達する可能性は残ります。
- post_max_size を小さく設定します。ファイルアップロードが不要なアプリケーションでは post_max_size = 8M、必要な場合はpost_max_size = 32M に設定します。upload_max_filesize は post_max_size より小さい値にしてください。Web サーバーまたはプロキシ側で、デコード後のリクエストサイズ、入力フィールド数、マルチパートのパート数、ヘッダー数、入れ子の深さを制限することも検討してください。これらの制限は、有効な Content-Lengthがないリクエストにも適用する必要があります。
- 可用性を保つ境界として、コンテナまたは cgroup の制限を使用します。可能であれば、影響を受けたワーカーだけを終了するポリシーを設定してください。RLIMIT_ASやRLIMIT_DATA は、脆弱性につながるメモリ割り当て失敗を引き起こす可能性があるため、代わりに使用しないでください。
CVE-2026-109619
- session.upload_progress.enabled=0 を設定し、すべてのワーカーを再起動してください。リクエスト解析より前に適用されるphp.ini、PHP-FPM のプール設定、またはサーバー設定を使用します。ini_set()やPHP-FPM の .user.ini に頼らないでください。この設定で確認済みのセッション関連経路は防げますが、ほかの変種は防げません。
- PHP 8.5 では、fatal_error_backtraces=0 を設定し、すべてのワーカーを再起動してください。これは確認済みの致命的エラーのバックトレース経路だけを防ぎます。
- 初期化前に診断メッセージを出力する、不正または非推奨のリクエスト単位の設定を削除してください。error_reporting、display_errors、@ を使って診断メッセージを隠しても効果はありません。
- コールバック、アップロードやインポートの処理、クリーンアップ処理など、攻撃者が到達可能な致命的エラーや実行タイムアウトを修正してください。
今回も、AI とその関連技術が発見に関わった脆弱性です。2026 年を通じて、脆弱性の公表とそれに伴うパッチの増加が続いています。Talos は、脆弱性に優先順位を付けて対応するプロセスを整備し、特にインターネットに公開されたシステムや、実際に悪用されている脆弱性を重視するよう組織に勧めています。優先順位付けの必要性が明らかになっていること、そしてパッチを迅速に適用する手順を簡素化する必要があることから、これまで一般的だった「展開前にパッチを組み込む」方法は、AI 時代には維持できなくなる可能性が高いと考えられます。
この脆弱性の実際の影響を評価するには時間がかかります。基盤技術に影響するこの種の脆弱性は、関連するプラットフォームやアプリケーションが影響を調査してパッチを提供する過程で、被害が連鎖的に広がる傾向があります。これは、Log4j の後に見られた悪用の波を思い起こさせます。
対応範囲
これらの脆弱性を対象とする、SNORT® の有料購読者向け SID は 67359、67360、67375です。無料のコミュニティルールはCommunity Rulesetで公開されています。
Authors
Log in to comment