PHPの脆弱性「PHP2Shell」とは？ネットショップ・WordPress運営者が今日やること｜対象の確認方法と修正版

2026年10月23日時点の情報です。PHP2Shellは認証不要で外部からプログラムを実行される恐れがある問題で、深刻度はCVSS v4.0で9.2です。 何が問題かを一言でいえば、ログインしていない第三者がサイトの裏側で好きな命令を動かせる恐れがある点です。 対象はWebのリクエストを処理するPHPのすべてです。コマンドラインのPHPが対象外とは、公式に明記されていません。 今日はWebで動くPHPの版を確認し、修正版でなければ更新してください。番号を変えずに修正するサーバー会社では、公式の適用完了告知も確認します。 楽天市場の店舗ページは楽天のサーバーで動いており、店舗側でPHPを操作する場所はありません。自社EC・WordPress・会社サイトを持っている人が、今日の確認の対象です。

PHPの脆弱性対策でまずこれだけ確認

PHPの版と契約サーバーの修正状況を確認し、未適用なら更新します。

1. 楽天以外のサイトを洗い出します。 自社EC、WordPress、会社サイト、問い合わせフォーム、公開中の旧サイトも確認します。
2. Webで動くPHPの版と公式告知を照合します。 契約プラン・対象ドメインを確かめ、今回の2件への修正が適用済みか確認します。
3. 未修正なら更新を依頼し、反映後の動作を確認します。 利用者側の切り替えが必要かを聞き、ログイン・注文・決済・メールまで確かめます。

VPSや自前サーバーでは、管理担当者による更新・全ワーカー再起動・反映確認が必要です。

PHP2Shellとは何かと影響するPHP環境

PHP2Shellは、WordPressなどを動かすPHP本体の脆弱性2件の通称です。

識別番号	問題の概要	開発元の評価
CVE-2026-109618	メモリ不足時のエラー処理の不備	CVSS v4.0：9.2
CVE-2026-109619	リクエスト間で残る内部状態の扱いの不備	CVSS v4.0：9.2

PHP-FPM、Apache mod_php、php-cgi、FrankenPHP、LiteSpeedも対象です。実行方式だけを理由に、更新不要とは判断できません。PHP公式告知

WordPress本体やプラグインの更新だけでは、PHPの修正にはなりません。楽天市場の店舗ページは楽天が管理するサーバーで動いており、店舗側でPHPを触る場所はありません。

PHPの修正版とセキュリティサポート終了日

通常の修正版は8.2〜8.5系列に提供され、7.4・8.0・8.1には出ていません。

「パッチを当てる」とは、ここでは修正を含む版の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.35	2026年12月31日
8.1	通常の修正版なし	2025年12月31日・終了済み
8.0	通常の修正版なし	2023年11月26日・終了済み
7.4	通常の修正版なし	2022年11月28日・終了済み

各系列では、表の修正版より前の通常版が影響対象です。終了日はPHP公式の現行表と終了済み一覧で確認できます。

7.4・8.0・8.1には、例外的に最小限の修正ソース（パッチ）が提供されています。サーバー会社が取り込む場合もありますが、通常サポートの再開ではありません。

8.2は2026年12月31日にサポートが終了します。8.2.35で今回の問題はふさがりますが、約2か月で再び更新されない版になります。WordPress.orgとWooCommerceの公式はPHP 8.3以上を推奨しており、移行先は8.3以上を目安に、利用中のEC製品やプラグインが対応する系列から選びます。

レンタルサーバー各社のPHP脆弱性対応状況

国内の主要各社の多くは10月22日中にサーバー側での適用を告知しました。ただし一部のプランや古い版は未完了で、利用者の作業も会社ごとに異なります。

時刻は日本時間で、告知時刻の記載がないものは日付だけを示します。

サービス・公式告知	告知日時	適用状況	利用者がすること
Xserver	10/22、10/23 13:15追記	10/22 06:45に8.2〜8.5、12:00に7.4〜8.1、14:00に5.6〜7.3完了	5.6〜8.5は急な切り替え不要。5.5以下は作成・検証中
さくらのレンタルサーバ	10/22	パネルで選べる全PHPに対応完了	緊急作業なし。サポート中の版への移行を検討
ConoHa WING	10/22 20:45時点の終報	提供中の全PHPに番号を変えず修正	切り替え不要
お名前.com	10/22 20:45時点	ベーシック・RS・AIホームページパックの全PHPに番号を変えず修正	対象プランは切り替え不要。旧SD・GSまで広げて判断しない
ロリポップ！	10/22	一部サイトを03:09頃に停止し、修正後13時頃に表示再開	8.2以降へ切り替え、表示・フォーム・アップロードを確認
heteml	10/22 18:05	一部サイトを03:05頃に停止し、修正後11:24頃に表示再開	8.2以降へ切り替え、サイトの動作を確認
mixhost	10/22	10/22 10:18頃、全サーバーの5.2〜8.5に番号を変えず修正	作業不要。8.2未満はサポート中の版への移行を推奨
カラフルボックス	10/22	同日朝までに旧版を含む全サーバーで対応完了	切り替え不要
KAGOYA	10/23 12:30更新	レンタルサーバープランは10/22 14:40〜24:00に順次更新	マネージド専用・共用・WordPress専用は恒久対応を調整中。公開制限等を相談

PHPの版を見る画面は、各社の管理画面の次の場所です。

サービス	PHPの版を見る・切り替える画面
Xserver	サーバーパネル → PHP Ver.切替
さくらのレンタルサーバ	サーバーコントロールパネル → スクリプト設定 → 言語バージョン設定
ConoHa WING	サイト管理 → サイト設定 → 応用設定 → PHP設定
ロリポップ！	ユーザー専用ページ → サーバーの管理・設定 → PHP設定
mixhost	cPanel → MultiPHPマネージャー（旧プランは Select PHP Version）
カラフルボックス	cPanel → ソフトウェア → MultiPHPマネージャー

ロリポップ！は旧版にも修正しましたが、応急的な対応と説明しています。表示が止まっていたサイトは、再開後の動作確認が必要です。

Shopify・BASEなどSaaS型カートのPHP対応

SaaS型カートは、公式に確認できた範囲で店舗側の作業を判断します。

サービス	公式情報から分かること	店舗側の判断
カラーミーショップ	10/22 08:49にメンテナンス完了	店舗側の対応不要と明記
STORES	PHPを使っておらず直接的な影響はないと説明	PHPの切り替え作業は不要と判断できます
MakeShop	10/21 23:00〜10/22 04:42にメンテナンス完了。店舗側の対応不要と明記。その後、受信メール確認（roundcube）を廃止	二段階認証のコードを roundcube だけで受けていた店舗は、管理画面右上のショップID → 契約者情報 → 運営者情報 → 事業者情報「メールアドレス」で受信先を変える
Shopify	ホスティングと自動更新を提供	標準基盤を店舗がPHP更新する運用ではありません。本件固有の対応不要声明は公開情報では確認できません

BASEは検索収録の公式告知で10月22日08:00の終了を確認できますが、元ページは直接閲覧できません。店舗の作業不要との明示も、公開情報では確認できません。

別契約のWordPress、外部アプリ、画像を置くサーバーは個別に確認します。カートの対応完了が、外部サービスの修正まで意味するわけではありません。

WordPressのサイトヘルスでPHPの版を確認する方法

WordPressでは、管理画面のサイトヘルスからWeb処理に使うPHPの版を確認できます。

1. WordPressの管理画面にログインし、［ツール］を開きます。
2. ［サイトヘルス］を開き、［情報］タブを選びます。
3. ［サーバー］を展開し、［PHPバージョン］を記録します。
4. サーバー会社の管理画面・公式告知と、対象ドメインの設定を照合します。

順路はWordPress.org公式案内に基づき、サイトごとに確認します。

コマンド画面のPHPと、Webサイトを動かすPHPが異なる場合があります。保守担当者には、対象ドメインのWeb処理で使う版の確認を依頼します。

PHPの版を上げる前のバックアップと互換性確認

系列を切り替える前に、バックアップとテーマ・プラグインの互換性を確認します。

1. データベースと全ファイルを保存し、復元方法も確認します。
2. WordPress本体・テーマ・プラグインの更新状況と、変更先PHPへの対応を調べます。
3. 可能ならテスト環境で試し、独自改修や決済機能も確認します。
4. 本番へ反映後、商品表示・カート・注文・決済結果・通知メールを確認します。

WordPress公式手順に沿って準備し、現在の系列内で修正できるかも確認します。

upload progress無効化とWAFは更新の代わりになるか

公式の立場は、完全な回避策はなく、修正を含むPHPへの更新だけが安全というものです。

暫定策	効く範囲と限界
session.upload_progress.enabled=0	CVE-2026-109619のアップロード進捗に関する一部経路だけを抑えます。109618や他の経路には効きません
PHP 8.5のfatal_error_backtraces=0	CVE-2026-109619の別の一部経路だけを抑えます
WAF	補助的な防御であり、PHP更新の代わりにはなりません

設定による暫定策は、どれも全ワーカーの再起動が必要です。PHPを処理する全プロセスへの反映を、サーバー管理者に確認してください。

upload progressの無効化は、アプリ内のini_set()やFPMの.user.iniに頼れません。

更新が難しい場合は、アクセス制限や一時停止をサーバー会社と相談します。IPAも、暫定対策が難しい場合の外部アクセス遮断やサービス停止を案内しています。

PHP修正後に侵入されていないか確認する項目

修正適用と過去の侵害調査は別なので、ファイルとログの点検も進めます。

確認項目	保守担当者と確認する内容
ファイル・管理者	覚えのないファイル追加、改ざん、管理者追加や権限変更
Web・PHPログ	不審なリクエストと、その前後のメモリ関連エラー・HTTPエラー
サーバー内部	PHP処理の異常終了・頻繁な再起動、不審なプロセス・外部通信

IPA・JPCERT/CCの点検項目と、今回の注意喚起に基づく確認です。

共有サーバーで見られない情報は、提供会社に調査を依頼します。痕跡がなくても、侵入なしとは断定できません。

不審な変更があれば、削除や復元を急がず、関連ログとファイルを保全します。影響範囲の調査と公開制限を、サーバー会社・保守会社に相談してください。

修正の確認と侵入の確認は分けて行う

修正が適用されたことと、修正前に侵入されていないことは、別々に確かめます。

1. 告知を追う：PHP公式と契約しているサーバー会社の告知を確認し、適用完了の告知を待ちます。
2. 版を2か所で照合する：CMSの管理画面とサーバーの管理画面で、Webで動くPHPの版をそれぞれ確かめます。
3. 侵入の有無を別に調べる：公開領域のファイル、管理者アカウント、定期処理を読み取りで点検します。
4. 確認できた範囲と未確認の範囲を分けて残す：調べきれなかった範囲は、未確認として記録します。

修正の適用を確かめても、それだけで侵入されていないとは言えません。

サイトを閉じるとは？メンテナンスモードで足りるかと閉じ方の違い

サイトを閉じて今回のリスクを抑えるには、PHPに届く前に止める必要があり、メンテナンス表示だけでは足りません。

各社の公式告知で確認できた停止例を、利用者サイトへの影響と日本時間の時刻で整理します。

サービス	止めた範囲・時刻と理由
ロリポップ！	10/22 03:09頃〜13時頃、一部サーバーの利用者サイト表示を停止
heteml	10/22 03:05頃〜11:24頃、一部サーバーの利用者サイト表示を停止
カラーミーショップ	予防措置で10/21 22:00〜10/22 08:49、表示・購入・管理画面を停止
Xserver	予防措置で10/21 16:00から管理画面などを停止。利用者サイトは止めずに修正

ロリポップ！とhetemlは、旧版の修正中に緩和策だけでは防げない懸念と、不審なアクセスがありました。保護を優先してサーバー単位で止め、PHPを使わないサイトも表示できなくなりました。

方法	PHPは動くか	今回の対策になるか	注意
WordPressのメンテナンスモード	動く	ならない	表示処理自体がPHP
.htaccessのBasic認証・IP制限	Apacheで拒否すればPHPに渡る前に止まる	条件付きの推論	設定の適用範囲とPHP製エラーページを確認
サーバー管理画面でのサイト停止・サーバー会社の停止	仕様による	PHPへの到達を止められるか確認	管理画面自体が止まる場合もある
DNSを外す	止まらない	単独ではならない	元サーバーは動き続ける

Apacheの処理順では認証・認可がPHPの処理に先行するため、拒否した要求はPHPに届かないと考えられます。Basic認証で本件を防げるとの公式説明はなく、Apache以外の構成で同様に止まるかは未確認です。

停止しても侵入済みの変更は残り得るため、別途、ファイルやログから侵入の有無を調べます。同じサーバーの別サイト、phpMyAdmin、cron、メール、APIは、停止範囲を個別に確認します。

停止中は注文や問い合わせを受けられず、予約メールの配信だけが続く場合もあるため確認します。

Google Search Centralは、全体停止は数日以内、緊急の1〜2日なら503の案内を推奨しています。PHPを使わない静的な案内を返し、robots.txtは503にせず、クロールを許可します。一時停止に403・404・noindexは使わず、Basic認証の401も長引けば検索から外れると考えられます。

IPAは、有効な暫定対策が難しければ、被害と業務影響から、外部アクセス遮断や一時停止の要否を判断するよう案内しています。

次に同じことが起きたときの初動チェックリスト

公式情報から対象と修正状況を確認し、停止の判断、証拠保全、侵入調査と必要な届出を進めます。

IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」付録8の流れに沿った確認です。

1. 情報収集：開発元・IPA・JPCERT/CC・サーバー会社の公式告知を確認します。
2. 対象確認：自社のどのサイトが対象か、全サイトのPHPの版を照合し、責任者・保守担当へ連絡します。
3. 修正確認・更新：適用済みか確認し、未適用なら更新と稼働中PHPへの反映を依頼します。
4. 停止の判断：更新できなければ遮断・停止を相談し、侵害が疑わしければ隔離を急ぎます。
5. 証拠保全：電源を切ったり不審なファイルを消したりせず、ログと対象ファイルを残します。
6. 侵入の確認：不審なファイル・管理者・通信を調べ、確認できた事実と未確認の範囲を記録します。
7. 届出：報告対象となる個人情報の漏えい等やそのおそれは、個人情報保護委員会へ報告します。速報は発覚から概ね3〜5日以内、確報は30日以内、不正目的の行為のおそれがある場合は60日以内です。調査完了を待たずに報告を進め、不正アクセスはIPA、犯罪性があれば警察にも届け出ます。

平時から次の情報をそろえ、緊急時に担当者が対象を探し直さずに済むよう、停止・更新の判断に備えます。

平時の備え	残しておく情報
サイトとサーバーの一覧	ドメイン・契約先・旧サイト・テスト環境
PHPの版	サイトごとのWeb用PHP・サポート期限
連絡先	サーバー会社・保守担当・停止の責任者
バックアップ	DB・全ファイル・正常な世代・復元方法
ログの保存期間	種類・保存日数・自動削除・保全方法
更新の手順書	互換性確認・反映・決済確認・復旧方法

被害を小さくする平時の守り方：個人情報とパスワードの保存

脆弱性はゼロにできないため、侵入されても盗まれる物を減らし、盗まれても使えない形で持つのが基本です。

守り方	やること	根拠
個人情報は基本的に持たない	必要な項目だけ集め、使い終えたら期限を決めて消す	個人情報保護法第22条は、利用する必要がなくなった個人データを遅滞なく消去するよう努めると定めています
カード情報は自社で持たない	決済代行会社の仕組みでカード番号を自社サーバーに通さず、保存もしない	クレジットカード・セキュリティガイドラインは、EC加盟店にカード情報の非保持化を求めています
パスワードは元に戻せない形で保存	暗号化ではなく、Argon2idやbcryptなどでハッシュ化する	OWASPは、パスワードは暗号化でなくハッシュ化で保存するよう求めています
元に戻す必要がある秘密は強く暗号化	APIキーや取引先のIDは強い暗号で保存し、解読の鍵はデータと別の場所に置く	鍵をデータと同じサーバーに置くと、侵入された時に一緒に盗まれます

解読の鍵は、可能ならインターネットにつながらない場所に保管します。サーバーが侵入されても、鍵が無ければ暗号化したデータは読めません。

WordPress本体は、ログインのパスワードをハッシュ化して保存しています。注意が要るのは、プラグインや独自の仕組みで保存している顧客情報やAPIキーです。

定期的な監査と攻撃者目線のAIレビューで備える

一度の対応で終わらせず、外部の監査とAIによるレビュー、最新情報の確認を定期的に繰り返します。

備え	内容
第三者機関による監査	自社と利害のない専門家に、定期的に設定や仕組みを点検してもらう
攻撃者目線のAIレビュー	最新の高性能AIに、攻撃者の立場で自社サイトの弱いところを探させる
最新情報の定期チェック	IPA・JPCERT/CC、使っているソフトの公式、サーバー会社の告知を決まった間隔で確認する

当社でも、第三者機関による監査と、最新のAIによる攻撃者目線のレビューを定期的に行っています。AIが見つけなかったことを安全の証明にせず、人が結果を確かめます。

AIで自社サイトのセキュリティを点検できる環境をつくる

Claude CodeやCodexをSSHでサーバーにつなぎ、権限を制限して読み取りで点検させる運用ができます。

攻撃側もAIを使い始めていると、日本の「サイバーセキュリティ戦略」は指摘しています。2025年12月23日閣議決定の同戦略は、「防御側としてもAIの活用を引き続き進めていく」としています。

PHPの版や設定、不審なファイル、管理者アカウントを調べ、公式告知との照合に使えます。Claude Codeの/security-reviewはコードの変更点をレビューし、サーバー設定は点検しません。

AIには読み取りだけで点検させ、本番を変える操作は人が承認してから行います。複数のAIで結果を見直させ、AIが見つけなかったことを安全の証明にしないことも大切です。

OWASP・NISTの資料と、CISAなど6機関の共同ガイダンスを基に、安全に使う条件を次のように整理できます。

条件	運用で守ること
読み取り専用・最小権限	SSH接続先でも書き込みや管理者権限を制限
秘密情報を渡さない	パスワード・APIキーを入力せず、読ませる資料からも除く
本番操作は人が承認	更新・削除・再起動の対象と内容を事前確認
プロンプトインジェクション対策	ログやWebページに紛れた指示には従わせない
結果は人が確かめる	根拠を照合し、見落としや未確認範囲も確認

PHP2ShellのCVSS・KEV掲載・被害情報の訂正

深刻度や被害情報は、公式に確認できた事実と未確認情報を分けて読みます。

出回っている情報	10月23日時点の整理
「CVSS 10.0」	誤りです。開発元のCVSS v4.0評価は両件とも9.2です
「CISA KEVに追加済み」	誤りです。10月23日時点では両CVEとも未掲載です
「修正版でも突破された」	公開情報では確認できません。確定情報として扱わないでください
「futureshopの不正アクセスはPHP2Shellが原因」	公式は因果関係を説明していません
「バルテックの件もPHP2Shellが原因」	同社は説明を訂正し、自社サービスの脆弱性が原因としています

KEVはCISA公式データで確認しています。

同じ時期に不正アクセスを公表したfutureshopも、公式告知では本件との関係を示していません。ニュースを読むときは、攻撃の試みと侵入の成功も分けて受け止めます。

よくある質問（FAQ）

必要な作業は、利用環境と契約先の公式告知を合わせて判断します。

楽天の店舗だけなら関係ある？

楽天市場の店舗ページは楽天が管理するサーバーで動いており、店舗側でPHPを操作する場所はありません。別契約のホームページやWordPress、独自の連携システムがあれば確認します。

サーバー側で直してもらえば版番号は上がる？

ConoHa・お名前.com・mixhostは、番号を変えずに修正しています。番号だけで判断せず、契約プランへの適用完了を確認してください。

PHP 8.0のままでいい？

今回の修正済みでも通常サポートは終了しているため、そのまま使い続ける判断は避けます。緊急の修正状況を確認したうえで、対応する新系列への移行を相談してください。

WAFを入れていれば大丈夫？

WAFを導入していても、今回のPHPの脆弱性への修正確認と更新は必要です。特定の通信を遮断できても、すべての経路を防げることにはなりません。

メンテナンスモードにすれば安全？

WordPressのメンテナンスモードでもPHPは動くため、今回の脆弱性への対策にはなりません。修正の適用を優先し、間に合わなければPHPに届く前の遮断や停止をサーバー会社へ相談します。

自分で確かめられないときは？

契約サービス名・プラン・サーバー名・対象ドメインを添えて、サーバー会社か保守会社へ問い合わせます。「両CVEの修正と稼働中PHPへの反映は完了したか」「当社の作業は残るか」を確認してください。