PHP 脆弱性「PHP2Shell」｜何をすれば良いか、影響と追加RCEの対応
この記事の要点
- PHPは2026年10月21日、認証なしの遠隔コード実行につながる脆弱性2件（CVE-2026-109618・109619、通称PHP2Shell）を修正した8.5.12・8.4.27・8.3.36・8.2.35を公開しました。
- 対象はWebリクエストを処理するPHP全般（PHP-FPM、Apacheのmod_php、php-cgi等）で、PHP公式はmod_phpの危険度が最も高いとしています。設定変更による緩和策は不完全で、完全な対策は更新だけです。
- Amazonは公表の4日前の10月17日に悪用の試行を観測しました。一方、CISAは10月23日に改訂した注意喚起でも、公開時点で悪用の成功は確認していないとしています。
- 共用のレンタルサーバーでは大手の事業者が修正の適用を告知していますが、VPS・自社サーバー・委託先のサイトは自分で確かめる必要があります。8.1以前には公式の修正リリースがありません。
- 10月23日に告知された3件目（CVE-2026-115560）は修正版が未公開ですが、条件はまれで、session.upload_progress.enabled=0 を設定済みなら追加作業は不要とPHP公式は説明しています。
Webサイトの開発に広く使われているプログラミング言語 PHP に、認証なしで遠隔からコードを実行されるおそれのある脆弱性が2件見つかりました。PHPの開発チームは2026年10月21日に修正版を公開し、すべての利用者にただちに更新するよう求めています[1]。「PHP2Shell」と呼ばれるこの問題について[13]、日本でもIPAとJPCERT/CCが注意喚起を出しました[6][7]。
公表の前から悪用の試行が観測されており[5]、10月23日には修正版でも直っていない3件目の脆弱性も告知されています[8]。情報が短い間に次々と更新されたため、「結局、自社は何をすれば良いのか」が分かりにくくなっています。
この記事では、専門家でなくても判断できるように、「何が起きたか」「自社は対象か」「何をすれば良いか」「侵害をどう調べるか」を順に整理します。情報は2026年10月25日時点のものです。
何が起きたのか？
PHPの処理系そのものに、遠隔の攻撃者が認証なしでコードを実行できる脆弱性が2件見つかり、2026年10月21日に修正版の 8.5.12・8.4.27・8.3.36・8.2.35 が公開されました[1]。PHPで動くWebサイトやWebサービスのほぼすべてが確認の対象になります。
CVSS（脆弱性の深刻度を0〜10で表す共通の指標）は、開発元の評価で2件とも 9.2 です[2][3]。公表前日の10月20日には、CVE番号が誤った公開時刻と誤った評価（10.0）付きで出回り、PHPの開発チームは予定していた公開を1日前倒ししました[9]。
| CVE | 何が起きるか（公式の説明の要約） | 確認された影響 |
|---|---|---|
| CVE-2026-109618 | メモリ不足（OOM）の処理が、リクエストのデータを初期化している途中でPHPを中断させる。後片付けの処理が、その不完全なデータを正しいものとして扱ってしまう[1] | Webサーバーの実行アカウントの権限での、認証なしの遠隔コード実行。mod_phpで、PHPの標準の入力・メモリ制限のまま実証[2] |
| CVE-2026-109619 | 解放済みのメモリを指す内部の状態が残り、同じワーカー（PHPを実行するプロセス）が処理する次のリクエストがそれを使ってしまう[1] | メモリ内容の漏えいと遠隔コード実行。セッションのアップロード進捗の経路では、mod_phpとPHP-FPMの両方で実証（FPMはアプリ側に条件となる処理がある場合）[3] |
2026年10月25日時点。CVSS v4.0 は開発元（PHP）の評価。米NISTのNVDはCVSS v3.1で109618を9.8、109619を8.1と評価しています[16][18]。
公表までの流れ
2024年
外部監査で兆候を把握
外部監査の指摘を修正する過程で、メモリ不足の処理の問題に気づいていた。PHP Foundationは対応の遅れを「構造的な失敗」と認めている[9]
8月〜9月
複数の研究者が報告
セキュリティ企業のCalifが8月11日に報告し、OpenAIも独自に同じ根本原因を報告した。追加の攻撃経路はWizが8月24日に、OpenAIが9月18日に報告した[9]
10月17日
最初の悪用試行
Amazonが自社のおとりサーバー網（MadPot）で、公表の4日前に悪用の試行を観測した[5]
10月20日
CVE番号が流出し、公開を前倒し
CVE番号が誤った情報付きで出回る（技術的な詳細は漏れていない）。公開予定を10月22日から21日に前倒しした[9]
10月21日
修正版を公開
8.5.12・8.4.27・8.3.36・8.2.35を公開し、ただちに更新するよう呼びかけた[1]。同日、IPAが事前準備を呼びかけ、CISA（米国のサイバーセキュリティ・インフラストラクチャセキュリティ庁）も注意喚起を出した[4][17]
10月22日
国内で注意喚起
IPAとJPCERT/CCが注意喚起を公開した[6][7]。ロリポップ!が修正を適用し、13時頃にサイトの表示を再開した[11]
10月23日
3件目を告知
PHPが修正版でも直っていない CVE-2026-115560 を告知し、設定による緩和策を案内した[8]。CISAは注意喚起を改訂し、検知ルールを追加した[4]。さくらインターネットが緊急メンテナンスの終了を告知した[10]
自社は対象か？どう見分ければいい？
Webリクエストを処理するPHPで、バージョンが修正版より古ければ対象です。 PHP公式は、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedを挙げ、なかでもmod_phpの危険度が最も高いとしています[1]。
| 系列 | 修正版 | 補足 |
|---|---|---|
| 8.5 | 8.5.12[1] | 8.5では、追加の緩和策として fatal_error_backtraces=0 が案内されている[1] |
| 8.4 | 8.4.27[1] | — |
| 8.3 | 8.3.36[1] | — |
| 8.2 | 8.2.35[1] | 8.2は2026年12月31日にサポート終了。以後はセキュリティ修正も出ない[12] |
| 8.1以前 | 公式リリースなし（7.4〜8.1はソース修正のみ） | PHPプロジェクトの更新対象外。7.4・8.0・8.1向けには、PHPのセキュリティチームが最小限のソース修正を提供した[1]。OSの提供元がバックポートを出している場合もある |
Linuxディストリビューションや長期サポート（LTS）事業者には事前に修正が渡されているため、OSのパッケージで入れたPHPはOSの提供元の更新情報も確認してください[1]。
mod_phpの危険度が高いのは、認証のないリクエストで、アプリのコードが動き始める前に攻撃が成立しうるからです[1]。つまり、アプリ側にどれだけ気を配っていても防げません。発見者の1社であるWizは、テスト時点で最新だったWordPressのコンテナイメージ（wordpress:latest）でも、認証なしでのコード実行を実証したとしています[13]。
悪用はどこまで進んでいるのか？
悪用の試行は大規模に観測されていますが、悪用の成功はCISAなどの公的機関がまだ確認していません。 CISAは10月23日の改訂版でも、公開時点で実際の悪用の成功は確認していないとしています（初版では「悪用は確認していない」としていた）[4]。それでも、すぐに更新できない組織にはシステムをオフラインにするよう勧告しています[4]。
Amazonの脅威インテリジェンスは、MadPotの観測データの中に、公表の4日前にあたる2026年10月17日のPHP2Shellの悪用試行を確認しました。
Amazon Threat Intelligence identified a PHP2Shell exploitation attempt dating to Oct. 17, 2026, in MadPot telemetry, four days before public disclosure of CVE-2026-109618 and CVE-2026-109619.
Amazonは、公開当日の10月21日にも複数の概念実証コード（脆弱性を突けることを示すコード）と、複数の攻撃者によるとみられる試行を確認しました。ただし、それらが実際のシステムで成功したかは分からないとしています[5]。そのうえでAmazonは、公表日を悪用の始まりと考えてはいけないと指摘し、調査は少なくとも10月17日から始めるよう勧めています[5]。
一方、米The Recordの取材に応じた数十人の専門家は、これまでの試行はどれも成功しておらず、公開されている概念実証の多くは理想的な実験環境でしか動かないとしています。そのため、10月23日（金）の時点では大規模な悪用は起こりにくいという見方です[14]。ただし、脆弱性情報を扱うVulnCheckは、本番相当の環境で攻撃を難しくしている大きな障壁を越える手法を開発したと説明しています。Googleの専門家も、限定的な悪用がすでに始まっている可能性を指摘しています[14]。
何をすれば良いか？今週中にやること
やることは「探す」「上げる」「調べる」の3つです。PHP公式は、設定で入れられる緩和策は特定の攻撃経路を減らすだけで、安全にはならないと明記しており、完全な対策は修正版への更新だけです[1]。IPAも、まずPHPを使っているものを棚卸しするよう求めています[17]。
情シス・Web担当のチェックリスト
- PHPで動いているサイト・サービス・社内システムを洗い出す（コーポレートサイト、ECサイト、問い合わせフォーム、WordPress、社内ポータル、製品やネットワーク機器の管理画面など）[17]
- 各環境のPHPのバージョンを確認し、修正版（8.5.12・8.4.27・8.3.36・8.2.35）以上かを確かめる[1]
- インターネットに公開しているものから優先して更新する[4]
- 8.1以前を使っているものは、サポート中の系列への移行計画を立てる。すぐに移行できなければ、外部からのアクセス遮断や一時停止を判断する[4][6]
- レンタルサーバー事業者・制作会社・運用委託先の告知を確認し、自社サイトの対応状況を問い合わせる[10][11]
- PHPを内部で使う製品やネットワーク機器は、マニュアルや開発元のセキュリティ情報を確認する[17]
- 更新後も、10月17日以降のログに侵害の痕跡がないかを調べる（次の節）[5][7]
レンタルサーバーとVPS・自社サーバーで、やることが違う
同じPHPでも、誰がサーバーを管理しているかで、更新を担う人が変わります。共用のレンタルサーバーでは、サーバー側のPHPは事業者が管理しているため、修正の適用も事業者が担います。たとえばさくらインターネットは、10月21日22時30分から一部サービスの予防的な緊急メンテナンスを行い、提供しているサポート終了版のPHPにも修正を適用したと10月23日に告知しました[10]。
すぐに更新できない場合は
PHP公式は、更新までのつなぎとして次のような設定を案内しています。ただし、どれも特定の攻撃経路を減らすだけで、安全になるわけではないと明記しています[1]。
memory_limit=-1を、アプリから上書きできない方法（FPMプールやApache設定の php_admin_value など）で設定し、すべてのワーカーを再起動する（完全ではない）[1][2]session.upload_progress.enabled=0を設定し、すべてのワーカーを再起動する。設定は php.ini やFPMのプール設定など、リクエストの解析より前に効く場所で行う（ini_set()や.user.iniには頼らない）[1]- PHP 8.5では
fatal_error_backtraces=0を設定し、すべてのワーカーを再起動する[1] post_max_sizeを小さくする（アップロードが不要なら8M、必要なら32M）。Webサーバーやプロキシの側でも、リクエストの大きさや項目の数を制限する[1]- multipart/form-data（ファイル送信などに使う形式）を使わないアプリなら、PHPに届く手前でその形式のリクエストを遮断する[2]
WAF（Webアプリへの攻撃を遮る仕組み）についても、CISAは更新までに一定の防御になりうるという位置づけにとどめています[4]。IPAは、有効な暫定対策が難しい場合には、被害や業務への影響を踏まえて、外部からのアクセス遮断やサービスの一時停止が必要か判断するよう求めています[6]。
3件目のCVE-2026-115560は何が違う？
10月23日に告知された CVE-2026-115560 は、10月21日の修正版でも直っていない別の脆弱性です。ただし起きる条件はまれで、設定1つで防げます。 PHP公式は、次の定例リリースまで session.upload_progress.enabled=0 を設定するよう勧めています[8]。
PHP公式によると、問題が起きるのは、設定で session.serialize_handler を php_binary か php_serialize にしたうえで、アプリが session_start() の前に ini_set() で php に切り替え、さらにアップロード進捗が有効なままになっている場合だけです[8]。実行中にこの設定を切り替えないアプリは、アップロード進捗を有効にしたままでよいとされています[8]。
この設定は、CVE-2026-109619 の緩和策としても10月21日に案内されていました。PHP公式は、そのときに設定していれば、そのまま維持すれば追加の作業は不要だとしています[8]。こうした構成は実際にはまれなため、PHPは緊急リリースではなく通常のリリースで修正し、そのときに詳しい情報を公開する方針です[8]。
侵害を受けていないか、どう調べる？
更新で今後の攻撃は防げますが、すでに侵入されていたかどうかは分かりません。JPCERT/CCは、対策の適用とあわせて侵害の有無を調べるよう求め、発見者らの公開情報をもとに調査の観点を示しています[7]。
- 過去のHTTPレスポンスで、不自然に長い、または形式のおかしい値の PHPSESSID（セッションを識別するCookie）が設定されていないか[7]
- 不審な multipart/form-data 形式のリクエストが届いていないか。その前後に、PHPのメモリ上限に関するエラーや HTTP 500 エラーが出ていないか[7]
- PHPのワーカープロセスが予期せず異常終了したり、頻繁に再起動したりした跡がないか[7]
- PHPのワーカープロセスがシェル（コマンドを実行するプログラム）を起動したり、ツールをダウンロードしたりしていないか[4]
JPCERT/CCは、こうした痕跡が見つからなくても、攻撃を受けていないとは言い切れないとしています[7]。侵害が疑われる場合は、ログなどの証拠を保全したうえで、影響範囲の調査と隔離を進めるよう求めています[7]。調べる期間について、Amazonは少なくとも10月17日までさかのぼって調べるよう勧めています[5]。
AIは今回どう関わったのか？
今回の脆弱性の発見には、AIを使った研究が関わっています。脆弱性の登録情報では、OpenAIが CVE-2026-109618 の発見者として記載されています[15]。発見者の1社であるWizも、自社の記事のタイトルで、AIがこの脆弱性を見つけたと打ち出しています[13]。
AIが脆弱性を見つける力を高めると、守る側にとっての意味は二つあります。一つは、長年見つかっていなかった不具合が表に出て、修正が進むことです。もう一つは、攻撃する側も同じ速さで脆弱性を調べ、攻撃コードを作りうることです。Amazonは、インターネットに公開しているシステムの重大な脆弱性については、更新や緩和策の期限を「時間」の単位で考えるべきだとしています[5]。
まとめ
PHPは2026年10月21日、認証なしの遠隔コード実行につながる2件の脆弱性（PHP2Shell）を修正しました[1]。公表前から悪用の試行が観測されており[5]、公的機関はすぐに更新するよう求めています[4][6][7]。
御社でやることは、PHPが動いている場所を洗い出し、修正版（8.5.12・8.4.27・8.3.36・8.2.35）以上に上げ、10月17日以降のログで侵害の有無を調べることです。共用のレンタルサーバーは事業者の対応を確認し、VPS・自社サーバー・委託先のサイトは自分たちで確かめてください。3件目の CVE-2026-115560 は、次の定例リリースまでは session.upload_progress.enabled=0 を入れておけば追加作業は不要です[8]。同じ週に修正された別の基盤の脆弱性はNode.js 脆弱性（2026年10月）、生成AIを含むセキュリティの考え方はAIセキュリティとはで解説しています。
よくある質問
PHPの脆弱性（PHP2Shell）で、企業はまず何をすれば良いですか？
まず、PHPで動いているサイトやシステムを洗い出し、バージョンが修正版（8.5.12・8.4.27・8.3.36・8.2.35）以上かを確認してください。古ければインターネットに公開しているものから優先して更新します。8.1以前には公式の修正版がないため、移行するか、外部からのアクセス遮断や一時停止を判断します。更新後は、2026年10月17日以降のログで侵害の痕跡を調べてください。
WordPressを最新版に更新すれば、PHP2Shellへの対策になりますか？
なりません。PHP2ShellはWordPressではなく、その下で動くPHPそのものの脆弱性です。WordPressやプラグインを更新しても、PHPのバージョンは変わりません。発見者のWizは、テスト時点で最新だったWordPressのコンテナイメージ（wordpress:latest）でも認証なしのコード実行を実証したとしています。PHP本体を修正版に上げてください。ただし、PHPを同梱したWordPressのコンテナイメージを使っている場合は、修正版のPHPを含むイメージに入れ替えることが、PHPの更新にあたります。
レンタルサーバーを使っていれば、自分で対応しなくても大丈夫ですか？
共用のレンタルサーバーでは、サーバー側のPHPは事業者が管理しており、大手の事業者が修正の適用を告知しています。まずは事業者の告知で対応の完了を確認してください。一方、VPSやクラウドの仮想サーバーなど自分で管理するサービスは、利用者自身で更新する必要があります。WordPress本体やプラグイン、テーマの更新もあわせて確認しておくと安心です。
10月23日に告知された CVE-2026-115560 には、追加の対応が必要ですか？
PHP公式は、次の定例リリースまで session.upload_progress.enabled=0 を設定するよう勧めています。CVE-2026-109619 の緩和策としてすでに設定していれば、そのまま維持すれば追加作業は不要です。起きる条件は、アプリが実行中にセッションの保存形式の設定を切り替える、まれな構成に限られます。
WAFを入れていれば、PHPを更新しなくても大丈夫ですか？
大丈夫ではありません。CISAはWAFについて、更新までの間に一定の防御になりうるという位置づけにとどめています。PHP公式も、完全な対策は修正版への更新だけだとしています。WAFは更新までの時間稼ぎとして使い、修正版への更新と侵害調査を進めてください。
出典・参考資料
- 注意喚起Security advisory: Critical remote code execution vulnerabilities, update now
- 注意喚起RCE via OOM corruption (GHSA-w8hw-w9fx-j79w)
- 注意喚起RCE via stale global state (GHSA-6wmf-4rv5-p3rp)
- 注意喚起Critical Vulnerabilities in PHP Require Immediate Patching
- 調査レポートAmazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot
- 注意喚起PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619：PHP2shell)
- 注意喚起PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起
- 注意喚起Informational advisory: Session upload progress
- 公式発表Today's PHP Security Release, and How We're Strengthening PHP Security
- 公式発表【重要】PHPの脆弱性に関する当社の対応状況について（2026年10月23日17:30追記）
- 公式発表PHPの脆弱性への対応に伴うメンテナンス完了と経緯のご報告
- 公式発表PHP 8.2.35 Released!
- 調査レポートPHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet
- 記事Reports of PHP bug exploitation attempts grow as experts downplay viability of exploits
- 公式発表CVE-2026-109618
- 注意喚起CVE-2026-109618 Detail
- 注意喚起【事前準備のお願い】PHPのセキュリティリリース公開予定について
- 注意喚起CVE-2026-109619 Detail
本記事の事実関係は、2026.10.25 時点で上記の出典をすべて再確認しています。 修正版・影響範囲・悪用状況は変わる可能性があります。最新の情報はPHPの公式告知とIPA・JPCERT/CCの注意喚起を確認してください。
