Amazon LinuxのPHPをアップデートする手順（php2shell脆弱性への対応）

自分が所有する、または管理を任されているサーバーだけを確認してください。当サイトは独立した個人運営のサイトで、PHP Group・php.netとは無関係です。サイトやサーバーへアクセスして検査することはありません。

結論

この記事のAWSの各ページへの参照は、2026年10月22日に確認した内容です。

PHP本家は、2件の脆弱性（CVE-2026-109618・CVE-2026-109619）を 8.2.35・8.3.36・8.4.27・8.5.12 で修正しました。Amazon Linuxのパッケージには、PHPの版番号のあとにディストリビューション固有のリリース番号が付くので、php.netの版番号だけでなく、下の表のAmazon Linuxの修正パッケージ番号（バージョン-リリース）の全体と比べてください。2026-10-22 時点の状況は次のとおりです。

• Amazon Linux 2023（AL2023）：php8.2〜php8.5 に修正パッケージがあります。php8.1 は、Amazonが 「No Fix Planned」（対応予定なし） としており、修正パッケージはありません。
• Amazon Linux 2（AL2）：Amazonが修正を示しているのは amazon-linux-extras の php8.2 だけです（ほかのextrasの系統についてAmazonの記載は見つかっていません）。コアリポジトリの php は 「No Fix Planned」（対応予定なし） です。
• Amazon Linux 2027 Preview：php8.5 に修正パッケージがあります（プレビューリリースです）。

AL2023で最もつまずきやすい点：AL2023はAMIごとにリポジトリのバージョンが固定（ロック）されています。そのため、古いAMIから作ったインスタンスで普通に sudo dnf upgrade を実行しても、更新が見つからない（Nothing to do）状態になり、修正パッケージが見えないことがあります。手順3の --releasever=latest を付けて実行してください。更新後はPHP-FPM（Apacheのmod_phpならApache）の再起動も必要です。

手元の版を入力して確認したい場合はチェックツール、全環境の一覧は修正版一覧をご覧ください。

背景

PHP公式は、2件の脆弱性（いずれもCVSS 4.0で9.2）により、Webリクエストを処理するPHP全般で、認証なしのリモートコード実行（外部の第三者にサーバー上でプログラムを実行されること）が起こり得ると公表しています（PHP公式アドバイザリ）。AWSもセキュリティ情報 2026-143-AWS（2026年10月21日公開、最終更新 10/21/2026 20:30 PDT）で、Amazon Linuxで稼働するPHPには更新版のパッケージを適用するよう案内しています。この情報には、修正済みのPHPへ直ちにアップグレードすることが「唯一の完全な対処（the only complete fix）」とも書かれています。

AWSはこの情報で、暫定対策のWAFルール例も公開しています。当サイトでは内容を転載しません。リクエストの照合パターンなどを含むため、必要な場合は元の情報で確認してください。ただし、それは更新の代わりにはなりません。

Amazon Linuxの修正公告（ALAS）には重要度 Important と書かれています。これはAmazon自身の評価尺度です。更新が必要かどうかの判断はPHP公式の案内に従ってください。

修正パッケージの一覧

下の表は、AWSの公式公告（ALAS）に基づく当サイトのデータから自動で表示しています。「修正版（以上）」の列が、各行で修正を含む最初のパッケージ番号です。状況の語だけで番号がない行は、Amazonが修正パッケージを示していない行です。「修正パッケージがない」ことは、その環境が問題ない、という意味ではありません。

AWSの情報には、地域についての注記もあります。商用リージョンでは更新版パッケージが利用可能で、非商用リージョンは2026年10月22日の提供が目標とされていました（2026-143-AWS、2026年10月22日確認）。お使いのリージョンで dnf や yum が修正パッケージを出さない場合は、まだ届いていない可能性があります。

手順1：OSとPHPのパッケージを調べる

cat /etc/system-release        # Amazon Linuxのリリース（AL2023かAL2か）
cat /etc/system-release-cpe    # 同じ情報をCPE形式で表示
rpm -q system-release          # AL2023：現在のリポジトリのリリースバージョン

AWSの命名とバージョン管理のページでは、OSの識別に /etc/system-release-cpe を読む方法が案内されています。同じページには、/etc/amazon-linux-release が /etc/system-release へのシンボリックリンクだとも書かれています。

入っているPHPのパッケージを一覧します。AL2023のPHPは、系統ごとに php8.1〜php8.5 というパッケージ名です。

# Amazon Linux 2023
sudo dnf list installed 'php*'

# Amazon Linux 2
yum list installed | grep php
yum list installed | grep amzn2extra-php8.2     # 出力があれば、extrasのphp8.2系統

'php*' のようにパッケージ名にワイルドカードを使う書き方は、DNFの公式ドキュメントにある、シェルと同じ照合規則です。

版のリリース番号まで含めて確認するには、RPMのクエリを使います。出力は、当サイトのチェックツールに貼り付けて比較できます。

rpm -q php8.3-cli      # AL2023：自分の系統に置き換え（例：php8.5-cli）。AL2は rpm -q php-cli

AWSの古い手順で入れた場合の注意：AWSのLAMPチュートリアルは、バージョンを付けない php-fpm・php のパッケージを入れる手順です。本文には「現在は8.1」とありますが、この記述は古く、AL2023は現在 8.1〜8.5 を提供しています（AWS：AL2023のPHP）。その手順で入れた環境は php8.1 のままの可能性があるので、必ず rpm -q で実際の系統を確認してください。

PHPがPHP-FPM経由か、Apacheのmod_php（httpd の中で動く）かで、手順4で再起動する対象が変わります。php.netはmod_phpを最もリスクが高い構成として挙げています。

手順2：修正パッケージの番号と比べる

上の表の自分の行（AL2023なら系統ごとの行）を見て、インストール済みの バージョン-リリース の全体が、修正版と同じか、それより新しいかを比べます。パッケージの中に書かれたPHPの版番号（8.3.xなど）ではなく、パッケージ番号全体で判断します。

「修正が入っているか」を rpm -q --changelog でCVE番号を検索して調べる方法はおすすめしません。AL2023の修正パッケージのチェンジログは「Package updated to 8.3.36」のような1行で、CVE番号は書かれていません（AWSのリポジトリのメタデータで確認、2026年10月22日）。

AL2023で「自分のインスタンスに適用できる公告（ALAS）は何か」を調べる、AWS公式の方法があります。

dnf updateinfo --releasever=latest --list

出典：AWS：適用可能な公告の一覧。AWSのページには、この形で最新リリースのメタデータを指定できると書かれています。

手順3：バックアップを取ってから更新する

更新前に、EBSのスナップショットかAMIを取得します。PHPの系統（8.2から8.3など）を変える場合は特に重要です。AWSのEBSスナップショットの作成とAMIの作成の案内（日本語ページは機械翻訳で、英語版が優先されます）では、AMIはインスタンスを選び、［アクション］→［イメージとテンプレート］→［イメージの作成］で作ります。そのときの［インスタンスを再起動］のチェックを外すと、イメージのファイルシステムの整合性は保証されません。コンソールの表示は変わることがあります。

Amazon Linux 2023

AWSの説明では、AL2023の各AMIは特定のバージョンのAL2023にロックされ、新しいパッケージ更新とセキュリティ更新は新しいリポジトリバージョンにのみ提供されます（AWS：リポジトリとOSの更新、確定的アップグレード）。インストール直後の状態では、releasever の上書き設定がなく、system-release のバージョンで固定されているため、利用できる更新はありません。

まず、最新リリースにセキュリティ更新があるかを確認します。

sudo dnf check-update --releasever=latest --security

AWSが推奨するのは、新しいリリースの更新をすべて適用する方法です。

sudo dnf upgrade --releasever=latest

AWSの確定的アップグレードのページによると、このコマンドは system-release も更新します。そのため、実行後は固定先が新しいリリースに変わり、次に新しい更新を受け取るには、もう一度 --releasever=latest を付けて実行する必要があります。

• AWSは、新しいリリースの更新は、個別に選ぶよりすべてインストールすることを推奨しています。AL2023の最新リポジトリの更新がカーネルを含む場合は、有効にするために再起動が必要です。本番では、先に検証用の環境で試してください。
• --security を付けた dnf upgrade は、公告（Advisory）のあるパッケージだけに更新を絞ります（AWS：インプレース更新）。ただし、AWSは全体の更新を勧めています。
• 同じ記述の中で、latest を永続的な設定にする方法（/etc/dnf/vars/releasever）も説明されていますが、AWSは固定を外すと本番環境との非互換が起こり得ると警告しています。このページでは、毎回 --releasever=latest を明示する方法だけを使います。

PHPのパッケージだけを更新したい場合は、パッケージ名を一緒に指定します。AWSの手順では、system-release を変えずに更新するために、パッケージ名とあわせて --releasever=latest を使います。

sudo dnf upgrade --releasever=latest 'php8.3*'      # 8.3は自分の系統に置き換え

ただし、AWSは次のように警告しています。ロックされたままのリポジトリで、新しいリリースの更新だけを個別に入れると、依存パッケージが変わっていて、あとから行うdnfの操作（インストールや更新）でうまく解決できなくなることがあります（AWS：インプレース更新）。このため、PHPだけの更新は例外的な方法と考え、可能なら全体の更新を選んでください。

sudo dnf check-release-update を使うと、新しいリポジトリのバージョンの一覧を見られます。EC2のようなコンテナ以外の環境では、このコマンドが標準で入っています（コンテナイメージには入りません）。参考：--releasever=latest は、2026年10月22日の確認時点では、リリース 2023.12.20261021 と同じリポジトリを指していました。AWSのリリースノートの「Core Updated Packages」には、php8.2 〜 php8.5 のパッケージが載っています（リリースノート）。このリリースには php8.1 のパッケージは載っていません。latest が指すリリースは新しい更新で変わるので、この対応は確認日時点のものです。

AWSのALAS2023公告のページには、実行する dnf のコマンドは書かれていません。ここまでのコマンドは、AL2023のユーザーガイドに基づいています。

php8.1 に修正パッケージはありません。php.netでもサポートが終了した系統です。AWSはセキュリティ情報の中で、PHP 5.4〜8.1には上流の修正がなく、サポートされる系統への移行が必要だと説明しています（AWSの表現です）。一方、php.netは7.4・8.0・8.1向けに、ソースだけの最小限のバックポートを用意したと公表しています（リリースやバージョン番号はありません。PHP公式アドバイザリ）。AL2023が提供するのは8.1〜8.5です。移行の考え方や、このソース版の位置づけはPHP 7.4・8.0・8.1 サポート終了後の対応をご覧ください。

Amazon Linux 2

AL2は2026年6月30日にサポートが終了しており、標準のセキュリティ更新は提供されません（AL2のFAQ、2026年10月22日確認。ALASの公告のヘッダーも「Amazon Linux 2 (EOS)」と表示）。そのうえで、amazon-linux-extras の php8.2 系統には、Amazonが修正公告を出しています（ALAS2PHP8.2-2026-015）。公告に書かれたAmazon公式のコマンドは次のとおりです。

sudo yum update php

公告には、この更新のほかにpcre2のCVE（CVE-2026-103111）の修正もまとめて含まれており、本ページの対象外です。

• コアのAL2リポジトリの php パッケージには修正がありません（「No Fix Planned」（対応予定なし））。
• そのほかの extras の系統についてのAmazonの記載は、当サイトでは見つかっていません。AWSのextras一覧（2026年10月22日確認）では、php8.1 の非推奨日は2025年12月31日で、php8.2 には非推奨日の記載がありません。利用できるトピックは amazon-linux-extras list で確認できます。
• AL2自体がサポート終了済みなので、AL2023への移行を計画してください。PHPの版が変わる移行は、アプリの動作確認が必要です。

AL2のPHP-FPMのサービス名は、当サイトでは確認できていません。手順4の再起動では、まず systemctl list-units 'php*' で実際の名前を調べてください。

Amazon Linux 2027 Preview

プレビューリリースです。公告（ALAS2027-2026-243）には、php8.5 の修正パッケージ 8.5.12-1.amzn2027.0.1 と、次の更新コマンドが書かれています。

sudo dnf update php8.5

手順4：PHP-FPMとApacheを再起動する

パッケージを更新しても、動いているPHPのプロセスが新しい版に入れ替わるとは限りません。AWSは、更新後はサービスの再起動で足りる場合もあるとしつつ、システムの再起動をすると以前のパッケージ更新が確実に反映されるとしています（AL2の更新）。

AL2023では、php8.3-fpm のようにバージョン付きのパッケージでも、systemdのユニット名は php-fpm.service です（php8.3-fpm パッケージのファイル一覧で確認しました。ほかの系統も同じ名前のはずですが、個別には確認していません）。AWSのLAMPチュートリアルも php-fpm という名前で再起動しています。

sudo systemctl try-restart php-fpm httpd

try-restart は、動いているサービスだけを再起動し、止まっているサービスには何もしません（systemctlのマニュアル）。Nginxの場合は、通常はPHP-FPMの再起動だけで足ります。

AL2023には smart-restart というパッケージがあり、AWSの説明では、sudo dnf install smart-restart でインストールすると、以後のdnfの操作でsystemdのサービスが自動で再起動されます（AWS：リポジトリとOSの更新）。rpm -q smart-restart で入っているか確認できます。標準で入っているかは、AWSの記述からは断定できません。PHPが自動で再起動されることを前提にせず、上のように自分で再起動し、状態を確認してください。

systemctl is-active php-fpm httpd

コンテナでPHPを動かしている場合は、パッケージを更新するのではなく、イメージをビルドし直してコンテナを作り直します。

手順5：更新できたか確認する

rpm -q php8.3-cli      # AL2023：自分の系統に置き換え。AL2は rpm -q php-cli

• 表の修正版と、インストール済みの バージョン-リリース の全体を比べます。php -v の表示ではなく、パッケージ番号で判断します。
• 出力は、当サイトのチェックツールに貼り付けても、同じデータとの比較ができます。入力した内容はブラウザの中だけで処理され、外部には送信されません。
• 再起動してから確認してください。ディスク上のパッケージが新しくなっていても、メモリ上のプロセスが古いままのことがあります。

Elastic BeanstalkとLightsailの場合

• Elastic Beanstalkはパッケージではなく、プラットフォームバージョンを更新します。AWSは、Amazon Linux 2023のPHPプラットフォームで修正版を提供したとしており、お客様側では環境のプラットフォームバージョンの更新が必要です（マネージドプラットフォーム更新を有効にした環境は、次のメンテナンスウィンドウで自動的に更新されます）。AWS自身の発表の要点と確認日は、下の表のとおりです。新しいプラットフォームバージョンがお使いのリージョンですぐには使えない場合もあるため、AWSのプラットフォーム履歴で、お使いのPHPの系統に修正版が含まれているかを確認してください（2026年10月22日時点の記載で、更新が続いています）。そのほかの状況は、当サイトの対応状況ページにまとめています。
• Lightsail：AWSは、Amazon LinuxなどのOSブループリントで作ったインスタンスには、自分で入れていない限りPHPは含まれないと説明しています。PHPを入れた場合は、このページのAmazon Linuxの手順で更新します。LightsailのWordPress・LAMPなどのブループリントは apt ベースです（AWSのLightsailのページ、2026年10月22日確認）。その場合はUbuntuとDebianの手順を参照してください。

修正パッケージがない場合

AL2023の php8.1、AL2のコアの php、およびAL2のextrasのうち修正が確認できていない系統が該当します。

• 修正のある系統（AL2023の8.2〜8.5、AL2のextrasの php8.2）への移行が、AWSが示している方向です。移行する前に、アプリの動作を検証環境で確認してください。
• 暫定的な対策はPHP公式アドバイザリを確認してください。ただし、更新の代わりにはならず、特定の攻撃経路への露出を減らすだけです。
• 当サイトの考え方として、版番号を揃えるためだけにPHPをソースからビルドすることは、第一の選択肢にはしていません。以後の更新をすべて自分で管理することになるためです。php.netが7.4・8.0・8.1向けに用意したソースの移植は、ほかに手段がない場合の一時しのぎとして位置づけています（詳しくはPHP 7.4・8.0・8.1 サポート終了後の対応）。

関連ガイド

• 修正版一覧：全ディストリビューション・全系統
• ホスティング別 対応状況：AWSなどの公式発表
• UbuntuとDebianのPHPアップデート手順
• PHPバージョンの確認方法
• PHP 7.4・8.0・8.1 サポート終了後の対応
• WordPressサイトの対応手順

自分のサーバーに合わせた手順がほしいとき

リポジトリのバージョン、PHPの系統、再起動の順番を自分で整理するのが難しい場合は、$49の個別パッチ対応プランがあります。お使いの環境に合わせた手順を、24時間以内にメールでお届けします。サーバーにログインすることはなく、手順書をお届けする形です。詳しくはこちらをご覧ください。