情報処理推進機構（IPA）は11月2日、ウェブサイトの構築に広く使われるプログラミング言語「PHP」で見つかった2件の深刻な脆弱性（CVE-2026-109618、CVE-2026-109619）について、注意喚起を更新した。2件を組み合わせた攻撃は「PHP2shell」と呼ばれる。追記では、PHPがVPN機器やセキュリティー製品のウェブ管理画面など「様々なところで利用されています」とし、自社・自組織で使う製品や機器について、開発者が出す脆弱性対策情報を注視し、更新が提供されたら適用するよう求めた。欠陥が悪用されると、認証を経ずに外部から任意のコードを実行されるおそれがある。米国の政府機関は10月26日、実際に悪用された脆弱性の一覧に2件を加えた。
認証なしで外部からコードを実行されるおそれ
PHPを開発するThe PHP Groupが10月21日に出したセキュリティー勧告によると、2件はいずれも、ログインなどの認証を経ないままサーバー上で任意のコードを実行される（リモートコード実行）おそれがある欠陥だ。PHP側は前日の予告で、2件の深刻度を共通脆弱性評価システム（CVSS）の第4版でともに9.2と示していた。10点満点で、最も重い「緊急（Critical）」の区分に入る。
1件目（CVE-2026-109618）は、メモリー不足（OOM）のエラー処理に起因する。PHPの説明では、リクエストの処理中にメモリーの確保に失敗すると、内部のデータが一部しか初期化されていない状態で処理が中断され、その後の後片付けの処理が不正なデータを正しいものとして扱ってしまう。勧告の技術資料は、ファイルの送信などに使う「multipart」形式のリクエストを細工すると、PHPの設定上の上限の範囲に見える要求でもメモリー不足を起こせると説明している。
2件目（CVE-2026-109619）は、あるリクエストのために使った内部の状態が、メモリーを解放した後も残ってしまう欠陥だ。同じワーカー（処理を受け持つプロセス）が次に処理するリクエストが、初期化される前にその古い状態を使う場合がある。
PHP側は、ウェブのリクエストを処理する全てのPHPの環境が危険にさらされるとし、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedを挙げた。最も危険度が高いのはmod_phpで、認証のないリクエストがアプリケーションのコードが動く前に攻撃を引き起こせることを実証したとしている。IPAによると、調査に関わった米セキュリティー企業Wizは、PHP 5.4以降の版は2件のうち少なくとも1件の影響を受けるとしている。
修正版は4系列、8.1以前には出ない
修正版は10月21日に公開された。日本時間では同日午後11時。IPAは同じ21日、公開に先立って「事前準備のお願い」を出し、PHPを使うプログラムの棚卸しを呼びかけていた。対象の版と修正版は次の通り。
| 系列 | 影響を受ける版 | 修正版 |
|---|---|---|
| 8.5系 | 8.5.12より前 | 8.5.12 |
| 8.4系 | 8.4.27より前 | 8.4.27 |
| 8.3系 | 8.3.36より前 | 8.3.36 |
| 8.2系 | 8.2.35より前 | 8.2.35 |
| 8.1以前 | 影響を受ける（Wizの調査では5.4以降） | PHPの開発元からは提供されない |
出典: IPA「PHPの脆弱性対策について」、The PHP Group のセキュリティー勧告
PHPの8.1以前の版は、開発元の保守期間が終わっている（サポート終了）。PHP側は、深刻さを考えて7.4、8.0、8.1向けに最小限の修正をソースコードで提供したとする一方、8.1以前の利用者には、修正を独自に提供する配布元に問い合わせるか、サポートされている版へ移るよう求めた。Linuxの配布元などには事前に修正を渡しており、OSに付属するPHPは配布元の更新を確かめるよう案内している。
PHP側は23日、別の欠陥（CVE-2026-115560）についても告知した。セッションの設定を実行中に切り替えるという一般的でない組み合わせでのみ起きるとして通常の更新で直す方針で、それまでは「session.upload_progress.enabled=0」の設定を勧めた。この設定はCVE-2026-109619の緩和策として21日に示したものと同じで、適用済みなら追加の対応は要らないとしている。
なお、Windows版のPHPは26日、圧縮形式「Brotli」の欠陥（CVE-2026-111497）を直した部品を入れて作り直された（圧縮ソフト「Brotli」に深刻な欠陥 米政府が悪用を確認、Node.jsなどに影響）。PHP本体の版は変わらない。
悪用の確認と、ファイアウォール製品への侵害の痕跡
公開から5日後の10月26日（米国時間）、米サイバーセキュリティー・インフラストラクチャー安全保障庁（CISA）は2件を「悪用が確認された脆弱性（KEV）」の一覧に加えた。一覧に記された対応期限は10月29日。CISAは21日に出し23日に更新した注意喚起で、組織内でPHPを使うシステムを洗い出し、インターネットに面したものから直ちに更新するよう促し、すぐに更新できない場合や8.1以前を使い続ける場合は、更新するまでシステムをネットから切り離すべきだとしていた。
これを受けてIPAは27日に注意喚起を更新し、国内での攻撃被害の事例は把握していないとしたうえで、対策済みの版への移行を改めて求めた。
日本の情報セキュリティーの調整機関であるJPCERT/CCも22日に注意喚起を出し、26日と29日に追記した。悪用できると主張する実証コードが多数公開され、悪用を試みる通信を観測したとの報告も相次いでいるという。29日の追記では、ある報告で、特定のファイアウォール製品の特定の版について侵害の成功を示唆する痕跡が確認されたと紹介した。報告によれば、攻撃者は製品を解析し、版ごとに今回の欠陥とLinuxカーネルの権限昇格の脆弱性を組み合わせた攻撃コードを作っていた。侵害した機器を足場に内部のネットワークへ広げようとした痕跡もあったという。CISAの一覧にも、Linuxカーネルの別の欠陥について、今回の2件と組み合わせてPHPのウェブシェル（遠隔操作用の不正なプログラム）を仕込み、最高権限でコマンドを実行できるとの記載がある。
IPAの11月2日の追記は、こうした流れの中で出た。PHPは利用者が直接入れたものだけでなく、製品や機器の内部にも組み込まれている。IPAは21日の事前準備の呼びかけの段階で、製品や機器の内部でのPHPの利用状況は利用者の側で把握できない場合があると指摘していた。JPCERT/CCも、PHPを組み込んだ製品の管理者に、製品が影響を受けるか、標的にした攻撃や侵害の報告がないかを確かめ、対策と侵害の調査を急ぐよう求めている。
すぐ更新できないときの手順
更新が難しい場合について、PHP側は攻撃の経路を狭める設定を示した。1件目にはメモリー上限を外す設定（memory_limit=-1）や、送信データの上限（post_max_size）を小さくすること、2件目にはアップロードの進み具合を記録する機能を止める設定（session.upload_progress.enabled=0）を挙げた。ただし「完全な緩和策はなく、更新だけが安全な選択だ」と明記している。
IPAは、修正が難しい場合の考え方を6段階で示した。まず使っているPHPがサポート対象かを確かめ、更新や移行が終わるまで脆弱なまま放置せずに暫定策やアクセス制限を講じる。有効な暫定策が難しければ、外部からのアクセスの遮断やサービスの一時停止が必要かを判断する。そのうえで、システムが果たしている役割と更新の難しさを把握し、事業責任者や経営層も含めて人員・予算・保守体制を確保できるかを検討する。確保の見通しが立たなければ、保守を受けられる製品への移行のほか、機能の縮小や公開の終了、システムの廃止も選択肢にするよう求めた。長く更新していないシステムでは、改修や動作確認に加え、開発時の資料の不足や担当者の不在、保守契約の終了が対策の妨げになることがあるとも指摘している。
すでに攻撃を受けていないかの点検について、JPCERT/CCは発見者らの情報として、▽過去の応答で不自然に長い、または異常な形式のPHPSESSID（セッションを識別するCookie）が設定されていないか▽不審なmultipart形式のリクエストと、その前後にメモリー上限のエラーやHTTP 500エラーが出ていないか▽PHPのワーカーが予期せず異常終了したり頻繁に再起動したりしていないか――を確かめるよう勧めた。痕跡が見つからなくても攻撃を受けていないとは断定できず、侵害が疑われればログなどの証拠を保全したうえでシステムの隔離などを行うよう求めている。
公的機関のサイトも一時停止
国内でも、欠陥への対応のためにサービスを止めた例が出ている。宮内庁は10月22日未明から、ウェブサイトの「ご意見・ご感想フォーム」、皇居や京都仙洞御所、桂離宮、修学院離宮の参観申し込みを受け付けるシステム、トップページの公式インスタグラムの紹介画面を、PHPの脆弱性対応のため一時停止し、同日午後4時30分ごろまでに復旧させた。
PHPは、利用者が自ら導入したウェブサイトだけでなく、機器のウェブ管理画面や業務用のソフトウェア製品の内部でも動いている。こうした製品の中のPHPは、利用者が自ら版を上げることができず、製品の開発者が出す更新を待って適用することになる。IPAの11月2日の追記は、自組織のPHPを更新し終えた組織にも、VPN機器などの製品について開発者の脆弱性対策情報を確かめ、更新が出たら適用するよう求めるものだ。