# PHP2shellのその後に関する調査レポート ## はじめに 2026-10-21、PHPの重大な脆弱性「PHP2Shell」（CVE-2026-109618 / CVE-2026-109619）の修正版が公開された。修正版が出たことで一件落着、とはならない。本稿は、修正版の公開から2日後の2026-10-23時点で、次の四つの問いについて公開情報を整理するものである。 1. EOL（サポート終了）のPHPを利用しているシステムはどうなるのか 2. サポート中のPHPであっても、脆弱性を修正できないシステムがあるのではないか 3. 修正できるとしても、動作検証を含めると、サービスをすぐには再開できないのではないか 4. そもそも、PHP2Shellの対策は完全なのか また、将来の予想を、"with PHP2shell" と "with vulnerability" としてまとめたものである。 本稿では、記述を次の三つに区分する。 - **【事実】**：一次情報（当事者の発表、公式文書、ソースコード）または報道で確認できる事項。報道や二次情報のみに依拠する場合は脚注にその旨を付記する - **【解釈】**：事実から筆者が読み取った内容 - **【仮説】**：検証を要する見立て 事態は進行中であり、本稿の記述は2026-10-23時点のものである。調査の深度は概要レベルとする。 > **【筆者注記】利害関係の開示** > 筆者は本稿で取り上げた組織・企業・団体・プロジェクト等との業務上の関係、出資関係、競合関係はない。 > 本稿はいかなる外部主体からの委託・資金援助も受けておらず、独立した調査・分析に基づく。 > **本記事の作成プロセス** > 本記事は、運営者とAIの協働により作成しています。作成プロセスおよび品質管理の詳細は、[[サイトポリシー#1.2 AI の利用について]]をご参照ください。 --- ## 更新履歴 | 日付 | 内容 | |---|---| | 2026-10-23 | 初版作成 | --- ## 1. 前提：PHP2Shellの要点 **【事実】** PHP2Shellは、PHP本体のメモリ不足時の処理と、リクエスト間に残る内部状態の扱いに起因する二つの脆弱性である。認証なしに遠隔からコードを実行される可能性があり、深刻度はいずれもCVSS v4.0で9.2とされた[^1]。影響はPHP 5.4まで遡るとされる[^2]。 **【事実】** PHPは2026-10-21、8.5.12、8.4.27、8.3.36、8.2.35を公開した。あわせて、設定の変更による緩和策は完全ではなく、更新だけが安全な選択肢だとしている[^1]。 > There are no complete mitigations, updating is the only safe choice. > > （意訳）完全な緩和策は存在しない。更新だけが安全な選択肢である。 --- ## 2. EOLのPHPを利用しているシステムはどうなるのか ### 2.1 公式の扱い **【事実】** PHPの発表によれば、8.1以前の系列はPHPプロジェクトからの更新を受けない。ただし今回は例外的に、7.4、8.0、8.1向けに最小限の修正をソースコードの形で用意した。これはGitHub上のブランチとして提供されるもので、正式なリリース（配布用のアーカイブや版番号の更新）ではない。自分でソースから構築する利用者や、長期サポートの提供元を持たない利用者を想定したものである[^1]。 **【事実】** 7.3以前（PHP 5系を含む）には、いかなる修正も提供されていない[^3]。 ### 2.2 規模 **【事実】** EOLの系列で動くPHPの数については、複数の推計がある。 | 推計元 | 方法 | 主な数値 | |---|---|---| | VirusTotal[^4] | HTTP応答の版表示（X-Powered-By） | 5.4〜8.1：約75.8万IP。サポート中の8.2〜8.5：約27.2万IP | | Mallory[^5] | Shodanのデータ（2026-10-21に訂正） | 版を表示しているサービスの73.5%が8.1以前 | | Modat[^6] | 自社の走査（2026-10-20、修正版公開前） | 版を読み取れたサービスの約79%がEOL系列 | **【事実】** いずれも、版を表示しているサーバーだけを数えた推計である。VirusTotalとMalloryは、これが実際に脆弱なサーバーの数を示すものではないと注記している[^4][^5]。Modatも、版を読み取れたサービスだけを数えたとしている[^6]。また、ディストリビューションが修正を取り込んだ場合、版番号は古いまま残ることがあるため、版表示だけでは修正の有無を判断できない[^7]。 **【解釈】** 方法が違うため数値は単純に比べられないが、版を表示しているPHPの過半、おそらく7割前後が、PHPプロジェクトから正式な修正を受けられない系列にある、という点では各推計が一致している。 ### 2.3 第三者による延命 **【事実】** EOLの系列でも、ディストリビューションや商用の延長サポートを通じて、修正を受けられる場合がある。 | 提供元 | 状況 | |---|---| | Ubuntu[^8] | 22.04の標準パッケージであるPHP 8.1に修正を提供した | | Red Hat[^9] | RHEL 8のphp:7.4モジュールに修正を提供した（版番号は7.4.33のまま） | | cPanel[^10] | ea-php74、ea-php80、ea-php81に修正を取り込んだ | | Plesk[^11] | Linux向けの7.4、8.0、8.1を同じ版番号のまま再構築した。5.6、7.2、7.3には修正を提供しない。Windows向けのEOL版については言及がない | | CloudLinux[^12] | alt-phpの5.2〜8.5に修正を提供した。4.4と5.1には提供しない | | TuxCare[^13] | 有償の延長サポートとして、EOLの系列（5.2〜8.1）を含む各系列に修正を提供する（対象範囲はOSにより異なる） | | Synology[^14] | 同社のPHPパッケージ7.4〜8.4には修正を提供したが、7.3には提供しない | **【事実】** 一方、Docker Hubの公式PHPイメージでは、8.5.12、8.4.27、8.3.36、8.2.35のタグが用意された一方、8.1以前のタグは見当たらなかった[^15]。 **【解釈】** 「EOLのPHP」が修正を受けられるかどうかは、PHPの版そのものではなく、そのPHPを誰から入手しているかで決まる。ディストリビューションや商用の延長サポート経由であれば修正を受けられる場合があるが、自分でソースから構築したもの、公式のコンテナイメージを使ったもの、長期サポートのないOSに載ったものは、修正を受けられない。その場合に残る選択肢は、サポート中の系列への移行（多くの場合、アプリケーションの改修を伴う）か、サービスの停止である。 --- ## 3. 脆弱性を修正できないシステム ### 3.1 PHPを組み込んだ製品 **【事実】** PHPは、ファイアウォール、NAS、管理画面などの製品に組み込まれていることがある。こうした製品では、利用者が自分でPHPを更新できず、製品の提供元の修正を待つしかない。主な提供元の2026-10-22前後の状況は次のとおりである（各社の状況を一覧した報道として[^16]）。 | 提供元 | 状況 | |---|---| | Palo Alto Networks | PAN-OSとPanoramaの全リリースが影響を受けるとした。修正の時期は未定。管理インターフェースへのアクセスを信頼できる内部のIPアドレスに制限することなどを回避策としている[^45] | | QNAP | 複数の製品が影響を受けるとし、修正は作業中で時期は未定。ポート転送やUPnPの無効化、VPN経由での利用を推奨している[^17] | | Synology | PHPパッケージは修正済み。DSM内部のPHPについては、リスクは小さいとしたうえで、修正は今後のDSMの版で行うとしている[^14] | | Fortinet、Cisco | 一部製品について調査中とし、影響を受けない製品と調査中の製品を一覧で公表した[^46][^47] | | Sophos | 自社製品は影響を受けないとした。ただし、サポートが終了した製品向けの旧ライセンスポータルが影響を受ける版のPHPで動いていたため、停止した[^18] | | SonicWall、WatchGuard | SonicWallは、列挙した製品群について影響を受けないとした（全製品を対象とした声明ではない）。WatchGuardは、初期評価として全製品が影響を受けないとし、確認を続けている[^19][^20] | **【事実】** JPCERT/CCは、PHPを組み込んだ製品の利用者に対し、製品の提供元の情報を確認するよう求めている[^21]。 ### 3.2 保守が途絶えたシステム **【事実】** 保守契約がない、開発元が対応しないなどの理由で更新できないシステムについて、各国の当局は次のように勧告している。 - **米国NSA**：すぐに更新できない場合は、完全に緩和できるまでシステムを停止すること。修正できないEOLのPHPを使うサービスは置き換えること[^22] - **英国NCSC**：PHPの一時的な緩和策を適用し、それもできなければシステムの停止を検討すること。古い版のPHPに限らず、すべてのPHPを洗い出すこと[^23] - **IPA**：更新できないシステムについて、次の六つの手順を示している[^24] 1. サポート状況の確認 2. 更新・移行までの暫定対策（アクセス制限。困難な場合は外部からのアクセスの遮断や一時停止の判断を含む） 3. システムの状況と、更新・移行の難しさの把握 4. 事業責任者や経営層を含めた、組織としての対応の実現性の検討（人員、予算、保守体制） 5. 今後の対応方針の決定（移行、提供機能の縮小、公開の終了、廃止を含む） 6. 利用者や業務への影響を考慮した実施 **【解釈】** IPAの勧告が、経営層を含めた人員・予算・保守体制の検討や、「公開の終了」「廃止」にまで踏み込んでいる点は重要である。保守が途絶えたシステムの問題は、技術の問題である以前に、そのシステムを誰が所有し、誰が維持の費用を負うのかという問題である。PHP2Shellは、普段は意識されない「持ち主のいないシステム」を、表に引き出したと言える。 **【解釈】** 組込み製品の場合、利用者にできるのは、修正が出るまで攻撃にさらされる範囲を狭めること（管理画面を外部に公開しない、VPNを経由させる、など）である。Palo Alto NetworksやQNAPが示した回避策も、この考え方に沿っている[^45][^17]。 --- ## 4. 修正できても、すぐには再開できない理由 ### 4.1 サービス停止の実例 **【事実】** - 英国では、2026-10-22、政府の32のサービスが利用できず、4つが部分的に利用できない状態にあると、上院で政府側が答弁した。予防措置として停止したもので、侵害は確認されていないとし、再開の時期は示さなかった[^25][^26]。 - 日本では、2026-10-22の1時台の時点で、211の組織がサービスの停止や緊急保守を公表していたと集計されている[^27]。 - レンタルサーバーのXserverは、2026-10-22の朝に8.2〜8.5の修正を適用し、一部の再開を始めた[^27][^28]。 ### 4.2 修正版自体が挙動を変える **【事実】** 修正版は、新たに「ハードなメモリ上限」（設定項目 `memory_hard_limit_percent`）を導入した[^29]。従来の `memory_limit` に達した場合はエラーとして処理されたが、新しい上限に達すると、PHPのプロセスは終了処理を行わずに直ちに終了する[^30]。 **【事実】** 修正版の公開当日には、これまで捕捉できていたメモリ不足のエラーが、プロセスの即時終了に変わったという不具合報告が、PHPの開発元に寄せられている[^31]。新しい設定項目の既定値の表示が誤っているという報告もある[^32]。一方、PHPの発表は、後方互換性の問題を挙げていない[^1]。 **【解釈】** 修正版の導入は、単なる「穴ふさぎ」ではない。メモリを多く使う処理（帳票出力、データ取込み、バッチ処理など）が、これまでと違う止まり方をする可能性がある。サーバーの台数やメモリの見積もり、監視の仕組みも含めて確認し直す必要があり、これが検証に時間がかかる理由の一つになる。 ### 4.3 侵害の確認が先に来る **【事実】** 悪用の試行は、修正版公開の4日前の2026-10-17に観測されていた[^33]。英国NCSCは、すぐに更新や停止ができない場合には、更新や緩和策の前に侵害やバックドアの有無を確認するよう求めている[^23]。JPCERT/CCは、「十分なテストを実施の上、速やかに」修正版を適用するよう求めると同時に、侵害の兆候として、不自然に長い、または異常な形式のセッションIDのCookie、不審なmultipart/form-dataリクエストとその前後のメモリ上限エラーやHTTP 500、PHPのワーカーの異常終了や頻繁な再起動の三つを挙げている[^21]。 **【解釈】** サービスを再開するには、侵害の確認、修正版の検証、適用、プロセスの再起動、再開後の監視という段階を踏む必要がある。修正版を入れるだけでは再開できず、「入れてよい状態か」を先に確かめなければならない。 ### 4.4 供給網の遅れと一時策の副作用 **【事実】** - 修正版を配る側にも遅れが出た。RHEL系で広く使われる非公式リポジトリ（Remi）は、公開当日には更新されない見込みとされ[^1]、CloudLinuxは修正済みパッケージを配布した後も、セキュリティ更新だけを適用する仕組みが参照する情報を、まだ公開していなかった[^34]。 - 一時策には副作用がある。WordPress向けのホスティング事業者の中には、修正版の入手を待つ間の緩和策として、アップロードできるファイルの大きさに制限がかかる可能性があると利用者に告知したところがあった[^35]。 ### 4.5 適用の進み具合 **【事実】** Computer Weeklyが報じたInfrawatchの集計によると、2026-10-22 20:20（UTC）頃の時点で、版を表示している公開PHPのうち修正済みは世界全体で約6%だった[^36]。別の調査は、版を表示しているPHPのサービスのうち、修正版が出た系列（8.2〜8.5）は27.3%にとどまり、18.8%はディストリビューションの表示があるため修正の有無を判別できないとしている[^37]。 ### 4.6 小括 **【解釈】** JPCERT/CCの「十分なテストを実施の上、速やかに」という要請は、「十分なテスト」と「速やかに」という、互いに引っ張り合う二つを同時に求めている。この両立は、二者択一ではなく、時間を稼ぐ手段との組み合わせで実現するしかない。具体的には、外部からのアクセス制限やWAFで攻撃にさらされる範囲を狭めて時間を稼ぎ、その間に検証を済ませて修正版を入れ、検証が済んだ機能から順に再開する、という段階的な進め方である。英国政府や日本の多くの組織が取った「予防的な停止」は、この時間稼ぎの最も強い形と読める。 --- ## 5. PHP2Shellの対策は完全なのか ### 5.1 修正の中身 **【事実】** 修正の本体は「Avoid state corruption via bailout」という一つのコミットで、389のファイルにわたる変更である。メモリ不足時に処理を打ち切る仕組みそのものを置き換え、リクエストの開始時に各種の内部状態を正しく初期化し直す内容になっている[^29]。 **【事実】** 発見者の一社であるWizは、この修正が問題を根本で解決し、修正版では全ての変種がなくなると述べている[^2]。ただし、これは発見者自身の評価である。Wizは共同発見者のCalifとOpenAIにパッチの検証への謝辞を述べているが、独立した第三者による公開の検証は確認できなかった。 **【解釈】** 修正は、実証された攻撃経路を個別にふさぐものではなく、原因となる仕組みそのものを改めるものである。コードの水準では、根本対策として設計されていると読める。 ### 5.2 修正版公開後の動き **【事実】** 2026-10-23時点で、PHPは追加の修正版も、同じ種類の新たなCVEも公開していない[^1]。また、8.5.12と8.4.27に含まれていた別の修正（ガベージコレクションの不具合修正）が原因の新たな不具合が見つかり、その修正がPHP-8.5ブランチとmasterに取り込まれた。これはPHP2Shellの修正によるものではない[^38]。 **【事実】** 修正版でもなお攻撃が成立すると主張する報告がネット上にあるが、いずれも報告者自身の主張にとどまり、第三者による再現は確認されていない[^39]。また、修正版でもセッションのアップロード進捗の機能を使えば、攻撃者が制御できる内容をセッションファイルに書き込めるため、アプリケーション側にファイル読み込みの脆弱性があれば、組み合わせてコード実行に至り得るという指摘もある。ただし、これはPHP本体の修正の回避ではなく、機能の性質だとされている[^40]。 ### 5.3 回避策の限界 **【事実】** PHPは、設定による緩和策は特定の攻撃経路への露出を減らすが、安全にはしないとしている。たとえば、セッションのアップロード進捗の機能を無効にすれば確認済みの経路はふさがるが、他の変種はふさがらない[^1]。 **【事実】** WAF（Webアプリケーションファイアウォール）の規則も一時しのぎにとどまる。CloudflareのCTOは、自社の規則について「一時しのぎにすぎない（STOPGAP only）」と述べた[^41]。規則はCloudflareを通る通信しか検査しないため、オリジンのサーバーへの直接の通信は防げない[^41]。Sygniaは、セッションのアップロード進捗の項目名に頼る規則では、その項目を使わないCVE-2026-109618の攻撃を検知できないと指摘している[^42]。 ### 5.4 修正後も残るリスク **【事実】** - **漏えいした秘密情報**：PHP2Shellでは、PHPのワーカーのメモリの内容が漏えいし得る。そこにはパスワード、認証トークン、APIキーなどが含まれ得る[^7]。Sygniaは、漏えいの可能性がある秘密情報を、封じ込めと復旧の一環として変更または失効させるよう推奨している[^42]。 - **すでに入り込んだ攻撃者**：Sygniaは、次のように述べている[^42]。 > Patching a vulnerable runtime does not remove an attacker who has already established access. > > （意訳）脆弱な実行環境を修正しても、すでに侵入を果たした攻撃者は取り除かれない。 - **再起動されていないプロセス**：修正版を入れても、動き続けているPHPのワーカーを再起動しなければ、修正は効かない[^3]。 - **版表示の当てにならなさ**：ディストリビューションの修正は版番号を変えないことがある。また、`php -v` が示すのは、Webのリクエストを処理しているものとは別のPHPである場合もある。このため、`php -v` の表示だけでは修正の有無を判断できず、パッケージと実行中のプロセスの両方を確認する必要がある[^7]。 ### 5.5 構造的な背景 **【事実】** PHP Foundationによれば、根本原因の兆候は2024年の外部監査の後に見つかっていたが、修正方針がまとまらずに停滞した。PHP Foundationはこれを「構造的な失敗」と呼び、意思決定を合意制から多数決に改めることを表明した。あわせて、2026年5月に設けたエコシステム・セキュリティチーム（Ecosystem Security Team）などの取り組みを説明した。また、脆弱性の報告は今後も増え続けるとの見通しを示している[^43]。 ### 5.6 小括 **【解釈】** 「対策は完全か」という問いには、二つの水準で答える必要がある。 - **コードの水準**：修正は根本原因の仕組みを改めるもので、現時点で確認された回避の報告もない。この水準では、完全に近いと評価できる。 - **社会の水準**：修正を受けられないEOLの系列、提供元の修正を待つ組込み製品、再起動されていないプロセス、すでに漏えいした秘密情報、すでに入り込んだ攻撃者が残る。この水準では、対策は完全からほど遠い。 **【仮説】** PHP2Shellの被害は、修正版の公開時点ではなく、これから長い時間をかけて、修正の届かない場所で顕在化する可能性がある。具体的には、EOLのPHPで動き続けるシステムと、修正の出ない組込み製品である。 --- ## 6. 考察 ### 6.1 「修正版がある」と「守られている」の距離 **【解釈】** 本稿で見た四つの問いは、いずれも「修正版がある」ことと「利用者が守られている」こととの間にある距離を示している。PHPの修正は、次のような長い経路を通って利用者に届く。 PHP本体 → ディストリビューションや延長サポートの提供元 → ホスティング事業者や管理パネル、製品の提供元 → システムの開発・保守を請け負う事業者 → システムの所有者 経路の各段で遅れが生じ、どこかの段が途絶えていれば、修正は届かない。しかも、版番号が変わらない修正があるため、利用者は自分のところまで修正が届いたかを、版表示で確かめることすらできない。 ### 6.2 EOLは「持ち主」の問題である **【解釈】** 2.3節で見たとおり、EOLの系列でも修正を受けられるかどうかは、入手経路で決まる。そして、修正を受けられないシステムに残る選択肢は、移行か停止である。この判断はシステムの所有者にしかできない。IPAが経営層の関与と「廃止」の選択肢まで示したのは、この点を正面から捉えたものと読める[^24]。 **【解釈】** 悪魔の代弁者として付け加えれば、「停止」は常に取れる選択肢ではない。停止そのものにも費用がかかり、止められない公共サービスもある。停止できないシステムには、アクセス制限やWAFで時間を稼ぎながら移行を急ぐ、という中間の道しかない。 ### 6.3 製品を提供する側への示唆 **【解釈】** PHPを組み込んだ製品を提供する側にとって、今回の事例は次の三点を示している。 1. **自社製品のどこにPHPがあるかを、すぐに答えられること**：FortinetやCiscoは、調査中の段階から、影響を受けない製品と調査中の製品を一覧で公表した[^46][^47]。部品構成表（SBOM）が整っていれば、この判断は速くなる。 2. **修正版より先に、攻撃にさらされる範囲を狭める手段を示すこと**：Palo Alto NetworksやQNAPは、修正の時期が未定の段階で、利用者が取れる回避策を示した[^45][^17]。 3. **自社製品のサポート期間と、組み込んだ部品のサポート期間を一致させること**：EUのサイバーレジリエンス法（CRA）は、製造者に製品のサポート期間を定め、その間は脆弱性に対処することを求めている[^44]。組み込んだPHPのサポートが製品より先に切れれば、修正できない部品を抱えることになる。製品本体への組込みではないが、Synologyが利用者向けに提供するPHP 7.3のパッケージに修正が出なかったことは、同じ構図を示している[^14]。 ### 6.4 結び **【解釈】** PHP2Shellの修正版は、2024年に根本原因の兆候が見つかってから、2026-10-21にようやく公開された。そして、その修正が利用者の手元に届き、使われ続けているシステムの全てが守られるまでには、はるかに長い時間がかかる。問われているのは修正の速さよりも、修正が届かない場所をどれだけ早く見つけ、どう扱うかである。 --- ## 7. with PHP2shell 本章は、ここまでの調査を踏まえた筆者の予想である。事実として確認できる部分を除き、【仮説】として扱う。 ### 7.1 PHP2Shellは「完了」し得るか **【仮説】** 影響を受けるサーバーがゼロになる、という意味での完了は来ないと予想する。ただし、PHP2Shellが日常的な雑音の一つとして扱われるようになる、という意味では、いずれ落ち着く。 ### 7.2 先例 **【事実】** 米国のサイバー安全審査会（CSRB）は、2022年7月の報告書で、Log4jの脆弱性を「風土病的な（endemic）脆弱性」と位置づけた。そして、脆弱な状態のシステムが今後10年、あるいはそれ以上にわたって残り得るとの見通しを示した[^48][^49]。 **【解釈】** PHP2Shellは、この先例よりも条件が悪い。 - 影響が、PHP 5.4まで遡る十数年分の版に及ぶ[^2] - 版を表示しているPHPの約7割が、公式の修正を受けられない系列にある（2.2節） - 修正の時期が未定の組込み製品がある（3.1節） - PHPを使っていることすら認識されていないシステムがある（7.4節） ### 7.3 推移の見立て **【仮説】** PHP2Shellは、次の三つの段階をたどると予想する。 | 段階 | 時期の目安 | 内容 | |---|---|---| | 急性期 | 数週間 | 公開されているサポート中のPHPへの大量の攻撃と、更新の波。2026-10-23時点はこの段階にある | | 慢性期 | 数か月〜数年 | 攻撃の的が、EOLのPHP、修正の遅い組込み製品、誰も把握していないPHPに移る。攻撃者にとって狙いやすい対象が長く残る | | 収束期 | 5〜10年 | 脆弱なPHPが「直される」のではなく、機器の更新やシステムの廃止によって「寿命で消えていく」形で数が減る。それでもゼロにはならない | **【事実】** 急性期のうちにも、攻撃の成功のしやすさは変わりつつある。VulnCheckによれば、GitHub上に何百と公開されたPoCのうち、実際に攻撃として成立するものはごく一部にとどまる[^53]。The Registerによれば、その主な理由は、メモリの配置をランダムにする防御機構（ASLR）だった[^54]。ところが2026-10-22、VulnCheckは、ASLRが有効なx86-64環境で、PHPの推奨する本番設定のまま遠隔からのコード実行を成立させるエクスプロイトを開発したと発表した。対象はPHP 8.4.10〜8.4.26で、同社の顧客向けに限られ、公開はされていない[^53][^54]。公開されているPoCの中にもASLRを破るものが少なくとも一つあるが、同社の検証では8.4.26の既定の設定でしか動かなかった[^53]。なお、同社は攻撃の成功率や必要な試行回数の数値は示していない[^53]。 **【仮説】** 攻撃1回あたりの成功確率は、PHPの版、CPUのアーキテクチャ、ワーカーの構成などの組み合わせと、攻撃者がその組み合わせに合ったエクスプロイトを持っているかによって、大きく振れる。そのうえで、この確率は固定された値ではなく、時間とともに上がっていく曲線として捉えるのが実態に近い。理由は二つある。一つは、試行が自動化されるため、1回あたりの確率が低くても、試行を重ねれば累積の確率は上がること。もう一つは、非公開の攻撃能力がいずれ公開されたり独自に再現されたりして、広がっていくことである。防御側にとって意味のある変数は、1回あたりの成功確率よりも、修正されないまま攻撃にさらされている時間の長さである。 **【仮説】** また、PHP2Shellは一つの脆弱性の名前にとどまらず、「メモリ不足時に内部状態が壊れる」という種類の脆弱性の名前になる可能性がある。PHP Foundationは脆弱性の報告が今後も増え続けるとの見通しを示しており[^43]、AIを使った探索で同じ種類の変種が見つかり続けることが考えられる。 ### 7.4 認識されていないPHP **【解釈】** 慢性期に最も危険なのは、修正版のないPHPよりも、PHPがあることを誰も認識していないシステムである。たとえば、次のような経緯が考えられる。 1. あるシステムの一部であるサブシステムの開発を、外部のベンダーに委託した 2. ベンダーはサブシステムをPHPで開発し、納品した。発注した側は、PHPが使われていることを知らない 3. 保守契約が切れた 4. PHP2Shellが発覚した。発注した側は、システム本体の開発会社に問い合わせ、PHPを使っていないことを確認した 5. しかし、サブシステムがPHPで書かれていることは、誰も知らない **【解釈】** この例の怖さは三つある。第一に、「確認した」という事実がかえって安心を生む。問い合わせた相手の答えは、その相手が作った範囲についてのものにすぎない。第二に、委託がさらに再委託される構造では、層が増えるたびに「何で作ったか」という情報が伝わりにくくなる。第三に、保守契約が切れていれば、気づいても直す人がいない。 **【解釈】** この状況への対策は、関係者に聞いて回ることではなく、動いているものを直接観測することである。英国NCSCが、古い版に限らずすべてのPHPを洗い出すよう求めているのも[^23]、この意味と読める。観測の手段には、次のようなものがある。 - **外から見る**：自社のIPアドレス帯や公開しているドメインを走査し、応答ヘッダの `X-Powered-By`、`PHPSESSID` というCookie、`.php` で終わるURLを探す - **中から見る**：サーバー、仮想マシン、コンテナの中で、PHPのプロセス、パッケージ、ファイルを探す - **通信の記録から見る**：プロキシやロードバランサーのログに `PHPSESSID` が流れていないかを調べる。社内向けのサブシステムは外から見えないため、この方法が効く **【解釈】** 平時の備えとしては、委託先に使用した言語やミドルウェアの一覧（部品構成表、SBOM）を納品物として求めること、保守契約が切れるときにシステムの構成情報を自社の資産台帳に引き継ぐことが考えられる。ただし、台帳は更新されなければ現実とずれていく。定期的に実物を観測し、台帳と突き合わせる仕組みがなければ、同じことが繰り返される。 ### 7.5 意味のある「完了」 **【解釈】** 社会全体でのPHP2Shellの完了は来ないが、組織ごとの完了は、定義さえすれば達成できる。たとえば、「自社のどこにPHPがあるかを把握しており、そのすべてが修正済みか、隔離されているか、廃止の予定が決まっている」と言える状態である。 **【解釈】** インターネット全体に残る脆弱なPHPの数は、どの組織にも変えられない。変えられるのは、自分の持ち場だけである。本章の題を「with PHP2shell」としたのは、PHP2Shellが消えることを待つのではなく、それが残り続ける前提で自分の持ち場を守る、という姿勢を示すためである。 --- ## 8. with vulnerability 本章は、7章の考え方をPHP2Shellから脆弱性一般に広げ、私たちが脆弱性と共存していく将来像について、筆者の仮説を示すものである。事実として確認できる部分を除き、【仮説】として扱う。 ### 8.1 前提となる変化 **【事実】** 将来像を考える前提として、次の三つの変化が確認できる。 - **発見の高速化**：PHP Foundationは、今や道具によって、防御側にも攻撃側にも、かつてない速さでバグが見つかるようになったと述べ、脆弱性の報告は今後も増え続けるとの見通しを示している[^43] - **風土病化の先例**：Log4jの脆弱性は、米国のサイバー安全審査会によって「風土病的な」脆弱性と位置づけられた[^48] - **成分表の国際化**：ソフトウェアの部品構成表（SBOM）について、2026年7月、米国CISAが最低限含めるべき要素を更新した。この文書には、日本を含む14か国のセキュリティ機関が共同で作成者として名を連ねている[^50]。EUのCRAも、製造者に製品の構成部品の把握とSBOMの作成を求めている[^44] ### 8.2 生体との比較 **【解釈】** 「風土病」という比喩を延ばすと、生体とシステムの決定的な違いが二つ見えてくる。 1. **自然治癒力がない**：生体は、傷を自分でふさぎ、侵入した病原体を自分で撃退する。システムに内包された脆弱性は、誰かが外から手を入れない限り、何年経ってもそのまま残る。自動更新は治癒力に似て見えるが、実態は人間が設計して外から与えた仕組みであり、生体でいえば自前の免疫より、予防接種や公衆衛生に近い 2. **世代の交代がない**：生体の集団では、個体はいずれ寿命を迎え、新しい世代に入れ替わる。システムには自然な寿命がなく、人間が廃止を決めない限り、古い部品は動き続ける。7.3節で収束期を「寿命で消えていく」と書いたが、その「寿命」の大半は人間の判断であり、自然死に近いのはハードウェアの故障くらいである **【解釈】** 一方、社会全体の水準では、獲得免疫に似た動きもある。大きな脆弱性の後にSBOMが普及し始め、CRAのような制度ができ、攻撃の手口は検知の仕組みに蓄えられて次の攻撃に備えられる。ただし、これは社会という集団の免疫であり、個々のシステムが自分で獲得するものではない。個々のシステムを治すのは、やはり人の手である。 ### 8.3 将来像の仮説 **【仮説1】脆弱性は「ゼロにする対象」から「量として管理する対象」になる** 発見が高速化し、修正の届かないシステムが残り続ける以上、すべての脆弱性をなくすことは目標として成り立たなくなる。目指すものは、公衆衛生が感染者をゼロにするのではなく重症化と流行の拡大を防ぐように、「致命的なものを、致命的な場所から優先して減らす」ことに移る。脆弱性への対応は、個々の事件への対処から、常に一定量が存在することを前提にした管理へと性格を変える。 **【仮説2】希少な資源は「発見」から「修正」と「把握」に移る** AIによって発見の費用は下がり続ける。一方で、修正を作る力（PHP2Shellの根本原因が2024年に見つかりながら修正が停滞したように[^43]）と、自分のどこに何があるかを把握する力（7.4節の認識されていないPHPのように）は、同じ速さでは増えない。脆弱性との共存の成否は、発見の量ではなく、この二つの力をどれだけ確保できるかで決まるようになる。 **【仮説3】防御の重心は「回復力」から「靭性」に移る** システムに自然治癒力がない以上、レジリエンスを「勝手に回復する力」として期待することはできない。目指すべきは、突破されても折れずに持ちこたえる性質、すなわち靭性を、設計によって作り込むことである。攻撃にさらされる範囲を最小にする（管理画面を外に出さない）、一か所が破られても全体に広がらない構造にする、どこに何があるかを観測できるようにする、といった備えは、いずれも脆弱性が残り続けることを前提にしたものである。 **【仮説4】「成分表」と「持ち主」と「寿命」が制度になる** 生体に欠けている二つの仕組みを、人間が制度として補う方向に進む。 - **成分表**：何が入っているかを把握する仕組み。SBOMの義務化が、国際的な基準と各国の規制の両面で進む[^50][^44]。ただし、成分の情報が委託先や再委託先から発注者まで遡って届く仕組みがなければ、7.4節の問題は解決しない - **持ち主**：誰がそのシステムに責任を負うかを明確にする仕組み。IPAが経営層の関与と「廃止」の選択肢まで示したように[^24]、脆弱性への対応は技術部門の仕事から、所有者の経営判断へと位置づけが変わる - **寿命**：自然な世代交代の代わりに、サポート期間と廃止の時期を、あらかじめ決めておく仕組み。CRAが製造者にサポート期間を定めることを求めているのは[^44]、システムに人為的な寿命を与える制度と読める **【仮説5】予防的なシステム停止が日常の光景になる** 新たな深刻な脆弱性が公表されるたびに、組織が攻撃を受ける前にシステムを予防的に止めることが、日常の光景になると予想する。日本で、台風の接近時に鉄道が計画運休を行うのと同じ構図である。 **【事実】** PHP2Shellでは、すでにこの光景が現れている。英国では政府のサービスが予防措置として停止され[^25]、日本では2026-10-22の1時台までに211の組織が停止や緊急保守を公表した[^27]。英国政府は、サービスの停止が侵害を意味するものではないと説明している[^26]。 **【事実】** 鉄道の計画運休については、国土交通省が2018年の台風での実施を検証し、2019年7月に最終とりまとめを公表した。計画運休の可能性を早めに複数の手段で知らせること、運転再開時にも具体的な情報を適切なタイミングで出すこと、各事業者があらかじめ情報提供のタイムラインを作ることなどを求めている[^51]。 **【解釈】** 比喩には、当てはまらない点もある。この違いが、そのまま予防的なシステム停止の課題になる。 | 観点 | 台風による計画運休 | 脆弱性による予防的停止 | |---|---|---| | 予報 | 数日前から進路が予報され、計画を立てる時間がある | 公表の日に突然来る。PHP2Shellでは公表が1日前倒しされた[^43] | | 再開の条件 | 台風が通り過ぎ、点検が済めば再開できる | 脅威は通り過ぎない。修正版の検証、適用、侵害の確認という、こちら側の作業が済むまで再開できない | | 頻度 | 季節性があり、年に数回 | AIによって深刻な脆弱性の発見が増えれば、頻発するおそれがある | **【解釈】** 三つ目の頻度の問題から考えると、目指すべきは全面停止を日常にすることではなく、全面停止をしなくて済む構造である。鉄道でいえば、全線運休ではなく、間引き運転や区間運休にあたるものである。外部に公開している入口だけを閉じて社内の利用は続ける、影響を受ける機能だけを止める、静的なページに切り替えて最低限の告知を出し続ける、といった形である。札幌市は公式サイトを一時停止し[^55]、WebSec Centerによれば、その間は簡易サイトを表示していた[^52]。最低限の告知を出し続ける形の一例と言える。IPAの勧告にある「提供機能の縮小」も、同じ考え方である[^24]。これは仮説3の靭性ともつながる。折れないとは止まらないことではなく、一部を止めても全体が機能し続けることである。 **【解釈】** 予防的な停止が社会に定着するには、計画運休と同じく、次の三つが要る。 1. **判断の基準**：どのような脆弱性が、どの範囲に影響する場合に止めるのかを、あらかじめ決めておく 2. **告知の型**：止めること、止める範囲、再開の見通しを、利用者に伝える型を用意しておく。国土交通省が鉄道事業者に求めた情報提供のタイムラインは、そのまま参考になる[^51] 3. **社会の理解**：「止めた」ことが「侵害された」と受け取られないことである。英国政府があえて停止は侵害を意味しないと説明したように[^26]、この理解がなければ、組織は評判を恐れて止める判断をためらう。計画運休が受け入れられたのも、「止めるのは安全のため」という理解が社会に広がったことが大きいと考えられる ### 8.4 悪魔の代弁者として **【解釈】** 「脆弱性と共存する」という考え方には、少なくとも三つの危うさがある。 1. **共存が放置の言い訳になる**：「ゼロにはならない」という認識が、「だから直さなくてよい」という結論にすり替わる危険がある。共存とは、管理し続けることであって、受け入れて放置することではない 2. **管理できる組織とできない組織の格差**：量としての管理には、把握と優先順位づけの能力が要る。人員や予算のない組織や個人は、管理の側ではなく、攻撃の的として残される側に回りやすい。共存の負担は均等には配られない 3. **AIが治癒力をもたらす可能性**：本章はシステムに自然治癒力がないことを前提にしたが、AIによる脆弱性の自動修正が進めば、この前提は部分的に崩れるかもしれない。発見を速めたのと同じ技術が、修正も速める可能性はある。ただし、それも人間が設計して与えた仕組みであり、修正を適用する判断と、修正が届かない古いシステムの問題は残る ### 8.5 結び **【解釈】** 「with vulnerability」とは、脆弱性がなくなる日を待つのではなく、脆弱性が常に存在する前提で生きることである。それは、自分の持ち場に何があるかを把握し、突破されても折れない構造を作り、必要なときにはためらわずに一部を止め、システムに欠けている治癒と世代交代を、人の手で回し続けることを意味する。PHP2Shellは、そのような時代がすでに始まっていることを示した事例の一つと言える。 --- ## 脚注 アクセス日はいずれも 2026-10-23 である。一次情報を取得できず、二次情報で内容を確認したものは、その旨を付記した。 [^1]: PHP, "Security advisory: Critical remote code execution vulnerabilities, update now", 2026-10-21. https://www.php.net/archive/2026.php#2026-10-21-5 （CVSSは2026-10-20の事前告知 "Upcoming Critical PHP Security Release" に記載：https://www.php.net/archive/2026.php#2026-10-20-1 ） [^2]: Wiz, "PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet". https://www.wiz.io/blog/php2shell-php-rce [^3]: watchTowr, "Frequently Asked Questions About PHP Remote Code Execution (PHP2Shell CVE-2026-109618 & CVE-2026-109619)", 2026-10-20（2026-10-22更新）. https://watchtowr.com/intelligence/php-cve-2026-109618-faq/ [^4]: VirusTotal, "Sizing the PHP exposure window for CVE-2026-109618 and CVE-2026-109619 with VirusTotal", 2026-10-21. https://blog.virustotal.com/2026/10/sizing-php-exposure-window-for-cve-2026.html [^5]: Mallory, "PHP2Shell CVE-2026-109618 CVE-2026-109619 | Am I affected?", 2026-10-20（2026-10-21訂正）. https://mallory.ai/blog/php-rce-rapid-response [^6]: Modat, "Leaked Critical PHP Vulnerabilities (CVE-2026-109618 & CVE-2026-109619): An internet exposure report", 2026-10-21. https://modat.io/blog/php-exposure-before-the-21-oct-2026-security-release/ [^7]: Qualys, "PHP2Shell: PHP Patches Two Critical RCE Vulnerabilities, Urges Immediate Updates", 2026-10-21（題名は公開後に変更されている）. https://blog.qualys.com/vulnerabilities-threat-research/2026/10/20/php-announces-critical-security-release-for-two-vulnerabilities [^8]: Ubuntu Security Notice USN-8948-1, 2026-10-21. https://ubuntu.com/security/notices/USN-8948-1 [^9]: Red Hat, RHSA-2026:87080. https://access.redhat.com/errata/RHSA-2026:87080 [^10]: cPanel, "EasyApache 4 Change Log"（25.91, 2026-10-21）. https://docs.cpanel.net/changelogs/easyapache-4-change-log-25 [^11]: Plesk, "Vulnerability CVE-2026-109618 and CVE-2026-109619 (PHP2Shell): Remote code execution in PHP shipped with Plesk", 2026-10-22更新. https://support.plesk.com/hc/en-us/articles/44397729587351-Vulnerability-CVE-2026-109618-and-CVE-2026-109619-PHP2Shell-Remote-code-execution-in-PHP-shipped-with-Plesk [^12]: CloudLinux, "PHP CVE-2026-109618, CVE-2026-109619 (PHP2Shell): fixed alt-php and ea-php packages and how to verify", 2026-10-22. https://cloudlinux.zendesk.com/hc/en-us/articles/31194180517916-PHP-CVE-2026-109618-CVE-2026-109619-PHP2Shell-fixed-alt-php-and-ea-php-packages-and-how-to-verify [^13]: TuxCare, "ELS PHP2Shell Patches FAQ". https://tuxcare.com/els-php2shell-patches-faq/ [^14]: Synology, "Synology-SA-26:14 PHP", 2026-10-22. https://www.synology.com/en-global/security/advisory/Synology_SA_26_14 （DSMについては同社の声明：https://www.synology.com/en-global/company/news/article/php2shell/Synology%20Statement%20on%20PHP2Shell%20Vulnerabilities ） [^15]: Docker Hub, "php" 公式イメージのタグ一覧. https://hub.docker.com/_/php/tags [^16]: Help Net Security, "What the PHP2Shell vulnerability means for Fortinet, Cisco and Palo Alto customers", 2026-10-22（報道。各社の一次情報は脚注45〜47）. https://www.helpnetsecurity.com/2026/10/22/php2shell-vulnerability-fortinet-cisco-palo-alto-networks/ [^17]: QNAP, "Security Notice: QNAP Statement on Critical PHP Vulnerabilities (PHP2Shell) - Security Advisory QSA-26-18", 2026-10-22. https://community.qnap.com/t/security-notice-qnap-statement-on-critical-php-vulnerabilities-php2shell-security-advisory-qsa-26-18/7293 [^18]: Sophos, "Sophos-SA-20261021-php2shell". https://www.sophos.com/en-us/security-advisories/sophos-sa-20261021-php2shell [^19]: SonicWall, "Product Notice: SonicWall Products and PHP Vulnerabilities (CVE-2026-109618 and CVE-2026-109619)", 2026-10-22. https://www.sonicwall.com/support/notices/product-notice-sonicwall-products-and-php-vulnerabilities-cve-2026-109618-and-cve-2026-109619/kA1VN000002YKw10AG [^20]: WatchGuard, WGSA-2026-0032, 2026-10-21. https://psirt.watchguard.com/WGSA-2026-0032/ [^21]: JPCERT/CC, 「PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起」（JPCERT-AT-2026-0033）, 2026-10-22. https://www.jpcert.or.jp/at/2026/at260033.html [^22]: NSA, "NSA Advisory: Critical Patches Recommended for PHP Vulnerabilities", 2026-10-21. https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/4630238/nsa-advisory-php-updates/ [^23]: NCSC (UK), "Critical security issue affecting PHP", 2026-10-21. https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php [^24]: IPA, 「PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619：PHP2shell)」, 2026-10-22. https://www.ipa.go.jp/security/security-alert/2026/alert20261022.html [^25]: The Register, "PHP2Shell puts dozens of UK government services out of service", 2026-10-22（報道。議事録の原文は未取得）. https://www.theregister.com/security/2026/10/22/php2shell-puts-dozens-of-uk-government-services-out-of-service/5304840 [^26]: ITV News, "More than 50,000 warnings sent to UK organisations over 'extremely serious' cybersecurity threat", 2026-10-22（報道。公開時の表題から変更されている）. https://www.itv.com/news/2026-10-22/more-than-30-government-services-offline-amid-global-php-cybersecurity-threat [^27]: piyolog, 「PHPの2件の深刻な脆弱性(CVE-2026-109618、CVE-2026-109619)についてまとめてみた」（二次情報。サービスの停止等を公表した組織の一覧を含む。各組織の一次発表は個別に未確認）. https://piyolog.hatenadiary.jp/entry/2026/10/21/174516 [^28]: zephel01（note）, 「PHP脆弱性で国内は何を止め、どう戻しているか。22日昼時点の整理」（二次情報）. https://note.com/zephel01/n/n308e32dbf49e [^29]: php/php-src, commit 3584a98 "Avoid state corruption via bailout", 2026-10-18. https://github.com/php/php-src/commit/3584a98bda0f2c0d367255b046798b0d3a221a19 [^30]: Mattias Geniar, "PHP's new memory_hard_limit_percent setting". https://ma.ttias.be/php-memory-hard-limit/ [^31]: php/php-src, Issue #24492, 2026-10-21. https://github.com/php/php-src/issues/24492 [^32]: php/php-src, Issue #24497. https://github.com/php/php-src/issues/24497 [^33]: The Register, "Hackers pile on PHP2Shell as AWS reveals attacks began before disclosure", 2026-10-22（報道）. https://www.theregister.com/cyber-crime/2026/10/22/hackers-pile-on-php2shell-as-aws-reveals-attacks-began-before-disclosure/5304749 [^34]: CloudLinux Blog, PHP CVE-2026-109618 and CVE-2026-109619. https://blog.cloudlinux.com/php-cve-2026-109618-and-cve-2026-109619 [^35]: The Repository, "PHP patches critical PHP2Shell vulnerabilities as hosts across the WordPress ecosystem race to protect customers"（報道）. https://www.therepository.email/php-patches-critical-php2shell-vulnerabilities-as-hosts-across-the-wordpress-ecosystem-race-to-protect-customers [^36]: Computer Weekly, "Botched PHP2Shell disclosure revealed as panic continues", 2026-10-22（報道。数値はInfrawatchの集計として引用されたもの。同社の追跡サイト https://php2shell-tracker.com/ は閲覧時点ごとに異なる値を表示する）. https://www.computerweekly.com/news/366652674/Botched-PHP2Shell-disclosure-revealed-as-panic-continues [^37]: Flare, PHP2Shellの露出状況に関するブログ記事, 2026-10-22. https://flare.io/learn/resources/blog/php2shell-exposure [^38]: php/php-src, commit f963484 "Fix GH-24488: GC double-frees the SimpleXMLElement properties table". https://github.com/php/php-src/commit/f9634847258a8c3ed6c12bb79104eba60bb631ea [^39]: lilting.ch, "PHP patched php2shell, then a page claimed RCE still survives on 8.5.12"（二次情報。主張の原文は未取得）. https://lilting.ch/en/articles/php2shell-post-patch-claims [^40]: dev.to（tanahiro2010）, 修正版でのセッションのアップロード進捗機能の挙動を検証した記事, 2026-10-22. https://dev.to/tanahiro2010/investigating-the-return-of-the-php2shell-nightmare-eee [^41]: The Hacker News, "PHP2Shell: What Actually Protects You Before the 14:00 UTC PHP RCE Patch, and What Doesn't", 2026-10-21（報道。修正版公開前に書かれた記事）. https://thehackernews.com/2026/10/php2shell-what-actually-protects-you.html [^42]: Sygnia, "PHP2Shell: Two Critical PHP Vulnerabilities Expose Web Servers to Remote Code Execution", 2026-10-22. https://www.sygnia.co/threat-reports-and-advisories/php2shell-two-critical-php-vulnerabilities-expose-web-servers-to-remote-code-execution/ [^43]: The PHP Foundation, "Today's PHP Security Release, and How We're Strengthening PHP Security", 2026-10-21. https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/ [^44]: Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 13(8)（サポート期間）; Annex I, Part II, point (1)（構成部品の特定とSBOMの作成）. https://eur-lex.europa.eu/eli/reg/2024/2847/oj [^45]: Palo Alto Networks, Security Advisory CVE-2026-109618, 2026-10-21. https://security.paloaltonetworks.com/CVE-2026-109618 [^46]: Fortinet PSIRT, FG-IR-26-186, 2026-10-21（2026-10-22更新）. https://fortiguard.fortinet.com/psirt/FG-IR-26-186 [^47]: Cisco, Security Advisory cisco-sa-php-october26-Jj384Daq, 2026-10-21（2026-10-22更新）. https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-php-october26-Jj384Daq [^48]: Cyber Safety Review Board, "Review of the December 2021 Log4j Event", 2022-07-11. https://www.cisa.gov/sites/default/files/publications/CSRB-Report-on-Log4-July-11-2022_508.pdf （内容は、CISAが公開する同報告書の要約版 "CSRB Review: December 2021 Log4j Event — Key Findings and Recommendations" で確認：https://www.cisa.gov/sites/default/files/publications/CSRB-Log4J-Key-Findings-and-Recommendations-Summary-508c.pdf ） [^49]: The Record, "First Cyber Safety Review Board report finds Log4j has become an 'endemic vulnerability'", 2022-07-14（報道）. https://therecord.media/first-cyber-safety-review-board-report-finds-log4j-has-become-an-endemic-vulnerability/ [^50]: 経済産業省, "METI Jointly Signs International Guidance on Minimum Elements for Software Bill of Materials (SBOM) for Cybersecurity with National Cybersecurity Office (NCO)", 2026-07-30（共著した14か国の一覧を記載。日本からは経済産業省とNCOが署名）. https://www.meti.go.jp/english/press/2026/07/20260730001.html （参考：Medcrypt, "CISA SBOM Minimum Elements: 2026 Update", 2026-07-29. https://www.medcrypt.com/blog/cisa-sbom-minimum-elements-2026-update ） [^51]: 国土交通省, 「「計画運休」、鉄道各社がタイムライン作成へ～鉄道の計画運休のあり方について最終とりまとめ～」, 2019-07-02. https://www.mlit.go.jp/report/press/tetsudo02_hh_000111.html [^52]: WebSec Center, PHP2Shellへの国内企業・組織の対応状況に関する記事（二次情報。札幌市の一次発表は未取得）. https://websec-center.com/blog/kokunai-kigyou-taiou/ [^53]: VulnCheck, "PHP2Shell Vulnerabilities: CVE-2026-109618 and CVE-2026-109619", 2026-10-21（2026-10-22更新）. https://www.vulncheck.com/blog/php2shell-vulnerabilities [^54]: The Register, "PHP2Shell exploit bypasses protections designed to stop remote code execution", 2026-10-22（報道）. https://www.theregister.com/security/2026/10/22/php2shell-exploit-bypasses-protections-designed-to-stop-remote-code-execution/5304883 [^55]: 北海道新聞, 「札幌市HPを一時停止 プログラミング言語「PHP」に欠陥、情報流出を予防」, 2026-10-21（報道）. https://www.hokkaido-np.co.jp/article/1394008/