PHP 7.4・8.0・8.1など古いPHPのphp2shell対策｜公式の修正版がないときの選択肢

古いPHPが今回とくに困る理由

2026年10月21日、PHP公式は、認証なしで外部からプログラムを実行される（RCE）おそれのある脆弱性2件を直した修正版を公開しました。通称はphp2shellです。公式は、Webのリクエストを処理しているすべてのPHP（PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeed）が対象だとしています［php.net］。脆弱性の中身はphp2shellの解説記事にまとめています。

修正版が出たのは、公式がまだサポートしている8.2〜8.5の4系列だけです。公式のお知らせには「PHP 8.1以前は、PHPプロジェクトからの更新をもう受けられない」とあります［php.net］。GitHubの2件のセキュリティアドバイザリでも、修正済みのバージョン（Patched versions）は8.2.35 / 8.3.36 / 8.4.27 / 8.5.12だけです［GitHub GHSA-w8hw-w9fx-j79w / GHSA-6wmf-4rv5-p3rp］。

つまり7.4・8.0・8.1のサイトは、「修正版に上げれば終わり」という通常の手順が使えません。8.1以前を使い続けるリスク全般は、PHP 8.1以前（サポート終了）を使い続けるリスクで解説しています。

公式が出した「最小限のバックポート」

ただし今回は、深刻さを理由に例外的な対応がありました。PHPのセキュリティチームは、ソースからビルドしている人や長期サポートの事業者を使えない人のために、PHP 7.4・8.0・8.1向けの最小限のソースのバックポートを用意したとしています［php.net］。

中身はphp-src（PHPのソースコード）のGitHubに、系列ごとのブランチとして置かれています。どのブランチも修正のコミットは1つで、「EOL（サポート終了）版向けの最小限の緩和」と書かれています。コミットの説明には、2件のアドバイザリ（CVE-2026-109618とCVE-2026-109619）を直すとあります［GitHub php-src］。

番号の付いたリリース（7.4.34のような修正版）や、Windows用のバイナリは出ていません。使うには、自分でソースに当ててビルドする必要があります。

対策を選ぶ順番

取れる対策を、確実なものから順に並べると次のようになります。

選択肢1：8.2以上に切り替える

最優先は、修正済みの8.2.35以上（8.3.36 / 8.4.27 / 8.5.12も可）に切り替えることです。公式の修正版なので、今回の2件がまとめて直ります。今後見つかる脆弱性にも、公式の修正版で対応できるようになります。

レンタルサーバーなら、管理画面のPHPバージョンの切り替えで済むことが多いです。ただ7.4から8.xへの切り替えでは、古いプラグインやテーマ、自作のコードがエラーで止まることがあります。WordPressの場合の進め方と、画面が真っ白になったときの戻し方はWordPressのPHPバージョンアップ手順にまとめています。

まずは検証用のコピーで8.2以上に切り替えて動作を確かめ、問題がなければ本番を切り替える流れが安全です。動作確認に時間がかかりそうなときは、その間だけ選択肢2〜4でしのぎます。

選択肢2：修正済みのパッケージを使う

PHP公式は「一部のディストリビューションや長期サポートの事業者は、バックポートした修正を提供している。詳しくは各ベンダーに確認するか、サポート中のバージョンに上げてほしい」としています［php.net］。古いPHPをOS標準のパッケージで使っているなら、まず配布元の対応を確かめてください。

各配布元の公式ページで確認できた内容は次のとおりです（2026年10月22日8時台。時刻は日本時間）。状況は変わるので、作業の前に必ず最新のページを開いてください。

Ubuntu

UbuntuのCVEページでは、22.04 LTSのphp8.1が8.1.2-1ubuntu2.28で修正済みです［Ubuntu CVE-2026-109618 / CVE-2026-109619］。この版は通常のセキュリティ更新で配られています（USN-8948-1）。

20.04 LTSのphp7.4など、さらに古いリリースの修正はUSN-8948-2で出ました。こちらは「Ubuntu Proで修正を提供」と表示されています。Ubuntu ProはCanonicalの延長サポートで、個人利用は無料とされています［Ubuntu］。Proを有効にしていないサーバーには、この更新は届きません。

Ubuntuの修正済みの番号は、公式の修正版（8.2.35など）とは並びが違います。自分のサーバーの番号は、公式の番号ではなく通知に載った番号と比べてください。更新の手順はVPS・自社サーバーのPHPを修正版に更新する手順にまとめています。

Red Hat Enterprise Linux

Red Hatの公開データ（CSAF/VEX）で、RHEL 8のphp:7.4モジュールとRHEL 9の標準のphp（8.0系）は、修正済みのパッケージが出ていることを確認しました［Red Hat］。番号はどちらも7.4.33・8.0.30のままで、修正だけが取り込まれています。AlmaLinuxやRocky LinuxなどRHEL互換のOSは、それぞれの配布元の告知を確かめてください（この記事では確認していません）。

Amazon Linux

Amazon Linuxのセキュリティセンターでは、2件のCVEとも、Amazon Linux 2023のphp8.1とAmazon Linux 2のCoreのphpが「No Fix Planned」でした。Amazon Linux 2023のphp8.2〜8.5などは「Pending Fix（修正待ち）」です［Amazon Linux Security Center］。

AWSのセキュリティ告知（2026-143-AWS）は、PHP 5.4〜8.1について「サポート終了で修正の予定はなく、サポート中の系列への移行が必要」としています。8.1以前では、CVE-2026-109619に効く暫定の設定を入れてワーカーを再起動し、すぐに移行を始めるよう求めています。CVE-2026-109618には「サポート終了版向けの修正はない」とも書いています［AWS］。

この記述は、php.netが7.4〜8.1向けのソースのバックポートを出したという説明と食い違って見えます。AWSが番号付きのリリースがないことを指しているのかどうかは、確認できていません。Amazon Linuxで8.1を使っている場合は、配布元の修正を待つより8.2以上へ移すことを前提に考えてください。

Debian

DebianのセキュリティトラッカーのCVE-2026-109618のページには、Debian 12のphp8.2とDebian 13のphp8.4の行しかありませんでした。php7.4で検索しても該当がなく、古いPHPの修正の有無は確認できませんでした［Debian Security Tracker］。

レンタルサーバー

共用のレンタルサーバーでは、PHP本体の更新はサーバー会社が行います。エックスサーバーは、公式の修正版がない古いPHPについて独自の修正の作成に着手したと告知しました。22日6:45時点では、8.2〜8.5はすべてのサーバーで適用が終わり、旧バージョンは一部で準備が整ったものから順次適用を始めたとしています［エックスサーバー］。ほかの会社の状況はレンタルサーバー各社の対応状況を見てください。サーバー会社が旧バージョンをどこまで直すかは会社ごとに違うので、契約先の告知を確かめてください。

選択肢3：公式のバックポートを自分で当てる

PHPをソースからビルドしているサーバーや、修正の出ない配布元を使っているサーバーでは、公式のバックポートを当ててビルドし直す方法があります。大まかな流れは次のとおりです。

1. php.netのお知らせから、使っている系列（7.4・8.0・8.1）のブランチを確かめる
2. 今のビルドと同じ設定（configureのオプションや拡張モジュール）で、修正を当てたソースをビルドする
3. 検証用の環境で、サイトが動くことを確かめる
4. 本番に入れ替え、PHP-FPMやWebサーバーを再起動する

パッケージで入れたPHPにソースのビルドを重ねると、OSの更新で上書きされたり、どちらが動いているか分からなくなったりします。作業の後は、Webから実際に動いているPHPを確かめてください。

選択肢4：暫定策でしのぐ（設定・WAF・一時停止）

1〜3がすぐにできない場合は、設定の変更やWAFで、攻撃の経路を一部ふさぐことになります。php.netは、すぐに更新できない場合の設定（memory_limit、post_max_size、session.upload_progress.enabled=0など）を示しています。ただし「完全な解決は更新だけで、これらの対策で安全になるわけではない」と明記しています［php.net］。

AWSの告知も「以下の設定変更は影響を減らす可能性があるが、どれも完全な緩和策ではない」としています［AWS］。設定の中身と限界はphp2shellはWAFやphp.iniの設定で防げる？で解説しています。

問い合わせフォームのような一部の機能だけがPHPで動いているなら、その機能を止めることも考えられます。攻撃されたときの影響が大きいサイトでは、修正が入るまでサイトを一時的に止める判断もあります。止められない場合も、侵入された形跡がないかは確認しておいてください。確認の手順は侵害チェックの記事にまとめています。

選択肢5：サーバーごと引っ越す

今のサーバーで8.2以上が選べず、修正の予定もないなら、新しいサーバーへ引っ越すことになります。たとえばOSが古く、新しいPHPのパッケージが入らないVPSや、古いバージョンしか選べないプランが当てはまります。

新しいサーバーで8.2以上の環境を作り、そこで動作を確かめてから、DNSを切り替えます。引っ越しの間は、古いサーバーで選択肢4の暫定策を続けてください。進め方はWordPressのサーバー移行（引っ越し）手順で解説しています。

よくある質問

PHP 7.4のサイトは、今すぐ止めたほうがいいですか？

一律には言えません。サーバー会社やOSの配布元が修正を入れているなら、すぐ止める必要は低くなります。修正が入っておらず、設定やWAFの暫定策も入れられない場合は、8.2以上に移すまで止めることも選択肢です。サイトの重要さと、止めたときの影響を比べて決めてください。

レンタルサーバーで7.4を使っています。何をすればいいですか？

まず、契約しているサーバー会社の告知で、古いPHPに修正を入れるかどうかを確かめてください。そのうえで、管理画面で8.2以上に切り替える準備を進めます。サーバー会社が古い版を直してくれた場合も、それはつなぎの対応です。

公式のバックポートを当てれば、7.4のままで大丈夫ですか？

今回の2件については修正が入ります。ただ公式は「最小限の緩和」と書いており、7.4は今後の脆弱性の修正を受けられません。次に同じような脆弱性が見つかったときに、また同じ問題が起きます。

参考にした情報

• php.net「Security advisory: Critical remote code execution vulnerabilities, update now」（2026年10月21日）
• GitHub GHSA-w8hw-w9fx-j79w（CVE-2026-109618） / GHSA-6wmf-4rv5-p3rp（CVE-2026-109619）
• GitHub php-srcのバックポート：PHP 7.4 / PHP 8.0 / PHP 8.1
• Ubuntu CVE-2026-109618 / CVE-2026-109619 / USN-8948-1 / USN-8948-2
• Red Hat RHSA-2026:87080 / RHSA-2026:87151 / Red Hat CSAF/VEX（CVE-2026-109618）
• Amazon Linux Security Center CVE-2026-109618 / CVE-2026-109619
• AWS Security Bulletin 2026-143-AWS「PHP web runtimes」
• Debian Security Tracker「CVE-2026-109618」
• エックスサーバー「予防的な安全対策に伴う公式サイト・管理画面等の一時停止のお知らせ」

あわせて読みたい

緊急情報2026.10.21

【10/22最新】PHP脆弱性「php2shell」とは？修正版公開・影響を受けるバージョンと今すぐやる対策（CVE-2026-109618/109619）

対策・手順2026.10.22

WordPressプラグインの脆弱性の調べ方｜使っているプラグインが危ないか確かめる方法と更新の運用

対策・手順2026.10.22

サイトを一時停止するとSEOに影響する？ php2shell対応で止めるときの正しい方法（503とRetry-After）｜Googleの助言