MOOBON
Technical Article ・ AWS / Security

PHP の緊急脆弱性「php2shell」Amazon Linux の PHP を確認・更新する手順と、更新までの暫定対策

2026年10月22日 公開読了 約8分MOOBON 技術ブログ

2026 年 10 月 21 日、PHP に 2 つの深刻な脆弱性(CVE-2026-109618 / CVE-2026-109619)が公開されました。細工したリクエストを 1 つ送るだけで、認証なしにサーバー上で任意のコードを実行される可能性があります。AWS は Amazon Linux の修正パッケージを 10 月 22 日に配布する予定としています。Amazon Linux で PHP を動かしている環境の確認・更新の手順と、更新までの暫定対策をまとめます。

本記事は 2026 年 10 月 22 日時点の情報です。Amazon Linux のパッケージの配布状況は、関連リンクの Amazon Linux Security Center で最新の状態を確認してください。

1. 何が起きているか

CVE内容
CVE-2026-109618メモリ不足(OOM)で処理が中断されたとき、初期化が終わっていないデータをリクエストの後片付けで使ってしまう。マルチパート(ファイルアップロード形式)のリクエストでメモリ不足を起こさせるのが主な攻撃経路。
CVE-2026-109619終わったリクエストのメモリを指したままの内部状態を、同じワーカーの次のリクエストが使ってしまう(use-after-free)。既定で有効な session.upload_progress が経路の 1 つ。
  • 認証なしでリモートからコードを実行される。PHP の開発チームは 2 つとも CVSS v4.0 で 9.2(Critical)と評価しています。Web サーバーのプロセスの権限で任意のコードが実行され、DB の接続情報などのファイルも読まれる可能性があります。
  • アプリケーションのコードより前に悪用される。リクエストの受け付け時点で起きるため、WordPress や Laravel などのアプリケーション側では防げません。Apache の mod_php では、既定の設定のまま攻撃が成功することが実証されています。
  • すでに攻撃の試行が報告されている。公開前日に CVE 番号が漏れたため、PHP の修正版は予定を 1 日早めて 10 月 21 日に公開されました。同日、Cloudflare や watchTowr が攻撃の試行を観測したと報告しています。「php2shell」の名前で、海外のセキュリティ各社が一斉に注意を呼びかけています。

PHP は Web サイトの 7 割近くで使われているとされ、影響の範囲が非常に広い脆弱性です。インターネットに公開している PHP のサーバーは、最優先で対応してください。

2. 影響を受けるバージョン

ブランチ影響を受けるバージョン修正版
8.58.5.0〜8.5.118.5.12
8.48.4.0〜8.4.268.4.27
8.38.3.0〜8.3.358.3.36
8.28.2.0〜8.2.348.2.35
5.4〜8.1すべて公式の修正版なし(サポート終了)

PHP-FPM・Apache の mod_php・php-cgi・FrankenPHP・LiteSpeed と、Web のリクエストを処理するすべての形態が対象です。PHP 8.1 以前はサポートが終了しているため、ソースからビルドする人向けの最小限のパッチ以外は提供されていません。PHP 8.2 も 2026 年 12 月 31 日でサポートが終わります。

3. Amazon Linux の配布状況

AWS のセキュリティ情報(2026-143-AWS)では、Amazon Linux の修正パッケージは 2026 年 10 月 22 日に配布予定です。Amazon Linux Security Center での各パッケージの状態は次の通りです(10 月 22 日時点)。

OSパッケージ状態
Amazon Linux 2023php8.2 / php8.3 / php8.4 / php8.5Pending Fix(配布待ち)
Amazon Linux 2023php8.1No Fix Planned(修正予定なし)
Amazon Linux 2(Extras)php8.2Pending Fix(配布待ち)
Amazon Linux 2(Core)php(5.4)No Fix Planned(修正予定なし)

「No Fix Planned」の PHP(AL2023 の php8.1、AL2 標準の PHP 5.4)には修正パッケージが出ません。6 章の暫定対策を入れたうえで、php8.3 以降への切り替えや、Amazon Linux 2023 への移行が必要です。当社が Amazon Linux 2 から 2023 へ WordPress を移行した記録はこちらの記事にまとめています。

4. 自分の環境を確認する

PHP のバージョンとパッケージ

# CLI の PHP のバージョン
php -v

# インストールされている PHP のパッケージ
rpm -qa 'php*' | sort

# Web サーバーの形態(php-fpm か、Apache の mod_php か)
systemctl status php-fpm httpd --no-pager | grep -E 'Loaded|Active'
httpd -M 2>/dev/null | grep -i php

CLI と Web で別の PHP が動いていることがあります。Web 側のバージョンは、phpinfo() を一時的に置くか、PHP-FPM なら php-fpm -v で確認します。

修正パッケージが出ているか(Amazon Linux 2023)

# 新しいリリースバージョンがあるか
sudo dnf check-release-update

# CVE を指定してセキュリティ更新を確認
sudo dnf updateinfo list --cve CVE-2026-109618 --releasever=latest
sudo dnf updateinfo list --cve CVE-2026-109619 --releasever=latest
Amazon Linux 2023 は、リポジトリのバージョンが AMI のリリースに固定されています。そのまま dnf update しても、新しいリリースで配布されたパッケージは入りません。--releasever=latest を付けて確認・更新します。

修正パッケージが出ているか(Amazon Linux 2)

# PHP のセキュリティ更新があるか
sudo yum updateinfo list security all | grep -i php

# amazon-linux-extras で有効にしている PHP
amazon-linux-extras | grep -i php

複数台をまとめて確認する

Systems Manager を入れている EC2 なら、Run Command で全台の PHP のバージョンを一度に集められます。

aws ssm send-command \
  --document-name AWS-RunShellScript \
  --targets Key=tag:Role,Values=web \
  --parameters 'commands=["php -v | head -1","rpm -qa php* | sort"]' \
  --comment "php2shell check"

aws ssm list-command-invocations --command-id <COMMAND_ID> --details \
  --query 'CommandInvocations[].[InstanceId,CommandPlugins[0].Output]' --output text

5. 修正パッケージを適用する

修正パッケージの配布を確認したら、更新してから PHP のプロセスをすべて再起動します。再起動しないと、古い PHP が動き続けます。

Amazon Linux 2023

# PHP のパッケージだけを最新のリリースから更新
sudo dnf upgrade --releasever=latest 'php8.3*'

# OS 全体を最新のリリースに上げる場合
sudo dnf upgrade --releasever=latest

# 再起動(php-fpm と Apache の両方)
sudo systemctl restart php-fpm
sudo systemctl restart httpd

# 確認(8.3 なら 8.3.36 以降)
php -v

php8.4 や php8.5 を使っている場合は、パッケージ名を読み替えてください。

Amazon Linux 2(Extras の php8.2)

sudo yum update 'php*'
sudo systemctl restart php-fpm
sudo systemctl restart httpd
php -v   # 8.2.35 以降

コンテナ・AMI で動かしている場合

  • ECS などのコンテナは、ベースイメージを修正版の PHP を含むものにしてイメージを作り直し、タスクを入れ替えます。
  • Auto Scaling で AMI から起動している場合は、更新済みの AMI を作って起動テンプレートを差し替えます。動いているインスタンスだけを更新すると、次のスケールアウトで古い PHP が起動します。

6. 更新できないときの暫定対策

修正パッケージが届くまでの間や、修正予定のない PHP を使っている場合は、次の対策で攻撃が成功する可能性を下げます。どれも完全な対策ではありません。更新できるようになったら、すぐに更新します。

CVE-2026-109619:アップロード進捗を無効にする

; /etc/php.ini(または /etc/php.d/ の設定ファイル)
session.upload_progress.enabled = 0

; PHP 8.5 の場合はこちらも
fatal_error_backtraces = 0

php.ini・PHP-FPM のプール設定・Apache の設定のいずれかに書き、すべてのワーカーを再起動します。ini_set() や .user.ini では効きません。アップロード進捗の機能を使っていなければ、修正後も無効のままにしておくことが推奨されています。

CVE-2026-109618:リクエストの大きさを制限する

; ファイルのアップロードがない場合
post_max_size = 8M
; アップロードがある場合(upload_max_filesize はこれより小さく)
post_max_size = 32M
  • マルチパートのリクエストを使わないサイトは、ロードバランサーや Web サーバーの手前で拒否します。
  • Web サーバーやプロキシで、リクエストの大きさ・ヘッダーの数・入力項目の数を制限します。Content-Length がないリクエストにも効くようにします。
  • PHP の開発チームは memory_limit = -1(アプリケーションから上書きできない形で設定)も挙げていますが、メモリを使い切るリスクがあるため、コンテナや cgroup のメモリ上限と組み合わせます。RLIMIT_AS などのプロセスのメモリ制限は、逆に脆弱性を引き起こすため使いません。

AWS WAF で防ぐ

ALB や CloudFront に AWS WAF を付けている場合、AWS は次の 2 つを推奨しています。

  • CVE-2026-109618:コアルールセット(CRS)の SizeRestrictions_BODY を有効にする(8 KB を超えるリクエストボディをブロック)。WordPress の管理画面からのアップロードなども止まるため、除外の条件を確認してから有効にします。
  • CVE-2026-109619:ボディに PHP_SESSION_UPLOAD_PROGRESS を含み、かつボディか Cookie に PHPSESSID を含む POST をブロックするカスタムルール(AWS は「PHP2Shell」という名前で例を示しています)を追加する。

AWS はマネージドルールの「PHP アプリケーション」ルールグループも更新する予定としています。

7. Elastic Beanstalk・Lightsail

サービスAWS の対応利用者がすること
Elastic Beanstalk10/21 に PHP プラットフォーム v4.13.12 を公開。修正版の PHP を含むプラットフォームは 10/22 に公開予定マネージドプラットフォーム更新が有効なら次のメンテナンス時間に適用される。無効なら手動でプラットフォームのバージョンを上げる
Lightsail更新したブループリントを 10/21 に公開予定動いているインスタンスは AWS では更新されない。新しいブループリントから作り直して移行するか、インスタンス内で PHP を更新する
Amazon WorkMail設定で対策済み。10/22 に PHP 8.3.36 へ更新予定対応不要

AWS のサービス自体は影響を受けていません。影響を受けるのは、利用者が上記のサービスの上で動かしている PHP です。

FAQ

よくある質問

QPHP-FPM を使っていれば安全ですか?
A

安全ではありません。攻撃の成功が実証されたのは Apache の mod_php ですが、PHP の開発チームは PHP-FPM・php-cgi・FrankenPHP・LiteSpeed も影響を受けるとしています。Web のリクエストを処理しているすべての PHP が対象です。

QWordPress などのアプリケーション側の更新は必要ですか?
A

今回の脆弱性は PHP 本体の問題で、アプリケーションのコードが実行される前に悪用されることがあります。WordPress やプラグインの更新では防げないため、PHP 本体を更新します。

QAmazon Linux 2 の標準の PHP(5.4)はどうすればよいですか?
A

Amazon Linux 2 の Core リポジトリの php パッケージは「No Fix Planned(修正予定なし)」です。暫定対策を入れたうえで、Amazon Linux 2023 など修正版の PHP が提供される環境への移行を進めてください。

Q設定変更(暫定対策)だけで十分ですか?
A

十分ではありません。PHP の開発チームも AWS も、修正版への更新だけが完全な対策だとしています。暫定対策は、修正パッケージが届くまでの間、攻撃が成功する可能性を下げるためのものです。

Qコンテナ(ECS など)で PHP を動かしている場合は?
A

ベースイメージ(php:8.3-fpm など)を修正版の PHP を含むものに更新してイメージを作り直し、タスクを入れ替えます。動いているコンテナの中で更新しても、次のデプロイで元に戻ります。

MOOBONISO/IEC 27001 CertificationAWS Partner Select Tier ServicesKinsta Agency Partner Badge
Copyright © 2026 MOOBON, Inc. All Rights Reserved.
適用規格:ISO/IEC 27001:2022
適用範囲:Web 系システム設計支援 / 自社クラウドサービス開発・運用・保守 / 受託システム開発・運用・保守 / サーバ構築・運用・保守