php2shell（CVE-2026-109618/109619）対応コマンドチェックリスト

はじめに

2026年10月21日23時、PHPに認証不要でサーバーを乗っ取られる恐れがある重大な脆弱性（通称：php2shell、CVE-2026-109618 / CVE-2026-109619、CVSS 9.2）の詳細とパッチが公開され、テレビのニュースなどでも「PHPの脆弱性」といったワードが取り上げられるなど、世間でも話題になりました。

今回の脆弱性はPHPのコアエンジン（Zend Engine）自体に起因するため、Webサーバーの種類を問わず、PHPを使っていれば影響を受ける可能性があります。

本記事では、Ubuntu/Debian系 + Apache（mod_php/php-fpm）環境を例に、「現状確認 → 侵害有無の確認 → 暫定対応 → 本対策（パッケージ更新） → 動作確認」という対応の流れをコマンドベースでまとめます。

今回の騒動の経緯

通常の脆弱性対応であれば「最新のマイナーバージョンに上げていれば、既知の脆弱性はある程度塞がれている」というケースも多いですが、今回のphp2shellは勝手が違いました。

PHP開発チームからは前日の10月20日に「翌日23時（日本時間）に重大なセキュリティリリースを予定している」という事前通知が出ていましたが、この時点ではCVE番号や影響を受けるバージョン、修正パッチの内容は一切公開されておらず、「今のうちに備えてほしい」というアナウンスのみでした。

そして予告どおり翌10月21日23時、脆弱性の詳細とパッチが同時に公開され、ここで初めてCVE番号や修正バージョンが明らかになっています。

ぼくがこの件を知ったのは10月21日の仕事中、同僚が教えてくれたからでした。
その日の23時にパッチ公開ということで、スピード感があり、SNSを見ても徐々に盛り上がっていて、面白かったです。

脆弱性の詳細とパッチが公開された瞬間に、攻撃手法のリバースエンジニアリングがなされてしまいます。
しかも最近は攻撃者側もAIを使って解析や攻撃コードの作成を一気に進められるようになってきているので、のんびりしていられないなと思い、夜までに対策や手順書を作ることにしました。

対応の流れ

ステップ1：現状確認

まず対象のサーバーごとに、稼働しているPHPのバージョンや構成を確認します。

# PHPのバージョン確認
php -v

# インストール済みのphp8.3系パッケージ一覧
dpkg -l | grep php8.3

# Apacheにロードされてるphp関連モジュール確認
apache2ctl -M | grep php

# php-fpmサービスの稼働状況確認
systemctl status php8.3-fpm 2>/dev/null

# 読み込まれているphp.iniのパス確認
php --ini

# Apache側の設定ファイルでPHP関連の指定がある箇所を検索
grep -rn "SetHandler\|proxy:fcgi\|php_value\|php_admin_value" /etc/apache2/sites-enabled/

ステップ2：侵害有無の確認

今回はCVSS 9.2の認証不要RCEなので、パッチを当てる前に「公開前からすでに攻撃されていないか」を一度確認しておきます。

# アクセスログに不審なリクエストが無いか確認（POST先の傾向など、サイトごとに異なるので一例）
sudo grep -E "POST" /var/log/apache2/*access.log | tail -200

# webroot配下に、最近になって作成・変更された実行可能ファイルが無いか確認
find /var/www -name "*.php" -mtime -2 -newer /etc/php/8.3/apache2/php.ini

該当するCVEの具体的な攻撃パターン（exploitの実際のリクエスト内容）までは本記事では特定していないので、ここはあくまで「念のための一般的な確認」です。
不審な形跡があれば、パッケージ更新だけでなく、該当ファイルの調査・隔離や関係者への報告など別途対応が必要になります。

ステップ3：パッチ公開までの暫定対応（攻撃面を減らす）

パッチがまだ配信されていない、またはまだ適用し終えていない待機時間帯は、PHPの実行自体を止めてしまうのが最も確実です。
色々と方法があるみたいですけど、以下のコマンドでWebサーバー（apache2）を停止することができます。

sudo systemctl stop apache2
sudo systemctl disable apache2

# 停止・無効化できたか確認
systemctl status apache2
ss -tlnp | grep -E ':80|:443'

ステップ4：パッチ公開後の本対策（パッケージ更新）

パッチが配信されていることを確認した上で、該当パッケージのみを対象にアップデートします。

sudo apt update
apt-cache policy php8.3-common   # 配信されたバージョンを確認

# php8.3系のパッケージだけを対象にアップグレード
# （apt upgrade -y だと無関係なパッケージまで巻き込んで長時間化したため、対象を絞った）
sudo apt install --only-upgrade $(dpkg -l | awk '/^ii  php8.3-/{print $2}') -y

php -v
dpkg -l | grep php8.3-common

アップグレード後、インストールされたパッケージが実際に今回のCVEの修正を含んでいるかをchangelogで確認します。

apt changelog php8.3-common | head -40

php8.3 (8.3.6-0ubuntu0.24.04.13) noble-security; urgency=medium

  * SECURITY UPDATE: Remote RCE via state corruption issue
    - debian/patches/CVE-2026-109618_109619.patch: Avoid state corruption via
      bailout in ...(省略)

SECURITY UPDATEの行と、パッチファイル名にCVE-2026-109618_109619が明記されていれば、適用したアップデートが今回のCVEの修正そのものであることを直接確認できます。

ステップ5：再起動と動作確認

ステップ3でapache2を停止していた場合は、ここで元に戻します。

sudo systemctl enable --now apache2

curl -I https://example.com/
# → 200を確認

まとめ

• 脆弱性の公開とパッチの公開が同時に行われるケースでは、「最新版を使っているか」よりも「パッチが出た瞬間に当てられる体制があるか」が重要
• パッチを当てる前に、すでに攻撃を受けていないかの確認もあわせて行っておくと安心
• 適用したアップデートが本当に対象のCVEを修正しているかは、apt changelogでパッチ名・CVE番号を確認することで裏付けが取れる