CentOS 6 の PHP2Shell パッチ：PHP 5.3 / 7.0 / 7.1 の脆弱性対策（CVE-2026-109618）

著者: Danila Vershinin ・公開: 2026年11月2日

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

CentOS 6 の PHP2Shell には、ディストリビューションからも上流からも修正が提供されていません。CVE-2026-109618 と CVE-2026-109619 は、認証不要のリクエスト 1 つで PHP サーバーを乗っ取れる、緊急のリモートコード実行の脆弱性ですが、CentOS 6 のサポートは 2020年に終了しています。GetPageSpeed は、CentOS 6 向けに 3 つの PHP 系統の修正版を提供しています。標準の PHP 5.3 と、Remi のパッケージ名で動く PHP 7.0 / 7.1 です。いずれも yum でその場で更新できます。

CentOS 7 をお使いの場合は CentOS 7 の PHP2Shell パッチをご覧ください。ビルドが修正済みか分からない場合は、パッケージ一覧を PHP2Shell チェッカー（英語）に貼り付けてください。

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 per the advisory, all web SAPIs (PHP-FPM, mod_php, php-cgi)
Fixed upstream:  8.5.12, 8.4.27, 8.3.36, 8.2.35 only
CentOS 6 fix:  GetPageSpeed php-5.3.3 (main repository), php70 and php71 channels, x86_64

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

まず、使っている PHP を確認します。

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

yum がどのリポジトリにも接続できない場合は、先にそれを直してください。CentOS 6 のミラーは廃止されています。vault に向ける手順は How to fix yum after CentOS 6 went EOL（英語）にあります。

CentOS 6 標準の PHP 5.3（php-common-5.3.3-50.el6_10 以前）は、GetPageSpeed のメインリポジトリから更新します。チャネルの指定は不要です。

yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum update 'php*'
service httpd restart   # or: service php-fpm restart

Remi の PHP 7.0 / 7.1（remi-php70 や remi-php71 からの php-common-7.1.33-10.el6.remi など）は、お使いのバージョンのチャネルから更新します。

yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum --enablerepo=getpagespeed-extras-php71 update 'php*' libicu-last libwebp
service php-fpm restart   # or: service httpd restart

PHP 7.0 の場合は php71 を php70 に置き換えてください。チャネルは上の例のように、そのトランザクションでだけ有効にしてください。チャネルにはベース名の php が入っているため、有効のままにすると、以後の yum update でそのバージョンが提案されてしまいます。

新規の CentOS 6 ホストの場合は、update 'php*' libicu-last libwebp を install php-cli php-fpm と必要な拡張モジュールに置き換えてください。EPEL は不要です。CentOS 6 にないライブラリは GetPageSpeed リポジトリから入ります。

PHP2Shell とは

PHP のセキュリティチームは 2026年10月21日に 2 件の重大な脆弱性情報（GHSA-w8hw-w9fx-j79w、GHSA-6wmf-4rv5-p3rp）を公開しました。研究者はこの 2 件を PHP2Shell と名付けています。日本でも IPA が注意喚起を出しています。

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

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

どちらも CVSS v4.0 で 9.2、認証は不要です。php.net は、Web リクエストを処理するすべての PHP 環境が危険にさらされているとしており、最も深刻なのは mod_php です。

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

CentOS 6 のサポートは 2020年11月30日に終了したため、標準の PHP 5.3.3 に新しいパッケージが出ることはありません。PHP プロジェクトが修正したのはサポート中のブランチだけで、7.4、8.0、8.1 にはソースのバックポートを公開しましたが、PHP 7.3 以前には何も公開していません。Remi の CentOS 6 向けリポジトリはアーカイブされており、新しいものは入ってきません。

つまり CentOS 6 のホストに残された選択肢は 4 つでした。パッチを手作業で移植して PHP を再ビルドするか、商用の延長サポートを契約するか、サーバー全体を今すぐ移行するか、脆弱なまま運用するかです。

PHP 5.3 は影響を受けますか？

脆弱性情報で公表されている範囲は PHP 5.4 からで、PHP プロジェクトは 5.3 を評価していません。5.3 のサポートは 2014年に終了しているためです。「5.3 が載っていない」は「確認されていない」という意味であり、「安全」という意味ではありません。

問題の構造は 5.4 より前からあります。CentOS 6 標準の PHP 5.3.3 でも、メモリ不足の処理は CVE-2026-109618 に悪用されるのと同じ形で巻き戻され、下の確認コマンドでその挙動を再現できます。これは危険な巻き戻しの証明であり、5.3 に対して動作するエクスプロイトの証明ではありません。修正でリセットされる古い状態のコードも、5.4 で追加されたセッションのアップロード進捗を除いて 5.3 に存在します。

それでも GetPageSpeed が 5.3 を修正したのは、評価されていないブランチを公開インターネットで動かし続けるリスクは負うべきではないからです。PHP2Shell チェッカー（英語）も、同じ理由で標準の 5.3 を脆弱と判定します。

PHP 5.3 / 7.0 / 7.1 の PHP2Shell 修正パッチ（バージョン別）

PHP	置き換え対象	インストール元	現在のビルド	修正を含む最初のビルド
5.3	標準の `php-5.3.3`	メインリポジトリ	`5.3.3-54.el6`	`5.3.3-51.el6`
7.0	Remi の `remi-php70`	`getpagespeed-extras-php70`	`7.0.33-52.el6`	`7.0.33-49.el6`
7.1	Remi の `remi-php71`	`getpagespeed-extras-php71`	`7.1.33-42.el6`	`7.1.33-40.el6`

7.0 と 7.1 のビルドには、公式の PHP 7.4 修正の移植が入っています。5.3 のビルドは、同じ修正を私たちの 5.4 向け移植から適用し、5.3 にはなかった文字列オーバーフローの検査も追加しています。これらのビルドには PHP2Shell 以外の修正も多数含まれており、一覧は各バージョンのページ（英語）にあります。

パッケージ名は今お使いのものと同じなので、その場で更新できます。設定ファイルはそのままで、PHP の API と ABI も変わらないため、サーバーにある PECL 拡張モジュールもそのまま読み込まれます。CentOS 6 向けビルドはベース名の php-* のみで、ソフトウェアコレクションはありません。アーキテクチャは x86_64 のみです。

Oracle（oci8）。 7.0 と 7.1 のチャネルには php-oci8 があり、Enterprise Linux 6 向けに Oracle が公開した最新のクライアントである Oracle Instant Client 18.5 にリンクしています。GetPageSpeed は Oracle のライブラリを再配布していないため、先に Oracle から入手してください。

各ビルドの検証方法。 クリーンな CentOS 6.10 コンテナで、置き換え対象のパッケージ（標準の 5.3.3-49、Remi の 7.0.33-23 と 7.1.33-10）をそのままインストールし、メモリ不足の確認コマンドで脆弱な挙動が再現することを確かめます。次に公開リポジトリから更新し、次の点を確認しています。

確認コマンドの結果が修正済みに変わること
PHP のモジュールが 1 つも失われないこと
Apache mod_php でページを配信し続けられること
EPEL なしの新規インストールでも動くこと

6 つのシナリオすべてが 2026年11月2日に成功しました。

PHP2Shell の影響確認：CentOS 6 サーバーが脆弱かどうかの確認方法

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

リリースが .el6.remi で終わるもの、または標準の el6_10 ビルドは脆弱です。更新後は、上の表にある GetPageSpeed のリリース（php-common-7.1.33-42.el6 など）が表示されます。

メモリ不足の修正は直接確認することもできます。CLI プロセス 1 つで 4 MB の上限を使い切るだけのコマンドです。

php -n -d memory_limit=4M -r 'str_repeat("x", 64 << 20);'; echo "exit code: $?"

終了コードが 255 なら、脆弱な巻き戻しが残っています。1 なら修正が適用されています。

元に戻す方法と注意点

更新の前にスナップショットを取ってください。CentOS 6 で私たちがテストしているのは更新で、ダウングレードはテストしていません。また、Remi の CentOS 6 向けリポジトリはアーカイブされています。頼りになる戻し方はスナップショットです。

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

最後に、CentOS 6 ではこれらのパッケージの対象は PHP だけです。カーネル、OpenSSL、glibc などのベース OS は CentOS 6 のままなので、移行を計画してください。対象範囲の詳細は Everpatch for CentOS 6（英語）にあります。先に CentOS 7 へ移行する場合は、CentOS 7 延長サポートで最新の LTS カーネルと保守されたベースパッケージも利用できます。

よくある質問

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

はい。PHP2Shell は 5.4 以降のすべてのブランチに影響し、Remi の CentOS 6 向け PHP 7.1 の最終ビルド 7.1.33-10.el6.remi は修正より前のものです。yum --enablerepo=getpagespeed-extras-php71 update 'php*' libicu-last libwebp を実行してください。

CentOS 6 の PHP 5.4、5.6、7.2 以降はどうなりますか？

GetPageSpeed が現在 CentOS 6 向けにビルドしているのは 5.3、7.0、7.1 です。他のブランチをお使いの場合は、どのバージョンかお知らせください。

必要なパッチのバージョンは？PHP のバージョンを確認するには？

5.3.3-51.el6、7.0.33-49.el6、7.1.33-40.el6 以上が必要で、上の表の現在のビルドをおすすめします。パッチを当てても PHP のバージョン番号は変わらないため、php -v ではなく rpm -q php-cli でパッケージのリリースを確認してください。

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

あります。GetPageSpeed のメインリポジトリにある php-5.3.3-54.el6 は、CentOS 6 標準のパッケージとそのまま置き換えられる更新版で、PHP2Shell の修正と多数の古いセキュリティ修正を含みます。リリースパッケージをインストールしたあと、yum update 'php*' を実行してください。

CentOS 6 のサポート期限はいつですか？まだ更新はありますか？

CentOS 6 のサポートは 2020年11月30日に終了しました。CentOS プロジェクトから新しいものは公開されず、vault には古いパッケージが残っているだけです。GetPageSpeed が修正を続けるのは PHP の層で、OS のそれ以外の部分は対象外です。

WordPress やプラグインを更新すれば、この PHP の脆弱性は防げますか？

いいえ。PHP2Shell は PHP 本体の脆弱性で、実証されたエクスプロイトはアプリケーションのコードが動く前に発動します。修正するには PHP そのものを更新する必要があります。

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

個人利用・開発・評価目的であれば必要ありません。パッケージは公開の GetPageSpeed リポジトリから登録なしでインストールできます。商用の本番環境での利用には、リポジトリ利用規約（英語）に基づき GetPageSpeed Ultra（年額 $500、自社サービスを運用するサーバー最大 10 台）が必要です。クライアントのサーバーを管理している場合や 10 台を超える場合は、年額 $800 からの GetPageSpeed Fleet をご利用ください。

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

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

WAF や前段の NGINX で防げますか？

一部だけです。更新の準備をしている間に NGINX で防げること、防げないことは PHP2Shell mitigation in NGINX（英語）にまとめています。

まとめ

CentOS 6 の PHP2Shell は、認証不要の深刻なリモートコード実行の脆弱性であり、ディストリビューションからも上流からも修正が届きません。GetPageSpeed の PHP 5.3、7.0、7.1 向けビルドは、その場で置き換えられ、検証済みで、無料でインストールできる修正版でこの穴を埋めます。

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