注記：この記事の内容は、ブログのサンプルとしてAIに生成させた「詰め物」の文章です。 運営者の意見を表明するものではありません。

PHP2Shellの騒動の中で、古い環境で動いていたサービスが終了を決めた、という報道を見た。 それを受けて、「何年も前にサポートが終了しているPHPを使い続けるのは、業界のプロとしてどうなのか」という素朴な意見も耳にした。 サポート切れを放置してよいと言いたいわけではない。 ただ、騒動全体に「パッチは適用しなければならない」という前提だけが強く流れていて、私にはそれが根拠のない強迫観念のように見えた。

報道された終了の事例

PHP2Shellは、2026年10月21日に公表されたPHPの2件の脆弱性（CVE-2026-109618、CVE-2026-109619）の通称である。 認証なしでリモートからコードを実行できる可能性があり、PHPのアドバイザリは、Webリクエストを受けるすべてのPHPが対象になると述べている1。

国内では、長年運営されてきたゲーム2作品がサービス終了を発表した。 一方は「古い仕組みの上で動作しているため十分な対策を取れず」という趣旨で、もう一方は「深刻なPHPの脆弱性に対する対応が困難となったため」という趣旨で説明されている。 ただし、私が確認できた報道には、どちらもPHPのバージョンは書かれていない2。 「PHP 7系以前だった」という話は、私の確認の範囲では裏付けが取れていない。

サポート切れの環境は珍しくなく、事情は外から見えない

サポートが終わった基盤を使い続けるのは、望ましいことではない。 PHP 7.4のサポートは2022年11月28日に終わっていて、7.3以前はそれより前に終わっている3。 私が見た別の事例には、2020年にサポートが終了したPython 2.7系を使い続けている大きなサービスがある4。

こうした例は、探せばいくらでも見つかる。 Webサイトの統計では、PHPを使うサイトのうちPHP 7が26.8%、PHP 5が7.7%で、合わせて3分の1ほどが、サポートの終わった系列で動いている5。 PHP 8の中にも、更新を受け取れない8.1以前の版が含まれるはずなので、実際の割合はこれより高いと考えられる。 今回PHPのセキュリティチームは、7.4、8.0、8.1向けに、最新の修正を古い版へ移した最小限のパッチ（バックポート）を公開した。 ソースからビルドする人向けの措置で、7.3以前には修正が出ていない6。

それでも、使い続けている側に、更新できない事情がある場合もある。 更新の費用、動作検証、依存するライブラリの対応状況は、外から見えない。 「プロとしてどうか」という問いは、その費用を払わずに済む立場から出やすいと感じる。

対策は被害の防止ではなく緩和である

サイバーセキュリティの入門的な講習を2時間ほど受けると、「すべての対策は被害の防止ではなく、緩和である」と教わる。 対策にはコストがかかり、どこまで払うかはトレードオフになる。 国家レベルの組織に狙われれば、いくら費用をかけても被害をゼロにはできない。 パッチが存在する前に突かれるゼロデイ攻撃もある。

この見方に立つと、「パッチを適用するか、しないか」の間に、いくつもの中間の選択肢が見えてくる。 パッチは強力な緩和策の一つだが、唯一の緩和策ではない。 適用できないときに、何で埋め合わせて、どの被害を受け入れるのかを決めるのが、本来のリスク管理だと思う。

PHP公式も緩和策を示している

PHPのアドバイザリには、まさにその「更新できないとき」の項目がある。 memory_limit=-1 を管理者側で固定する、post_max_size を小さく設定する、session.upload_progress.enabled=0 にする、といった設定が挙げられている7。

ただし、同じアドバイザリは、これらが「特定の攻撃経路への露出を減らすだけで、環境を安全にするものではない」と明記している。 完全な対策とされているのは、この2件に対する修正版への更新である。 同じ機能の周辺に未知の問題が残らないことまでは、アドバイザリも述べていない。

つまり、「PHPのコアチームですら緩和策を示している」は事実だが、「だから更新しなくてよい」は公式の立場と違う。 この点は、自分の主張の側でも取り違えないようにしたい。

最新版なら脆弱性が少ない、という前提

「古い版は危ない、最新版にすれば安心だ」という前提も、疑ってみたい。

今回の脆弱性は、サポート切れの版だけの問題ではなかった。 8.2から8.5までの各系列でも、8.5.12より前、8.4.27より前といった版は影響を受けていて、最新の系列である8.5系も例外ではなかった8。

もう少し一般的な話をすると、ソフトウェアの脆弱性は、新しい版で新しく混入したものばかりではない。 OpenBSDを7年半、15版にわたって調べた研究では、報告された脆弱性の62%が、調査の開始時点ですでに存在していたコードに由来していた9。 こうしたコードは版が上がっても引き継がれるので、新しい版に移っても、古い版に潜んでいた問題がまとめて消えるとは限らない。

ただし、新しい版のほうが脆弱性が多いとは、この研究からは言えない。 新しい版には、既知の問題の修正が入っている。 言えるのは、版の新しさだけでは、脆弱性の少なさを保証できない、ということである。

脆弱性の発見と悪用は、速くなったのか

「見つかった脆弱性を直すほど、ソフトウェアは安全になっていく」という見方は、発見と修正にある程度の時間がかかることを前提にしている。 その前提が、AIの高度化で崩れつつあるのではないか。 数値を確かめると、猶予が縮む兆候はあったが、AIが原因だと言える材料は見つからなかった。

Mandiantの報告では、脆弱性が公表されてから悪用されるまでの平均日数が、2018年の63日から、2024年に-1日、2025年に-7日（推定）と縮んでいる。 マイナスは、平均して、パッチが出る前に悪用が始まっていることを意味する10。 一方、VulnCheckの2026年上半期の集計では、CVEの公表から悪用済み脆弱性カタログ（KEV）への追加までの中央値は、2025年の120日から80日に縮んだ。 公表日以前に悪用の証拠があった割合は、28.93%から23.43%へ、わずかに下がっている11。

この2つは、平均と中央値、悪用の開始とカタログへの掲載のように、測っているものが違う。 縮む方向は同じでも、「公表前に悪用が始まる」と「公表後80日」は、そのまま並べられない。 どちらにも、AIの影響を切り分けたデータはない。

AIが見つけた脆弱性が悪用されやすいのかも、決め手がない。 VulnCheckの同じ集計では、AI支援で発見されたとされる脆弱性1,061件のうち、悪用が確認されたのは14件（1.3%）で、全体の悪用率とほぼ同じ水準だった12。 件数が少なく、「AI支援」と判定する基準も説明されていないので、早期の観察にとどまる。

整理すると、猶予が縮む兆候はあるが、それが変曲点なのか、AIによるものなのかは、手元の数値では判断できない。 猶予が縮むのが本当なら、更新の優先度は上がる。 同時に、更新が間に合わない環境で何で埋めるかを、事前に決めておく必要が増す。

問いたいのは、当てないときの埋め方

この脆弱性は、実際に重い。 ApacheにPHPを組み込む方式（mod_php）では、アプリケーションのコードが動く前に、認証なしの1リクエストで攻撃が成り立つ実証が公式から示されている。 セキュリティ企業が置いた囮のサーバー（ハニーポット）では、公表直後から悪用が観測されたとも報告されている13。 更新の優先度を上げるべきだという判断は妥当である。

それでも違和感が残るのは、判断の中身が見えないからだ。 更新できないものを止める、サポート切れのバージョンを上げる、上げられなければ終了する。 それぞれが検討の結果なら、立派な判断である。 サービスの終了も、攻撃面を丸ごと消す、一つの緩和策と言える。 ただ、報道の論調からは、費用、露出、代替策を比べた形跡が読み取れず、「適用しないのは怠慢だ」という物言いだけが目立つ。 私には、そこに緩和という考え方が抜け落ちているように見える。

私が問いたいのは、パッチを当てるかどうかではない。 最新版にすれば安心とも、サポート切れは怠慢だとも言い切れないなかで、当てないと決めたとき、あるいは当てられないときに、何で埋めて、何を受け入れるのかを、決めているかどうかである。

Footnotes

  1. PHPのセキュリティアドバイザリ（2026-10-21）によると、CVE-2026-109618はメモリ不足の処理がリクエストの内部データを中途半端に初期化した状態で中断させ、後片付けがその無効なデータを有効とみなす問題である。リスクが最も高いのはmod_phpで、アプリケーションのコードより前に、認証なしのリクエストで攻撃が成り立つ実証があるとされる。修正版は8.5.12、8.4.27、8.3.36、8.2.35。PHP.net, “Security advisory: Critical remote code execution vulnerabilities, update now”、GitHub Security Advisory, GHSA-w8hw-w9fx-j79w ↩

  2. Game Sparkの報道（2026-10-22）による。『ワールドクエスト』が10月21日付、『僕の魔界を救って！』が10月22日付で終了を発表した。いずれも記事は公式告知の要約で、PHPのバージョンや具体的な構成には触れていない。公式告知そのもの（原文）は確認していない。Game Spark, “「PHP」重大脆弱性問題で長年運営ゲーム2作品が相次いでサービス終了…” ↩

  3. PHP 7.4は2022年11月28日（最終リリース7.4.33）、7.3は2021年12月6日、7.2は2020年11月30日にサポートが終了している。PHP.net, “Unsupported Branches” ↩

  4. Python 2は2020年1月1日にサンセットし、以降は新しいバグ報告や修正が行われない。最後のリリースである2.7.18は、1月1日までの修正をまとめて2020年4月に公開された。ここで触れた「Python 2.7系を使い続けている大きなサービス」は、私が見聞きした事例であり、具体名は挙げず、公開情報での裏付けも取っていない。Python.org, “Sunsetting Python 2” ↩

  5. W3Techsの集計（2026-10-24時点）で、サーバーサイド言語がPHPと判別できたサイトのうち、PHP 8が65.4%、PHP 7が26.8%、PHP 5が7.7%、PHP 4が0.1%。サイトを数えた統計であり、実際に稼働している環境やサーバーの数ではない。ページに調査対象の範囲の記載は見当たらなかった。また、PHP 7.4など個別の版の割合は同ページに載っておらず、PHP 8の内訳（8.1以前を含む）は確認していない。「PHP 8.1以前はPHPプロジェクトから更新を受け取れない」という記述はPHPのアドバイザリによる。W3Techs, “Historical trends in the usage statistics of PHP versions”、PHP.net, 同上 ↩

  6. 「PHP 8.1以前はPHPプロジェクトから更新を受け取れない」とアドバイザリは述べ、ディストリビューションやLTSベンダーのバックポート、またはサポート中のバージョンへの更新を案内している。7.4、8.0、8.1にはセキュリティチームが最小限のソースバックポートを公開した。7.3以前（PHP 5を含む）に修正が出ていないという点は、解説記事（watchTowr）の整理に基づく。PHP.net, 同上、watchTowr, “PHP2Shell FAQ” ↩

  7. アドバイザリは、この2件について「更新が完全な解決策であるのに対し、以下の措置は特定の攻撃経路への露出を減らすが、環境を安全にするものではない」という趣旨で、更新できない場合の措置を示している。CVE-2026-109618向けには、memory_limit=-1 を、アプリケーションから上書きされない形で設定すること、post_max_size を小さくすること（ファイルアップロードが不要なら8M、必要なら32M）、コンテナやcgroupの制限を可用性の境界として使うことが挙げられている。RLIMIT_AS と RLIMIT_DATA は、脆弱な経路を引き起こすため使わないよう注意されている。CVE-2026-109619向けには session.upload_progress.enabled=0 で、確認済みの経路を塞げるが、他の変種は塞げないとされる。PHP.net, 同上、GitHub Security Advisory, GHSA-w8hw-w9fx-j79w ↩

  8. PHPのアドバイザリが示す影響範囲は、8.2.35より前、8.3.36より前、8.4.27より前、8.5.12より前である（GHSA-w8hw-w9fx-j79w）。最新の系列である8.5系の、8.5.11以前も含まれる。GitHub Security Advisory, GHSA-w8hw-w9fx-j79w ↩

  9. Ozment and Schechter, “Milk or Wine: Does Software Security Improve with Age?”（USENIX Security 2006）。OpenBSDの15版、7.5年を対象に、報告された脆弱性の62%が調査開始時点で存在していた「基盤となる」コードに由来し、その報告率は減少傾向にあるが、基盤的な脆弱性の寿命の中央値は2.6年以上だったとされる。20年前の研究であり、対象もOpenBSD 1つなので、PHPや現在のソフトウェアにそのまま当てはまるとは限らない。USENIX Security 2006, “Milk or Wine” ↩

  10. Google Threat Intelligence Group（Mandiant）のM-Trends 2026による。平均の悪用までの日数（TTE）は2018年が63日、2024年が-1日、2025年が-7日（推定）。算出方法の詳細は、参照した報道に記載がない。M-Trends 2026の本文は直接確認しておらず、報道を経由している。Help Net Security, “Attackers are handing off access in 22 seconds, Mandiant finds” ↩

  11. VulnCheck, “State of Exploitation 1H 2026”による。2026年上半期に追加された495件のKEVが母数で、CVE公表からKEV追加までの中央値は、2025年の120日から80日に縮んだ。公表日以前に悪用の証拠があった割合は、2025年の28.93%から23.43%へ下がった。KEVへの追加日は、攻撃者が最初に悪用した日とは限らない。VulnCheck, “State of Exploitation 1H 2026” ↩

  12. 同じVulnCheckの集計で、AI支援による発見に帰属された脆弱性1,061件のうち、悪用が確認されたのは14件（1.3%）。データは、AnthropicのProject Glasswing経由の報告と、Berkeley Vulnerability Research Initiativeのテレメトリを統合したもの。この割合は、同期間の全脆弱性の悪用率とほぼ一致すると報じられている。ここでの「AI支援」の判定基準は、参照した記事に説明がなく、VulnCheckのレポート本体は直接確認していない。Infosecurity Magazine, “Just 1% of AI-Discovered Vulnerabilities Exploited in the Wild, Research Shows” ↩

  13. 悪用の観測は、watchTowrのハニーポットによる報告（2026-10-21以降）で、2026-10-22時点ではCISAのKnown Exploited Vulnerabilitiesカタログには掲載されていなかった。報告者側の発表であり、独立した確認は取っていない。watchTowr, “PHP2Shell FAQ” ↩