Tesujititle: セキュリティホールはコードより「置きっぱなし」から生まれる ― PHPの穴が多く見える理由 outcome: 「PHPは穴が多い」という印象の背景を、利用の広さ・古い書き方の写し替え・共有サーバーでの放置という観点から整理し、言語選びより先に「保守する人と仕組み」を考える視点を持てる。 channelIds: ["security"] nodeIds: （未定。公開ノードから選ぶ。名前からIDを推測しない） alt_titles:
- 「誰でも置けて、置いたまま動き続ける」：PHPの穴が目立つ本当の理由
- 言語より保守：PHPのセキュリティを「放置」という視点から見直す
Webの世界には、「誰でも置けて、置いたまま動き続ける」ものがたくさんあります。そして、セキュリティホールの多くは、書かれた瞬間よりも、置かれたまま誰にも見られなくなったあとに生まれる――私たちはそう考えています。
「PHPはセキュリティホールが多い」という声は、今もよく聞きます。ここから書くのは私たちの感想ですが、その印象の大部分は言語そのものの性質というより、PHPがあまりに広く、長く、手軽に使われてきたことの裏返しなのではないでしょうか。広く使われたものほど、放置されたコピーも多く残る。この記事では、その構図を順に見ていきます。
1. 母数と年月：広く使われてきたことの重み
まず数字から。Webの技術利用状況を調査しているW3Techsによると、サーバー側のプログラミング言語が判明しているWebサイトのうち、69.2%がPHPを使っています（W3Techs、取得日：2026-10-29）。
同じページでは、PHPを使うサイトのバージョン内訳も示されています（同上、取得日：2026-10-29）。
- バージョン8：65.7%
- バージョン7：26.5%
- バージョン5：7.7%
- バージョン4：0.1%
一方、PHP公式の「Supported Versions」ページで現在サポート対象として載っているのは8.2・8.3・8.4・8.5の各系列だけです（php.net、取得日：2026-10-29）。つまり、W3Techsの集計でバージョン7以前に分類されるサイト（合計で約3分の1）は、公式のサポート一覧に載っていない系列で動いていることになります。ただし、Linuxディストリビューションやホスティング事業者が、独自に修正を提供している場合もあります。なお、W3Techsの数字は外部から推定した値で、バージョン8の中のどの系列かまではこの集計からは分かりません。
母数が大きく、歴史が長い。それだけで、「穴が見つかった」「被害が出た」というニュースの中にPHPという単語が登場する回数は自然と増えます。件数の多さが、そのまま言語の危うさを意味するわけではありません。
「件数」を比べる前に
「PHPはCVE（公開された脆弱性の識別番号）が多い」という話もよく見かけます。ただし、ここには2種類の穴が混ざりがちです。
- PHP本体（処理系）の穴：php-srcのアドバイザリなどで公表され、PHPのバージョンアップで直るもの
- PHPで書かれたアプリケーションの穴：CMS、プラグイン、管理ツールなど個々のソフトウェアの不具合で、そのソフトの更新で直るもの
後者は「PHPで書かれている」というだけで、PHPという言語の不具合ではありません。この2つを分けずに数えたり、数え方の違う他の言語の件数とそのまま並べたりすると、実態とかけ離れた印象になります。この記事では、数え方をそろえた比較の出典を確認できなかったため、件数の比較はしていません。
2. 写し替えて増える：古い書き方が生き残る仕組み
PHPは「調べればすぐ動くコードが見つかる」言語でした。ブログ記事、Q&Aサイト、入門書のサンプル。そこに書かれたコードをコピーし、少し直して使う。それ自体は多くの人が学ぶ自然な道筋です。
問題は、書かれた当時の書き方が、時代が変わってもそのまま写し替えられ続けることです。一般論として、例えばこんなパターンがあります。
- ユーザーの入力をそのまま文字列としてつなげて、SQL文を組み立てる（SQLインジェクションの典型的な原因）
- 入力値を画面に出すときにエスケープしない（XSSの原因）
- すでに非推奨・削除済みの関数を使ったサンプル
古い記事は検索結果に残り続け、コピーされたコードはさらに別の記事やプロジェクトに写されます。穴は「書いた人」ではなく、更新されないまま増殖したコピーから生まれていく。これも、放置の一つの形だと私たちは考えています。
3. 共有サーバー文化：FTPで上げたら終わり
PHPが広まった背景には、安価なレンタルサーバー（共有サーバー）の存在があります。ファイルをFTPでアップロードすれば、そのまま動く。この手軽さは、多くの人にWebで何かを公開する手段を与えました。
その一方で、「アップロードしたら完成」という感覚も生まれやすくなります。
- サーバーのPHPのバージョンが、契約したときのまま変わっていない
- CMS本体は更新しても、プラグインやテーマは何年も更新されていない
- 一時的に入れた管理ツールや、インストール用のフォルダが残ったまま
- 作った人が離れ、誰が管理しているのか分からないサイトが動き続けている
どれも、コードを書いた時点では問題がなかったかもしれません。それでも、時間がたち、新しい脆弱性が見つかり、修正版が出ても当てられない。放置された環境は、そうやって少しずつ穴だらけになっていきます。
4. 今日の話題とのつながり：修正があっても、当たっていなければ狙われる
最近のニュースも、この構図をよく表しています。
PHP2Shell（CVE-2026-109618・CVE-2026-109619）：PHP本体の脆弱性で、10月21日（UTC）に修正版（8.5.12、8.4.27、8.3.36、8.2.35）が公表されました。米CISAは10月26日にこの2件を「既知の悪用された脆弱性（KEV）」カタログに追加しています。さらに10月28日（米国時間）には、5月に修正版が出ていたLinuxカーネルの脆弱性Fragnesia（CVE-2026-46300）もKEVに追加され、その説明にはPHP2Shellと連鎖させてroot権限でコマンドを実行できる旨が書かれています（CISA KEV（CVE-2026-109618）、CISA KEV（CVE-2026-109619）、CISA KEV（CVE-2026-46300）、NVD CVE-2026-109618、NVD CVE-2026-109619、確認日：2026-10-29）。カーネル側の修正は5か月前に出ていました。FragnesiaとPHP2Shellの連鎖については、Tesujiの記事「Fragnesia」でも詳しく書いています。
phpMyAdminの件：10月27日（UTC）以降、研究者のabraxas氏がX上で、phpMyAdmin 5.2.3の2FA（WebAuthn）に関する未修正だとする問題や、追加の複数の問題を公表しました。これはabraxas氏の主張で、2026年10月29日時点で、phpMyAdmin公式のセキュリティ情報ページに今回の件の公式発表やCVE番号は確認できていません（phpMyAdminセキュリティ情報）。主張された問題の多くは「ログイン画面が外から届く」「初期設定用のsetupフォルダが残っている」といった条件付きです。最新の状況は公式情報で確認することをおすすめします。この件の詳しい整理は、Tesujiの記事「phpMyAdmin 5.2.3の未修正報告から考える」にまとめています。
PHP本体の穴と、PHPで書かれた管理ツールの穴。種類は違いますが、どちらも「修正や対策の手段はあるのに、置かれたままの環境」が狙われるという点で共通しています。
5. 今のPHPは別物：言語側は変わってきた
「PHP＝危ない」というイメージの多くは、昔の書き方や古いバージョンの記憶に根ざしているように感じます。今のPHPと、その周りの道具はかなり変わっています。
サポートの仕組みがはっきりしている：PHPの各系列は、最初の安定版から2年間は通常のバグとセキュリティの修正、その後の2年間は重大なセキュリティ問題の修正だけが提供され、計4年でサポート終了（EOL）になります（php.net、取得日：2026-10-29）。同ページによると、セキュリティサポートの期限は次のとおりです。
| 系列 | 初回リリース | セキュリティサポート期限 |
|---|---|---|
| 8.2 | 2022年12月8日 | 2026年12月31日 |
| 8.3 | 2023年11月23日 | 2027年12月31日 |
| 8.4 | 2024年11月21日 | 2028年12月31日 |
| 8.5 | 2025年11月20日 | 2029年12月31日 |
8.2系は、あと2か月ほどでセキュリティサポートが終わります。期限は公式ページで確認し、計画的に移行することをおすすめします。
プリペアドステートメント：SQLを文字列連結で組み立てるのではなく、PDOなどのプリペアドステートメント（プレースホルダに値を渡す方式）を使うことが、今では標準的な書き方です。2章で触れたSQLインジェクションの典型的な原因を、書き方の段階で避けやすくなります。
Composerによる依存関係の管理：ライブラリをComposerで管理すれば、どのライブラリのどのバージョンを使っているかが記録され、更新もしやすくなります。「どこかから落としてきたファイルが置いてある」状態から抜け出す第一歩です。
フレームワークの標準対策：主要なPHPフレームワークの多くは、テンプレートでの自動エスケープ、CSRF対策、データベース操作の抽象化などを標準で備えています。書く人が毎回意識しなくても、基本的な対策が効く作りになっています。ただし、設定や書き方によっては効かないこともあります。
言語と道具は、すでに「安全に書きやすい」方向へ進んでいます。残る課題は、それを使い続け、更新し続ける人と仕組みがあるかどうかです。
6. 結論：言語を選ぶより、保守する人がいるかどうか
どんな言語で書かれていても、誰も更新しなくなったシステムは、時間とともに穴が増えていきます。PHPが目立つのは、それだけ多くの場所に置かれ、長く動き続けてきたからだ――というのが、この記事を通しての私たちの見方です。
だからこそ、新しく何かを作るときも、今あるサイトを見直すときも、「どの言語にするか」の前に、次のことを考えるのをおすすめします。
- 誰が保守するのかを決める：作った人がいなくなっても、更新を引き継げる人や体制があるか。
- 何が動いているかを把握する：PHPのバージョン、CMSやプラグイン、管理ツール、残っているインストール用フォルダなどを一覧にしておく。
- サポート期限をカレンダーに入れる：php.netの期限を目安に、移行の時期を前もって決めておく。
- 使っていないものは置かない：不要になったツールやコピーは削除し、管理画面は外から届かない状態にする。
- 公式のセキュリティ情報やKEVをときどき見る：「いま悪用されているか」を優先順位の手がかりにする。
セキュリティホールは、書いた瞬間よりも、置きっぱなしにした時間の中で育ちます。言語の評判より、「この先も誰かが面倒を見られるか」を先に考える。それが、どの言語を選ぶ場合にも役立つ視点だと思います。
ここに書いたのは一般的な考え方で、すべての環境での安全を保証するものではありません。実際の対応は、PHPやお使いのソフトウェア・サーバーの最新の公式情報を確認したうえで判断してください。
参考資料
- W3Techs：Usage statistics of PHP for websites https://w3techs.com/technologies/details/pl-php （取得日：2026-10-29）
- PHP：Supported Versions https://www.php.net/supported-versions.php （取得日：2026-10-29）
- CISA：Known Exploited Vulnerabilities Catalog（CVE-2026-46300） https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-46300 （確認日：2026-10-29）
- CISA：KEV Catalog（CVE-2026-109618、追加日 2026-10-26） https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-109618 （確認日：2026-10-29）
- CISA：KEV Catalog（CVE-2026-109619、追加日 2026-10-26） https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-109619 （確認日：2026-10-29）
- NVD：CVE-2026-109618 https://nvd.nist.gov/vuln/detail/CVE-2026-109618 （確認日：2026-10-29）
- NVD：CVE-2026-109619 https://nvd.nist.gov/vuln/detail/CVE-2026-109619 （確認日：2026-10-29）
- NVD：CVE-2026-46300 https://nvd.nist.gov/vuln/detail/CVE-2026-46300 （確認日：2026-10-29）
- phpMyAdmin：Security https://www.phpmyadmin.net/security/ （確認日：2026-10-29）