PHP 2026年10月22日

PHPの重大脆弱性「php2shell」（CVE-2026-109618/109619）、WordPressサイトの担当者が今すぐ確認すること

XECIN 脆弱性WordPressセキュリティCVE

2026年10月21日（日本時間の同日夜）、PHPの開発チームが重大な脆弱性2件を修正したバージョンを公開しました。前日に「重大なセキュリティリリースを出す」という予告があり、21日のうちにさくらインターネットが一部サービスの機能を止め、Cygamesやpixivなども緊急メンテナンスを発表しています（日経クロステック）。

一夜明けて、「うちのサイトは関係あるのか」「サーバー会社に任せておけばいいのか」が分からないまま、という方も多いと思います。

XECINは企業サイトの制作と運用を支援しています。エンジニアではないWeb担当者の方も含めて、今日やることをすぐ確認できるように、ここに整理しておきます。技術的な仕組みの解説より、「自分のサイトで何をするか」を優先しました。

サイトやシステムを管理する立場の方（情報システム部門・管理職）向けには、バックアップの確認、影響度の見極め、止めるかどうかの判断、個人情報の確認を管理者向けの記事にまとめています。

先に結論

  • WordPressなど、PHPで動いているサイトはほぼすべてが対象です。WordPress本体の更新は不要で、更新が必要なのはサーバーのPHPです。
  • レンタルサーバーなら、PHPの更新はサーバー会社が行います。担当者は「サーバー会社のお知らせ」と「自分のサイトのPHPバージョン」を確認してください。
  • PHP 8.1以前で動いているサイトには、PHP公式の修正版が出ません。サーバー会社の独自対応を確認し、なければ8.2以上（できれば8.3以上）への切り替えを急いでください。切り替えの前にバックアップを。

何が起きたのか

修正されたのは、PHP本体の次の2件です。どちらもCVSS v4.0で9.2（Critical）と評価されていて、ログインなどの認証なしに、外部からサーバー上でプログラムを実行されるおそれがあります。セキュリティ企業や報道では「php2shell（PHP2Shell）」という通称で呼ばれています。

CVE公式の名称ざっくり言うと
CVE-2026-109618RCE via OOM corruptionメモリ不足で処理が途中で打ち切られたとき、作りかけのデータを、後片付けの処理が正しいデータとして扱ってしまう
CVE-2026-109619RCE via stale global stateあるリクエストで使い終わって解放されたメモリを、同じプロセスが次のリクエストで参照してしまう

PHPの公式発表は、Apacheに組み込んで動かす「mod_php」構成のリスクが最も高いとしています。認証なしのリクエストで、アプリケーションのコードが動き出す前に攻撃が始まることが実証されているためです。PHP-FPM、php-cgi、FrankenPHP、LiteSpeedも対象で、「Webのリクエストを処理しているPHPはすべてリスクがある」と明記されています。

さらに、EUのセキュリティ機関であるCERT-EUは21日、技術的な詳細が公の場で議論され、初期のPoC（攻撃の概念実証コード）が出回り始めたとして、すでに悪用されている可能性が高まっていると注意を呼びかけています。

10月22日 追記（攻撃の状況）

修正版の公開前からCloudflareが攻撃の初期の試みを観測していたと伝えられ、セキュリティ企業のwatchTowrも21日、両CVEへの攻撃の試みを観測していると報告しました（The Hacker News）。一方で、侵入に成功した事例は確認されておらず、米CISAの「悪用が確認された脆弱性」カタログ（KEV）にも、22日に確認した時点（カタログ版 2026.10.21）で両CVEは載っていません。攻撃の試み自体は始まっているので、更新は急いでください。

影響を受けるバージョンと修正版

いま使っているPHP修正版補足
8.5系8.5.12セキュリティサポートは2029年12月31日まで
8.4系8.4.27セキュリティサポートは2028年12月31日まで
8.3系8.3.36セキュリティサポートは2027年12月31日まで
8.2系8.2.352026年12月31日でサポート終了（残り約2か月）
8.1系・8.0系・7.4系以前PHP公式の修正版はなしLinuxディストリビューションや長期サポート（LTS）ベンダーの修正パッケージを使うか、サポート中のバージョンへ切り替える。PHP公式は、ソースから自分でビルドする人向けに、7.4・8.0・8.1用の最小限の修正パッチを公開している

WordPressの公式ブログも同じ日に「Critical PHP Security Release」を出し、この脆弱性はWordPress固有のものではなく、WordPress側の更新は不要で、予定もないとしています。WordPressのバージョンをいくら上げても、今回の件は解決しません。

まず、自分のサイトのPHPバージョンを確かめる

確認の方法は3つあります。上から順に手軽です。

  1. WordPressの管理画面：「ツール」→「サイトヘルス」→「情報」タブ→「サーバー」を開くと、「PHPバージョン」が表示されます。WordPress公式が案内している確認場所です。
  2. レンタルサーバーの管理画面：「PHPバージョン設定」「PHP設定」といった名前のメニューで、ドメインごとに選んでいるバージョンが分かります。
  3. サーバーに入れる場合はコマンドで：
# コマンドライン用のPHPと、Webで動いているPHP-FPMは別物のことがあるので両方見る
php -v
php-fpm8.3 -v   # Ubuntu / Debian の例。RHEL系なら php-fpm -v

ひとつ落とし穴があります。Ubuntu、Debian、RHELなどのディストリビューションが配布しているPHPは、修正だけを取り込む（バックポートする）ため、修正済みでも php -v の表示が「8.3.36」のようには上がらないことがあります。ディストリビューション版を使っている場合は、php -v の数字ではなく、各ディストリビューションのセキュリティ情報に載っている「今回のCVEを修正したパッケージの版」と照らし合わせてください。

外からレスポンスヘッダを見る方法もあります。

# レスポンスヘッダにPHPのバージョンが出ていないかを見る（出ていれば、攻撃者からも見えている）
curl -sI https://www.example.co.jp/ | grep -i x-powered-by

ただ、これは改善の余地がある方法です。ヘッダを出さない設定のサイトも多い（出さないのが望ましい）ため、何も表示されなくても「PHPではない」とは言えません。確認の本命は、管理画面とサーバー上のコマンドです。ヘッダにバージョンが出ていた場合は、php.iniの expose_php = Off で隠しておくことをおすすめします。

サーバーの種類ごとにやること

A. レンタルサーバー（共用サーバー）の場合

PHPそのものの更新はサーバー会社の仕事で、利用者がPHPを入れ替えることはできません。担当者がやることは次の4つです。

  1. 契約しているサーバー会社の「お知らせ」や「障害・メンテナンス情報」を確認する（今回は、管理画面や一部の機能を一時的に止めて対応した会社もあります）
  2. 自分のサイトのPHPバージョンを確認する
  3. 8.1以前を選んでいる場合は、サーバー会社がそのバージョンにも独自の修正を当てるのかを確認する。案内がなければ、8.2以上への切り替えを検討する（後述）
  4. メンテナンスが明けたら、トップページ・主要なページ・問い合わせフォームの送信が正しく動くかを確認する

B. VPS・クラウド・専用サーバー（自社や制作会社が管理）の場合

OSのパッケージを更新し、PHP-FPM（mod_phpならApache）を再起動して、動いているプロセスをすべて入れ替えます。再起動を忘れると、古いPHPのまま動き続けます。

# Ubuntu / Debian の例（PHP 8.3 の場合）
sudo apt update && sudo apt upgrade
sudo systemctl restart php8.3-fpm    # mod_php の場合は apache2 を再起動

# RHEL / AlmaLinux / Rocky Linux の例
sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm       # mod_php の場合は httpd を再起動

Dockerの公式イメージを使っている場合は、イメージを取り直して再ビルドし、コンテナの中の php -v が修正版以上になっていることを確認します。

注意が必要なのが、RHEL系で使われることの多いremiリポジトリ（rpms.remirepo.net）です。PHP公式は、ボランティアで運営されているこのリポジトリには公開当日の更新がないとして、ディストリビューション公式のパッケージか、ソースからのビルドへの切り替えを求めました。remiを使っている場合は、更新が届いているかを必ず確認してください。

8.1以前のPHPを自前のサーバーで動かしていて、すぐに更新できない場合について、WordPress公式は各国のセキュリティ機関の助言を引きながら、更新の準備ができるまでサーバーをオフラインにすることも検討すべきだとしています。

C. 制作会社・保守会社に任せている場合

「任せているから大丈夫」と考えず、今日中に次の4点を確認しておくことをおすすめします。そのまま使える文面を置いておきます。

件名：PHPの脆弱性（CVE-2026-109618 / CVE-2026-109619）への対応について

お世話になっております。標記の件について、以下を教えてください。
1. 弊社サイトが動いているPHPのバージョン
2. 修正版（8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 以上、またはディストリビューションの修正版）の適用状況と予定日時
3. PHP 8.1以前の場合の対応方針（修正パッケージの有無、バージョンアップの要否と費用）
4. 適用後の動作確認の範囲（問い合わせフォームの送信を含むか）

すぐに更新できないときの暫定策（エンジニア向け）

PHP公式は「更新以外に完全な対策はない」と明言しています。以下は、確認されている攻撃経路の一部をふさぐだけで、これで安全になるわけではありません。更新までのつなぎとして使ってください。

CVE-2026-109618（メモリ不足の経路）への対策

  • memory_limit=-1 を、アプリケーションから上書きできない方法（FPMプールやApache設定の php_admin_value）で設定する。ほかのプールやディレクトリ、アプリの設定で上限が戻っていないかも確認する
  • post_max_size を小さくする（ファイルのアップロードが不要なら 8M、必要なら 32M）。upload_max_filesize は post_max_size より小さく
  • Webサーバーやプロキシの側でも、リクエストのサイズ、入力項目の数、multipartのパートやヘッダの数、ネストの深さを制限する（Content-Lengthのないリクエストも対象に）
  • メモリ上限を外す代わりに、コンテナやcgroupのメモリ制限を「サーバー全体が落ちないための歯止め」として使う。RLIMIT_AS / RLIMIT_DATA での制限は、かえって脆弱な経路を踏ませるので使わない

CVE-2026-109619（古い状態が残る経路）への対策

  • session.upload_progress.enabled=0 にして、全ワーカーを再起動する。設定はphp.iniやFPMプールなど、リクエストの解析より前に効く場所で行う（ini_set() や .user.ini に頼らない）
  • PHP 8.5では fatal_error_backtraces=0 にして、全ワーカーを再起動する
  • リクエストごとに適用している、無効な設定や非推奨の設定を取り除く。error_reporting や display_errors、@ で警告を隠しても効果はない
  • 攻撃者が届く経路で起きる致命的エラーや実行時間切れを潰す（アップロードやインポートの処理、コールバックの中も含む）

FPMのプール設定に入れる場合の例です。

; /etc/php/8.3/fpm/pool.d/www.conf の末尾に追記する例（Ubuntu / Debian）
; 更新までのつなぎ。これで安全になるわけではない
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_flag[session.upload_progress.enabled] = off
; PHP 8.5 の場合は次も
; php_admin_flag[fatal_error_backtraces] = off

WordPressやプラグインは、実行中に ini_set() でメモリ上限を変えることがあります（WordPress本体の WP_MEMORY_LIMIT もこの仕組みです）。php_admin_value で設定した値はアプリケーションから変えられないため、この用途に向いています。逆に言えば、php_value や ini_set() で設定しても、あとから上書きされるおそれがあります。

PHP 8.1以前で止まっているサイトへ

ここが、今回いちばんしんどいところだと思います。

企業サイトのWordPressが古いPHPのまま止まっている理由は、たいてい「テーマやプラグインが新しいPHPで動くか分からないから」です。実際、PHPのバージョンを上げた途端に「このサイトで重大なエラーが発生しました」と表示されるのは、WordPressでよくあるトラブルのひとつです。

ただ、今回は8.1以前にPHP公式の修正版が出ないため、「互換性が不安だから上げない」という選択がとりにくくなりました。サーバー会社が独自の修正を当てる場合も、それは一時的な措置です。

切り替える場合は、次の順で進めると事故が減ります。

  1. バックアップを取る：ファイルとデータベースの両方。バックアップから戻す手順も事前に確認しておく
  2. WordPress本体・テーマ・プラグインを先に最新にする：更新が何年も止まっているプラグインは、この機会に代わりを探す
  3. テスト環境で先に切り替える：サーバー会社にステージングの機能があれば使う
  4. 本番を切り替えたら、すぐに確認する：トップページ、主要なページ、管理画面へのログイン、問い合わせフォームの送信（メールが届くところまで）
  5. 重大なエラーが出たら、PHPのバージョンを一度戻して原因を切り分ける：PHPのバージョンを上げたらWordPressが表示されないときの直し方を参照。ただし戻した状態は脆弱なままなので、長く置かない

切り替え先は、できれば8.3以上を選んでください。8.2のサポートは2026年12月31日で終わるため、いま8.2に上げると、2か月後にまた同じ判断が待っています。8.3のセキュリティサポートは2027年12月31日まで、8.4は2028年12月31日までです。

自力で戻せなくなったときは、WordPress緊急復旧サービスでもご相談を受けています。

「また対応か」と感じた方へ（3か月で5回目）

正直なところ、今回の件で一番こたえているのは、技術的な対応そのものより「またか」という気持ちのほうではないでしょうか。WordPressで動くサイトの担当者から見ると、この3か月だけでも次の5回がありました（いずれもWordPress.orgとPHPの公式発表より）。

日付出来事
2026年7月17日WordPress 7.0.2：criticalとhighの脆弱性を1件ずつ修正。深刻度が高いため、自動更新の仕組みで強制アップデート
2026年9月17日WordPress 7.1.1：セキュリティ修正11件
2026年9月22日WordPress 7.1.2：criticalの脆弱性1件を修正
2026年10月6日WordPress 7.1.3：セキュリティ修正7件
2026年10月21日PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35：criticalの脆弱性2件を修正（今回）

プラグインの脆弱性はここに含めていません。1回ごとに見れば「更新すれば終わり」でも、担当者はそのたびに情報を追い、制作会社と連絡を取り、動作を確かめることになります。運用を考えると、効いてくるのはこの積み重ねなんですよね。

構造の話をすると、PHPやWordPress、プラグインの脆弱性は、「公開しているサーバーの上で、アクセスのたびにPHPが動く」構成である限り、毎回自分たちの問題になります。

このサイト（xecin.jp）は、Astroでビルドした静的なHTMLを、AWS（S3 + CloudFront）から配信しています。ページの配信にPHPを使っていないため、10月21日の夜も、サイト本体について更新すべきものはありませんでした。

もちろん、静的な配信にすれば脆弱性への対応がゼロになる、という話ではありません。ビルドに使うライブラリの更新は続きますし、問い合わせフォームのような動的な処理は、外部のサービスや関数に持たせることになります。会員機能やECのように、本質的に動的な仕組みが必要なサイトにも向きません。それでも、「公開中のサーバーで動くPHPが狙われる」種類の緊急対応は発生しなくなります。延命と乗り換えのどちらを選ぶかの考え方は、WordPress / PHPのEOLにどう向き合うかに整理しています。

XECIN サービス

AI Web Platform — PHPの緊急対応を繰り返さないコーポレートサイト基盤

ページの配信にPHPを使わない静的構成（Astro + AWS）に、AIエージェントによる運用を組み合わせたサイト基盤です。WordPressからの移行にも対応し、このサイト自体が同じ仕組みで運用されています。初回相談は無料・オンライン30分から。

AI Web Platform を見る →

おわりに

この記事は2026年10月22日時点の情報です。サーバー会社の対応や悪用の状況は、これからも変わっていきます。新しい情報が出たら追記します。

PHPやWordPressの重大な脆弱性は、これからも定期的に出てきます。XECINとしては、そのたびに担当者が「今日やること」をすぐ確かめられるように、こうした整理を続けていくつもりです。そのうえで「この対応を何度も繰り返したくない」と感じたら、それはサイトの仕組みそのものを見直すきっかけなのかもしれません。

参考（一次情報）