PHP2Shellとは？2つの脆弱性と3件目、修正版・悪用状況を時系列でやさしく解説【2026年10月】

2026年10月21日の夜、日本時間の23時ごろに、PHP（ピーエイチピー）というプログラミング言語の緊急の修正版が公開されました。PHPは、ブログやネットショップ、会社のホームページなど、世界のWebサイトの約7割で使われているとされる言語です。

修正されたのは、外から誰でも、ログインもせずにサーバーを乗っ取れるおそれがある重大な欠陥2件で、研究者のあいだでは「PHP2Shell（ピーエイチピー・ツー・シェル）」と呼ばれています。

翌22日にかけて、国内でも省庁や自治体、銀行、レンタルサーバーなどが、念のためにサイトやサービスを止める対応を取りました。ニュースで「PHPの脆弱性」という言葉を初めて聞いた方も多いと思います。その後の10月23日には、関連する3件目の欠陥も告知されています。

この記事では、PHP2Shellについて、何が起きたのか、どんな順番で明らかになったのか、2つの欠陥はどういう仕組みなのか、どの版に直せばいいのか、3件目は何なのか、そして実際にどこまで悪用されているのかを、専門用語をかみくだきながら1本にまとめます。

先に結論を書いておくと、次の5つです。

PHP2Shellとは何か

まず、言葉の整理から始めます。PHPは、Webサイトの裏側で動くプログラムを書くための言語です。

たとえばブログの記事を表示したり、問い合わせフォームの内容を受け取ったり、ネットショップで買い物かごの中身を覚えておいたりする処理の多くが、PHPで書かれています。個人ブログでよく使われるWordPress（ワードプレス、ブログやサイトを作るための無料のソフト）も、PHPで作られています。

今回問題になったのは、WordPressのような「PHPで書かれたソフト」ではなく、PHPそのものです。PHPで書かれたプログラムは、サーバーに入っている「PHPの本体」（専門的にはインタプリタと呼ばれる、プログラムを1行ずつ読んで実行する仕組み）が動かしています。

その本体に欠陥があったため、上に載っているソフトが何であっても影響を受ける、というのが今回の大きな特徴です。

「RCE」と「認証不要」の意味

報道では「認証不要のリモートコード実行（RCE）」という言葉がよく出てきます。RCEは Remote Code Execution の略で、外からサーバーに好きな命令を実行させられることを指します。サーバーの中のファイルを書き換えたり、データを抜き出したり、別の攻撃の足場にしたりと、攻撃する側にとってはいちばん価値の高い種類の欠陥です。

「認証不要」は、ログインしなくても攻撃できるという意味です。管理者のパスワードを盗むといった下準備がいらず、インターネットから届くふつうのリクエスト（サイトを見るときにブラウザがサーバーに送るお願いの通信）を細工するだけで成り立つおそれがあります。この2つがそろうと、脆弱性の中でも最も重い部類に入ります。

「シェル」は、サーバーに命令を打ち込むための窓口のことです。PHP2Shellという通称は「PHPの欠陥を突いて、サーバーの命令窓口を手に入れられる」という意味合いで付けられたものです。正式な名前はあくまで下に書くCVE番号で、通称は研究者やメディアが呼びやすいように付けたものです。

CVE番号とCVSSの点数

CVE（シーブイイー）は、世界中の脆弱性に振られる通し番号です。同じ欠陥を誰もが同じ番号で呼べるようにするためのもので、今回の2件は CVE-2026-109618 と CVE-2026-109619 です。

深刻度は CVSS（シーブイエスエス）という共通の物差しで、0点から10点で表されます。9点以上は「緊急」に当たります。

今回は、評価する組織によって点数が少しずつ違います。下の表にまとめました。

点数の違いは、物差しの版の違いや、どの条件を重く見るかの違いから生まれます。どの評価でも8点以上なので、「とても重い欠陥」という点は共通しています。ニュースで「CVSS 10.0」と書かれているものを見かけたら、それは流出時の誤った値をもとにしている可能性があります。

10年以上前から潜んでいた

今回の欠陥は、10年以上前からPHPの中にあったとされています。脆弱性を報告した会社の一つ、Wiz（ウィズ、米国のクラウドセキュリティ企業）は、PHP 5.4以降のほぼすべての版が、2件のうち少なくとも1件の影響を受けると説明しています。PHP 5.4は2012年に出た版なので、長いあいだ誰にも気づかれずに使われ続けてきたことになります。

PHPは、無料で誰でも使えるオープンソース（設計図にあたるソースコードが公開されているソフト）です。レンタルサーバーの多くが標準で用意しているため、自分でPHPを入れた覚えがなくても、ブログやホームページが実はPHPで動いているということがよくあります。

ネットショップを作るサービスや、会社の問い合わせフォーム、自治体のお知らせのページ、予約や申し込みの受付など、身近なところで広く使われています。そのため、PHPの本体に欠陥が見つかると、影響は特定の業界にとどまらず、インターネット全体に広がります。

Wizは、WordPress、Drupal（ドルーパル）、Joomla（ジュームラ）という代表的なサイト作成ソフトの最新のコンテナ（サーバーの環境をひとまとめに箱詰めしたもの）で、ログインなしにサーバーを操れることを実際に確かめたと発表しています。さらに、命令の実行までいかなくても、サーバーのメモリ（作業中のデータを一時的に置いておく場所）から機密情報を読み取れることも示しました。

よくある勘違い

ニュースが一気に広まったため、いくつか勘違いされやすい点もあります。先に整理しておきます。

• 「WordPressを最新にすれば直る」わけではありません。欠陥はPHPの本体にあるので、直すべきはPHPです。WordPressの開発チームも、本体の更新は不要で予定もないとしています。
• 「サイトを止めた組織は攻撃された」わけではありません。多くは、確認と更新が終わるまで念のために止めた予防的な対応です。
• 「CVSS 10.0」は正式な点数ではありません。流出したときについていた誤った値で、正式な評価は9.2、9.8、8.1です。
• 「防御サービスに入っていれば何もしなくてよい」わけではありません。Cloudflareなどの対策は修正版を入れるまでのつなぎで、提供元自身も修正版の適用が必要としています。
• 「PHPを使っていないパソコンやスマホも危ない」わけではありません。影響を受けるのは、Webのリクエストを処理しているサーバー側のPHPです。ふつうにサイトを見ているだけの人の端末が、直接狙われるものではありません。

何が起きたのか、時系列で整理する

PHP2Shellは、10月21日に突然見つかったものではありません。最初の兆候から数えると2年近く、本格的な報告からも2カ月以上かけて修正が準備されてきました。そのうえで、最後の数日に情報の流出や公開の前倒しが重なりました。

まずは全体の流れを表で見てください。時刻は、断りがない限り日本時間です（UTCは世界標準時で、日本時間はUTCに9時間を足したものです）。

ここから、いくつかの節目をもう少しくわしく見ていきます。

日付と時刻を読むときの注意

海外の資料は世界標準時（UTC）で書かれていることが多く、日本の報道は日本時間で書かれています。そのため、同じ出来事でも資料によって日付がずれて見えることがあります。

たとえばwatchTowrの投稿は、UTCでは10月20日18時26分ですが、日本時間では21日の3時26分です。修正版の公開も、UTCでは21日の14時、日本時間では21日の23時です。

修正版の公開時刻については、UTCの14時とする資料と13時30分とする資料があります。また、先に書いたとおり、Califが欠陥を見つけた日付についても、8月1日とする主張と、8月11日の報告を基準にする資料があります。

この記事では、複数の資料で確かめられた日付を表に入れ、食い違いがあるものはその旨を書いています。ほかの記事やニュースを読むときも、日付や時刻が「どの時間で書かれているか」を意識すると、混乱が少なくなります。

2024年に見つかった「兆候」が止まっていた理由

最初のきっかけは2024年です。OSTIF（オープンソースのソフトに外部の監査を手配している非営利団体）を通じて、フランスのセキュリティ企業Quarkslab（クォークスラブ）がPHPを監査し、メモリ不足のときの処理がおかしな状態を残すという兆候を見つけていました。

ただ、その時点では「どうすれば攻撃に使えるのか」が特定できませんでした。

脆弱性の修正では、「理屈のうえでは危ない」ものと「実際に攻撃が成り立つ」ものとで、優先度が大きく変わります。PHPの開発を支えるPHP Foundation（PHPの開発を資金面で支える非営利の財団）の説明によると、このときは具体的な攻撃経路が見えなかったため、ほかの問題の対応が優先され、修正は数カ月にわたって止まっていたそうです。

8月から9月、3つの組織がそれぞれ報告

状況が大きく変わったのが2026年の夏です。7月30日にCalifがPHPの監査を始め、8月11日に、2024年の兆候と同じ根本原因で実際にRCEまで至ることを報告しました。OpenAIも同じ根本原因を別に報告したとされ、PHP Foundationはこの日から修正を最優先にしたと説明しています。

なお、Califは「8月1日にLLM（大規模言語モデル、ChatGPTのような文章を扱うAI）が検出していた」とも主張しており、資料によって発見の日付に食い違いがあります。ここでは、報告の日付として複数の資料で一致している8月11日を基準にしています。

その後、8月24日にWizが、9月18日にOpenAIが、それぞれ追加の攻撃経路を報告しました。同じ欠陥でも、攻撃が成り立つ道筋が複数あると、ふさぐ場所も増えます。2件目の CVE-2026-109619 は、こうした追加の報告を通じて全体像が見えてきたものです。

今回の報告にはAIが深く関わっています。

• CalifはOpenAIの取り組み「Patch the Planet（パッチ・ザ・プラネット）」の枠組みで、OpenAIのAIモデル「GPT-5.6 Sol」を使って欠陥を見つけたと説明されています。
• WizもAIを併用して独立に見つけたとしています。
• ただし「AIがひとりでに見つけた」のではなく「人間の研究者がAIを道具として使った」とみる分析もあります。

この話題は関連記事「AIが脆弱性を見つける時代」でくわしく扱います。

修正がなかなか進まなかった事情

8月の時点で根本原因が分かっていたのに、公開が10月までかかったのはなぜでしょうか。PHP Foundationは経緯の説明の中で、修正の方針について関係者の合意を得るのに時間がかかったこと、対応できる人手が足りず作業が止まったり再開したりを繰り返したことを認めています。

意思決定の仕組みや人員不足を構造的な問題とし、今後は多数決での決定や、難しい修正の早期把握、専門のエンジニアを確保するための資金支援を呼びかけています。

PHPは世界中で使われている一方で、開発の多くはボランティアや少人数の財団に支えられています。土台の修正は、少しでも間違えると世界中のサイトを壊してしまうため、慎重に進める必要があります。人手が足りないまま慎重さを求められると、どうしても時間がかかります。

10月20日の流出と、21日への前倒し

本来の予定では、修正版は10月22日に公開されるはずでした。ところが20日（UTC）に、CVE番号2件が、誤った公開時刻と誤ったCVSS 10.0の値がついた状態で外に出てしまいます。

Hacker Newsに投稿され、のちに削除されましたが、watchTowrがXで「公表前の重大な欠陥の情報が漏れている」と投稿し、欠陥そのものが実在することも広く知られるようになりました。

PHP Foundationによると、このとき漏れたのは番号や点数などで、技術的な詳細は漏れていなかったとされています。それでも「PHPに重大な欠陥がある」と分かれば、攻撃する側は修正版が出た瞬間に差分を調べて攻撃方法を探しにかかります。

配布元（Linuxのディストリビューションなど）が準備できる時間と、利用者が更新しやすいタイミングのバランスを考え、公開は22日から21日に1日前倒しされました。

さらに21日の日本時間16時41分には、コンテナの配布を手がけるChainguardが、修正入りのコンテナを予定より6時間以上早く公開しました。

エンバーゴは、関係者が「この日時までは秘密にしておく」と約束して修正の準備を進める仕組みです。その約束が公開直前に破られた形になり、修正内容から欠陥の場所を推測できる状態が、公式の公開より先に生まれてしまいました。

公開後の数日間

21日の日本時間23時に修正版が公開されると、その日の夜から22日にかけて、国内でも多くの組織がサイトやサービスを止めて確認作業を進めました。セキュリティ専門ブログpiyolog（ピヨログ）の集計では、告知や報道で確認できた国内の組織は246にのぼります。

国税庁や銀行、保育園の連絡アプリ、レンタルサーバーなどがどう止まり、どう戻ったのかは、関連記事「日本で何が止まったか」でまとめます。

22日にはIPA（情報処理推進機構、国のIT政策を支える独立行政法人）とJPCERT/CC（日本のセキュリティ事故の連絡調整を担う組織）が注意喚起を出しました。そして23日、PHPは3件目の欠陥を告知します。こちらはあとの節でくわしく書きます。

1つ目の欠陥 CVE-2026-109618（メモリ不足のときの後片付け）

ここからは、2つの欠陥の仕組みを、できるだけたとえ話を使って説明します。細かい技術の話は省いていますが、「なぜログインなしで攻撃が成り立つのか」がつかめるように書きます。

PHPは、リクエストのたびに準備と後片付けをしている

サイトを見に来た人のブラウザからリクエストが届くと、PHPはまず「このリクエスト用の作業スペース」をメモリの中に用意します。送られてきたデータを読み込んで整理し、プログラムを動かし、結果を返し、最後に作業スペースを片付けます。これを1件ごとに、1秒に何十回、何百回と繰り返しています。

レストランの厨房にたとえると、注文が入るたびに調理台を用意し、材料を並べ、料理を作って出し、調理台を拭いて片付ける、という流れです。片付けの担当は「調理台には決まった形で材料が並んでいるはず」と信じて手順どおりに片付けます。

途中でメモリが足りなくなると、中途半端な状態が残る

CVE-2026-109618 は、英語の資料では「OOM corruption」と呼ばれています。OOMは Out Of Memory の略で、メモリが足りなくなることです。PHPには、1件のリクエストが使ってよいメモリの上限（memory_limit という設定）があり、それを超えると処理を打ち切ります。

問題は、リクエスト用の作業スペースを準備している途中でメモリが足りなくなった場合です。準備が途中で打ち切られると、作業スペースの中のデータが「並べかけ」の不完全な状態で残ります。

ところが、そのあとの後片付けの処理は、データがきちんと並んでいるものと信じて手順どおりに動いてしまいます。並べかけの材料を「完成した調理台」だと思って片付けようとして、間違った場所に手を伸ばしてしまうようなものです。

攻撃する側は、わざとメモリが足りなくなるような大きなリクエストや細工したリクエストを送り、この「並べかけ」の状態を作り出します。そのうえで、後片付けが間違った場所を触るように仕向けると、最終的にはサーバーに好きな命令を実行させられるおそれがある、というのがこの欠陥の大まかな流れです。

なぜログインなしで成り立つのか

この欠陥のやっかいなところは、問題が起きるのが「リクエストを受け取って準備している段階」だという点です。サイトのプログラム（WordPressなど）が「この人はログインしているか」を確かめるのは、準備が終わってプログラムが動き始めてからです。準備の段階で問題が起きるなら、ログインの確認より前に攻撃が成り立ってしまいます。

つまり、サイト側のプログラムをどれだけ丁寧に作っていても、その手前にある土台で問題が起きるので防げません。これが「認証不要」と言われる理由であり、PHPの上で動くソフトの種類に関係なく影響が出る理由でもあります。

設定でできる緩和策とその限界

PHPの案内では、この欠陥に対して memory_limit=-1（メモリの上限をなくす設定）が緩和策として挙げられています。上限がなければ「上限を超えて途中で打ち切られる」ことが起きにくくなるからです。

ただし、サーバー全体のメモリが尽きれば確保の失敗そのものは起こりうるので、完全な対策にはなりません。アプリ側から設定を上書きできないようにすること、すべてのワーカーを再起動すること、ほかの設定でメモリの制限が再び有効にならないか確かめることも必要とされています。

また、コンテナやcgroup（Linuxでプロセスごとに使える資源を区切る仕組み）でメモリを制限している場合は、確保の失敗を確実には防げず、上限に達したときにワーカーがまとめて止まるおそれがあると注意されています。RLIMIT_AS や RLIMIT_DATA（プロセスが使えるメモリの量を制限する仕組み）は、かえって確保の失敗を起こして危ない処理を動かしてしまうおそれがあるため、使わないよう案内されています。

上限をなくすことには、メモリを使い切って別の不具合を招く心配もあるので、あくまで修正版を入れるまでのつなぎと考えてください。

2つ目の欠陥 CVE-2026-109619（次のリクエストに残る古い情報）

2つ目の CVE-2026-109619 は、英語の資料では「stale global state」と呼ばれています。stale は「古くなった」、global state は「リクエストをまたいで残る全体の状態」という意味です。こちらは「1件目のリクエストの名残が、2件目のリクエストに悪さをする」タイプの欠陥です。

ワーカーは、何件ものリクエストを続けて担当する

PHPを動かすサーバーでは、ワーカーと呼ばれる処理役のプロセス（コンピューターの中で動いている一つひとつの作業単位）が、リクエストを順番に担当します。リクエストのたびにワーカーを作り直すと時間がかかるので、同じワーカーが1件目を終えたら2件目、2件目を終えたら3件目と、使い回されるのがふつうです。

使い回すためには、前のリクエストの作業スペースをきちんと片付け、次のリクエストに何も残さないことが前提になります。ホテルにたとえると、チェックアウトのあとに部屋を清掃し、前の客の荷物やメモが残っていない状態で次の客を迎えるのと同じです。

解放したはずのメモリを指したまま残る

この欠陥では、致命的なエラーが起きたときなどに、ワーカーの中の「全体の状態」を記録している部分が、きちんと消去されないことがあります。gihyo.jpの解説によると、終了処理の途中で出た警告によって、いったん消した情報が再び記録されてしまう場合もあるそうです。

その結果、1件目のリクエストが終わって作業スペースのメモリは解放された（使い終わったので返却された）のに、「全体の状態」はそのメモリの場所を指したままになります。

次のリクエストが来ると、PHPは「全体の状態」が指す場所を信じて使おうとします。しかし、その場所はもう返却済みで、別のデータが置かれているかもしれません。

これを use-after-free（ユーズ・アフター・フリー、解放後使用）と呼びます。片付けたはずの場所の住所をプログラムが覚えたままで、そこへ書き込もうとしたら、すでに別のデータが置かれていた、という状況です。

攻撃する側は、1件目のリクエストでわざとこの状態を作り、2件目のリクエストで返却済みの場所に自分の都合のよいデータを置くように仕向けます。うまくいけば、PHPに自分のデータを「正しい情報」として使わせ、最終的に命令を実行させられるおそれがあります。

確認された攻撃の道筋

資料によると、この欠陥が攻撃につながることが確かめられた道筋は、主に2つです。

• fatal_error_backtraces（PHP 8.5の機能）：致命的なエラーが起きたときに、どこで何が起きたかの記録（バックトレース）を残す機能です。この道筋は mod_php（Apacheに組み込む方式）で確かめられています。
• セッションのアップロード進捗：ファイルをアップロードしている途中の進み具合を、セッション（同じ利用者の一連のアクセスを覚えておく仕組み）に記録する機能です。この道筋は mod_php と PHP-FPM の両方で確かめられています。

PHP-FPMで攻撃が成り立つかどうかは、後ろで動くアプリの処理にも左右されるとされています。いずれにしても、「うちはこの機能を使っていないから大丈夫」と自分で判断するのは難しく、修正版に更新するのが確実です。

設定でできる緩和策

この欠陥に対しては、session.upload_progress.enabled=0（アップロード進捗の記録を止める設定）が緩和策として案内されています。PHP 8.5では fatal_error_backtraces=0 も使えます。どちらも、設定を変えたあとにすべてのワーカーを再起動しないと効きません。

注意点として、アップロード進捗を止める設定は、php.ini（PHP全体の設定ファイル）など、リクエストを読み込む前に適用される場所で行う必要があります。プログラムの中で設定を変える ini_set() や、フォルダごとに置く .user.ini に頼るのは不十分とされています。

リクエストを読み込む段階で問題が起きるので、プログラムが動いてから設定を変えても間に合わないためです。

また、エラーの表示を止めたり、ログにエラーが出ていなかったりしても、それは安全の証明にはならないと明記されています。攻撃がうまくいった場合、目立つ痕跡を残さないこともありうるからです。

2つの欠陥を並べてみる

ここまでの説明を、表で並べておきます。どちらも「PHPが自分の作業の状態を信じすぎた」ことから生まれた欠陥ですが、問題が起きるタイミングが違います。

どちらの欠陥も、プログラムの書き方の小さな見落としが、長い年月を経て見つかったものです。PHPの本体は、C言語という、メモリの扱いを人間が細かく管理する言語で書かれています。

C言語は速く動く代わりに、「どのメモリをいつ返却したか」を間違えると、今回のような問題が起きやすいことが知られています。世界中の基盤ソフトの多くが同じ事情を抱えているため、似た種類の欠陥はほかのソフトでも見つかり続けています。

影響を受ける範囲と、どれくらいの数があるのか

PHPの公式の案内では、Webのリクエストを処理するすべてのPHPの実行環境が対象とされています。PHPには、Webサーバーとのつなぎ方がいくつかあり、どれを使っているかでリスクの高さが変わります。

PHPの動かし方ごとの違い

下の表は、主な動かし方と、今回の欠陥との関係をまとめたものです。

表のとおり、どの動かし方でも「対象外」にはなりません。mod_phpが特に危ないとされているのは、PHPがWebサーバーの中に組み込まれているため、問題が起きたときの影響がWebサーバーそのものにおよびやすく、アプリの処理より前の段階で攻撃が成り立つことが確認されているためです。

なお、攻撃が成り立った場合に実行される命令は、Webのリクエストを処理しているプロセスと同じ権限で動きます。サーバーの管理者権限（何でもできる最高の権限）がそのまま取られるわけではありませんが、Webサイトが触れるものには手が届くと考えておく必要があります。サイトのファイルやデータベースの接続情報などが、それに当たります。

影響を受ける版と、修正版がない版

版ごとの状況は次のとおりです。PHPの版は「8.4」のような大きな区切り（ブランチ）と、その後ろの「.27」のような細かい番号で表されます。

PHP 7.4、8.0、8.1はすでにサポートが終わっている版ですが、今回は深刻さを考えて、PHPが最小限の修正をソースコードの形で出しました。ソースからPHPを組み立てている人や、長期サポートの業者を使えない人のためのものです。

サーバー管理ソフトのcPanel（シーパネル）は、自社のPHPパッケージ（ea-php 7.4／8.0／8.1）に修正を移植しています。国内でも、エックスサーバーがPHP 5.6〜7.3への修正の適用を終えたと22日に告知するなど、事業者が独自に古い版を直している例があります。

修正版のない版を名乗るサーバーが約150万台

インターネット上の機器を調べているCensys（センシス）の調査では、分析した約260万台のPHPサーバーのうち、約150万台が修正版の提供されていない版を名乗っていました。「名乗っていた」というのは、サーバーが応答の中で知らせている版の情報をもとにした数字だからです。

事業者が独自に修正を当てていても番号は古いままのことがあるので、150万台がすべて危ないとは限りません。それでも、古い版のPHPが世界中で大量に動き続けている実態が見えてきます。

PHPは世界のWebの約7割で使われているとされます。そのうちのかなりの部分が、サポートの終わった版のまま動いていることになります。今回の件で、古い版を使い続けることの危うさが改めて浮き彫りになりました。

修正版と、直すときの注意点

ここからは、実際に直すときの話です。PHPの案内は一貫していて、「修正版への更新が唯一の確実な対処で、設定の変更だけでは完全には防げない」としています。

修正版を入れたら、ワーカーの再起動を忘れない

Linuxのディストリビューション（Linuxを使いやすくまとめた配布版。Ubuntu、Debian、Red Hat系など）には、修正が事前に共有されていました。自分でサーバーを管理している場合は、使っている配布元の更新情報を確認してパッケージを更新します。

ただし、配布元によっては10月23日時点で修正がまだ準備中のものもあったとされています。たとえばRed HatのRHEL 8〜10や、SUSEの一部の版では作業が進行中と報じられました。ボランティアで運営されている有名なPHPパッケージの配布元（remirepo）も、21日のうちには更新が出ず、22日に修正版を公開しています。

すぐに直せないときの緩和策

どうしても更新に時間がかかる場合のために、PHPは一時的な緩和策を案内しています。ただし、どれも修正版の代わりにはなりません。

国内で多くの組織がサイトを一時的に止めたのは、表のいちばん下の考え方によるものです。直すまでのあいだ、外から届かない状態にしておけば、少なくとも攻撃は受けません。

WordPressの開発チームも、PHP 8.2未満のサーバーを自分で管理している場合は、更新の準備ができるまでサーバーをオフラインにすることも検討するよう案内しています。

Cloudflareなどの防御サービスは「つなぎ」

Cloudflareは、WAF（ワフ、Webサイトの手前で怪しい通信を見分けて止める防火壁のような仕組み）を使っているサイトに対して、無料プランも含めて10月21日から保護を提供しました。無料プランでは利用者の操作は不要で、有料プランでは管理されたルールが「遮断」の設定になっているか確認が必要とされています。

リクエストとそれに対するサーバーの応答を組み合わせて見て、攻撃と判断したら応答が届く前に止める仕組みも入れたと説明しています。

ただし、DNSの設定が「DNS only」（Cloudflareを通さず直接サーバーにつながる設定）になっていると、WAFは働きません。また、Cloudflare自身も、WAFは緩和策であって、PHPの修正版の適用が必要だとしています。

防御サービスは時間を稼ぐためのもので、根本的な修理ではない、と考えてください。

WordPressを使っている人が確かめること

個人でWordPressのブログを運営している方は、まず自分のサイトのPHPの版を確かめてください。WordPressの管理画面で「ツール」→「サイトヘルス」→「情報」→「サーバー」と進むと、PHPのバージョンが表示されます。

WordPressの開発チームによると、今回の件でWordPress本体の更新は不要で、予定もないとのことです。直すべきはPHPのほうです。

レンタルサーバーを使っている場合、PHPの更新は基本的に事業者が行います。各社のお知らせで、自分の使っている版に修正が当たったかを確認するのが確実です。

管理画面で古い版（たとえば7.4や8.0）を選んでいる場合は、サポート中の8.2以降に切り替えられないかも検討してください。くわしい手順は、関連記事「このブログもPHPで動いています」で書いています。

立場ごとにやること

watchTowrのまとめなどをもとに、立場ごとにやることを整理すると次のようになります。

• サーバーを管理している人：PHPが動いているサーバーとアプリをすべて洗い出し、インターネットに公開されているもの、特にmod_phpで動いているものから先に更新します。更新後はワーカーを再起動します。
• 開発・運用を担当している人：使っているPHPの版とブランチを確認します。7.4、8.0、8.1を使っている場合は、配布元のパッケージ、修正の移植、新しい版への移行のどれで対応するかを決めます。
• セキュリティを担当している人：忘れられた古いサーバーやPHP 5のような古い版も含めて、組織全体を調べます。更新できないものにはアクセス制限などの一時的な対策を当て、公式の勧告や米CISAのKEVの更新を追い続けます。
• レンタルサーバーで個人サイトを運営している人：事業者のお知らせを確認し、管理画面でPHPの版を確かめ、古い版を選んでいればサポート中の版への切り替えを検討します。

OpenAIは、PHPの版を確かめる道具をGitHub（プログラムを公開・共有するサービス）で公開し、AIを使った開発支援ツールCodex（コーデックス）用のスキルとしても提供しています。ただし、版の番号だけでは修正済みかどうかを確定できないとも注意しています。事業者が独自に修正を当てている場合など、番号と実際の状態が一致しないことがあるためです。

更新できたかを確かめる

自分でサーバーを管理している場合、更新が終わったら、実際に動いているPHPが新しい版になっているかを確かめます。ここでよくある落とし穴が二つあります。

一つ目は、「コマンドで確かめた版」と「Webで動いている版」が違うことです。サーバーに命令を打ち込む画面で php -v と入力すると版が表示されますが、これは命令を打ち込む画面で使われるPHPの版です。Webのリクエストを処理しているPHP-FPMやmod_phpは、別の版が入っていることがあります。

一つのサーバーに複数の版のPHPを入れて、サイトごとに使い分けている場合は特に注意が必要です。Webで動いている版は、WordPressのサイトヘルスの画面や、PHPの設定を一覧表示する phpinfo() の出力などで確かめます。

二つ目は、先に書いたワーカーの再起動です。パッケージを更新しただけでは、動いているワーカーは古い版のままです。PHP-FPMのサービス、またはApacheを再起動したあとで、もう一度版を確かめると確実です。

サーバーが何台もある場合や、コンテナで動かしている場合は、すべての台で新しい版のイメージ（コンテナの元になる設計図）に入れ替わったかも確認します。古いイメージから立ち上がったコンテナが一つでも残っていれば、そこが入口になりえます。

また、配布元によっては、版の番号を上げずに修正だけを当てる（バックポートと呼びます）ことがあります。その場合、表示される番号は8.2.35より前のままでも、修正は入っていることになります。

逆に、番号だけを見て「修正済み」と判断するのも危険です。配布元の勧告で、自分の使っているパッケージの名前と版に、今回のCVE番号の修正が含まれているかを確かめるのがいちばん確実です。

レンタルサーバーやクラウドの「自動」の範囲

レンタルサーバーや、アプリを置くだけで動かしてくれるクラウドのサービスでは、事業者がPHPの更新を代わりにしてくれることが多いです。ただし、どこまで自動で直るかはサービスごとに違います。

gihyo.jpによると、LaravelというPHPの開発の枠組みを作っている会社のサービスでも、稼働中のアプリに修正版を自動で当てたもの、利用者が自分で更新する必要があったもの、利用者が再度デプロイ（アプリを置き直すこと）する必要があったものと、対応が分かれました。

「サービスに任せているから大丈夫」と思っていても、自分で選んだ古い版や、自分で作ったコンテナの中のPHPは、事業者の自動更新の対象外ということがあります。使っているサービスのお知らせを読み、「自分は何かする必要があるのか」を一度確かめておくと安心です。

3件目の欠陥 CVE-2026-115560

10月21日の修正版が出て一段落と思われた23日、PHPはもう一つの欠陥 CVE-2026-115560 を告知しました。こちらは「PHP2Shellの2件とは別の欠陥」で、セッションのアップロード進捗という機能に関わるものです。

どんな条件で起きるのか

gihyo.jpの解説によると、この欠陥は次の条件がそろったときに、RCEにつながるおそれがあります。

• セッションのデータを保存するときの形式（session.serialize_handler という設定）が、設定ファイルで php_binary か php_serialize になっている
• プログラムの中で ini_set() を使って、その形式を実行中に php に切り替えてから、session_start()（セッションを始める命令）を呼んでいる
• アップロード進捗の記録（session.upload_progress）が有効になっている

シリアライズとは、プログラムの中のデータを、保存したり送ったりできるように一続きの文字や数字の並びに変換することです。

保存の形式が途中で切り替わると、「書いたときの形式」と「読むときの形式」が食い違い、データの区切りを取り違えることがあります。アップロード進捗の記録には外から送られてきた情報が入るため、この取り違えを攻撃に使われるおそれがある、というのが大まかな仕組みです。

条件を見ると分かるように、保存の形式を実行中に切り替えるという、ふつうはあまりしない作りのアプリで起きるものです。PHPも、特定の設定とアプリのコードの組み合わせでしか起きない、まれな経路だとしています。2件の本体のように「PHPを使っていれば誰でも対象」というものではありません。

修正は次の定例リリースで、それまでは設定で止める

この3件目は、10月21日の修正版には含まれていません。PHPは、緊急の修正版ではなく次の定例のバグ修正リリースで直す予定とし、くわしい告知もそのときに出すとしています。

それまでのあいだは、session.upload_progress.enabled=0 を設定するよう案内しています。

この設定は、2つ目の CVE-2026-109619 の緩和策と同じものです。つまり、21日の時点ですでにアップロード進捗の記録を止めていた場合は、追加の対応はいりません。また、保存の形式を実行中に切り替えないアプリであれば、この機能を有効のままにしておいても問題ないとされています。

アップロード進捗の記録は、大きなファイルをアップロードするときに「いま何パーセント」と表示するために使われることがある機能です。止めると、その表示が出なくなるサイトもありえます。

ただ、多くのサイトではこの機能を使っていないので、止めても困らないことがほとんどです。自分のサイトで使っているか分からない場合は、レンタルサーバーの事業者やサイトの制作会社に確認するのが確実です。

「修正版を入れたのにまだ危ないのか」という疑問

3件目の告知を見て、「21日の修正版を入れたのに、まだ危ないのか」と不安になった方もいると思います。

大きな欠陥が見つかると、その周辺を多くの研究者が調べ直すため、関連する欠陥が続けて見つかることはよくあります。今回も、2件の調査の流れの中で3件目が見つかったと考えられます。

今後も追加の告知が出る可能性はあるので、PHPの公式発表や、使っている事業者のお知らせを、しばらくは気にかけておくと安心です。

悪用はどこまで進んでいるのか、世界はどう動いたか

最後に、実際の攻撃の状況です。ここでは「攻撃の試行が観測された」ことと「侵入に成功したことが確認された」ことを分けて書きます。ニュースでは両者が混ざって伝えられることがあるので、注意して読む必要があります。

公表の前から、試行は始まっていた

攻撃の試行は、修正版が公開される前から観測されていました。AmazonはハニーポットのMadPotで10月17日、公表の4日前に悪用の試行を観測しています。

21日の夕方以降は、WordPressのセキュリティを手がけるPatchstack（パッチスタック）、Cloudflare、セキュリティ企業のHadrian（ハドリアン）などが、試行が出始めていると相次いで公表しました。

Cloudflareの最高経営責任者マシュー・プリンス氏は、公表前の10時間に数千件、公表から45分で数万件、2時間以内に数十万件、投稿の時点で数百万件の試行があったと報告しています。

22日の0時過ぎには、公開されたPoC（攻撃が成り立つことを示す試作のコード）を使った試行も観測されました。watchTowrも、21日以降に自社のハニーポットで実際の悪用を観測しています。

さらに、脅威の調査を手がけるHunt.io（ハント・アイオー）は、Mirai（ミライ）型のボットネットがPHP2Shellを広がるための手段に加えたとみています。Miraiは、防犯カメラやルーターなどのIoT機器（インターネットにつながる家電や機器）を乗っ取ってつなげ、大量の攻撃に使う古くからのボットネット（乗っ取った機器の集まり）です。

ほかにも、Webシェル（サーバーに置いて外から操作するための裏口のプログラム）の設置を試みて失敗した例や、大半は単なる探り（スキャン）だという分析が報告されています。

「成功」の確認は、まだ見当たらない

一方で、侵入に成功したと公式に確認された報告は、10月24日時点では見当たりません。オランダのNCSC-NL（国家サイバーセキュリティセンター）とHunt.ioは、成功した侵害を確認していないとしています。Patchstackも、確かな侵害の証拠はないとしました。

Sophos（ソフォス）は、以前に出した「悪用に成功した」という報告を23日に訂正しています。NCSC-NLは、国外での悪用の可能性を伝える報告を1件把握しているものの、成功は確認できていないと更新しました。

ここまでに出てきた報告を、分類ごとに表にまとめます。

米国のCISA（サイバーセキュリティ・インフラストラクチャセキュリティ庁）は、実際に悪用が確認された脆弱性をKEV（Known Exploited Vulnerabilities）というカタログにまとめています。ここに載ると、米国の政府機関には期限つきでの対応が求められます。piyologの整理では、10月24日14時の時点で、今回の3件はいずれもKEVに載っていません。

なぜ、試行が数百万件もあるのに成功の確認がないのでしょうか。理由の一つは、公開されたPoCが動くための前提条件が多いことです。

VulnCheck、Rapid7、Sansec、SANS ISCといったセキュリティの専門組織は、公開PoCは条件がそろわないと動かず、広く確実に使えるものではないと評価しています。SANS ISCとSansecは、そのために大量の悪用は起きにくいとみています。

侵入されていないか気になるとき

修正版を入れる前の期間に、外からの攻撃を受けていなかったかが気になる方もいると思います。修正版を入れると、それ以降の攻撃は防げますが、入れる前にすでに入り込まれていた場合、その痕跡は自動では消えません。

OpenAIは、PHP2Shellで侵害されていないかを確かめるためのCodex用のスキルをGitHubで公開しています。自分でサーバーを管理している場合は、こうした道具も参考にしながら、次のような点を確かめておくとよいでしょう。

• 見覚えのないファイルがないか：サイトのフォルダの中に、作った覚えのないPHPのファイルが増えていないかを確かめます。Webシェルは、ふつうのファイルに見える名前で置かれることが多いです。
• 最近書き換えられたファイルがないか：更新作業をしていないのに、10月中旬以降に中身が変わったファイルがないかを確かめます。
• Webサーバーのログに不自然な記録がないか：同じ相手から大きなリクエストが大量に届いていないか、メモリ不足や致命的なエラーが急に増えていないかを見ます。ただし、先に書いたとおり、ログにエラーがないことは安全の証明にはなりません。
• 管理者のアカウントが増えていないか：WordPressなどの管理画面に、作った覚えのない管理者のユーザーが追加されていないかを確かめます。
• パスワードやAPIキーを取り替えるかどうか：WizはRCEに至らなくてもメモリから機密情報を読めることを示しています。データベースのパスワードや外部サービスのAPIキーなど、サーバーに置いている秘密の情報は、念のため取り替えることも検討します。

レンタルサーバーを使っている個人の方は、ここまでの作業を全部自分でする必要はありません。事業者のお知らせを確認し、管理画面のログイン履歴や、WordPressのユーザーの一覧に見覚えのないものがないかを見ておく程度で十分なことが多いです。気になる点があれば、事業者のサポートに相談してください。

各国の政府は「止めてでも守る」を選んだ

海外では、政府機関がサイトを予防的に止める動きが目立ちました。主な動きを表にまとめます。

日本でも、先に書いたとおり246の組織が停止などの対応を取りました。止めたことは「攻撃を受けた」という意味ではなく、「確認と更新が終わるまで、念のため外から届かないようにした」という意味です。

たとえばエックスサーバーは、アカウントの管理画面などを止めましたが、利用者のサイトの表示やメールは続けており、停止は不正アクセスによるものではないと案内しています。止めた組織と止めなかった組織の違いは、関連記事「日本で何が止まったか」でくわしく扱います。

海外のメディアでは、この時期を「Black October（ブラック・オクトーバー）」と呼ぶ言い方も広がりました。これは誰かが計画した一連の攻撃の名前ではなく、10月中旬に深刻な事件が立て続けに起きたことを指す呼び名です。

PHP2Shellと同じ時期に、AIのAPI（ほかのプログラムからAIの機能を呼び出すための窓口）をまとめて扱うライブラリの汚染や、開発者向けサービスの侵害なども相次ぎました。こちらは関連記事「“Black October”の10日間」でまとめます。

「まだ出てくる」という見方

今回の件では、AIを使った解析によって、長年見過ごされてきた欠陥が見つかりました。OpenAIは、PHP2Shellは発見と修正が進んでいる複数の重大な欠陥の一部にすぎず、今後数カ月で同じような発見が大幅に増えると予測しています。

Cloudflareのプリンス氏も、インターネットの基盤を支える別の重要なソフトに複数の深刻な欠陥があることを把握していると明かし、今後しばらくは対応が相次ぐという見通しを示しました。

一方で、AIが見つける欠陥の中には、攻撃に転用するのが難しいものも含まれるという指摘もあります。見つかる数が増えることが、そのまま被害が増えることを意味するわけではありません。ただ、修正版が出たら早めに入れる、古い版を使い続けない、という基本の大切さは、これまで以上に増していると言えます。

今回の件から見えること

PHP2Shellの経緯を振り返ると、技術の欠陥そのもの以外にも、考えさせられる点がいくつかあります。

• 一つ目は、見つけることと直すことのあいだに大きな差があることです。兆候は2024年に見つかり、攻撃方法も2026年8月には分かっていました。それでも、世界中で使われている土台を壊さずに直す方法を決め、配布元と足並みをそろえて公開するまでには、2カ月以上かかりました。AIで欠陥を見つける速さが上がっても、直す側の人手が増えなければ、この差はむしろ広がるおそれがあります。PHP Foundationが人員不足を認め、資金支援を呼びかけているのはそのためです。
• 二つ目は、秘密を守る約束の難しさです。エンバーゴは、修正の準備が整うまで攻撃する側に知られないようにするための大切な仕組みですが、関わる組織が増えるほど、どこかから漏れる危険も増えます。今回は、番号の流出と、修正入りのコンテナの早すぎる公開という二つのほころびが重なり、公開が前倒しされました。結果として、配布元によっては修正の準備が間に合わないまま公開を迎えることになりました。
• 三つ目は、古い版を使い続けることの危うさです。修正版のない版を名乗るサーバーが約150万台あったという数字は、一度作ったサイトがそのまま放置されやすいことを示しています。サポートが終わった版は、今回のような重大な欠陥が見つかっても、公式には直してもらえません。今回はPHPが特別に最小限の修正を出しましたが、いつもそうしてもらえるとは限りません。

仕組みから学びたい人へ

今回の件をきっかけに、「Webの脆弱性はなぜ生まれるのか」を基礎から知りたくなった方には、徳丸浩さんの『体系的に学ぶ 安全なWebアプリケーションの作り方 第2版』（SBクリエイティブ）があります。「徳丸本」の愛称で知られ、Webアプリの開発者やセキュリティの担当者のあいだで長く読まれてきた本です。

先にお断りしておくと、この本はPHP2Shellのような「PHP本体の欠陥」を扱った本ではありません。扱っているのは、PHPなどで書かれたWebアプリ側で起きる脆弱性と、その防ぎ方です。

また、第2版は2018年の刊行で、2026年8月には@ITで8年ぶりの改訂となる第3版の内容が紹介されています。第3版の発売時期は、この記事の時点では確認できていないので、購入の前に出版社の情報を確かめてください。

そのうえで、出版社の内容紹介から分かる、この本の良いところは次のとおりです。

• PHPで書かれたサンプルのアプリを実際に攻撃してみる形で、脆弱性が生まれる理由と具体的な対処方法を学べます。PHPを使う人にとって、自分の書くコードに引き寄せて読みやすい作りです。
• OWASP Top 10 – 2017（Webアプリの代表的な危険をまとめた国際的な一覧）に対応した改訂で、XXEや安全でないデシリアライゼーション（データの復元処理を悪用される問題）など、当時新しく注目された脆弱性も加えられています。今回の3件目にも出てきた「シリアライズ」の危うさを考える助けになります。
• HTML5の普及に合わせてWeb APIとJavaScriptの解説が新設されたほか、「脆弱性診断入門」の章が新しく設けられ、自分のサイトの弱点を確かめる考え方にも触れられています。
• 実習環境はWindowsに加えてMacにも対応しており、手元のパソコンで手を動かしながら読み進められます。
• HTTPやセッション管理、同一オリジンポリシーといったWebセキュリティの基礎から、文字コードの問題、開発の進め方まで、688ページで幅広くまとめられています。

体系的に学ぶ 安全なWebアプリケーションの作り方 第2版をAmazonで見る

まとめ

PHP2Shellは、世界のWebの約7割を支えるPHPの本体に、10年以上前から潜んでいたとされる2件の欠陥（CVE-2026-109618、CVE-2026-109619）です。

1つ目はメモリが足りなくなったときの後片付けが中途半端なデータを信じてしまう問題、2つ目は前のリクエストの名残が次のリクエストで解放済みのメモリを使わせてしまう問題で、どちらもログインなしで外からサーバーに命令を実行させられるおそれがあります。

2024年の兆候から始まり、2026年8月から9月にCalif、OpenAI、Wizが報告、10月20日の情報の流出を受けて公開が1日前倒しされ、21日の日本時間23時に修正版が出ました。23日には、条件の限られた3件目（CVE-2026-115560）も告知されています。

攻撃の試行は公表前から数百万件規模で観測されていますが、侵入の成功を公式に確認した報告は、10月24日時点では見当たりません。

• PHPを 8.5.12／8.4.27／8.3.36／8.2.35 以降に更新し、ワーカーを再起動する
• 7.4／8.0／8.1以前を使っている場合は、配布元や事業者の修正を確かめるか、サポート中の版へ移る
• 3件目に備えて、必要に応じて php.ini で session.upload_progress.enabled=0 を設定する
• すぐに直せないシステムは、外からのアクセスを制限することも検討する
• レンタルサーバーなら事業者のお知らせを確認し、管理画面でPHPの版を確かめる

「試行は多いが成功の確認はない」という今の状況は、更新を済ませるための猶予と考えるのがよさそうです。今後もAIによる発見で同じような告知が続くと見込まれているので、自分のサイトがどの版のPHPで動いているかを、この機会に一度確かめておいてください。

同じブログの「情報漏洩が10月だけで13件…」の記事では、今月相次いだ情報漏洩と、自分の情報が含まれていたときにやることをまとめています。

出典

• piyolog（PHP2Shellの経緯と状況のまとめ）
• gihyo.jp（PHPの緊急セキュリティリリースの解説）
• watchTowr（CVE-2026-109618 FAQ）
• Help Net Security（PHP2Shellの修正に関する記事）
• The Hacker News（PHPの緊急パッチに関する記事）
• Rapid7（CVE-2026-109618 / CVE-2026-109619の解説）
• CERT-EU Security Advisory 2026-018
• Wikipedia PHP2Shell
• 紀伊國屋書店 体系的に学ぶ安全なWebアプリケーションの作り方 第2版（出版社内容情報）
• @IT ITエンジニア必読書『徳丸本』が8年ぶりの改訂へ

※この記事の内容は、2026年10月24日時点で公表されている情報をもとにしています。