CentOS 7 の PHP2Shell パッチ：PHP 5.4〜8.4 の脆弱性対策（CVE-2026-109618）

著者: Danila Vershinin ・公開: 2026年10月30日・更新: 2026年10月30日

この記事は英語版の日本語訳です。

CentOS 7 の PHP2Shell は緊急の問題です。CVE-2026-109618 と CVE-2026-109619 は、認証不要のリクエスト 1 つで PHP サーバーを乗っ取れるリモートコード実行の脆弱性で、CentOS 7 向けに修正版 PHP を提供しているのは GetPageSpeed だけです。CentOS 7 で動く PHP は、標準の 5.4 から 8.4 まで、すべてのバージョンに Remi の 2 つのパッケージ形式それぞれの修正版パッケージ（パッチ適用済みビルド）があります。お使いのバージョンのチャネルから GetPageSpeed 版をインストールし、PHP-FPM を再起動してください。

他のディストリビューションをお使いの場合や、ビルドが修正済みか分からない場合は、パッケージ一覧を PHP2Shell チェッカー（英語）に貼り付けてください。ディストリビューションのバックポートも判定し、各プラットフォームの対策を表示します。Ubuntu 20.04 は PHP2Shell on Ubuntu 20.04、Graviton を含む Amazon Linux 2 は PHP2Shell on Amazon Linux 2 を参照してください（いずれも英語）。

CVE-2026-109618  RCE via out-of-memory corruption   (GHSA-w8hw-w9fx-j79w)  CVSS v4.0 9.2
CVE-2026-109619  RCE via stale global state         (GHSA-6wmf-4rv5-p3rp)  CVSS v4.0 9.2
Affected:  PHP 5.4 and later, all web SAPIs (PHP-FPM, mod_php, php-cgi, LiteSpeed, FrankenPHP)
Fixed upstream:  8.5.12, 8.4.27, 8.3.36, 8.2.35 only
CentOS 7 fix:  GetPageSpeed channels php54 php56 php70 php71 php72 php73 php74 php80 php81 php82 php83 php84

PHP2Shell 対策：CentOS 7 で修正版 PHP に更新する手順

CentOS 7 サーバーの PHP は、ほとんどが Remi リポジトリのもので、2 つの形式のどちらかで入っています。GetPageSpeed はすべてのバージョンで両方の形式を提供しています。まず、どちらの形式かを確認します。

rpm -qa 'php*-common' --qf '%{NAME}-%{VERSION}-%{RELEASE}\n'

ベース名パッケージ（remi-php74 などからの php-common-7.4.33-15.el7.remi）は、システムの PHP を置き換える形式です。お使いのバージョンのチャネルから更新します。

yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum --enablerepo=getpagespeed-extras-php74 upgrade 'php-*'
systemctl restart php-fpm

php74 はお使いのバージョンに置き換えてください：php54、php56、php70、php71、php72、php73、php80、php81、php82、php83。チャネルは上の例のように、そのトランザクションでだけ有効にしてください。各チャネルにはそれぞれのバージョンのベース名 php が入っているためです。

CentOS 7 標準の PHP 5.4（CentOS 7 に最初から入っている php-common-5.4.16-48.el7）は、php54 チャネルからパッチ適用済みの 5.4.45-20.el7 にその場で更新できます。パッケージ名、設定ファイル、拡張モジュールの ABI は変わらないため、CentOS ビルドの拡張モジュールや ionCube 5.4 ローダーもそのまま読み込まれます。mod_php のパッケージ php も更新対象に含めてください。

yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum --enablerepo=getpagespeed-extras-php54 upgrade php 'php-*'
systemctl restart httpd

ソフトウェアコレクション（remi-safe からの php74-php-common-7.4.33-15.el7.remi）は、独自のパッケージ名で並行インストールされる形式です。GetPageSpeed 版は常に有効なメインリポジトリにあるため、チャネルの指定は不要です。

yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum upgrade 'php74-php*'
systemctl restart php74-php-fpm
scl enable php74 -- php -v

他のコレクションでは、4 か所の php74 を php56〜php84 に置き換えてください。Apache の mod_php をお使いの場合は、PHP-FPM の代わりに httpd を再起動します。更新後は php -v の著作権表示の下に Built by GetPageSpeed LLC と表示されます。

PHP2Shell とは

PHP のセキュリティチームは 2026年10月20日に予告したうえで、10月21日に 2 件の重大な脆弱性情報を公開しました。研究者はこの 2 件を PHP2Shell と名付けています。日本でも IPA が注意喚起を出し、@IT などが報じています。

CVE-2026-109618：メモリ不足による破損を突くリモートコード実行。 PHP はメモリ不足（out of memory）のエラーが起きると、処理中の操作から抜け出します。これがリクエスト開始時、たとえばマルチパートのアップロードを解析している最中に起きると、リクエストのデータは半分しか初期化されていません。その後の後始末処理はそれを正しいデータとして扱うため、リクエストを操作できる攻撃者がそのメモリを操作できてしまいます。

CVE-2026-109619：古いグローバル状態を突くリモートコード実行。 リクエストが持つ状態の一部が、メモリ解放後も残ります。同じワーカーが処理する次のリクエストは、通常の初期化でリセットされる前にそれを使ってしまうことがあります。確認されている経路には、セッションのアップロード進捗と、初期化前に出力される INI の診断メッセージがあります。

どちらも CVSS v4.0 で 9.2、認証は不要です。php.net は、Web リクエストを処理するすべての PHP 環境が危険にさらされているとしており、最も深刻なのは mod_php です。実証されたエクスプロイトはアプリケーションのコードが動く前に発動します。Tenable は PHP2Shell がすでに広く悪用されていると報告しており、Amazon のハニーポットは公開の 4 日前に攻撃の試みを観測しています。

PHP2Shell の影響確認：CentOS 7 で影響を受けるサーバー

Web で PHP を提供している CentOS 7 / RHEL 7 サーバーは、修正版のビルドをすでに使っている場合を除き、すべて影響を受けます。PHP-FPM、Apache mod_php、php-cgi のどれでも同じです。PHP 8.2 と 8.3 も例外ではありません。上流はこれらのブランチを修正しましたが、Remi の CentOS 7 向けビルドは 8.2.20 と 8.3.8 で止まっているため、yum update では修正版が届きません。

IPA の注意喚起で修正版が示されているのは 8.2〜8.5 だけですが、IPA が引用する Wiz の分析のとおり、PHP 5.4 以降のすべてのバージョンが影響を受けます。CentOS 7 で多く使われている 5.4、5.6、7.x も対象です。

CentOS 7 のサーバーに修正版が届かない理由

PHP プロジェクトが修正したのは、サポート中のブランチ（8.5.12、8.4.27、8.3.36、8.2.35）だけです。7.4、8.0、8.1 には最小限のソースのみのバックポートを公開し、PHP 7.3 以前には何も公開していません。

CentOS 7 サーバーの多くは Remi リポジトリの PHP を使っていますが、Remi は 2024年6月に EL7 向けのビルドを終了しています。公開当日、php.net は Remi の利用者に対して、その日のうちにリポジトリの更新はないのでソースからビルドするよう案内しました。ホスティング事業者は顧客に、自分でサーバーにパッチを当てるよう連絡しました。

つまり、Remi の PHP を使う CentOS 7 ホストに残された選択肢は 3 つでした。パッチを手作業で移植して PHP をソースから再ビルドするか、パッケージ名やパスが異なる商用の延長サポートを契約するか、脆弱なまま運用するかです。

暫定策（memory_limit / session.upload_progress）だけでは不十分な理由

脆弱性情報には暫定策として memory_limit=-1、小さな post_max_size、session.upload_progress.enabled=0 が挙げられています。更新の準備をしている間に適用する価値はありますが、PHP チームは完全な対策は更新だけだと明言しています。メモリ制限を外しても、実際のメモリ確保の失敗は脆弱な処理に到達しますし、アップロード進捗を無効にしても防げるのは CVE-2026-109619 の確認済みのセッション経路だけで、他の経路は残ります。

PHP の前段で NGINX が防げること、防げないことは PHP2Shell mitigation in NGINX（英語）にまとめています。

PHP 5.4〜8.4 の PHP2Shell 修正パッチ（バージョン別）

GetPageSpeed は Remi の EL7 向け PHP のすべてのブランチを、PHP2Shell の修正を入れて再ビルドしました。どのパッケージも Remi のパッケージ名、ABI、ライブラリの SONAME を保っているため、yum upgrade でその場で入れ替わります。PECL 拡張モジュールや ionCube Loader も再ビルドなしで動きます。各バージョンのページに、含まれるセキュリティ修正の一覧があります（英語）。

PHP	ベース名チャネル	修正版ビルド（両形式）	修正の出どころ
5.4	`getpagespeed-extras-php54`	`5.4.45-20.el7`	PHP 5.6 向けの適用を 5.4 に移植。CentOS 7 標準の `php-5.4.16` とそのまま置き換え可能
5.6	`getpagespeed-extras-php56`	`5.6.40-44.el7`	上流 7.4 の修正を PHP 5.6 に適用し、差分ごとに監査。他の 5.6 移植が省いている executor 終了時のリセットも含む
7.0	`getpagespeed-extras-php70`	`7.0.33-46.el7`	公式 7.4 修正の移植
7.1	`getpagespeed-extras-php71`	`7.1.33-35.el7`	公式 7.4 修正の移植
7.2	`getpagespeed-extras-php72`	`7.2.34-30.el7`	公式 7.4 修正の移植
7.3	`getpagespeed-extras-php73`	`7.3.33-26.el7`	公式 7.4 修正をそのまま適用
7.4	`getpagespeed-extras-php74`	`7.4.33-35.el7`	公式 7.4 修正（Remi が保守する 7.4 ソースに含まれるもの）
8.0	`getpagespeed-extras-php80`	`8.0.30-25.el7`	PHP 8.0 の公式バックポートを 1 行ずつ検証
8.1	`getpagespeed-extras-php81`	`8.1.34-8.el7`	8.1 の公式バックポート。Remi が保守する 8.1.34 から再ビルド（EL7 は 8.1.29 で停止）
8.2	`getpagespeed-extras-php82`	`8.2.35-2.el7`	上流の PHP 8.2.35（EL7 は 8.2.20 で停止）
8.3	`getpagespeed-extras-php83`	`8.3.36-2.el7`	上流の PHP 8.3.36（EL7 は 8.3.8 で停止）
8.4	`getpagespeed-extras-php84`	`8.4.27-3.el7`	上流の PHP 8.4.27

各バージョンのソフトウェアコレクション（php56-php-*〜php84-php-*）は、メインの getpagespeed-extras リポジトリにあります。PHP 8.4 には CentOS 7 向けの Remi ビルドが存在しなかったため、php84-php は GetPageSpeed 独自のコレクションです。scl enable php84 は他と同じように使えます。

PHP2Shell 以外の修正も含みます。 Remi は EL7 向けのビルドを終えた後も、EL8 以降向けにサポート終了（EOL）済みの PHP の修正を続けました。GetPageSpeed のビルドはその保守されたソースを元にしているため、EL7 には届かなかった 2024〜2026年の修正も含みます。Remi のソースが 2026年10月のセキュリティ修正より前で止まっているバージョン（5.6、7.0、7.1、7.2、7.3）には、GetPageSpeed がその修正（mysqlnd、OpenSSL のホスト名検証、SOAP、phar、ストリームフィルター、FastCGI の ACL、HTTP リダイレクト）を自ら移植しています。

Oracle（oci8）。 5.6〜8.3 のすべてのチャネルに php-oci8 と phpNN-php-oci8 があり、Remi のビルドと同じく Oracle Instant Client 21 にリンクしているため、既存の oci8 環境もそのまま更新できます。oracle-instantclient-basic 21.x は Oracle から入手してください。GetPageSpeed は Oracle のライブラリを再配布していません。

PHP 8.4 の違い。 oci8 はありません（上流がコアから削除）。zip は同梱の拡張モジュールです（php-zip / php84-php-zip）。8.4 は EL7 の古いライブラリではなく、保守されているライブラリ（OpenSSL 3.5 LTS、ICU 74、libzip 1.11、libpq 17、libxml2 2.13）にリンクしています。

各ビルドの検証方法。 クリーンな CentOS 7 コンテナで、置き換え対象の Remi パッケージをそのままインストールし、PHP2Shell の 2 つの検証コードが再現することを確認します。次にその場で更新し、両方が修正されたことを確認します。さらに次の点も確認しています。

phpt テストスイート全体で、修正により意図的に挙動が変わるテストを除き、Remi 版と比べて退行がないこと
php -m のモジュール一覧が、PECL 拡張モジュールと ionCube を含めて同じであること
設定ファイルが保持され、メモリ不足のリクエストの後も PHP-FPM が応答し続けること
yum downgrade で Remi のパッケージに戻せること

パッケージのテストとは別に、実際のページをすべてのチャネルで、Apache mod_php と PHP-FPM の両方を通して配信するランタイムテストも用意しています。シナリオは 4 つで、新規インストール、PECL 拡張モジュールと ionCube を読み込んだ状態での Remi からの更新、そしてソフトウェアコレクションで同じ 2 つです。変更のたびに実行し、公開リポジトリに対しても毎晩実行しています。

最初のビルドは公開翌日の 10月22日に、PrestaShop 1.6、Magento 1、独自開発の PHP 8.0 のサーバーで本番投入されました。停止時間は PHP-FPM の再起動だけでした。

サーバーが脆弱かどうかの確認方法

rpm -qa 'php*-common' --qf '%{NAME}-%{VERSION}-%{RELEASE}\n'

リリースが .el7.remi で終わるものは脆弱です。Remi の EL7 ビルドはすべて修正より前のものです。更新後は、上の表にある GetPageSpeed のリリース（php-common-7.4.33-35.el7 や php82-php-common-8.2.35-2.el7 など）が表示されます。

rpm が使えず php だけ使える場合は、現行の GetPageSpeed ビルドなら php -v に正確なリリースが表示されます。

php -v | grep 'Built by'

Built by GetPageSpeed LLC (7.1.33-42.el7)

このリリースを上の表と比べるか、php -v の出力全体を PHP2Shell チェッカーに貼り付けてください。リリースのない Built by GetPageSpeed LLC だけの表示は古いビルドなので、上の rpm コマンドで確認してください。

元に戻す方法と注意点

必要になれば yum downgrade で Remi のパッケージに戻せます。PHP 8.0（どちらの形式も）の戻し先は Remi の 8.0.30-6 です。古い 8.0.30-3 は Remi のミラーにもう存在しません。PHP 8.4 には戻し先の Remi ビルドがないため、以前の PHP バージョンに戻すことになります。

バックポートしたブランチ（5.6〜8.1）では、1 つ挙動が変わります。memory_limit に達したリクエストは、そのワーカーを即座に終了します。シャットダウン関数は実行されず、バッファ済みの出力も送信されません。これは PHP のセキュリティチームが自らの EOL 向けバックポートで選んだのと同じ判断です。安全でない巻き戻し処理こそが PHP2Shell に悪用されているためです。メモリ不足をシャットダウンハンドラーで捕捉することに頼っているコードは、見直しが必要です。

最後に、CentOS 7 そのもののサポートは終了したままです（2024年6月30日にサポート期限切れ）。これらのチャネルが修正し続けるのは PHP の層であり、OS がサポート対象になるわけではありません。GetPageSpeed が EL7 向けに保守しているその他のもの（最新の LTS カーネルを含む）は Everpatch for CentOS 7（英語）で扱っています。移行は計画しつつ、それまで脆弱なまま運用しないでください。

よくある質問

CentOS 7 の PHP 7.4 は CVE-2026-109618 の影響を受けますか？

はい。PHP2Shell は 5.4 以降のすべてのブランチに影響し、Remi の EL7 向け PHP 7.4 の最終ビルドは修正より前のものです。Remi の php74 ソフトウェアコレクション（php74-php-* パッケージ）の場合は、GetPageSpeed のリリースパッケージをインストールして yum upgrade 'php74-php*' を実行します。ベース名でのインストール（remi-php74 からの php-7.4.33-15.el7.remi）の場合は、代わりに yum --enablerepo=getpagespeed-extras-php74 upgrade 'php-*' を実行します。

CentOS 7 の PHP 5.6 にセキュリティパッチはありますか？

あります。getpagespeed-extras-php56 チャネルの php-5.6.40-44.el7 には、PHP2Shell の修正と、Remi が EL8 向けにしか公開しなかったその後のセキュリティ修正が含まれ、Remi の remi-php56 パッケージとそのまま置き換えられます。php56-php コレクションにも同じビルドがメインリポジトリから提供されます。

CentOS 7 の PHP 8.3 は修正されていますか？

はい。Remi の CentOS 7 向け PHP 8.3 は 8.3.8 で止まっていますが、getpagespeed-extras-php83 チャネルで上流の修正版 8.3.36（8.3.36-2.el7）を提供しています。php83-php コレクションも同じです。

WordPress やプラグインを更新すれば PHP2Shell は防げますか？

いいえ。PHP2Shell は PHP 本体の脆弱性で、アプリケーションのコードが動く前に発動します。WordPress やプラグインの更新では直らず、PHP そのものを修正版に更新する必要があります。

WAF で PHP2Shell は防げますか？

WAF は一時的な緩和策にはなりますが、完全な対策ではありません。悪用されるのはリクエストの解析と後始末の段階で、PHP チームも完全な対策は更新だけだとしています。NGINX で防げる範囲は PHP2Shell mitigation in NGINX（英語）を参照してください。

PHP のバージョンを確認するには？

php -v を実行します。CentOS 7 では、どの形式・どのリポジトリのパッケージかを判断するため、上の rpm -qa 'php*-common' の結果も確認してください。

CentOS 7 のサポート期限はいつですか？

CentOS 7 のサポートは 2024年6月30日に終了しました。それ以降、OS のセキュリティ更新は提供されていません。PHP の層は GetPageSpeed のチャネルで修正できますが、移行の計画は別途必要です。

PHP 7.1 と 7.2 は？

どちらも 10月24日から対応しています：getpagespeed-extras-php71（7.1.33-35.el7）と getpagespeed-extras-php72（7.2.34-30.el7）。両方の形式があり、インストール手順は他のバージョンと同じです。

PHP2Shell の修正に GetPageSpeed のサブスクリプションは必要ですか？

個人利用・開発・評価目的であれば必要ありません。パッケージは公開の GetPageSpeed リポジトリから登録なしで無料でインストールできます。商用の本番環境での利用には、リポジトリ利用規約（英語）に基づき GetPageSpeed Ultra（年額 $500、最大 10 台）が必要です。Ultra がこれらのバックポートの費用をまかない、次の EOL PHP の脆弱性にも対応し続けます。

PECL 拡張モジュールや ionCube Loader はそのまま動きますか？

はい。修正は構造体のレイアウトや API 番号を変えておらず、検証でも更新前後で読み込まれるモジュール一覧が同じであることを確認しています。

session.upload_progress.enabled=0 だけで十分ですか？

いいえ。CVE-2026-109619 の確認済みの経路を 1 つ塞ぐだけで、CVE-2026-109618 には効果がありません。PHP のセキュリティチームは、完全な対策は更新だけだとしています。

まとめ

CentOS 7 の PHP2Shell は、認証不要の深刻なリモートコード実行の脆弱性であり、Remi の PHP を使うサーバーには上流からもディストリビューションからも修正版が届きません。GetPageSpeed のチャネルは、5.4〜8.4 のすべての PHP について、その場で置き換えられ、検証済みで、無料でインストールできる修正版でこの穴を埋めます。

業務でこれらのサーバーを運用していますか？ 商用の本番環境での利用には GetPageSpeed Ultra（年額 $500、最大 10 台）が必要です。新しい PHP の脆弱性が出るたびに、上流が何年も前に見放したブランチへ修正を移植し直す必要があります。Ultra はその作業をまかない、最大 10 台のサーバーを次の脆弱性にも備えた状態に保ちます。CentOS 7 向けの NGINX ビルドとモジュールを含む GetPageSpeed リポジトリ全体も利用できます。お支払い画面（Stripe）は日本語で表示されます。

CentOS 7 サーバーの対策は PHP だけでは半分です。前段の NGINX も、設定変更のたびに少しずつずれていきます。GetPageSpeed Amplify は全ホストで gixy による定期スキャンを実行し、検出結果を NGINX の実行時メトリクスと結び付けます。サポートが終了した nginx-amplify-agent（2026年1月に EOL）とそのまま置き換えられます。