PHP で動く Web サイト(WordPress・EC-CUBE・Laravel など)を運用している方、サーバーを保守している方向けの記事です。
PHP 本体に、認証なしで遠隔からコードを実行される(RCE)脆弱性が 2 件見つかり、2026年10月21日(現地時間)に修正版が公開されました。通称は PHP2Shell です。
この記事では「自分のサーバーの PHP が対象か」「ディストリビューション版の見分け方」「更新後に忘れがちな再起動」「すぐ更新できないときの緩和策」を、コピペで使えるコマンド付きでまとめます。
何が起きたのか
| 項目 | 内容 |
|---|---|
| CVE | CVE-2026-109618(OOM 時の状態破損)/ CVE-2026-109619(前のリクエストの状態が残る問題) |
| 深刻度 | どちらも CVSS v4.0 9.2(Critical) |
| 影響 | 未認証のリモートコード実行(Web サーバーの実行ユーザー権限) |
| 対象 | PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 より前の各系列 |
| 修正版 | 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 |
| 8.1 以前 | 公式の更新は提供されない(配布元・LTS ベンダーのバックポートを確認) |
| 悪用状況 | 2026年10月26日(米国時間)に CISA の KEV カタログ(悪用が確認された脆弱性の一覧)へ登録 |
| 公式告知 | PHP: Security advisory(2026-10-21) |
| 国内の注意喚起 | IPA: PHP の脆弱性対策について(CVE-2026-109618、CVE-2026-109619) |
開発元のアドバイザリ(GHSA-w8hw-w9fx-j79w / GHSA-6wmf-4rv5-p3rp)によると、どちらも「リクエストの後始末が不完全なまま次の処理に進む」ことに起因します。攻撃の仕組みの詳細は扱いません。
押さえておくべき点は 3 つです。
- WordPress やプラグインを更新しても直らない。 欠陥は PHP 本体(ランタイム)にあります。
- Apache の mod_php は HTTP 経由での悪用が実証済み。 PHP-FPM もソース分析上は影響を受けうるとされ、「FPM だから安全」とは言えません。
- 設定変更だけで安全にする方法はない。 開発元は「修正版への更新が唯一の完全な対策」と明言しています。
1. Web で動いている PHP のバージョンを確かめる
注意点は、ターミナルの php -v と Web で動いている PHP が別物のことがある点です。両方確認します。
# CLI の PHP(cron・wp-cli で使われる)
php -v
# PHP-FPM のバージョン(系列ごとにバイナリ名が違う)
ls /usr/sbin/php-fpm* 2>/dev/null
for f in /usr/sbin/php-fpm*; do "$f" -v | head -1; done
# Apache に mod_php が組み込まれているか
apachectl -M 2>/dev/null | grep -i php
WordPress なら、管理画面の ツール → サイトヘルス → 情報 → サーバー に、Web 側で実際に動いている PHP のバージョンが表示されます。レンタルサーバーで複数の PHP を切り替えている場合は、サイトごとに確認してください。
判定は次のとおりです。
| 表示されたバージョン | 判定 |
|---|---|
| 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 以上 | 修正済み |
| 8.2〜8.5 で上記より前 | 要更新(ただし次節のディストリ版に注意) |
| 8.1 以前 | 公式の修正なし。 配布元のバックポート有無を確認し、サポート版へ移行 |
2. ディストリビューション版は「番号」ではなく「変更履歴」で判定する
Ubuntu・Debian・RHEL 系の標準パッケージは、**バージョン番号を上げずに修正だけを取り込む(バックポート)**ことがあります。番号が古く見えても修正済みのことがあるので、パッケージの変更履歴に CVE 番号があるかで判定します。PHP の公式告知でも、ディストリビューションと LTS ベンダーには事前に修正が渡されたとしています。
# RHEL / AlmaLinux / Rocky Linux
rpm -qa | grep -E '^php(-fpm|-cli|-common)?-[0-9]'
rpm -q --changelog php-common | grep -E 'CVE-2026-10961[89]' | head
# Ubuntu / Debian(パッケージ名は環境に合わせる。例: php8.3-fpm)
dpkg -l | grep -E '^ii +php[0-9.]*-(fpm|cli|common)'
apt changelog php8.3-common 2>/dev/null | grep -E 'CVE-2026-10961[89]' | head
CVE 番号が見つかれば修正済み、見つからなければ更新を当てます。
# RHEL 系
sudo dnf upgrade --refresh 'php*'
# Ubuntu / Debian
sudo apt update && sudo apt install --only-upgrade 'php8.3-*'
サードパーティのリポジトリ(複数バージョンの PHP を配るもの)を使っている場合は、そのリポジトリで修正版が出ているかを先に確認してください。共用のレンタルサーバーは利用者側で PHP を更新できないため、事業者の告知を確認します。
3. 更新後は「すべてのワーカー」を再起動する
パッケージを入れ替えても、動き続けている古いプロセスは古いコードのままです。今回の脆弱性はワーカー(リクエストを処理する常駐プロセス)の状態に関わるため、再起動は必須です。
# PHP-FPM(サービス名は環境に合わせる。例: php8.3-fpm / php-fpm)
sudo systemctl restart php8.3-fpm
# Apache(mod_php の場合)
sudo systemctl restart apache2 # RHEL 系は httpd
# 再起動後、プロセスの起動時刻が更新後になっているか確認
ps -o pid,lstart,cmd -C php-fpm8.3,php-fpm,apache2,httpd | head
最後に、1. のサイトヘルス表示がもう一度修正版になっているか確認して完了です。
4. すぐ更新できないときの緩和策(更新までのつなぎ)
開発元のアドバイザリと公式告知には、攻撃を受けにくくするが安全にはならない緩和策が挙がっています。あくまで更新までのつなぎとして使ってください。
; php.ini(または FPM のプール設定)
; アップロード進捗表示を使っていなければ無効化(既定は On)
session.upload_progress.enabled = 0
; PHP 8.5 のみ: 致命的エラー時のバックトレース取得を無効化
fatal_error_backtraces = 0
; 受け付けるリクエストの大きさ・入れ子の深さを必要最小限に
post_max_size = 8M
max_input_nesting_level = 32
max_input_vars = 1000
max_file_uploads = 10
FPM のプールで固定したい場合は、アプリ側から上書きできない php_admin_value を使います。
; /etc/php/8.3/fpm/pool.d/www.conf などの末尾
php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[post_max_size] = 8M
設定を変えたら、3. と同じくすべてのワーカーを再起動しないと反映されません。値はサイトの実際の用途(添付ファイルの大きさ、フォームの項目数)に合わせて、動作確認のうえで調整してください。
このほかアドバイザリは、memory_limit=-1 の設定、ファイルアップロードを使わないサイトでの multipart リクエストの手前での遮断、RLIMIT_AS / RLIMIT_DATA によるメモリ制限を使わないこと、なども挙げています。memory_limit=-1 はメモリ無制限にする設定で、別の負荷問題を招きうるため、採用するなら影響を見極めてからにしてください。
アップロード機能を使わないパスへの multipart を Web サーバー側で止める例です(nginx)。
# server ブロック内: 例として /api/ 配下はファイルを受け取らない前提
location /api/ {
if ($content_type ~* "^multipart/") {
return 415;
}
client_max_body_size 1m;
# 既存の fastcgi_pass などの設定はそのまま
}
WordPress の管理画面(メディアのアップロード)や問い合わせフォームの添付など、multipart を使う場所には適用しないでください。
5. 攻撃を受けていないかの確認
悪用は Web サーバーの実行ユーザー権限でのコード実行なので、確認の基本は改ざん・不審ファイルの有無です。
# 直近 14 日に変更された PHP ファイル(WordPress の例)
find /var/www -name '*.php' -mtime -14 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort | tail -50
# アップロード用フォルダに PHP ファイルがないか(通常は存在しない)
find /var/www -path '*/uploads/*' -name '*.php*' -ls
# WordPress コアファイルの改ざん確認
wp core verify-checksums
wp plugin verify-checksums --all
# PHP ワーカーの異常終了が急に増えていないか(手がかりの一つ)
grep -iE 'segmentation fault|exited on signal' /var/log/apache2/error.log /var/log/php*-fpm.log 2>/dev/null | tail -20
不審なファイルが見つかった場合は、ファイルだけ消して終わりにせず、侵害を前提に、バックアップからの復元と認証情報(DB パスワード・管理者パスワード・API キー)の変更まで行ってください。
6. 同じ被害を防ぐには
今回の件は「CMS とプラグインだけ見ていると気付けない」タイプの脆弱性でした。
- PHP 本体を更新対象の一覧に入れる。 CMS・プラグインと同じ頻度で、PHP とディストリのセキュリティ更新を確認します。Ubuntu / Debian なら unattended-upgrades で自動化できます
- サポート切れの系列を使わない。 PHP 8.1 以前は今回、公式の修正が出ていません。PHP 8.2 も公式告知によると 2026年12月31日でサポート終了です。今のうちに 8.3 以降への移行計画を立てておくと、次の緊急時に慌てずに済みます
- 更新後の再起動まで手順に含める。 「パッケージは新しいのにプロセスは古い」状態を残さないようにします
-
改ざん検知を定期実行する。 上の
verify-checksumsと uploads 内の PHP 検出を cron で回すだけでも、気付くまでの時間が短くなります
まとめ
- PHP2Shell(CVE-2026-109618 / 109619)は PHP 本体の未認証 RCE。CVSS 9.2、CISA が悪用を確認済み
- 修正版は 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12。8.1 以前は公式の修正なし
- Web 側の PHP バージョンを確認し、ディストリ版は変更履歴の CVE 番号で判定する
- 更新後はすべてのワーカーを再起動。緩和策は更新までのつなぎにとどめる
関連記事
本記事のような設定の抜けは、Web サイトを 9 つの守りでまるごと守るサイトドックでまとめて対策できます → https://sitedock.jp