php2shellとは｜PHPの重大な脆弱性の対象と、WordPressのサイトで今すぐ確かめること 2026

php2shell（ピーエイチピー・トゥー・シェル）は、2026年10月21日（日本時間23時）にPHPの開発チームが公表した、2件の重大な脆弱性（CVE-2026-109618、CVE-2026-109619）の呼び名です。ログインしていない外部の人が、細工した通信を送るだけでサーバー上で任意のプログラムを動かせるおそれがあり、Webのリクエストを処理しているPHPはすべて対象です。直す方法は、PHPそのものを修正版（8.5.12、8.4.27、8.3.36、8.2.35）以上に更新することだけで、WordPressやプラグインを最新にしても解消しません。WordPressでサイトを運営している人がまずやることは、管理画面の「ツール」から「サイトヘルス」を開き、「情報」タブの「サーバー」欄でPHPのバージョンを確かめることです。2026年10月26日には米国のCISA（サイバーセキュリティ・インフラストラクチャセキュリティ庁）が、この2件を「実際に悪用された脆弱性」の一覧に加えました。この記事では、2026年10月30日時点の公式発表をもとに、何が起きたのか、自分のサイトが対象かどうかの確かめ方、今すぐやること、制作を外注している場合に依頼先へ確かめることを順に説明します。

php2shellとは：PHPの開発チームが公表した2件の重大な脆弱性

PHPは、Webサイトを動かすためのプログラミング言語です。WordPressもPHPで書かれており、ブログ、会社のホームページ、ネットショップ、予約フォームなど、日本で動いている多くのサイトの土台になっています。今回の脆弱性は、その土台にあたるPHP本体の中で見つかりました。

公表までの経緯と日時

PHPの公式サイト（php.net）の発表を時系列で並べると、次のとおりです。

日付（日本時間）	公式発表の内容
2026年10月20日	重大な脆弱性2件を修正する特別リリースの予告（危険度はどちらもCVSS v4.0で9.2）
2026年10月21日 23時	修正版 8.5.12／8.4.27／8.3.36／8.2.35 の公開と、セキュリティ勧告の公表
2026年10月22日	IPA（情報処理推進機構）が日本語の注意喚起を掲載
2026年10月23日	PHPがセッションのアップロード進捗の設定について補足の勧告を公表
2026年10月26日	CISAが2件を悪用が確認された脆弱性の一覧（KEVカタログ）に追加

予告の段階で公表日時が決まっていたのは、PHPの開発チームが、各Linuxディストリビューションや長期サポートの提供会社に修正を先に渡し、利用者が同時に更新できるよう準備したためです。php.netの勧告には「Linux distributions and LTS vendors received the patches in advance（ディストリビューションと長期サポートの提供会社には事前に修正を渡している）」と書かれています。

危険度9.2は「最も重い区分」

危険度は、脆弱性の深刻さを数値で表す国際的な基準CVSS（共通脆弱性評価システム）の第4版で、10点満点中9.2です。GitHubに掲載された2件の勧告（GHSA-w8hw-w9fx-j79w と GHSA-6wmf-4rv5-p3rp）は、どちらも区分が「Critical（緊急）」になっています。評価の内訳を見ると、攻撃はネットワーク越しに行え、ログインも利用者の操作も要らず、成功した場合は情報の漏えい、改ざん、停止のいずれの被害も大きい、という判定です。

名前の読み方と意味

php2shellという呼び名は、CISAやIPAの注意喚起でも使われています（IPAの表記は「PHP2shell」）。名前の「2」は英語の to（〜へ）に掛けたもので、「PHPからシェルへ」という意味合いの呼び名と読めます。シェルとは、サーバーにコマンドを打ち込んで操作する仕組みのことです。つまり、Webサイトに届いた通信をきっかけに、攻撃者がサーバーを操作できる状態に入り込める、という今回の脆弱性の性質をそのまま表した名前です。

何が問題なのか：ログインなしで外部からプログラムを動かされるおそれ

「php 脆弱性」で調べた人の多くが知りたいのは、具体的に何が起きるのかという点です。公式の勧告に書かれている内容を、技術の細部を省いて整理します。

2件の脆弱性の中身

php.netの勧告は、2件を次のように説明しています。

番号	公式の名前	起きること（要約）
CVE-2026-109618	RCE via OOM corruption	メモリが足りなくなったときの処理の途中で、作りかけのデータが正しいものとして扱われてしまう
CVE-2026-109619	RCE via stale global state	前の通信で使い終わったはずのデータが残り、次の通信の処理で使われてしまう

RCEは Remote Code Execution（遠隔からのコード実行）の略で、外部から任意のプログラムを動かされることを指します。どちらも、PHPがWebからのリクエストを受け取って処理を始める前後の、ごく内部の仕組みに起因する問題です。そのため、WordPressのテーマやプラグイン、独自に書いたプログラムの出来とは関係なく、PHPが動いているだけで対象になります。

被害として想定されること

GitHubの勧告によれば、確認された影響は「Webサーバーのプログラムが動いている権限で、認証なしに任意のコードを実行できること」です。サイトの運営者の目線に置き換えると、次のような被害につながります。

・サイトの中身を書き換えられる（偽の広告や詐欺サイトへの誘導を埋め込まれる）
・お問い合わせフォームや会員登録で集めたお客様の情報を抜き取られる
・データベースへの接続情報を盗まれ、別の仕組みまで侵入される
・サーバーを、迷惑メールの送信や他のサイトへの攻撃の踏み台にされる

特に、個人情報やカード決済の画面を扱うネットショップ、予約サイト、会員制のサイトは、被害が起きたときの影響が大きくなります。

動かし方によって危険の度合いが違う

php.netは、対象を「Webのリクエストを処理するすべてのPHP」としたうえで、動かし方の例として PHP-FPM、Apache の mod_php、php-cgi、FrankenPHP、LiteSpeed を挙げています。そのうえで、最も危険が高いのは Apache の mod_php だと明記しています。

We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs. （mod_phpの危険が最も高いと考えている。認証されていないリクエストによって、アプリケーションのコードが動く前に攻撃が成立することが実証されている） 出典: php.net

FPM や LiteSpeed については、GitHubの勧告で「ソースコードの分析から影響を受けると考えられるが、完全な攻撃の成立は実証されていない」という趣旨の説明がされています。ただし、実証されていないことは安全であることを意味しません。PHPの開発チームもCISAも、動かし方を問わず更新するよう求めています。

自分のサイトは対象か：PHPのバージョンで判断する

対象かどうかは、PHPのバージョン（版）の数字で決まります。IPAの注意喚起に書かれている影響を受ける範囲は次のとおりです。

系列	影響を受ける版	修正版	公式のセキュリティサポートの期限
8.5系	8.5.12より前	8.5.12	2029年12月31日
8.4系	8.4.27より前	8.4.27	2028年12月31日
8.3系	8.3.36より前	8.3.36	2027年12月31日
8.2系	8.2.35より前	8.2.35	2026年12月31日
8.1系以前	すべて	PHPの開発チームからは出ない	終了済み

サポートの期限は、php.netの「Supported Versions」のページに載っている日付です。サイトヘルスなどで確かめた数字が、同じ系列の修正版と同じか、それより大きければ修正済みです。たとえば「8.3.36」や「8.4.27」なら対応済み、「8.3.30」なら未対応です。

8.1以前は修正版が出ない

PHP 8.1以前は、すでに公式のサポートが終わっています。php.netの勧告は「PHP 8.1 and older no longer receive updates from the PHP project（8.1以前はPHPプロジェクトから更新が提供されない）」と明記しています。今回は事態の重さから、7.4、8.0、8.1向けに最小限の修正をソースコードの形で公開していますが、これは自分でPHPを組み立てて（ビルドして）いる人向けのものです。レンタルサーバーを借りている人が自分で当てられるものではありません。

8.1以前を使っているサイトは、サポートが続いている8.2以上の修正版に切り替える必要があります。なお、8.2系も2026年12月31日でサポートが終わるため、これから切り替えるなら8.3以上を選ぶと、短い期間で2度作業をせずに済みます。WordPressの公式サイトも、推奨する環境を「PHP 8.3以上」としています。

古い版でもサポートを受けている場合がある

自社でサーバーを管理している場合、Linuxのディストリビューションや長期サポートの提供会社が、古い系列のPHPに修正を移植して配っていることがあります。この場合、画面に出る版の数字が修正版より小さくても、中身は直っていることがあります。数字だけで判断せず、使っているディストリビューションや提供会社のセキュリティ情報で、今回の2件のCVE番号が修正済みかどうかを確かめてください。

8.2より古いかは「年」で見当がつく

サイトを作ったのが何年も前で、それ以来PHPの版を変えた覚えがない場合は、8.1以前のままである可能性が高いと考えて確かめてください。IPAは、公表前の事前の注意喚起の時点で「サポート終了の古いPHPを利用し続けているウェブサイト・ウェブサービスも見受けられます」と指摘しています。

WordPressやプラグインを最新にしても直らない理由

今回の件で最も多い誤解が、「WordPressを最新版にしたから大丈夫」というものです。

WordPressは、PHPの上で動くアプリケーションです。建物に例えると、PHPが基礎と柱、WordPressが部屋の内装、プラグインが家具にあたります。今回見つかったのは基礎の側の欠陥なので、内装や家具をどれだけ新しくしても直りません。勧告のとおり、mod_phpでは「アプリケーションのコードが動く前に」攻撃が成立するため、WordPressのセキュリティ系のプラグインが働き始める前の段階で処理が終わってしまうことになります。

WordPressの更新とPHPの更新は別の操作

項目	更新する場所	誰が操作するか
WordPress本体・テーマ・プラグイン	WordPressの管理画面の「更新」	サイトの運営者
PHPのバージョンの選択	レンタルサーバーの管理画面	サイトの運営者
PHP本体の修正の適用（同じ系列の中の更新）	サーバー	共用サーバーならサーバー会社、自社管理なら自社

レンタルサーバーの共用プランでは、PHP本体に修正を当てるのはサーバー会社の仕事で、利用者がやるのは「どの系列のPHPを使うか」を管理画面で選ぶことです。ここを混同すると、「自分では何もできない」と放置したり、逆に「WordPressを更新したから終わり」と思い込んだりします。

WordPressの更新が無駄という意味ではない

もちろん、WordPress本体とプラグインを最新に保つことは、それ自体が大事な対策です。サイトが乗っ取られる原因の多くは、古いプラグインや推測されやすいパスワードです。今回の件は「WordPressの更新だけでは足りない」という意味で、WordPressの更新をやめてよいという話ではありません。

PHPの版を上げるとサイトが崩れることがある

古いPHPから新しいPHPへ系列をまたいで切り替えると、古いテーマやプラグインが動かなくなり、画面が真っ白になったりエラーが出たりすることがあります。PHPは版が上がる過程で古い書き方を使えなくしてきたためです。切り替える前には、WordPress本体とテーマ、プラグインを先に最新にし、サイトのファイルとデータベースのバックアップを取ってください。多くのレンタルサーバーは管理画面からバックアップを取れ、PHPの版も元に戻せます。

PHPのバージョンの確かめ方

ここからは、実際に自分のサイトのPHPの版を確かめる手順です。サイトの作り方と、使える画面によって方法が変わります。

WordPressのサイトヘルスで確かめる

WordPressのサイトなら、これが最も確実で簡単です。

1. WordPressの管理画面にログインする
2. 左のメニューの「ツール」から「サイトヘルス」を開く
3. 画面上部の「情報」タブを押す
4. 「サーバー」の欄を開き、「PHP バージョン」の数字を見る

ここに「8.3.36」のように3つの数字で版が表示されます。数字のあとに「（64ビット値をサポート）」などの説明が付いていることもありますが、見るのは先頭の数字だけで構いません。

レンタルサーバーの管理画面で確かめる

WordPress以外のサイトや、WordPressにログインできない場合は、レンタルサーバーの管理画面で確かめます。多くの会社では「PHPバージョン設定」「PHP設定」といった名前の画面があり、ドメインごとに使っているPHPの系列が表示されます。共用サーバーでは、管理画面に「8.3」のように系列だけが出て、細かい版はサーバー会社が管理していることがあります。その場合は、サーバー会社のお知らせで、その系列に今回の修正が当たったかどうかを確かめます。

URLを入れて調べる方法

管理画面に入れない、あるいは自分のサイト以外（取引先のサイトなど）の状況を知りたい場合は、外から調べる方法があります。@SOHOでは、サイトのURLを入れるとPHPを使っているかどうかと、外から分かる範囲で版を調べる無料のPHP脆弱性チェックを公開しています。ただし、サーバーの設定でPHPの版を外に出さないようにしているサイトでは、外からは版が分かりません。外から分からなかった場合は、管理画面での確認に切り替えてください。

phpinfoを使うときの注意

PHPの設定を一覧表示する phpinfo() という命令を書いたファイルをサーバーにアップロードして、ブラウザで開く方法もあります。ただし、このページにはサーバーの内部の情報が大量に表示され、攻撃者にとって手がかりになります。使うときは推測されにくいファイル名にし、確認が終わったらすぐに削除してください。消し忘れたまま公開しておくのは避けるべきです。

自社管理のサーバーで確かめる

VPSや専用サーバーを自分で管理している場合は、サーバーにログインして php -v を実行すると版が表示されます。ただし、コマンドで表示されるPHPと、Webサーバーが実際に使っているPHPが別のものになっていることがあります。複数の版を入れているサーバーでは、Webサーバーの設定やPHP-FPMの設定で、どの版が使われているかまで確かめてください。

今すぐやること：サイトの持ち方ごとの手順

確かめた版が修正前だった場合の動き方は、サイトの持ち方で変わります。

レンタルサーバーを使っている場合

1. サーバー会社のお知らせ（管理画面のお知らせ欄や公式サイトの障害・メンテナンス情報）で、今回の脆弱性への対応状況を確かめる
2. 使っているPHPの系列に修正が当たっているかを確かめる
3. 8.1以前を使っているなら、管理画面でPHPの版を8.3以上に切り替える（先にバックアップを取る）
4. 切り替えたあと、トップページ、お問い合わせフォーム、管理画面へのログインなど、主な画面が動くかを見る

共用サーバーでは、PHP本体の修正はサーバー会社が行います。一方で、どの系列を使うかは利用者が選んでいるため、サポートが終わった古い系列を選んだままにしている場合は、利用者側で切り替えない限り危険が残ります。

自社でサーバーを管理している場合

1. 修正版（8.5.12、8.4.27、8.3.36、8.2.35）か、ディストリビューションが配る修正済みのパッケージに更新する
2. PHP-FPMやApacheを再起動し、すべての作業用のプロセス（ワーカー）に新しい版を読み込ませる
3. 再起動後に、Webサーバーが使っているPHPの版を改めて確かめる
4. ログを見て、PHPの作業用のプロセスがシェルを起動していないか、見覚えのない道具を取得していないかを確かめる

4つ目は、CISAが「PHPの作業用のプロセスがシェルを起動したり、ツールをダウンロードしたりする不審な動きを監視する」ことを求めている点に沿ったものです。2026年10月26日に悪用の確認が公表された以上、修正を当てる前に侵入されていなかったかを確かめることも欠かせません。

すぐに更新できない場合の一時しのぎ

PHPの開発チームは、すぐに更新できない人向けに、特定の攻撃経路を狭める設定を案内しています。主なものは次のとおりです。

対象	案内されている設定（要約）
CVE-2026-109618	memory_limit を -1 にし、アプリケーション側で上書きできないようにする
CVE-2026-109618	post_max_size を小さくする（アップロードが不要なら8M、必要なら32M）
CVE-2026-109619	session.upload_progress.enabled を 0 にして、すべてのワーカーを再起動する
CVE-2026-109619	PHP 8.5では fatal_error_backtraces を 0 にする

ただし、php.netは修正版の告知で「There are no complete mitigations, updating is the only safe choice（完全な回避策はなく、更新だけが安全な選択肢である）」と明言しています。これらの設定は更新までの時間稼ぎで、設定したから安全になるわけではありません。memory_limit を -1 にするとメモリの上限がなくなるため、サーバーの負荷にも気を配る必要があります。

2026年10月23日には、session.upload_progress.enabled を 0 にしておくことを改めて勧める補足の勧告も出ました。こちらは特殊な設定とプログラムの組み合わせでだけ起きる別の問題（CVE-2026-115560）で、次の通常の更新で詳しい勧告を出すとされています。10月21日の時点でこの設定を入れた場合は、そのまま維持してください。

更新できるまで止めるという選択

CISAは、すぐに更新できない場合や、8.1以前のサポートが終わった版を使い続けている場合は、PHPで動くシステムを更新できるまでインターネットから切り離すよう求めています。また、WAF（Webアプリケーションファイアウォール）は更新までの間に一定の防御になりうるとしつつ、あくまで更新までのつなぎという位置付けです。お客様の情報を扱うサイトで、修正の見通しが立たない場合は、一時的にメンテナンス画面に切り替えることも検討してください。

被害の状況と、根拠のない情報への注意

2026年10月30日時点で分かっていること

公表時点（10月21日）では、PHPの開発チームは実際の攻撃が確認されたとは書いておらず、「攻撃が成立することは実証されている」という段階でした。その後、CISAは2026年10月26日に2件をKEVカタログ（悪用が確認された脆弱性の一覧）に加え、注意喚起を更新しました。IPAも10月27日に注意喚起を更新し、次のように書いています。

CVE-2026-109618とCVE-2026-109619について、2026年10月26日（現地時間）、CISAのKEVカタログ（Known Exploited Vulnerabilities Catalog）に、悪用された脆弱性として掲載されました。 IPAでは国内での攻撃被害の事例については把握しておりませんが、改めて本件情報をご確認のうえ、対策済みバージョンへの移行を進めるようお願いいたします。 出典: ipa.go.jp

つまり、海外では悪用が確認されたと公的機関が判断し、国内の被害事例は2026年10月27日時点でIPAが把握していない、という状況です。被害が見えていないことは、攻撃が来ないことを意味しません。修正前の版のまま公開しているサイトは、早めに対応してください。

公式以外の情報との付き合い方

大きな脆弱性が公表されると、SNSや動画で、根拠のはっきりしない対処法や被害の話が広がります。「この設定を入れれば更新しなくてよい」「このプラグインを入れれば防げる」といった情報は、PHPの開発チームの案内と矛盾しています。対応は、php.netの勧告、IPAの注意喚起、使っているサーバー会社の公式のお知らせをもとに進めてください。

なお、2026年10月26日にphp.netは、Windows向けのPHPの配布物を、圧縮を扱う部品（Brotli）の別の脆弱性を直したものに差し替えたと告知しています。これはWindowsでPHPを動かしている場合の話で、PHPの版の数字は変わりません。レンタルサーバーでWordPressを動かしている多くの人には関係のない告知です。

サイトを見ているだけの人は何かする必要があるか

「php 脆弱性 一般人」という検索もされています。サイトを訪れて閲覧するだけの人が、自分のパソコンやスマートフォンで何かを更新する必要はありません。今回の対策が必要なのは、PHPで動くサイトを持っている人と、そのサイトを管理している会社です。ただし、乗っ取られたサイトが偽のログイン画面や偽の決済画面に誘導することはありえます。いつも使っているサイトで見慣れない画面が出たら、入力をやめ、運営者に連絡してください。

制作を外注しているサイトの持ち主が依頼先に確かめること

会社のホームページやネットショップの制作と保守を、制作会社やフリーランスに頼んでいる場合、サーバーの管理画面に自分では入れないことも多いはずです。その場合は、依頼先に次の点を確かめてください。返事は口頭ではなく、メールなど記録が残る形でもらうと、あとで確かめ直せます。

1. うちのサイトはPHPで動いているか。動いているなら、今のPHPの版はいくつか
2. 今回の2件（CVE-2026-109618、CVE-2026-109619）に対応済みか。対応済みなら、いつ、どの版にしたか
3. 8.1以前を使っている場合、8.3以上に切り替える予定日はいつか。切り替えでサイトの改修が必要か
4. 修正を当てる前に侵入されていなかったか、ログやファイルの改ざんを確かめたか
5. サーバーの契約者は誰か（自社名義か、依頼先の名義か）。サーバー会社からのお知らせは誰に届いているか
6. 今後、同じような重大な脆弱性が出たとき、誰がいつまでに対応する取り決めになっているか

5つ目と6つ目は、今回に限らず大事な点です。サーバーの契約を依頼先の名義で結んでいると、サーバー会社からの重要なお知らせがサイトの持ち主に届きません。保守契約が切れていて、誰もPHPの版を見ていなかったという例も珍しくありません。

保守の体制が無い場合の考え方

IPAの注意喚起は、修正対応が難しい場合の進め方として、サポート状況の確認、暫定対策、システムの役割の見直し、組織としての実現性の検討、方針の決定、利用者への影響の考慮という6つの段階を示しています。そのうえで、維持管理の体制を確保する見通しが立たない場合は「保守を受けられる製品・サービスへの移行、提供機能の縮小、公開の終了やシステムの廃止も含めて検討してください」と書いています。

長く手を入れていないサイトは、PHPの版を上げるとテーマやプラグインが動かなくなり、改修費がかかることがあります。その場合でも、修正されていない状態で公開を続けることの危険と比べて判断してください。見積もりを取るときは、「PHPの版を何から何に上げるか」「改修の範囲」「切り替え後の動作確認の範囲」「以後の保守の内容と月額」を分けて書いてもらうと、比べやすくなります。

脆弱性への対応を任せられる人材と、これからの備え

今回のように、公表から数日のうちに悪用が確認される事例が続くと、サイトの持ち主が自分だけで対応しきるのは難しくなります。中小企業や個人事業では、サイトを作った人が退職している、制作会社と連絡が取れなくなっている、といった事情で、PHPの版を誰も把握していないこともあります。

外部の専門家に頼める作業

PHPの版の確認と切り替え、テーマやプラグインの動作確認、ログの確認、サーバーの引っ越しといった作業は、単発で外部の技術者に依頼できる内容です。セキュリティ分野の仕事の種類と内容は、AI・マーケティング・セキュリティのお仕事で、脆弱性への対応やセキュリティの運用がどのような仕事として成り立っているかを紹介しています。PHPで動く業務システムの改修まで含む場合は、開発の仕事の範囲になります。アプリケーション開発のお仕事では、Webのシステムの開発や保守を外部に頼むときの仕事の中身を説明しています。

依頼先を選ぶときは、サーバーやネットワークの基礎を理解しているかも見るとよいでしょう。ネットワーク技術の基礎を証明する資格としては、CCNA（シスコ技術者認定）があり、試験の範囲や難易度をまとめています。資格は判断材料の一つで、実際にPHPの版の切り替えやサーバーの移行を手がけた経験があるかを、過去の作業内容で確かめるのが確実です。

普段からの備え

今回のような事態のたびに慌てないために、普段から次の点をそろえておくと、次に重大な脆弱性が公表されたときの初動が速くなります。

・サイトごとに、PHPの版、サーバー会社、契約者、管理画面に入れる人を一覧にしておく
・サーバー会社のお知らせが、サイトの持ち主にも届くようにしておく
・バックアップが自動で取られているか、戻す手順を誰が知っているかを確かめておく
・サポート期限（8.2系は2026年12月31日）の前に、次の系列へ切り替える予定を立てておく

自社のサイトに弱いところがないかを定期的に調べたい場合は、無料のツールでできる範囲もあります。オープンソースで始めるWebサイト脆弱性診断｜OWASP ZAPの使い方ガイドでは、オープンソースの診断ツールでサイトの弱点を洗い出す手順を説明しています。また、取引先のシステムの弱点が自社の被害につながる場合の考え方は、取引先経由のウイルス侵入を防ぐ！中小企業のサプライチェーンリスク管理で整理しています。制作や保守を外注している会社にとって、依頼先の対応状況を確かめることも、この管理の一部です。

運営者の立場から見えること

在宅ワークとフリーランスの仕事の場を20年以上運営してきた立場から見ると、サイトの保守は「作って終わり」の発注が多く、公開後の更新を誰が担うかが決まっていないまま年月が過ぎている例が少なくありません。今回のように土台のPHPに問題が出たとき、すぐに動けるのは、作った人と保守を続けている人が同じで、日頃から連絡が取れている関係です。単発で作業を頼むだけでなく、版の確認や更新を定期的に任せられる相手を見つけておくことが、結果として一番の備えになります。

@SOHOは、仕事を頼みたい人と受けたい人が直接やり取りできる、在宅ワークとフリーランスの仕事探しのサイトです。仲介の手数料がかからないため、PHPの版の切り替えやサイトの保守のような単発の作業も、技術者と直接条件を決めて依頼できます。

PHPの脆弱性への対応は、版を確かめる、修正版に切り替える、切り替えられないなら止めるか専門家に頼む、という3つの判断に集約されます。まずはサイトヘルスかサーバーの管理画面を開き、PHPの版の数字を確かめるところから始めてください。

よくある質問

Q. php2shellとは何ですか？

2026年10月21日（日本時間23時）にPHPの開発チームが公表した2件の脆弱性、CVE-2026-109618とCVE-2026-109619の呼び名です。危険度はCVSS v4.0で9.2の「緊急」で、ログインしていない外部の人が細工した通信を送るだけで、サーバー上で任意のプログラムを動かせるおそれがあります。Webのリクエストを処理しているPHPはすべて対象です。

Q. WordPressを最新版にすれば対策になりますか？

なりません。問題はWordPressではなく、その土台のPHP本体にあるためです。PHPを修正版（8.5.12、8.4.27、8.3.36、8.2.35）以上にする必要があります。共用のレンタルサーバーでは、PHP本体の修正はサーバー会社が行い、利用者はサポート中の系列を選んでいるかを管理画面で確かめます。8.1以前を選んでいる場合は切り替えが必要です。

Q. PHP 7.4や8.1を使い続けても大丈夫ですか？

PHP 8.1以前は公式のサポートが終わっており、PHPの開発チームから修正版は出ません。CISAは、8.1以前を使い続けているシステムは更新できるまでインターネットから切り離すよう求めています。バックアップを取り、WordPress本体とテーマ、プラグインを最新にしてから、8.3以上へ切り替えてください。8.2系は2026年12月31日にサポートが終わります。

Q. 実際に被害は出ていますか？

CISAは2026年10月26日に、この2件を悪用が確認された脆弱性の一覧（KEVカタログ）に加えました。IPAは10月27日の更新で、国内での攻撃被害の事例は把握していないとしつつ、対策済みの版への移行を求めています。被害が見えていないことは攻撃が来ないことを意味しないため、修正前の版を使っているサイトは早めに対応してください。