コンテンツへスキップ
一覧に戻る
2026/10/29

PHP の重大脆弱性「PHP2shell」公開から1週間:悪用状況・各国の対応・残る課題(2026年10月続報)

PHP の重大脆弱性「PHP2shell」公開から1週間:悪用状況・各国の対応・残る課題(2026年10月続報)

PHP の CVE-2026-109618/109619(通称「PHP2shell」)の公開から1週間。米国 CISA による「悪用が確認された脆弱性」への追加、3件目の脆弱性 CVE-2026-115560(未修正)、修正版で見つかった不具合、日本と各国の公的機関・事業者の対応をまとめ、いま確認すべきことと侵入の痕跡の調べ方を解説します。

シェア

要点

  • 米国 CISA が10月26日(米国時間)、両 CVE を KEV(悪用が確認された脆弱性)に追加。一部製品の管理画面への悪用も観測されていますが、侵入された組織名は10月29日時点で未公表です
  • 3件目の CVE-2026-115560 は最新版でも未修正です。次の定期リリースまで session.upload_progress.enabled=0 を設定(設定済みなら維持)してください
  • 修正版の 8.4.27 / 8.5.12 には SimpleXML のクラッシュなどの不具合があります。SimpleXML の修正は次の版(公開日未定)に入る予定です。版を戻すのは避けてください
  • 多くの機関が「更新できなければ停止・隔離」を勧告。国内でも自治体や企業がサイトを一時停止し、主なレンタルサーバーの多くは旧版も含めて修正を終えました
  • 攻撃の試みは公開前の10月17日から観測されています。更新済みでも、10月17日以降のログ・ファイル・プロセスを確認してください

この記事について

本記事は、10月22日に公開した「PHP・Node.js・Go の2026年10月セキュリティ修正まとめ」の続報です。脆弱性の仕組み、修正版、OS・環境別の更新手順はそちらをご覧ください。

本記事では、2026年10月21日の公開から10月29日(日本時間)までに、PHP プロジェクト、各国の公的機関、OS ベンダー、セキュリティ企業、研究者・大学、ホスティング事業者、製品メーカーが自ら公開した情報を確認し、この1週間で何が分かり、何が変わったかをまとめました。報道だけで確認できなかった情報は載せていません。

状況はまだ動いています。「〜時点」と書いた項目は、作業前に末尾の公式リンクで最新の状況をご確認ください。

この1週間の経緯

日付は、日本の機関は日本時間、海外の機関は発表元の表記(米国時間や UTC)に従っています。

  • 10月17日:Amazon のおとり環境(ハニーポット)で、公開前にもかかわらずこの脆弱性を狙ったとみられる通信を観測(Amazon が10月21日に公表)
  • 10月20日(UTC):CVE 番号が誤った評価(CVSS 10.0)とともに出回り、PHP は予告を前倒しして公開日時を22日から21日に変更。EU の CERT-EU は修正の公開前に注意喚起を出しました
  • 10月21日(日本時間の夜):PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 を公開。Cloudflare などの WAF 事業者は、公開の7〜9時間ほど前から防御ルールを有効にしていました
  • 10月22日:JPCERT/CC、IPA、JVN が注意喚起。中国の CNCERT も注意喚起を出し、韓国は民間のサイバー危機警報を引き上げました。国内のレンタルサーバー各社が緊急メンテナンスを実施
  • 10月23日:PHP が3件目の脆弱性 CVE-2026-115560 を告知(修正版はまだなし)。米国 FBI も注意喚起を公開
  • 10月24日(UTC):研究者が公開したおとり環境のデータで、この脆弱性によるとみられるコード実行が確認されました
  • 10月26日(米国時間):米国 CISA が両 CVE を KEV(悪用が確認された脆弱性のカタログ)に追加。JPCERT/CC が注意喚起を更新
  • 10月28〜29日:GreyNoise のおとり環境でもコード実行を確認。製品メーカー各社の修正版の公開が続いています

悪用の状況:どこまで確認されたか

米国 CISA が「悪用が確認された脆弱性」に追加

  • 米国の CISA は10月26日(米国時間)、CVE-2026-109618 と CVE-2026-109619 を KEV カタログに追加しました。KEV は、実際に悪用された証拠がある脆弱性だけを載せる一覧です。米国の連邦政府機関には10月29日までの対応と、侵入の有無の確認(フォレンジック調査)を求めています。ランサムウェアでの利用は「不明」とされています
  • CISA の注意喚起は「すぐに更新できない場合や PHP 8.1 以前を使っている場合は、修正するまで PHP を使うシステムをオフラインにする」よう求めています。WAF は一時的な防御にすぎないとしています。CISA は検知用のルール(SIGMA)も公開しました
  • 米国 NVD は10月22日(UTC)、CVE-2026-109619 の評価を CVSS v3.1 で 9.8 から 8.1 に下げました。CVE-2026-109618 は 9.8 のままです。PHP 自身の評価(CVSS v4.0 で 9.2)は変わっていません

おとり環境での実行確認と、出回る攻撃ツール

  • 研究者が公開したおとり環境のデータでは、10月24日(UTC。日本時間では25日未明)に3台のおとりサーバーで、Apache のプロセスから直接シェルが35回起動されました。PHP 8.4.26、Apache + mod_php の構成です。報告者自身、攻撃が成功しやすいよう意図的に設定した環境だとしています
  • GreyNoise は、10月28日から29日にかけて、ドイツの1つの IP アドレスからの攻撃で、おとりサーバーが OS コマンドを実行した例を5件確認したとしています(日本時間10月29日 13:44 時点)
  • オランダのデルフト工科大学の観測では、攻撃に使われたプログラムとして、Mirai 系の DDoS ボットと Nim 言語で書かれたバックドアが見つかっています
  • 動作を確認していない攻撃コード(PoC)が GitHub などに大量に公開されました。VulnCheck は、本物はごく一部だとしています。韓国の KISA は、出回っている「攻撃テスト用コード」にマルウェアが仕込まれている例が多いとして、検証されていないコードを実行しないよう呼びかけています
  • 一方、Sansec は「公開されている PoC の多くは、標準構成の PHP には通用しない」という研究者の分析を紹介し、大規模な悪用の可能性は当初の予想より低いとしています。VulnCheck は、標準設定の mod_php で多くの版に通用する攻撃コードを自社で作成したとしています。攻撃の成否は版、構成、メモリ配置によって大きく変わります

取り下げられた報告と、まだ確認されていないこと

  • Sophos は10月22日(UTC)に「攻撃の成功を1件確認した」と発表しましたが、同日中に「スキャンであり、侵入の証拠はない」と訂正しました。Palo Alto Networks の Unit 42 も、欧州の政府機関1か所への攻撃を PHP2shell と関連づけた10月23日(米国時間)の追記を、25日(同)に「この CVE との関連は確認できない」として撤回しました
  • 10月29日時点で、PHP2shell によって実際に侵入された組織の名前は、一次情報では確認できませんでした。CrowdSec も、10月25日までに公に確認された侵入は「0件」としています
  • ただし、Palo Alto Networks は自社製品(PAN-OS)の、インターネットに公開された管理画面への悪用を観測したとしています(後述)

観測された攻撃通信の規模

  • GreyNoise:10月21日から29日までに、417 の IP アドレスから約24万回のアクセス(うち攻撃の試みが約21万回)
  • デルフト工科大学:73 か国の 664 の IP アドレスから約7.3万回の攻撃リクエスト。ピークは10月26日 23:00(日本時間)の1時間で、8,179回
  • Fastly:公開前の10月21日 12:59(日本時間)から22日の夜(日本時間。UTC では22日の昼)までの間に、「PHP2shell」の名前を持つツールから約25万回のリクエスト。約3分の1は防御側の確認を名乗るものです
  • WP Engine は24時間で100万件以上の関連リクエストを WAF で遮断し、攻撃の成功は確認していないとしています
  • Censys によると、PHP が動いているインターネット上のホストは約418万台です(10月23日時点。修正済みかどうかは含みません)

各国・地域の公的機関の対応

日本

  • JPCERT/CC(JPCERT-AT-2026-0033、10月22日公開・26日更新):攻撃を試みる通信の報告が複数あるとしつつ、コード実行の成否は版・環境・メモリ配置に左右されるとしています。26日の更新で CVE-2026-115560 と緩和策を追加しました。痕跡の手がかりとして、異常な PHPSESSID、不審な multipart/form-data リクエストの後のメモリ上限エラーや HTTP 500、PHP ワーカーの予期しない異常終了や再起動を挙げ、痕跡が確認されない場合でも「攻撃を受けていないと断定することはできません」としています
  • IPA(10月22日公開・27日更新):CISA の KEV 追加を追記しました。国内での攻撃被害の事例は把握していないとしています。更新できない場合は暫定策かアクセス制限、それも難しければ外部からの接続の遮断やサービスの停止を検討するよう求めています
  • JVN(JVNVU#99905564、10月28日更新):国内メーカーの状況を掲載。ソリトンシステムズと FFRI セキュリティは「該当製品あり」としています
  • 自治体:滋賀県は154のシステムのうち13(うち県立学校が6)が10月26日正午の時点でも停止中、東京都港区はホームページの一部機能を10月21日深夜から停止し、28日時点で一部を再開しています。大阪市も一部サービスを停止し、福岡県は23日に県ホームページの停止機能をすべて再開しました(各所属が管理する一部のサイトは対応中)。港区、大阪市、福岡県は、不正アクセスや情報漏えいなどの被害は確認されていないとしています
  • 企業:ソフトバンクは法人向けの一部の Web サイトとサービスを緊急メンテナンスのため一時停止しました。LINE WORKS は、PHP を使っていたのは自社の Web サイトだけで、22日に対応を終えたとしています

米国

  • CISA:上記の KEV 追加と注意喚起のほか、組み込み製品を含めて PHP の利用箇所を洗い出し、インターネットに公開されたものから優先して対応するよう求めています
  • FBI(PSA I-102326-PSA、10月23日):すぐに更新できなければ、対策が済むまでシステムをオフラインにすること、侵入された場合は隔離して Web と PHP のログを保全し、FBI に報告することを求めています

欧州

  • EU:欧州委員会、ENISA、CERT-EU、Europol などが10月21日に共同声明を出し、ホスティング事業者と連携した特定・更新と、更新できないアプリの隔離を呼びかけました。CERT-EU(Security Advisory 2026-018)は修正の公開前の10月20日に第1版を出しています
  • フランス(CERT-FR):10月26日の更新で、特定の PHP 環境に対する攻撃の試みを観測したとしています
  • ドイツ(BSI):警戒レベル「3/オレンジ」。一部の事業者が予防的にシステムを切り離し、ドイツ国内の複数のサイトがつながりにくくなったとしています。規制対象の業界や連邦行政で侵入が確認された報告はないものの、自動化された攻撃の試みは起きているとしています(10月22日の第1.2版)
  • 英国(NCSC):PHP の特定、更新、暫定策の適用、すぐに対策できなければオフライン化の検討、侵入とバックドアの確認を求めています
  • オランダ:政府ポータルの Overheid.nl、MijnOverheid.nl、公的認証 DigiD のサイトなどを10月21日に予防的に停止しました。NCSC-NL は、PHP を組み込んだ製品の対応状況を GitHub で一覧にしています(10月28日時点で757製品、うち「脆弱」218、「修正済み」144、「調査中」354)

アジア・太平洋ほか

  • 韓国:科学技術情報通信部と KISA は10月22日正午、民間のサイバー危機警報を「関心」から「注意」に引き上げました。KISA は、委託先や放置されたサーバー、テスト環境も含めた洗い出し、修正前に公開していたサーバーの DB・API・管理者の認証情報の変更、検証されていない PoC を実行しないことなど、8項目の対応手順を示しています
  • 中国:CNCERT は10月22日に注意喚起(CNTA-2026-0006)を出し、CNVD-2026-41674 / CNVD-2026-41675 として「高危」に分類しました。技術情報と PoC が広く出回っているとして、PHP の利用状況の確認と公式手段での更新を求めています
  • 香港(HKCERT):リスクを「極めて高い」とし、悪用されていると記載。10月27日の更新で F5、Citrix、Palo Alto Networks、QNAP、Cisco などの製品情報を追加しました
  • シンガポール(CSA)、インド(CERT-In)、カナダ(CCCS)、ニュージーランド(NCSC)なども注意喚起を出しています。悪用についての表現は機関によって異なり、カナダは公開情報に基づき「悪用されている」、インドは「大規模な悪用」としています

サービス事業者・製品メーカーの対応

国内のレンタルサーバー

主な共有レンタルサーバーの多くは、10月22日から28日にかけて修正を終えています(一部の旧プランの古い版は対象外です)。多くの事業者は、サポートが終わった古い版(5.x〜8.1)にも独自に修正を当てていますが、表示される版番号は変わりません(例:ConoHa WING は 8.5.11 のまま)。WordPress の「サイトヘルス」などで古い版が表示されても、事業者のお知らせで修正済みかどうかを確認してください。

  • エックスサーバー:10月26日 6:20 までに全対象サーバーの対応を完了。8.2〜8.5 は修正版に更新し、5.1〜8.1 は版を変えずに修正しました。予防措置として、21日16時からサービスサイトと管理パネルを停止し、22日から順次再開しました(利用者のサイトとメールは稼働を継続)
  • ロリポップ:8.2 以降は修正版、7.4〜8.1 は PHP 開発者が用意した修正、5.3〜7.3 は独自の修正を適用し、全版で session.upload_progress を無効にしました。一部のサーバーでは22日の未明から昼過ぎまで、全サイトの表示を停止しました。攻撃とみられる通信は観測したものの、不正アクセスは確認していないとしています
  • ConoHa WING・お名前.com レンタルサーバー:10月22日に全版(5.6.40〜8.5.11)へ修正を適用。利用者の作業は不要としています
  • さくらのレンタルサーバ:コントロールパネルで選べる全版の修正を完了。利用者が自分でインストールした PHP は、利用者自身での対応が必要としています
  • KAGOYA:10月28日時点でレンタルサーバーの更新を完了。修正前の PHP でサイトを公開し続けることは推奨しないとしています
  • CPI:古い共有・マネージドプランの多くで、修正前の版は「対象外」で、php.ini での暫定策か版の切り替えを案内しています。不明な .php ファイルや、身に覚えのない CMS の管理者アカウントがないかの確認も呼びかけています
  • mixhost:10月22日に全版(5.2〜8.5)の修正を完了しています
  • VPS やクラウドサーバーなど、利用者が自分で OS を管理するサーバーは、利用者自身の更新が必要です(エックスサーバー、さくらの VPS、KAGOYA CLOUD VPS なども同様に案内しています)

海外のホスティング・クラウド

  • WordPress 向けなどのホスティング:WP Engine、Kinsta、GoDaddy、Hostinger、SiteGround、Automattic(WordPress.com など)は、いずれも修正や防御を終えたとしています。WP Engine と Kinsta は、攻撃の成功は確認していないとしています。WordPress.org は、WordPress 本体の更新は不要(PHP 側の問題)としています
  • AWS:Elastic Beanstalk の PHP 8.2〜8.5 プラットフォームは修正済みです。Lightsail は新しいイメージ(ブループリント)を公開しましたが、動いているインスタンスは新しいインスタンスへの移行が必要と案内しています。Lambda には AWS が管理する PHP ランタイムがないため、独自ランタイムやコンテナは利用者が更新して再デプロイします。AWS WAF の PHP 向けルールグループ(AWSManagedRulesPHPRuleSet)は 2.4 版が既定になりましたが、AWS 自身が「更新の代わりにはならない」としています
  • Microsoft Azure:App Service for Linux の組み込み PHP は、サポート中の版(8.2〜8.5)が修正版に更新されました(Extended チャネルへの適用は最後。サポート終了版は修正なし)。App Service for Windows の組み込み PHP はサポート終了済みで、修正の予定はありません。Marketplace の WordPress のうち古い Alpine ベースのイメージも修正されないため、Debian ベースへの移行が案内されています
  • Google Cloud:App Engine スタンダードと、自動更新を有効にした Cloud Run(Cloud Run functions を含む)は自動で修正される場合があります(GCP-2026-070)。Apigee は、利用者が運用する Drupal ベースの開発者ポータルだけが影響を受けるとしています(GCP-2026-072)
  • OVHcloud:共有ホスティングは自動で更新。ベアメタルと VPS は利用者が更新します

中国のクラウド・サーバー管理パネル

  • 宝塔面板(BT Panel):Linux 版・Windows 版で 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 を提供し、Linux 版ではサポート終了版にも独自の修正版(8.1.35、8.0.31、7.4.34、7.3.34、7.2.35、7.1.34、7.0.34)を公開しました。5.4〜5.6 はまだテスト段階です。Windows 版の 8.1 以前には修正がなく、設定による緩和策だけです。ソフトウェア一覧を更新し、PHP を更新した後に PHP を再起動します
  • Alibaba Cloud Linux:Alibaba Cloud Linux 2 は php-5.4.16-48.2.al7、3 は php-7.4.33-8.0.1.al8、4 は php-8.3.36-1.alnx4 以降が修正版です。Alibaba Cloud は、php -v の結果と PHP-FPM・mod_php・コンテナで実際に動く PHP が違う場合があると注意しています
  • Tencent Cloud・Huawei Cloud:それぞれ注意喚起を出し、Tencent Cloud は WAF・クラウドファイアウォール・ホストセキュリティ製品、Huawei Cloud は WAF とクラウドファイアウォールでの防御を案内しています。Huawei Cloud は「実際の攻撃を確認した」としていますが、詳細は示していません

PHP を内蔵する機器・製品

ファイアウォール、VPN 装置、NAS などの管理画面には PHP が組み込まれていることがあり、サーバーの OS や PHP を更新しても直らず、メーカーの修正版(ファームウェアなど)が必要です。各メーカーの情報を確認してください。

  • Palo Alto Networks(PAN-OS):管理画面(Web UI と XML API。管理プロファイルを設定したデータプレーンのインターフェースを含む)だけが影響を受け、インターネットに公開された管理画面への悪用を観測したとしています。修正版(hotfix)は10月25日から順次公開されており、一部は10月29〜30日に予定されています。GlobalProtect と Prisma Access は影響を受けません
  • Citrix NetScaler ADC / Gateway:CTX697263 で修正版(14.1-73.49 以降、13.1-64.32 以降など)を公開しています
  • Cisco:Expressway は 15.5.21、Duo Access Gateway は 3.2.0 で修正。Cisco 製品への悪用は把握していないとしています
  • QNAP:QSA-26-18 で QTS 6.1.0.3656 / 5.2.11.3661 などを公開。NAS をインターネットに直接公開しないよう呼びかけています
  • Synology:Synology-SA-26:14 で各 PHP パッケージの修正版を公開(例:PHP 8.2 は 8.2.35-0171)。PHP 7.3 はサポート終了のため修正されません
  • Sophos:自社製品は影響を受けないとしています。一方で、影響を受ける PHP を使っていた旧ライセンスポータル(MyUTM)を予防的に停止しました
  • Docker:公式イメージと Docker Hardened Images は修正版に更新済みです。FROM php:... で作った自前のイメージは、作り直さない限り古いままです

10月22日の記事からの更新(修正版の提供状況)

前回の記事で「未提供」とした項目の多くに修正版が出ました。10月29日時点の状況です。

  • packages.sury.org(arm64):8.2〜8.5 の arm64 向け修正版(版に 20261021 を含むもの)が10月26日(日本時間)までに公開されました
  • Oracle Linux:OL9 の php:8.2(ELSA-2026-87072)と php:8.3(ELSA-2026-87079)、OL8 の php:8.2(ELSA-2026-87073)と php:7.4(ELSA-2026-87080)が公開されています。OL9 の php:8.4 はまだありません
  • RHEL 9 の php:8.4 モジュール:10月29日時点でも修正版はありません。修正済みの php:8.3 か php:8.2 へストリームを切り替えるか(PHP の版が変わるため事前に検証を)、Red Hat の RHSB-2026-013 の暫定策を適用してください
  • Red Hat の追加の修正:10月23日以降、EUS・AUS など長期サポート版向けの修正が出ています。RHEL 7(ELS)は CVE-2026-109619 だけが影響し、php-5.4.16-48.el7_9.1 で修正されました
  • winget:PHP.PHP.8.4 と NTS 版のパッケージも 8.4.27 などの修正版に更新されました
  • AWS Elastic Beanstalk:PHP 8.3 / 8.2 も10月22日に AL2023 v4.13.13 で修正されました
  • SUSE / openSUSE:10月22日に SLES 15 SP5 / SP6(LTSS)、SLES 16.0、Leap 16.0 などにも修正が出ました(例:SLES 16.0 と Leap 16.0 は php8 8.4.27-160000.1.1)
  • Fedora:F43(php 8.4.27-2.fc43)と F45(php 8.5.12-1.fc45)も安定版になりました
  • Alpine Linux:前回の記事で「v3.23 以前は修正されない」と書きましたが、その後 v3.21〜v3.23 にも修正版が入りました(例:v3.23 の php84 8.4.27-r0)。サポートが終わった v3.20 以前は修正されません
  • Debian(有償の ELTS):Debian 10 の php7.3(ELA-1854-1)と Debian 9 の php7.0(ELA-1855-1)にも修正が出ています
  • 変わらず修正されないもの:Amazon Linux 2 の標準 php と Amazon Linux 2023 の php8.1 は「修正予定なし」のままです。php8.2 以降への移行が必要です

新たに分かった問題

3件目の脆弱性 CVE-2026-115560(修正版はまだない)

  • PHP は10月23日、セッションのアップロード進捗機能に、リモートコード実行につながる可能性がある別の問題(CVE-2026-115560)があると告知しました。10月21日の修正版(8.5.12 などの最新版)でも直っていません
  • 条件は限られます。設定ファイルで session.serialize_handler を php_binary か php_serialize にし、アプリが session_start() の前に ini_set() で php に切り替えていて、なおかつアップロード進捗機能が有効な場合です。PHP 自身も「起こりにくい」としています
  • 対策は、session.upload_progress.enabled=0 を php.ini か FPM のプール設定(php_admin_flag[session.upload_progress.enabled] = off)で設定し、すべての PHP ワーカーを再起動することです。前回の記事で CVE-2026-109619 の暫定策として紹介した設定と同じなので、すでに設定済みなら外さずに維持してください。PHP は、次の定期リリースで修正と詳しい情報を公開するとしています
  • この設定はアップロードの進捗表示を使う一部のアプリに影響します。PHP 本体でも、既定値を無効にする提案(GH-24648)が出ています
  • 10月29日時点で、この CVE の正式な記録(cve.org や NVD)はまだ公開されていません
  • Cloudflare は、この CVE を既存の WAF ルールで防げるとしていますが、session.upload_progress.name を既定値から変えているサイトは対象外としています

修正版で見つかった不具合(リグレッション)

  • SimpleXML のクラッシュ(GH-24488):8.4.27 と 8.5.12 で、get_object_vars()、(array) によるキャスト、json_encode() でプロパティを読んだ SimpleXML オブジェクトをガベージコレクションが解放する際に、PHP が異常終了することがあります(PHP-FPM のログに exited on signal 6 など)。同じリリースに入った別の修正が原因で、セキュリティ修正そのものではありません。修正は 8.4.28 / 8.5.13 に入る予定ですが、公開日は決まっていません。WordPress のホスティング向けハンドブックは、修正前の版に戻さないよう呼びかけ、8.3.36 にはこの不具合がないとしています
  • メモリ上限での強制終了(GH-24492):セキュリティ修正で新しく入った「ハードなメモリ上限」(既定で memory_limit の2倍)に達すると、通常の「Allowed memory size」エラーではなく、プロセスが終了コード137で終了する場合があります。8.2〜8.5 で報告されており、10月29日時点で未解決です。大きなデータを扱う処理が「Hard memory limit」のメッセージや終了コード137で止まる場合は、これを疑ってください
  • セッションが消える(GH-24493):8.5.12 で、アップロード進捗の処理が一部の正しいデータを受け付けず、セッション全体が破棄される場合があると報告されています(10月29日時点で未解決)
  • 10月29日時点で、PHP は 8.5.13 / 8.4.28 の公開日を発表していません

Windows 版の再ビルド(Brotli)

  • PHP は10月26日、Windows 版を Brotli 1.2.1 で作り直した 8.5.12-1 / 8.4.27-1 / 8.3.36-1 / 8.2.35-1 を公開しました。Brotli の境界外書き込み(CVE-2026-111497、前回の記事の Node.js の項で紹介したもの)への対応です
  • 影響するのは、cURL の HTTP 応答の自動展開を有効にしている場合です(既定では無効)。PHP 本体の版は変わりません
  • 10月29日時点で、winget のパッケージは再ビルド前の zip を指しています。必要な場合は php.net の Windows 版から直接入手してください
  • CISA は10月27日(米国時間)、CVE-2026-111497 も KEV に追加しました

いま確認・対応すべきこと

1. 修正が本当に効いているか

  • 前回の記事の手順で、パッケージの版と Web 側で実際に動く PHP の版を確認し、Apache の完全な再起動と PHP-FPM の再起動を済ませたかを確かめてください。古いプロセスは古いコードのまま動き続けます
  • session.upload_progress.enabled が無効になっているかを確認します。コマンドライン版は php -r 'var_dump(ini_get("session.upload_progress.enabled"));' で分かりますが、Web 側は別の設定のことがあるため、管理者の IP からだけ見られる一時的なスクリプトで ini_get('session.upload_progress.enabled') を表示して確認し、確認後すぐ削除します
  • ファイアウォール、VPN 装置、NAS、業務システムなど、PHP を内蔵する製品がないかを洗い出し、メーカーの情報を確認します。NCSC-NL の一覧(末尾のリンク)も参考になります

2. 侵入の痕跡がないか(10月17日以降を対象に)

Amazon は、公開前の試みが見つかったことから、少なくとも10月17日以降を調査の対象にするよう勧めています。以下は Debian / Ubuntu の場所の例です(RHEL 系は apache2 を httpd に読み替えてください。ログの場所が違うものは各項目に併記しています)。

  • Web サーバーや PHP のプロセスからシェルやダウンロードツールが起動されていないか:ps -ef --forest で、apache2・httpd・php-fpm の下に sh、bash、curl、wget などがないかを見ます
  • 新しく作られた、または書き換えられた PHP ファイル:sudo find /var/www -type f -name '*.php' -newermt 2026-10-17 -ls(公開ディレクトリが別の場所ならその場所で)
  • 異常終了の記録:sudo sh -c 'zgrep AH00051 /var/log/apache2/error.log*'(Apache の子プロセスの異常終了。RHEL 系は /var/log/httpd/error_log*)、sudo sh -c "zgrep 'exited on signal' /var/log/php8.4-fpm.log*"(PHP-FPM。版は使っているものに読み替え、RHEL 系は /var/log/php-fpm/error.log*)。ログは日ごとや週ごとに切り替わるため、古いログも含めて調べます。ただし、異常終了の記録は上記の SimpleXML の不具合など、攻撃以外の原因でも出ます
  • 大量の「Allowed memory size」エラーや HTTP 500 が、不審な multipart/form-data リクエストの直後に出ていないか(JPCERT/CC の挙げる手がかり)
  • Web サーバーのプロセスの通信:sudo ss -tnp | grep -E 'apache2|httpd|php-fpm'(自サーバーの 80 / 443 番への着信は通常の閲覧です。それ以外に、見覚えのない宛先への接続がないかを見ます)
  • 見覚えのないファイルや定期実行:sudo find /tmp /var/tmp /dev/shm -newermt 2026-10-17 -ls(Apache などは systemd の設定で /tmp/systemd-private-* の下に書き込むため、ls /tmp だけでは見えません。Sophos は /tmp/nfs を痕跡の例に挙げています)、sudo crontab -u www-data -l(RHEL 系は apache)
  • CMS の管理者アカウントに見覚えのないものがないか
  • 痕跡が見つからなくても、攻撃がなかったとは言い切れません(JPCERT/CC)

3. 侵入の疑いがある場合

  • サーバーをネットワークから隔離します。KISA は、証拠を残すため再起動せずに隔離するよう勧めています
  • Web サーバーと PHP のログを保全し、日本では JPCERT/CC、そのほかの国では各国の CERT や捜査機関に相談します
  • 修正前にインターネットに公開していたサーバーでは、データベース、API キー、管理者のパスワードなどの認証情報を変更します(KISA)
  • ネットで出回っている攻撃コードで「自分のサーバーが攻撃されるか」を試すのはやめてください。マルウェアが仕込まれている例が報告されています

4. サポート終了版(8.1 以前)を使っている場合

  • PHP プロジェクトは 8.1 以前の新しい版を出しておらず、7.4 / 8.0 / 8.1 向けの最小限の修正をソースとして公開しているだけです。共有レンタルサーバーの多くは独自に修正を当てていますが、VPS や自社サーバーでは自分で対応する必要があります
  • 修正済みのパッケージを使える選択肢として、packages.sury.org(Debian / Ubuntu。7.4〜8.1 にも修正あり)、Debian の有償 ELTS、Ubuntu Pro(ESM)、宝塔面板の独自ビルドなどがあります
  • 米国 CISA は、8.1 以前を使っている場合は修正するまでオフラインにするよう求めています。根本的には新しい版への移行が必要です。PHP 8.2 のセキュリティサポートは2026年12月31日に終わるため、KISA は 8.3 以降を勧めています

公式情報(一次情報)

免責事項

本記事は2026年10月29日時点の公開情報を Two Sheep株式会社が整理したもので、各製品の動作や安全性を保証するものではありません。作業の前に、必ず各提供元の最新情報をご確認ください。本文で触れた企業・団体は動向を説明するために挙げたもので、当社との取引関係を示すものではありません。記載の社名・製品名は各社の商標または登録商標です。

データセンターに設置したサーバーの再起動、コンソール作業、機器交換など、現地での作業が必要な場合は、当社のリモートハンズサービスにご相談ください。

シェア