MENU
情報漏えい・脆弱性・詐欺の最新情報を、公式発表をもとに
  1. ホーム
  2. 情報セキュリティ
  3. 脆弱性・アップデート
  4. PHPの重大脆弱性php2shellは自分も対象？確認方法とアップデート方法

PHPの重大脆弱性php2shellは自分も対象？確認方法とアップデート方法

広告
脆弱性・アップデート
PHPの重大脆弱性php2shellは自分のサイトも対象？修正版と確認手順

PHP 8.2〜8.5 の修正版より前のバージョンでWebリクエストを処理しているサーバーは、すべて今回の2件の重大な脆弱性（CVE-2026-109618・CVE-2026-109619）の対象で、修正版は PHP 8.5.12・8.4.27・8.3.36・8.2.35 の4つ、PHP公式は「更新が唯一の安全な選択」としています。PHP公式は2026年10月21日、認証なしのリモートコード実行につながる2件を修正したと発表しました。オランダの国家サイバーセキュリティセンター（NCSC-NL）はこの2件を「php2shell」と呼んでいます。この記事では「自分は対象か（確認方法）」「今すぐ何をするか（アップデート方法）」と最新情報を、PHP公式・GitHubのセキュリティアドバイザリ・公的機関・関係企業の発表に書かれた内容だけで整理します。

【結論】

  • 対象：Webリクエストを処理するすべてのPHP（PHP-FPM・Apache mod_php〔Apache に組み込んで動かす方式〕・php-cgi・FrankenPHP・LiteSpeed）。影響バージョンは 8.2.35／8.3.36／8.4.27／8.5.12 より前です。
  • 今すぐやること：PHPを修正版（8.5.12・8.4.27・8.3.36・8.2.35）か、OS・ベンダーが配布する修正済みパッケージに更新し、PHPのワーカー（リクエストを処理するPHPのプロセス）を再起動します。レンタルサーバーは契約先の公式のお知らせを確認します。
  • 確認方法：php -v・phpinfo の画面・WordPress の「サイトヘルス」でPHPのバージョンを見て、修正版より前なら対象です（手順は下の「PHP脆弱性の確認方法とアップデート方法」）。
  • 最新情報（2026年11月9日確認）：PHP公式のニュースでは、10月21日のあと新しいセキュリティリリースは出ておらず、最新版は 8.5.12・8.4.27・8.3.36・8.2.35 のままです。10月23日告知の3件目（CVE-2026-115560）は、次の定例のリリースで修正するとしています。
  • 更新できない場合：設定による緩和策はありますが、PHP公式は「完全な緩和策はない」と明記しています。あくまで更新までのつなぎです。
  • 悪用の状況：米国CISAは2026年10月26日（米国時間）、2件を「悪用が確認された脆弱性」のカタログ（KEV）に追加しました。IPAは2026年10月27日時点で、国内での攻撃被害の事例は把握していないとしています。
目次

PHP脆弱性の一覧（2026年10月）：CVE・深刻度・修正版

PHP公式の告知とGitHub上のセキュリティアドバイザリ（GHSA）の記載です。

項目CVE-2026-109618CVE-2026-109619
公式の名称RCE via OOM corruption（メモリ不足の処理での破損によるリモートコード実行）RCE via stale global state（古いグローバル状態の再利用によるリモートコード実行）
アドバイザリGHSA-w8hw-w9fx-j79wGHSA-6wmf-4rv5-p3rp
深刻度（CVSS v4.0）Critical・9.2Critical・9.2
想定される影響認証なしでのリモートコード実行（Webワーカーのアカウントの権限で）認証なしでのメモリの解放後使用（use-after-free）、メモリ内容の漏えい、リモートコード実行
影響バージョン8.2.35未満／8.3.36未満／8.4.27未満／8.5.12未満（GHSAの記載）
修正版PHP 8.5.12・8.4.27・8.3.36・8.2.35
公開日時（日本時間）事前告知：2026年10月21日早朝（php.net の掲載は10月20日20:32 UTC）／修正版：2026年10月21日（予定は23:00、GHSAの公開時刻は22:34）

CVSSのベクタは2件とも CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N です。ネットワーク経由で権限もユーザーの操作も不要、成功すると機密性・完全性・可用性に大きな影響がある一方、攻撃の複雑さは「高」、前提条件は「あり」と評価されています。

なお、PHP 8.2 は2026年12月31日でサポート終了となり、それ以降はセキュリティ修正も出ません（PHP公式）。8.2.35 に更新した場合も、移行の計画が必要です。

この2件のほかに、PHP公式は2026年10月23日、3件目の CVE-2026-115560 を告知しています（内容と対策は下の「3件目のCVE-2026-115560」）。

PHP脆弱性の最新情報（2026年11月9日確認）

  • 新しいセキュリティリリース：PHP公式の2026年のニュースアーカイブでは、10月21日の 8.5.12・8.4.27・8.3.36・8.2.35 のあと、PHP 8.2〜8.5 の新しいリリースは出ていません（11月5日の PHP 8.6.0 RC5 はテスト版で、PHP公式は本番環境で使わないよう求めています）。
  • 3件目（CVE-2026-115560）：PHP公式は「次の定例のバグ修正リリース」まで session.upload_progress.enabled=0 にするよう勧め、詳しいアドバイザリはそのリリースで公開するとしています。11月9日時点で、そのリリースはまだ出ていません。
  • Windows版：PHP公式は2026年10月26日、Windows版のビルドを 8.5.12-1・8.4.27-1・8.3.36-1・8.2.35-1 に更新しました（Updated PHP Windows builds for Brotli security fix）。同梱の Brotli を 1.2.1 にして別の脆弱性 CVE-2026-111497 を直したもので、「-1」はパッケージの作り直しを示し、PHP本体のバージョンは変わらないとしています。

自分は影響を受ける？　環境別の切り分け

PHP公式は対象を「Webリクエストを処理するすべてのPHP」とし、Apache の mod_php を最もリスクが高いとしています。mod_php では、アプリのコードが動く前に認証なしのリクエストで攻撃が成立することが実証されているためです。

環境対象か何をすべきか
レンタルサーバー（共用サーバー）サイトのPHPが修正版より前なら対象（7.4・8.0・8.1 などサポート終了版も含む）契約先の公式のお知らせ・管理画面で対応状況を確認。PHPのバージョンを選べる場合は、選んでいるバージョンも確認します。
自社サーバー・VPS（Linux）Webで使うPHPが修正版より前なら対象ディストリビューションやLTSベンダー（サポート終了後も有償で修正を出す事業者）の更新パッケージを適用し、PHP-FPMやApacheを再起動します。
WordPressWordPressを動かしているPHPが対象。WordPress本体やプラグインの更新では直らないPHP本体を修正版にします（上の2行のどちらかの手順）。
Docker・コンテナイメージに入っているPHPが修正版より前なら対象ホスト側のPHPを更新しても、イメージや機器に同梱されたPHPが更新されるとは限りません（NCSC-NL）。修正版を含むイメージで作り直し、入れ替えます。
PHP 8.1 以前対象として扱う（CERT-EU は影響製品に8.1以前を挙げる）。PHPプロジェクトからの更新はありませんベンダーのバックポート（修正の移植）を確認するか、サポート中のバージョンへ移行します。ソースからビルドする人向けに、PHP 7.4・8.0・8.1 用の最小限のソースバックポートも公開されています。
製品・ネットワーク機器（内部でPHPを使うもの）内部でPHPを使っていれば影響の可能性製品のマニュアルや開発元・提供元のセキュリティ情報を確認します（IPA）。
PHPの重大脆弱性2件について、Webで使っているか・PHPのバージョン・自分で更新できるかの順に、影響と対応を切り分けるフロー図（自作）
PHP公式・GHSA・IPA・NCSC-NLの記載をもとに当サイトで作成

自社サーバーでApacheとPHP-FPMを組み合わせて監視ツールなどを動かしている場合も、Webで使うPHPなら対象です（構成の例：Zabbix Server 6.0 のインストール手順（AWS/Red Hat/MySQL/Apache））。

Zabbix を使っている場合（php2shell と Zabbix の関係）

監視ツールの Zabbix は2026年10月22日、「Zabbix Statement on Recently Reported PHP Security Vulnerabilities」を公表しました。認証なしのリモートコード実行につながりうる重大なPHPの脆弱性を把握しているとしたうえで、PHPは Zabbix のフロントエンド（Web画面）で使われるものの、Zabbix のパッケージには含まれない別のソフトウェアだと説明しています。そのため、PHPの安全性は導入しているバージョンと、PHPやOSの提供元の更新しだいだとし、PHPの公式アドバイザリとOSの提供元の案内に沿って更新を適用するよう求めています。インターネットに公開しているPHPを優先するよう書いています。

この声明には、CVE番号や「php2shell」という呼び名は書かれていません。Zabbix の課題管理システムでは、CVE-2026-109618・CVE-2026-109619 を理由に、サポート中の各バージョンのPHPの要件を 8.3 以上に上げる課題（ZBX-28251）が2026年10月22日に作られ、11月9日時点で未解決（Unresolved）です。Zabbix のサーバーでは、フロントエンドを動かしているPHPのバージョンを下の「確認方法」で調べ、修正版かOSの修正済みパッケージに更新します。

PHP脆弱性の確認方法とアップデート方法（今すぐやること）

手順は2つです。①使っているPHPのバージョンを確認し、②修正版より前ならアップデートしてワーカーを再起動します。

確認方法：使っているPHPのバージョンを調べる

  • コマンドで確認：サーバーに入れる場合は php -v でPHPのバージョンとSAPI名（SAPIはPHPとWebサーバーをつなぐ方式。cli・fpm-fcgi・apache2handler・litespeed など）が表示されます（PHPマニュアルのコマンドラインオプション）。これはコマンドライン版の情報で、Webサーバーが使うPHPとは別のこともあるため、Web側の確認も合わせて行います。
  • Web側で確認：phpinfo() は、PHPのバージョンやサーバー情報、設定値などを出力する関数です（PHPマニュアル）。出力には環境変数やサーバー変数なども含まれるため、確認用に置いたファイルは確認後すぐに削除します。
  • WordPressで確認：管理画面の「ツール」→「サイトヘルス」→「情報」タブの「サーバー」セクションに、ウェブサーバーやPHPに関する情報が表示されます（WordPress.org のサイトヘルス画面の解説）。

表示されたバージョンが 8.5.12・8.4.27・8.3.36・8.2.35 より前なら更新が必要です。ただし、ディストリビューションやLTSベンダーが修正をバックポートしたパッケージを配布する場合もあるため（PHP公式・NCSC-NL）、番号だけで判断せず、ベンダー側の告知で修正済みかどうかを確認します。

アップデート方法：修正版に更新し、ワーカーを再起動する

  • OSのパッケージの場合：LinuxディストリビューションとLTSベンダーには事前にパッチが渡されています（PHP公式）。ベンダーの更新パッケージを確認します。
  • ソースから入れている・Windowsの場合：修正版のソースとWindows版のバイナリは php.net のダウンロードページにあります。Windows版は2026年10月26日に 8.5.12-1 などへ作り直されています（PHP本体のバージョンは同じ。上の「最新情報」）。
  • remirepo を使っている場合：CERT-EU（EUの機関向けのCSIRT）は、有志が運営する rpms.remirepo.net はリリース当日には更新が出ないとし、PHPチームがディストリビューションのパッケージかソースからのビルドへの切り替えを求めていると伝えています。
  • 更新後：PHP-FPM・Apacheなど、PHPを動かしているプロセスを再起動し、もう一度バージョンを確認します。

すぐに更新できない場合の緩和策（完全ではない）

PHP公式は、以下の対策は特定の攻撃経路を減らすだけで、安全にするものではないと明記しています。更新までのつなぎです。

対象公式の緩和策注意点（公式の記載）
CVE-2026-109618memory_limit=-1 を、できればアプリから上書きできない方法（FPMプールやApache設定の php_admin_value など）で設定プール・ディレクトリ・アプリの設定で有限の値に戻っていないか確認する。より下のレベルのメモリ確保の失敗は、引き続き脆弱な処理に到達しうる
post_max_size を小さくする（ファイルのアップロードが不要なら 8M、必要なら 32M）upload_max_filesize は post_max_size より小さく保つ
Webサーバーやプロキシで、デコード後のリクエストサイズ・入力フィールド数・multipartのパート数・ヘッダー数・ネストの深さを制限する使える Content-Length がないリクエストにも制限が効くようにする
コンテナや cgroup のメモリ上限を可用性の境界として使う（影響を受けたワーカーだけを終了させる方式が望ましい）RLIMIT_AS・RLIMIT_DATA で代用しない（脆弱なメモリ確保の失敗を引き起こしうる）
CVE-2026-109619session.upload_progress.enabled=0 にして、すべてのワーカーを再起動php.ini・FPMプール・リクエスト解析の前に効くサーバー設定で行う。ini_set() やFPMの .user.ini には頼らない。確認済みのセッションの経路は防げるが、別の変種は防げない
PHP 8.5 では fatal_error_backtraces=0 にして、すべてのワーカーを再起動確認済みの「致命的エラーのバックトレース」の経路だけを防ぐ
リクエストごとに適用される、無効・非推奨の設定（初期化の前に診断メッセージを出すもの）を取り除くerror_reporting・display_errors・@ で表示を隠しても効果はない
攻撃者が到達できる致命的エラーと実行タイムアウトを解消するコールバック・アップロードやインポートの処理・後片付けでの失敗も含む

3件目のCVE-2026-115560：次の定例リリースまで session.upload_progress.enabled=0 にする

PHP公式は2026年10月23日（日本時間19:12）、「Informational advisory: Session upload progress」で3件目の脆弱性CVE-2026-115560を告知しました（2026年10月25日追記）。起きるのは、アプリが設定で session.serialize_handler を php_binary か php_serialize にしたうえで、実行中に ini_set() で php に切り替えてから session_start() を呼び、しかもセッションのアップロード進捗機能が有効なときだけ、としています。PHP公式はこの組み合わせを「unlikely in practice」（実際には起きにくい）として臨時のリリースは出さず、次の定例のリリースで修正し、詳しいアドバイザリもそのときに公開するとしています。

それまでの対策として、PHP公式は session.upload_progress.enabled=0 にするよう勧めています。これはCVE-2026-109619の緩和策（上の表）と同じ設定で、10月21日の時点で設定していれば「keep it in place and no further action is needed」（そのまま続ければ追加の作業は不要）としています。GHSAはこの設定を php.ini・FPMプール・リクエスト解析の前に効くサーバー設定で行い、ini_set() やFPMの .user.ini に頼らないよう求めており、CERT-EU（v1.2）は設定後にすべてのワーカーを再起動するよう書いています。実行中にシリアライズの方式を切り替えないアプリは、この機能を有効のままでよいとしています。JPCERT/CCも2026年10月26日に注意喚起（JPCERT-AT-2026-0033）を更新し、CVE-2026-115560の緩和策として session.upload_progress.enabled=0 に設定し、すべてのワーカーを再起動するよう加えています（2026年10月27日追記）。

2つの脆弱性のしくみ（公式の説明の範囲で）

CVE-2026-109618：メモリ不足のときに処理を途中で打ち切るしくみ

PHPは、メモリ不足（OOM）のエラーが起きると処理を途中で打ち切ります。PHP公式によると、リクエストの内部データが一部しか初期化されていないタイミングで打ち切られると、後片付けの処理がその不完全なデータを正しいものとして扱ってしまうことがあります。GHSAでは、multipart形式（ファイルのアップロードなどで使う形式）の解析で、PHPの制限内のままメモリ不足に至る方法が複数あるとしています。

mod_php では、開始処理が失敗しても後片付けの処理が常に実行されるため、アプリのコードが動く前に問題が起きます。WordPressのセキュリティプラグインのような、アプリ側の対策より前の段階です。FPMについては、ソースの分析上は影響を受けるとされています（完全な攻撃の実証はない、とも明記）。

CVE-2026-109619：前のリクエストの「古い状態」が残るしくみ

PHPのワーカーは複数のリクエストを順番に処理します。PHP公式によると、あるリクエストの内部の状態がメモリの解放後も残り、同じワーカーが処理する次のリクエストが、初期化の前にその古い状態を使ってしまうことがあります。GHSAは、致命的なエラー（メモリ不足を含む）で本来のリセットが行われないことを原因の一つに挙げ、PHP 8.5 の致命的エラーのバックトレース機能と、セッションのアップロード進捗機能（初期設定で有効）を使う経路を「確認済み」としています。緩和策の表に fatal_error_backtraces と session.upload_progress.enabled が出てくるのはこのためです。なお、セッションの経路によるリモートコード実行は、mod_php だけでなく PHP-FPM でも検証済みとされています（GHSA）。

攻撃の具体的な手順は、この記事では扱いません。

公式に書かれていないこと・現時点でわからないこと

  • 実際の悪用：PHP公式の告知とGHSAには、攻撃に悪用されたことを確認したという記載はありません。IPAは2026年10月21日の事前告知の時点で「悪用した攻撃を確認しているわけではありません」としています。一方でCERT-EUは、技術的な詳細が公開の場で議論され、初期の概念実証コード（PoC）が出回り始めたことから、すでに悪用されている可能性が高まっていると評価しています。米国CISAは2026年10月26日（米国時間）、CVE-2026-109618・CVE-2026-109619を「悪用が確認された脆弱性」のカタログ（KEV）に追加し、対応期限を2026年10月29日としました（CISAの発表）。CISAは同じ日に、2026年10月21日に出したPHPの注意喚起（Critical Vulnerabilities in PHP Require Immediate Patching）も、KEVへの追加を反映して更新しています。JPCERT/CCも2026年10月26日に注意喚起（JPCERT-AT-2026-0033）を更新し、「本脆弱性を悪用できると主張する実証コードが多数公開されているほか、本脆弱性の悪用を試みる通信を観測したとの報告も相次いでいます」と追記しました。一方で、実証コードで実際に任意のコードを実行できるかは、PHPのバージョンや実行環境、メモリ配置などの条件に依存し、環境に応じた調整が必要になるともしています。自社製品への影響を公表しているCisco（v1.7）は「The Cisco PSIRT is not aware of any malicious use of the vulnerabilities」（悪用は把握していない）、Palo Alto Networksも自社製品への悪用は把握していないとしています。Palo Alto Networksは同社のファイアウォールのOS（PAN-OS）が影響を受けるとし、修正版（hotfix）は一部の版で公開済み、ほかの版は10月27日〜30日に公開する予定としています。2026年10月27日訂正：この項目の以前の版では「2026年10月25日時点で、KEV（2026年10月23日版）にCVE-2026-109618・CVE-2026-109619は載っていません」と書いていましたが、CISAは2026年10月26日（米国時間）にこの2件をKEVに追加しました。
  • 国内の被害：2026年10月27日時点で、IPAは「IPAでは国内での攻撃被害の事例については把握しておりません」としています（2026年10月27日に更新されたPHPの脆弱性対策について）。JPCERT/CC・JVNの公表にも、国内の被害の記載はありません。
  • 公的機関の注意喚起：IPAは2026年10月21日に「【事前準備のお願い】PHPのセキュリティリリース公開予定について」を公開し、PHPを使うプログラムの棚卸しと速やかな適用の準備を求めています。サポート終了の古いPHPを使い続けるサイトも見受けられ、攻撃者が極めて短時間で攻撃を実行する可能性があるとしています。IPAは続けて2026年10月22日に「PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619：PHP2shell)」を公開し、影響を受けるのは 8.2.35／8.3.36／8.4.27／8.5.12 より前の各系列として修正版への更新を求め、更新が難しい場合の暫定対策や、サポート終了版からの移行・公開終了の検討まで段階的に示しています（2026年10月23日追記）。JPCERT/CCは2026年10月22日に「PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起」（JPCERT-AT-2026-0033）を公開し、PHPが国内で広く利用されていることを確認しているとして、速やかな対策の適用と侵害の有無の調査を求めています。JVNも同じ10月22日に「JVNVU#99905564」を掲載しました（10月23日更新）。その後、JPCERT/CCは2026年10月26日に注意喚起の「I. 概要」「IV. 緩和策」に情報を追記し、IPAは2026年10月27日に、2件がCISAのKEVカタログに悪用された脆弱性として掲載されたことを追記しています（2026年10月27日追記）。2026年10月25日訂正：この項目の以前の版では「JPCERT/CCの注意喚起とJVNの掲載は、2026年10月23日時点で確認できませんでした」と書いていましたが、JPCERT/CCの注意喚起は2026年10月22日13:11に、JVNの掲載は同じ10月22日に公開されていました。
  • 古いバージョンの範囲：GHSAの影響バージョンはサポート中の 8.2〜8.5 で示されています。IPAの事前告知は、CERT-EUが「PHP 5以降が影響を受ける」と記載していたことに触れています。公開後のCERT-EU（v1.1、10月23日のv1.2も同じ）は8.1以前のサポート終了系列を影響製品に含めています。PHP公式は8.1以前には更新を出さないとし、7.4〜8.1向けの最小限のバックポートを公開しました。7.4より古い系列（PHP 5 など）が影響を受けるかは、PHP公式の告知・GHSAに書かれていません。
  • 各レンタルサーバー・クラウド・ディストリビューションの対応状況：公式発表だけを集めた一覧をPHP脆弱性php2shell、各社の対応状況まとめ【毎日更新】に分けました。バージョン番号を変えずに修正を適用する会社（mixhost など）もあるため、表示だけでは判断せず各社の告知で確認してください。

国内で公表されたサイバー攻撃・情報漏えいの事例は、2026年 国内の情報漏えい・サイバー攻撃一覧にまとめています。また、AIが実在の脆弱性を自力で突く研究が進んでいる点は、AWS Security AgentがCVE 37件中33件を突破した発表の解説で取り上げています。

よくある質問

PHPの脆弱性の確認方法とアップデート方法は？

確認は、サーバーで php -v を実行するか、phpinfo の出力やWordPressの「ツール」→「サイトヘルス」→「情報」でPHPのバージョンを見ます。8.5.12・8.4.27・8.3.36・8.2.35 より前なら、OSやベンダーの修正済みパッケージか php.net の修正版に更新し、PHP-FPMやApacheなどPHPを動かしているプロセスを再起動します。レンタルサーバーは契約先の公式のお知らせで対応状況を確認します。

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

いいえ。今回の脆弱性はPHP本体にあり、修正はPHP 8.5.12・8.4.27・8.3.36・8.2.35に入っています。WordPressを動かしているPHPを修正版に更新する必要があります。

レンタルサーバーを使っている場合は何をすればいいですか？

契約しているサーバー会社の公式のお知らせで、PHPの更新状況を確認してください。WordPressなら「ツール」→「サイトヘルス」→「情報」タブの「サーバー」でPHPに関する情報を確認できます。

PHP 8.1以前を使っている場合はどうなりますか？

PHPプロジェクトからの更新はありません。ディストリビューションやLTSベンダーのバックポートを確認するか、サポート中のバージョンへ移行してください。

設定変更（緩和策）だけで安全になりますか？

なりません。PHP公式は「完全な緩和策はなく、更新が唯一の安全な選択」としています。memory_limit や session.upload_progress.enabled などの設定変更は、特定の攻撃経路を減らすだけです。

すでに攻撃に悪用されていますか？

米国CISAは2026年10月26日（米国時間）、この2件を悪用が確認された脆弱性のカタログ（KEV）に追加しました。JPCERT/CCも同じ日に、悪用を試みる通信を観測したとの報告が相次いでいると注意喚起に追記しています。一方、PHP公式の告知には悪用を確認したという記載はなく、IPAは2026年10月27日時点で国内での攻撃被害の事例は把握していないとしています。CiscoとPalo Alto Networksも、それぞれの製品についての告知で悪用は把握していないとしています。

あわせて読みたい：お名前.com レンタルサーバーでPHPを8.4に変更した手順（当サイトの記録）

あわせて読みたい：なぜ修正の前日に予告が出たのか（事前告知のしくみと前例）

あわせて読みたい：レンタルサーバー・クラウド各社の対応状況（毎日更新）

あわせて読みたい：Node.jsの脆弱性10件（2026年10月）は自分の環境も対象？修正版と今やること

あわせて読みたい：FortiGate の認証情報の漏えい（FortiBleed）は新しい脆弱性？

あわせて読みたい：eMudhra の中間 CA 侵害、ブログ運営者がすること

あわせて読みたい：PHP2Shell はどう見つかったか（AI と脆弱性の増加）

あわせて読みたい：同じ週に公表されたお名前.com デスクトップクラウドの不正アクセス

あわせて読みたい：名前の似た HTTP2Shell（Brotli）は別の脆弱性

あわせて読みたい：PHP2Shellの影響を受ける製品の一覧（NAS・ルーター・管理パネルほか）

まとめ

  • CVE-2026-109618・CVE-2026-109619は、Webリクエストを処理するPHPを対象とした、認証なしのリモートコード実行につながる2件の脆弱性です（CVSS v4.0 9.2・Critical）。
  • 修正版は PHP 8.5.12・8.4.27・8.3.36・8.2.35。OS・ベンダーの修正済みパッケージやイメージに更新し、ワーカーを再起動します。
  • WordPress本体の更新では直りません。レンタルサーバーは契約先の公式のお知らせを確認します。
  • 設定による緩和策は「完全ではない」と公式が明記しています。PHP 8.1以前は、ベンダーのバックポートかサポート中のバージョンへの移行が必要です。

参考（確認日：2026年10月22日・25日・27日・11月9日）

脆弱性・アップデート
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

関連記事

コメント

コメントする

CAPTCHA


目次