PHPの脆弱性「php2shell」とは？わかりやすく解説と、個人サイトの緊急対応・対策

自分が所有している、または管理を任されているサーバー・サイトだけを確認してください。 当サイトのチェッカーは、入力されたバージョン番号をブラウザ内で表と照合するだけで、サイトやサーバーへは一切アクセスしません。当サイトは独立したサイトで、PHP Group・php.netとは無関係です。

結論（先に3行）

• 「php2shell」は、PHPの重大な脆弱性2件（CVE-2026-109618・CVE-2026-109619）につけられた通称です。開発元のPHP Groupは、ログインなしで外部から遠隔操作（リモートコード実行）されるおそれがあるとしています。
• 対象はPHPが動いているサーバー側です。レンタルサーバーなら、多くの場合はサーバー会社が対応します。ただし、古いPHPを選んでいる場合は、会社によっては自分でバージョンを切り替える必要が出ることがあります（会社の案内に従ってください）。
• やることは「確認→更新→再確認」の3ステップです。PHP Groupは、完全な回避策（暫定対処）はなく、更新が唯一の対処だと述べています（php.net 公式告知）。

サイトを「見るだけ」の人（閲覧者）向けの行動指針は、この記事の対象外です。

php2shellとは？PHP脆弱性をわかりやすく解説

PHPは、WordPressをはじめ多くのホームページやブログの裏側で動いているプログラムです。そのPHP本体に重大な欠陥（脆弱性）が2件見つかり、PHP Groupが2026年10月21日に修正版を公開しました。

• 何が危ないのか：PHP Groupは、2件とも「認証不要のリモートコード実行につながり得る」と説明しています。つまり、ログイン情報を持たない第三者が、サーバー上で勝手にプログラムを動かせてしまうおそれがあるということです。深刻度は2件ともCVSS v4.0で9.2（Critical）と、PHP Groupが評価しています（NVDも独自にCVSS v3.1の評価を付けており、CVE-2026-109618は9.8（Critical）、CVE-2026-109619は10月22日に9.8から8.1（High）へ引き下げられました）。
• WordPressが悪いわけではありません：問題はWordPressなどのアプリ本体ではなく、サーバーで動くPHPのバージョンにあります。アプリを最新にしても、PHPが古いままなら対策になりません。
• 通称について：「php2shell」という名前は、php.netの告知やCVE情報には出てきません。発見者のWiz Researchが自社ブログでつけた名前で、CERT-EUなどでも使われています。
• 攻撃は始まっている？：公式の言い方は機関ごとに違います。PHP Groupは、mod_php環境のリスクが最も高いとし、mod_phpについては、認証なしのリクエストでアプリのコードが動く前に攻撃を起こせる、実証済みの攻撃があるとしています。CERT-EUは、概念実証（PoC）が出回り始めており、すでに攻撃されている可能性が高まったと述べています（CERT-EU 2026-018）。IPAは修正版公開前の注意喚起で「現時点でIPAが悪用した攻撃を確認しているわけではありません」としています（IPA）。PHP Foundationは、PoCの出回りが10月21日に増えたとする一方、公開時点で動作する攻撃コードは確認できなかったとしています（PHP Foundation）。カナダのサイバーセキュリティセンターは、PoCが公開情報で報告されていて、確認時点では実際の攻撃は確認されていないとしています（AL26-026）。どの発表も、早めに更新するよう呼びかけている点は同じです。

攻撃の手順や仕組みの詳細は、ここでは扱いません。対策に必要な情報ではないためです。

影響を受けるPHPと修正版

PHP Groupによると、対象は「PHP-FPM、Apache（mod_php）、php-cgi、FrankenPHP、LiteSpeedなど、Webリクエストを処理するすべてのPHP」です（php.net）。

出典：php.net 告知、サポート期間。NVDのCPE設定は、8.2.35未満のすべてのバージョン（8.1以前を含む）と、8.3.0以上8.3.36未満、8.4.0以上8.4.27未満、8.5.0以上8.5.12未満を対象としています（NVD）。Linuxディストリビューション別の表は修正版バージョン一覧にあります。

古いPHP（8.1以前）の場合

PHP 8.1以前は、PHPプロジェクトから更新が提供されません。PHP Groupのセキュリティチームは、PHP 7.4・8.0・8.1向けに、自分でソースからビルドする人や、長期サポート（LTS）版を使えない人向けに最小限のソース修正を公開しましたが、配布パッケージやバージョン番号はありません（php.net）。フランスのCERT-FRは、PHP 5.x・6.x・7.x・8.0.x・8.1.xのすべてを影響ありとして挙げています（CERTFR-2026-ALE-014）。

古い系統は「サポートされているPHP（8.3以降を推奨）へ移る」のが本筋です。 なお8.2は2026年12月31日でセキュリティサポートが終わるため、移行先に選ぶなら8.3以降が無難です。

個人サイトの緊急対応：まず自分の環境を見分ける

PHP脆弱性の対策は3ステップ：確認→更新→再確認

更新の前に、サイトのバックアップ（VPSならスナップショット）を取ってください。 特に、PHPの系統を変える（例：7.4から8.3へ）場合は、WordPressのテーマやプラグインが動かなくなることがあります。

手順A：レンタルサーバーの場合

1. 確認

• サーバーの管理画面（コントロールパネル）で、サイトごとのPHPバージョン設定を開いて番号を控えます。
• WordPressなら、管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」でも、PHPのバージョンを確認できます。
• 番号をチェッカーに入力して、上の修正版と照らし合わせます。
• 表示される番号が修正版より古くても、サーバー会社が独自に修正を当てている場合があります（例：エックスサーバーはPHP 5.6〜8.5への適用を完了し、PHP 5.5以下は修正パッチの作成・検証中、ロリポップ！は公式修正版のない古いバージョンにも独自の修正を適用したと案内しています）。お使いのサーバー会社の最新のお知らせを、必ず確認してください。

2. 更新

• サーバー会社が「こちらで更新する」と案内している場合は、完了のお知らせを待ちます。
• 7.4・8.0・8.1などの古いPHPを選んでいる場合は、まず会社の発表で、自分のバージョンとプランが対象に入っているか確認します。ConoHa WINGやカラフルボックスのように、切り替えは不要と案内している会社もあります。【目安】（本サイトの案内で、会社の指示ではありません）対象に入っていても、サポートが終わった系統を使い続けることになるため、バックアップを取ってから、PHP 8.3以降への切り替えも並行して検討してください。さくらインターネットは、サポート期間中の最新版PHPへの移行の検討をすすめています。手順は各社のヘルプにあります（例：さくらの「PHPのバージョンを変更したい」）。
• 切り替え前に、使っているテーマ・プラグインがそのPHPで動くかを確認し、バックアップを取っておきます。

3. 再確認

• 管理画面でPHPバージョンが切り替わったことを確認します。
• サイトのトップページ、記事ページ、問い合わせフォーム、WordPressの管理画面（ログイン）が表示できることを確認します。
• 「重大なエラー」などが出た場合は、PHPの設定を元に戻してから、プラグインやテーマの対応状況を調べます。

手順B：VPS・自前サーバーの場合

1. 確認

php -v                                  # コマンドライン用PHP（Webで動くPHPと別のことがあります）
php-fpm -v 2>/dev/null || ls /usr/sbin/php-fpm*   # PHP-FPMの版数
dpkg -l | grep -E '^ii +php'            # Debian / Ubuntu のパッケージ
rpm -qa | grep -i '^php'                # RHEL・Alma・Rocky・Amazon Linux

2. 更新（ふだん使っている更新手段で行います。8.3 は自分の系統に置き換えてください）

Debian / Ubuntu の場合：

sudo apt update
apt list --upgradable 2>/dev/null | grep -i php
sudo apt install --only-upgrade 'php8.3*'

RHEL系の場合（修正パッケージの公開状況は、ディストリビューションとPHPのストリームごとに違います。先に下の一覧で確認してください）：

sudo dnf check-update 'php*'
sudo dnf upgrade 'php*'

Dockerの場合（公式イメージの修正版タグを確認してから、ビルドし直してコンテナを作り直します）：

docker build --pull --no-cache -t myapp:patched .
docker compose up -d --force-recreate

3. 再起動と再確認（更新しただけでは、動いているPHPは入れ替わりません）

sudo systemctl restart php8.3-fpm       # ユニット名は環境により異なります（RHEL系は php-fpm）
sudo systemctl restart apache2          # mod_php を使う場合のみ（RHEL系は httpd）
php -v
dpkg -l | grep -E '^ii +php8.3'

最後に、systemctl status php8.3-fpm でエラーなく動いていること、サイトが表示されることを確認し、バージョンをチェッカーで照合します。コンテナの場合は docker exec <コンテナ名> php -v で確認します。

Linuxのパッケージは「番号が古いまま」でも修正済みのことがある

Ubuntuのように、PHPを新しいバージョンに切り替えず、修正だけを既存のバージョンへ取り込む（バックポート）ディストリビューションがあります。一方、DebianやRHELの新しい系統のように、本家と同じ番号の版へ更新されるものもあります。そのため、番号が古く見えても修正済みの場合があります。PHP公式の番号ではなく、ディストリビューションが示す「修正済みパッケージのバージョン」と比べてください。

• Ubuntu 24.04 LTSの修正済みは 8.3.6-0ubuntu0.24.04.13、22.04 LTSは 8.1.2-1ubuntu2.28（Ubuntu）。
• Debian 13（trixie）は 8.4.27-1~deb13u1（DSA-6574-1）。
• Red Hatは、RHEL 10（php 8.3・php8.4）、RHEL 9（php 8.0・php:8.2・php:8.3）、RHEL 8（php:7.4・php:8.2）に修正パッケージを公開しています（例：RHEL 10 の php8.4 は 8.4.27-1.el10_2、RHSA-2026:87071）。RHEL 9の php:8.4 は、確認時点では修正がなく「Affected」（影響あり）のままです（Red Hat）。Rocky Linuxは、10（php 8.3・php8.4）、9（php 8.0・php:8.2・php:8.3）、8（php:7.4・php:8.2）に修正パッケージを公開していますが、9の php:8.4 と、8のそのほかのストリームは、確認時点では公告が見つかっていません。Oracle Linuxは、10（php 8.3・php8.4）、9（php 8.0・php:8.2・php:8.3）、8（php:7.4・php:8.2）にエラータが掲載されている一方、9のそのほかのモジュールストリーム（php:8.4など）と、8のそのほかのストリームは、確認時点では掲載が見つかっていません。AlmaLinuxは、10（php 8.3・php8.4）、9（php:8.3）、8（php:7.4）に公告があります。AlmaLinux 9のphp:8.2は、公告に2件のCVEが載っていますがphp本体のパッケージが一覧になく、未確認です。AlmaLinux 8のphp:8.2と9のphp 8.0は、公告が見つかっていません。
• Amazon Linux 2023は、php8.2〜8.5に修正があります（例：php8.4 は 8.4.27-1.amzn2023.0.1、ALAS2023-2026-3303）。一方、Amazon Linux 2023のphp8.1と、Amazon Linux 2の標準のphpは、Amazonの案内が「No Fix Planned」（対応予定なし）です。Amazon Linux 2の拡張（amazon-linux-extras）のphp8.2には、修正版 8.2.35-1.amzn2.0.1（ALAS2PHP8.2-2026-015）があります。
• Alpineは、3.24のリポジトリに修正版（php85 8.5.12-r0、php84 8.4.27-r0、php83 8.3.36-r0）が入っています。edgeも x86_64 のインデックスでは同じ版が入っていますが、確認時点では x86・ppc64le・s390x・riscv64 は古いビルド（8.5.11-r0・8.4.26-r0・8.3.35-r0）のままでした。apk upgrade のあと、入った版が修正版以上か確認してください。3.23以前は、PHPが入っているcommunityリポジトリのサポートがすでに終了しています（3.23は2026年5月1日、3.22は2025年11月1日、3.21は2025年5月1日、3.19は2024年5月1日）。それでも3.23のphp83（8.3.36-r0）・php84（8.4.27-r0）・php85（8.5.12-r0）、3.22のphp84（8.4.27-r0）・php83（8.3.36-r0）・php82（8.2.35-r0）、3.21のphp82（8.2.35-r0）には、確認時点で修正版が公開されています。一方、3.21のphp83・php84、3.20、3.19には、修正版の記載がありません。communityのサポートが終了しているため、今後出る保証もありません。3.22はリリース全体ではまだサポート期間内ですが、PHPはcommunity側にあるため、今後の更新は保証されず、移行先の候補は3.24か公式のDockerイメージです。ただし、3.24のcommunityリポジトリのサポートも2026年11月1日まででまもなく終わるため、3.24へ移る場合はこの期限を前提に、その後の移行計画も立ててください。
• 有志が運営するRemiのRPMリポジトリについて、PHP Groupは公開当日に更新が出ないと述べ、ディストリビューション標準のパッケージか、ソースからのビルドへの切り替えを推奨しています（php.net）。その後、RemiのEL 8・9・10向けリポジトリには、2026年10月21日付で8.2.35〜8.5.12のビルドが並んでいます（例：EL 9の8.3は 8.3.36-1.el9.remi、リポジトリ）。ただしRemiは2件のCVEを名指ししていません。上の表で、版が本家の修正版以上かどうかを確認してください。
• 全ディストリビューションの番号は修正版バージョン一覧にまとめています。公式ページで最新の状況も確認してください。

レンタルサーバー各社の案内（2026年10月22日時点）

下表は、各社の公式お知らせを確認した時点の内容です。状況は変わるため、最新は必ず各社のページで確認してください。

そのほかのサーバー会社はホスティング別 対応状況にまとめています。公式の発表が見つからなかった会社は「発表なし」、発表はあっても修正済みと確認できない会社は「未確認」と記載し、どちらも「修正済み」とはしていません。

公的機関の情報（JPCERT/CC・IPA・JVN）

各機関の案内は更新されることがあります。最新は各機関のページでご確認ください。

更新が間に合わないときは

php.netには、設定やWebサーバー側で攻撃経路を狭める暫定措置も載っています。ただしPHP Group自身が、これらは特定の攻撃経路への露出を減らすだけで、完全な対処は更新だけだと明記しており、更新までのつなぎにすぎません（php.net）。更新できない事情がある場合は、サーバー会社か制作会社に早めに相談してください。

自分の環境に合わせた手順がほしい方へ

「自分の環境でどうすればいいか分からない」という方向けに、個別パッチ対応プラン（49ドル） も用意しています。お使いの環境に合わせた対応手順を24時間以内にメールでお届けします（サーバーへのログインや代行作業は行いません。実施はご自身で）。詳細はこちらをご覧ください。

関連ページ：PHPバージョンチェッカー、レンタルサーバー編、WordPress編、修正版バージョン一覧、ホスティング別 対応状況、ガイド一覧