本文へ移動
TechHiroba テックひろば
セキュリティ AI生成 文責 blackstrawberry

PHP の認証不要 RCE、8.2〜8.5 は修正版へ、8.1 以下は修正予定なし

CVE-2026-109618/109619 は認証なしで PHP ワーカー上のコード実行につながる。8.2〜8.5 の影響範囲と最初の修正版、修正の出ない 5.4〜8.1 の扱い、AWS 各サービスの状況と WAF での暫定策を整理する。

PHP の Web ランタイムで、認証なしにコードを実行されうる脆弱性が2件（CVE-2026-109618、CVE-2026-109619）見つかった。AWS が米国太平洋時間2026年10月21日14時30分（日本時間22日6時30分）に出したセキュリティ速報 2026-143-AWS によると、影響を受けるのは PHP 8.2〜8.5 の各系列の修正前バージョンだ。上げ先は 8.5.12、8.4.27、8.3.36、8.2.35 のいずれかで、速報はこの更新を唯一の完全な修正としている。

PHP 5.4〜8.1 で動かしている場合は事情が違う。速報によれば、これらは EOL で上流の修正版は出ておらず、出す予定もない。サポート中の系列への移行が必要とされている。

系列ごとの影響範囲と最初の修正版

系列影響を受けるバージョン最初の修正版
PHP 8.58.5.0〜8.5.118.5.12
PHP 8.48.4.0〜8.4.268.4.27
PHP 8.38.3.0〜8.3.358.3.36
PHP 8.28.2.0〜8.2.348.2.35
PHP 5.4〜8.1EOL上流の修正なし・予定なし

出典：AWS セキュリティ速報 2026-143-AWS（2026年10月21日公開）

速報の説明では、細工した Web リクエストを影響のある PHP ワーカーに送ることで、任意コードの実行、プロセスから読めるデータの読み出し、サービス停止が起こりうる。認証は要らず、インターネットから顧客アプリケーションへの境界を越えて届く。被害は攻撃されたワーカーとそのアプリケーション権限の範囲にとどまり、顧客をまたいだ波及は現時点で確認されていないという。

AWS のサービス自体は影響を受けないと速報は述べている。対象になるのは、AWS 上で顧客が該当バージョンの PHP を動かしているケースだ。

8.1 以下で動いているサーバーの扱い

EOL 系列（5.4〜8.1）に対して速報が示す対応は 3 つある。CVE-2026-109619 には効く範囲で暫定の設定対策を入れること、PHP ワーカーを再起動すること、修正済みのサポート系列への移行をすぐ始めることだ。CVE-2026-109618 については、EOL 系列向けの修正はないと明記されている。暫定の設定対策が具体的に何かは、速報本文には書かれていない。

ここでいう「修正なし」は、上流の PHP として修正版が出ないという意味だ。OS ディストリビューションなど別の経路で修正が提供されるかどうかは、この速報からは判断できない。

AWS のサービス上で PHP を動かしている場合

AWS セキュリティ速報が10月21日時点で示した各サービスの状況は次のとおり。日付の多くは当時の「予定」であり、実際の更新状況は各サービスの情報で確かめる必要がある。Amazon Linux のセキュリティ情報には10月22日付で修正済み PHP パッケージが掲載されている。

  • Amazon WorkMail は、到達できる条件を絞る設定レベルの対策を適用済み。8.3.36 への更新は10月22日予定で、顧客側の対応は不要とされている。
  • AWS Elastic Beanstalk は、両 CVE に対処した PHP プラットフォーム v4.13.12 を10月21日にリリースした。上流の PHP 修正を含む後続リリースは10月22日予定。Managed Platform Updates を有効にしていれば次のメンテナンスウィンドウで自動適用され、無効なら自分でプラットフォームバージョンを更新する。
  • Amazon Linux は、更新済み PHP パッケージが10月22日予定。出たらすぐ適用するよう求めており、詳細は Amazon Linux Security Center の各 CVE のページにある。
  • Amazon Lightsail は、更新済みブループリントが10月21日に出る見込みとされた。稼働中のインスタンスは AWS がその場で更新できないため、新しいブループリントからインスタンスを作り、アプリケーションを移す必要がある。

Elastic Beanstalk の v4.13.12 は「両 CVE に対処」とされる一方、上流の修正を含むのは後続リリースだとも書かれている。v4.13.12 の時点で PHP 本体が修正版になっているかは、速報の文面からは読み取れない。

更新できるまでの WAF での補い方

まず PHP 本体を修正版へ更新することが優先だ。更新まで AWS WAF を使う場合は、PHP 向けマネージドルールグループの設定と更新状況を確認する。速報の公開時点では、このルールグループの更新が予告されていた。既定バージョンを使う設定か、バージョンを固定しているかを Web ACL で確認し、固定している場合はAWS WAF のルール更新履歴で最新のルールを確認する。Count に変更したルールは、検知してもブロックしない点にも注意したい。

以下の 2 つは10月21日の速報公開当初に案内された暫定・補完策であり、最新の PHP マネージドルールグループの確認より優先する手順ではない。速報は、これらの設定だけでは完全に緩和できないと説明している。

CVE-2026-109618 には、Core rule set（CRS）マネージドルールグループの SizeRestrictions_BODY ルールを使う。8KB（8,192 bytes）を超えるリクエストボディをブロックするルールなので、それより大きいボディを正当に受けるエンドポイントがあれば、そのリクエストも止まる。適用前に該当する画面や API を洗い出しておきたい。

CVE-2026-109619 には、速報の公開当初に WebACL に追加するカスタムルール（名前は PHP2Shell）が JSON で案内されていた。条件は、メソッドが POST で、ボディに PHP_SESSION_UPLOAD_PROGRESS を含み、かつ Cookie のキーが PHPSESSID かボディに PHPSESSID を含むこと。一致したらブロックし、CloudWatch メトリクスとリクエストのサンプリングを有効にする設定だ。現在のマネージドルールの更新状況はAWS WAF のルール更新履歴でも確認できる。これら公開初期のルールは追加の補完策として検討できるが、誤検知や正当なリクエストの遮断に注意が必要だ。WAF は PHP 本体の更新に代わる完全な修正ではない。

手元の環境で確かめる順番

  1. 実際にリクエストを処理している PHP ワーカーのバージョンを確認し、上の表と照らし合わせる。
  2. 8.2〜8.5 で修正版未満なら、同じ系列の修正版以上に上げる。
  3. 5.4〜8.1 なら、修正済みのサポート系列への移行計画をすぐ立てる。それまでは CVE-2026-109619 向けの暫定対策を入れ、ワーカーを再起動する。
  4. PHP の更新が完了するまで、AWS WAF の PHP マネージドルールグループの設定と更新履歴を確認する。既定バージョンか固定バージョンかを確認し、固定している場合は最新ルールの適用を検討する。公開当初の CRS・カスタムルールは、必要に応じた暫定・補完策として扱う。

Elastic Beanstalk、Amazon Linux、Lightsail を使っているなら、手順 2 の「上げる」はそれぞれのプラットフォーム更新、パッケージ更新、インスタンスの作り直しに置き換わる。

出典 種別について