PHPの脆弱性「php2shell」とは？影響範囲・確認方法・対応手順をエンジニア向けに解説【2026年10月】

📖 読了時間：約15分

PHPの脆弱性「php2shell」とは、2026年10月21日に修正版が公開された2件の重大な脆弱性（CVE-2026-109618、CVE-2026-109619）の通称です。ログインなどの認証がなくても、外部からの通信でサーバー上のプログラムを実行されるおそれがあり、深刻度はどちらもCVSS v4.0で9.2（緊急）と評価されています。

修正版は、PHP 8.2.35、8.3.36、8.4.27、8.5.12の4つです。WordPressやLaravelなどPHPで動くシステムは、アプリケーション側を最新にしていても、PHP本体が古いままなら影響を受ける可能性があります。PHP公式は「完全な回避策はなく、更新が唯一の安全な選択肢」としています。

以下では、仕組み、影響を受ける環境、確認の手順、対応方法と暫定対策、経歴での伝え方の順に解説します。内容は2026年10月22日時点の公開情報にもとづいています。

この記事を読めば、担当しているPHP環境が対象かどうかを判断し、何から手を付ければよいかが分かります。対応を終えたら、無料のスキルログに作業の内容を記録して、経歴として残しておきましょう。

php2shellという通称は、発見に関わった研究者やセキュリティ企業の発信で使われ始めた呼び名です。2件とも、外部から送り込んだプログラムをサーバー上で動かされる「リモートコード実行（RCE）」につながるおそれがあります。

項目	CVE-2026-109618	CVE-2026-109619
不具合の中身	メモリ不足で処理が中断されたとき、作りかけのデータを正しいデータとして片付けてしまう	終わったリクエストの情報が解放後も残り、同じワーカーが処理する次のリクエストで使われてしまう
起きうること	リモートコード実行	リモートコード実行、メモリの中身の漏えい
深刻度	CVSS v4.0で9.2（緊急）	CVSS v4.0で9.2（緊急）
認証	不要	不要
攻撃のきっかけ	大量の項目を含む送信などで、わざとメモリ不足を起こさせる	エラーやセッションのアップロード進捗の機能などを経由する
修正版	8.2.35／8.3.36／8.4.27／8.5.12	8.2.35／8.3.36／8.4.27／8.5.12

なぜ「緊急」と評価されているのか

理由は3つあります。1つ目は、ログインが不要で、外部から通信を送るだけで攻撃を試みられることです。2つ目は、PHPの初期設定のままでも成立しうることです。公式のセキュリティ勧告では、Apacheのmod_phpの環境で、標準の入力やメモリの制限のままリモートコード実行を確かめたと書かれています。3つ目は、アプリケーションのコードが動く前の段階で攻撃が起きうるため、WordPressやフレームワークの側の対策では止められないことです。

悪用の状況

修正版の公開時点で、米国のセキュリティ企業は「実際の攻撃に悪用されることが予想され、攻撃コードも近く公開される見込み」としていました。一方、国内のセキュリティ企業の解説では、悪用できると主張するコードがインターネット上に出回り始めていると指摘されています。修正の内容から攻撃方法が調べられることも多いため、早めの更新が必要です。

PHPの公式の発表では、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなど、Webのリクエストを処理するすべてのPHPの環境が対象とされています。そのうえで、実行方式によって検証の進み具合が異なります。

実行方式	公式の勧告での検証状況	危険度の目安
Apacheのmod_php	2件とも、リモートコード実行を確認済み	最も高い
PHP-FPM	109619はセッションの機能を経由した実行を確認済み。109618はソースの解析のみ	高い
FrankenPHP	109618はmod_phpと同様に影響を受ける可能性。109619は初期設定では経路が見つかっていない	要注意
LiteSpeed（LSAPI）	2件とも、条件によって影響を受ける可能性	要注意

PHPのバージョンごとの状況

PHP 8.2〜8.5は、それぞれ8.2.35、8.3.36、8.4.27、8.5.12より前のものが対象です。PHP 8.1以前はPHP公式のサポートが終わっており、正式な修正版はリリースされていません。7.4、8.0、8.1向けの最小限の修正がGitHub上で公開されていますが、通常のリリースではありません。古いバージョンは、サポート対象への移行を前提に考えましょう。

アプリケーション側の更新では防げない

WordPress本体やプラグイン、Laravelなどのフレームワークを最新にしても、今回の問題は解消しません。不具合があるのはそれらを動かしているPHP本体だからです。

PHP 8.2は年末でサポートが終わる

PHP 8.2は、2026年12月31日で公式のセキュリティサポートが終了します。今回8.2.35に更新した場合も、2か月ほどで次の移行が必要になります。可能なら、この機会に8.3以降への移行を計画しましょう。

• Webで動いているPHPのバージョンを確かめる
• 実行方式（Server API）を確かめる
• OSやサーバー事業者が修正を当てているかを確かめる

Webで動いているPHPのバージョンを確かめる

サーバーにログインできる場合は、php -v でバージョンを表示できます。ただし、コマンドで動くPHPと、Webで動くPHPが別のバージョンになっていることがあります。Webの側は、phpinfo()の出力や、WordPressなら管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」で確かめましょう。

実行方式（Server API）を確かめる

phpinfo()の「Server API」の欄に、実行方式が表示されます。「Apache 2.0 Handler」ならmod_php、「FPM/FastCGI」ならPHP-FPMです。phpinfo()を表示するファイルを公開の場所に置いた場合は、サーバーの情報が外から見えてしまうため、確認が終わったらすぐに削除してください。

OSのパッケージは番号だけで判断しない

UbuntuやRed Hat系などのOSが配布するPHPのパッケージは、バージョン番号を変えずに修正だけを取り込むことがあります。この場合、番号が古く見えても修正済みのことがあります。OSの提供元のセキュリティ情報をCVE番号で検索するか、パッケージの更新履歴で修正が入ったかを確かめましょう。

レンタルサーバーやクラウドの場合

レンタルサーバーや、PHPの実行環境を提供するクラウドのサービスでは、事業者が修正を当てる場合と、利用者がバージョンを切り替える必要がある場合があります。お知らせを確かめ、分からなければ問い合わせましょう。

• 影響調査：対象のサーバーの一覧、PHPのバージョン、実行方式を洗い出す
• 報告：対象の範囲と、更新の予定を関係者に伝える
• 準備：Webサイトとデータベースのバックアップを取る
• 検証：可能なら検証環境で更新し、主な機能が動くかを確かめる
• 本番への適用：修正版に更新し、PHPのワーカーを再起動する
• 確認：表示、ログイン、フォーム、決済などの動作と、ログに不審な通信がないかを確かめる

環境	更新の方法	注意点
レンタルサーバー	管理画面でPHPのバージョンを切り替える。修正を事業者が当てる場合もある	事業者のお知らせで修正の状況を確かめる
VPS・自社サーバー	OSのパッケージを更新するか、修正版のPHPを入れる	更新後にPHP-FPMやApacheの再起動を忘れない
Docker	修正版のPHPを含むイメージに更新して作り直す	古いイメージのタグに固定していないか確かめる
クラウドの実行環境	提供元の手順に従い、ランタイムを更新する	自動で更新されるかは提供元によって異なる

すぐに更新できないときの暫定対策

公式のセキュリティ勧告には、更新までの間に危険を下げる設定が載っています。ただし、どれも完全な対策ではなく、更新の代わりにはなりません。

• memory_limit=-1 を、アプリ側から上書きできない形で設定する（メモリの上限がなくなるため、サーバーの資源には注意が必要）
• session.upload_progress.enabled=0 を設定する
• PHP 8.5では fatal_error_backtraces=0 も設定する
• post_max_size や max_input_nesting_level を控えめにする
• アプリで使っていなければ、ファイル送信の形式（multipart）の通信をWebサーバーの手前で止める
• 設定を変えたら、すべてのワーカーを再起動する

更新後に確かめること

更新が終わったら、主な機能が動くかに加えて、すでに攻撃を受けていないかも確かめます。修正版の公開前後のアクセスログやエラーログに不審な記録がないか、見覚えのないファイルが増えていないかを見ておきましょう。

影響調査から本番への適用、確認までを担当した経験は、保守運用やセキュリティ対応の実績になります。作業を終えたら、内容を忘れないうちに記録しておきましょう。

脆弱性が公開されてから対応を終えるまでの流れは、セキュリティエンジニアの仕事の一部でもあります。どんな業務があるかはセキュリティエンジニアの仕事内容で、その分野を目指す方法はセキュリティエンジニアの転職完全ガイドで紹介しています。

書き方	例
伝わらない例	サーバーの保守を担当。PHPのバージョンアップを実施
伝わる例	PHPの緊急脆弱性（CVE-2026-109618／109619）への対応を担当。社内Webサイト5件のバージョンと実行方式を調査して影響を報告し、検証環境で互換性を確かめたうえで、公開から3日以内に本番の更新と動作確認を完了

書くときに入れたい4つの要素

• 対象：どのシステムやサーバーを、何件担当したか
• 役割：調査、判断、作業、確認のどこを担当したか
• 工夫：手順書を作った、暫定対策を先に入れたなど
• 結果：どれくらいの期間で、問題なく終えられたか

数字と期間を入れると伝わる

対象の件数や、公開から対応完了までの日数を入れましょう。セキュリティの経験の書き方はセキュリティ設計 スキルシートの書き方で、実績の書き方全般はエンジニアの職務経歴書のプロジェクト実績の書き方で詳しく解説しています。スキルログでは、案件ごとに期間・役割・規模・成果を入力でき、PDF出力でスキルシートにまとめられます。

php2shellは、2026年10月21日に修正版が公開された、PHP本体の2件の脆弱性です。修正版は8.2.35、8.3.36、8.4.27、8.5.12で、Webのリクエストを処理するPHPの環境は広く影響を受ける可能性があります。

まずはバージョン、実行方式、OSのパッケージの修正状況を確かめ、対象であれば速やかに更新しましょう。すぐに更新できない場合は暫定対策を入れつつ、更新の日程を決めておくことが大切です。

参考：PHP公式・2026年のお知らせ、CVE-2026-109618の公式セキュリティ勧告、CVE-2026-109619の公式セキュリティ勧告、PHP公式・サポート対象のバージョン

WordPressを最新版にしていれば大丈夫ですか？

いいえ、大丈夫とは限りません。今回の問題はWordPressではなくPHP本体にあるため、WordPressを最新にしていても、PHPが修正前のままなら影響を受ける可能性があります。

php2shellとは何ですか？

2026年10月に公表されたPHPの脆弱性2件（CVE-2026-109618とCVE-2026-109619）の通称です。どちらも、認証なしでサーバー上のプログラムを実行されるおそれがあります。

PHP 7.4や8.1を使っている場合はどうすればよいですか？

サポート対象のバージョンへの移行を進めてください。正式な修正版は出ていないため、移行までの間は暫定対策を入れ、事業者やOSの提供元が独自に修正を出していないかも確かめましょう。

暫定対策だけで十分ですか？

十分ではありません。PHP公式は、設定の変更では完全には防げず、更新だけが確実な対策だとしています。暫定対策は、更新までの時間を稼ぐためのものと考えましょう。

すでに攻撃されていないかを確かめるにはどうすればよいですか？

アクセスログとエラーログを確かめるのが第一歩です。不審な大きさの送信や、見覚えのないファイルの追加がないかを見ます。判断が難しい場合は、セキュリティの専門家に調査を依頼しましょう。

ここまでの内容を踏まえて、まずは担当しているPHP環境のバージョンを確かめ、対応を終えたらその内容を記録しておきましょう。