PHPは本当に脆弱性が多いのか：言語別の脆弱性発見数と普及率の相関から、差の正体を探る

「PHPは脆弱性が多い言語だ」という話は、技術選定の場で何度も耳にします。しかし脆弱性の「発見数」は、その言語で書かれたコードが世の中に多いほど、また探している人が多いほど膨らみます。発見数の多さがそのまま「言語として危ない」ことを意味するのか。普及率との相関を取り、相関で説明できない「残差」がどこに残るのか、そして件数ではなく重大度や処理系そのものに目を移すと何が変わるのかを、公開データで確かめました。

本記事の数値は、2026年10月28日時点で公開されているデータを集めたものです。脆弱性データベースの件数は毎日増えるため、絶対値ではなく、順位・比率・相関の形に注目して読んでください。集計の方法は末尾にまとめています。

1. 「言語別の脆弱性数」に公式統計はない

まず押さえておきたいのは、CVE（共通脆弱性識別子）には「言語」という欄がないことです。2025年に公開された CVE は約4.8万件で過去最多でしたが、これを言語で割り振った公式統計は存在しません。言語別に語るには何らかの代理指標を選ぶ必要があり、その選び方で結論が変わります。

Mend（旧 WhiteSource）が自社データベースで過去10年のオープンソース脆弱性を集計したところ、C が全体の50%超を占め、PHP は7言語中2位でした。2019年公開の内訳では、C が47%、PHP が17%、Java が11%、JavaScript が10%、Python・C++ が5%、Ruby が4%です。C が突出するのは、OS・ブラウザ・ランタイムといった巨大で歴史の長いプロジェクトがほぼ C で書かれているからで、PHP 本体（インタプリタ）の脆弱性も C のメモリ安全性の問題として数えられています。「PHPの脆弱性」と「PHPで書かれたアプリの脆弱性」は、この時点ですでに別物です。この記事では前者を第4節で、後者をそれ以外の節で扱います。

言語別に最も素直に比べられるのは、パッケージレジストリ単位の脆弱性情報です。GitHub Advisory Database のレビュー済みアドバイザリ（GitHub のスタッフが内容と影響範囲を確認したもの）を、公開リポジトリから直接数えてエコシステム別に並べたのが図1です。

累計では npm（JavaScript）が7,992件で最多、Maven（Java）、pip（Python）、Composer（PHP）が6,500〜7,200件で続きます。この見方では PHP は4位です。ただし2025年の1年分だけを切り出すと、GitHub の公表値では Maven 22.2%、Composer 19.4%、Go 17.3%、pip 17.2%、npm 14.9% の順になります。Go が全期間の構成比（10.9%）より6ポイント高いのは、GitHub が Go パッケージの取りこぼしを掘り起こすキャンペーンを行ったためだと説明されており、数え方を変えなくても「誰がどこを集中的に見直したか」で1年分の順位は動きます。

2. 普及率との相関を取る

2.1 なぜ「割り算」ではなく「相関」か

発見数は分母が大きいほど増えます。よくある手は件数を普及率で割って「1パッケージあたり」「開発者1%あたり」を出すことですが、これは「件数は普及率に正比例する」と決め打ちした分析です。両対数で回帰すれば、正比例するかどうか（傾きが1かどうか）をデータに答えさせることができます。

回帰直線は「普及率がこれだけなら、件数はだいたいこれくらい」という予測です。実際の件数がその予測から外れている分を残差と呼び、この記事では「予測の何倍か」という倍率で示します。残差が大きいほど、普及率では説明がつかない要因が大きいことになります。

2.2 登録パッケージ数との相関

図2は、図1の件数を、ecosyste.ms が集計する各レジストリの登録パッケージ数（npm 約602万、Go 約254万、pip 約95万、NuGet 約87万、Maven 約74万、Composer 約53万、crates.io 約37万、RubyGems 約21万）に対して両対数でプロットしたものです。

回帰直線の傾きは0.48で、1を大きく下回ります。パッケージ数が10倍になっても、アドバイザリは約3倍にしか増えません。npm の600万パッケージの大半は小さなユーティリティで、1パッケージあたりの脆弱性の「密度」は規模とともに薄まる、と読めます。決定係数は0.36で、パッケージ数で説明できるのは件数のばらつきの3分の1程度です。

残りが残差です。Composer（PHP）は回帰直線の2.4倍、Maven（Java）は2.2倍、pip（Python）は1.8倍の位置にあり、NuGet（C#）は0.3倍、RubyGems は0.6倍にとどまります。

2.3 開発者利用率との相関

図3は、分母を Stack Overflow Developer Survey 2025（回答者31,771人）の「この1年で使った言語」の割合に替えたものです。利用率は JavaScript 66.0%、Python 57.9%、Java 29.4%、C# 27.8%、PHP 18.9%、Go 16.4%、Rust 14.8%、Ruby 6.4% です。

傾きは0.73、決定係数は0.42で、パッケージ数より当てはまりがわずかに良くなります。ここでも Composer（PHP）が回帰直線の2.1倍で最も上にあり、Go が1.8倍、Maven（Java）が1.7倍で続きます。npm と pip はほぼ直線上（1.0倍）、NuGet は0.3倍です。

2.4 2つの分母で残差を重ねる

結論の前半はこうなります。普及率との相関を取り除いても、PHP（Composer）は2つの分母の両方で最も大きな残差を残します。 「普及しているから多く見えるだけ」では説明できません。ただし PHP だけが突出しているわけではなく、Java（Maven）が常にすぐ隣にいます。逆に、素の件数で最多だった JavaScript は、どちらの分母でも「普及率どおり」の位置に収まります。

点が8つしかないため、ここでの相関は統計的な検定ではなく、記述的な目安として読んでください。分母が違えば倍率も動きます（Go はその典型です）。それでも、2つの独立した分母で同じ2つのエコシステムが上に残ることは、偶然とは考えにくい結果です。

2.5 重大度を評価軸に加える

ここまでは1件を1件として数えてきました。しかし XSS と任意コード実行では意味がまるで違います。GitHub Advisory Database はアドバイザリごとに Critical / High / Moderate / Low の4段階の重大度（CVSS に基づく）を付けているので、その内訳を図6に示します。

Composer（PHP）は Critical が10.0%、Critical と High を合わせて38.9%で、8エコシステム中もっとも低い比率です。npm は Critical が18.3%で最も高く、Maven と crates.io が13.3%、pip が12.4%で続きます。PHP の件数の3割を占める XSS は多くが Moderate に分類されるため、件数が多いわりに重大なものの比率は低い、という構図です。

Critical の件数だけを取り出して、第2.2節・第2.3節と同じ回帰をやり直すと、順位が入れ替わります。

Critical に絞ると、パッケージ数に対する残差は Maven（Java）が2.6倍で最上位になり、PHP は2.1倍で2位に下がります。利用率に対しては Maven、PHP、Go が1.9倍で並びます。npm は2020年だけで549件の Critical が付いた年があり（当時の npm 由来のアドバイザリに高い CVSS が付きやすかった影響です）、全件では普及率どおりだった位置が Critical では少し上に動きます。

つまり「PHP は脆弱性が多い」は、件数で見れば正しく、重大なものに限れば Java と並ぶか下回る、という二段構えで読むのが正確です。PHP の残差は「数は多いが軽いものが多い」、Java の残差は「数はやや少ないが重いものが多い」という性格の違いがあります。 リスクを件数ではなく「重大度 × 件数」で見るなら、PHP だけを特別視する根拠は弱くなります。

3. 時系列で見る：利用率が下がっても、件数は増える

横断の比較には「古いエコシステムほど累計が多い」という偏りが残ります。そこで各エコシステムについて、年ごとのアドバイザリ件数（CVE 番号の年で集計）と、Stack Overflow 調査の各年の利用率を、2017年を100として重ねたのが図4です。

PHP の利用率は2017年の28.1%から2025年の18.9%へ3分の2に下がりましたが、アドバイザリ件数は214件から561件（2024年は989件）へ2.6倍に増えました。両者の相関係数は −0.89 で、強い「逆相関」です。Java も同様で、利用率は下がり続け、件数は増え続けています（r = −0.66）。一方、Python と Go は利用率も件数も増えていて、正の相関です（r = 0.89、0.95）。

4つの言語に共通しているのは、利用率がどちらに動いても件数は増えていることです。利用率が件数を決めているなら PHP と Java の件数は減っていたはずで、そうなっていない以上、件数を動かしている主因は普及率とは別のところにあります。候補は、既存コードの蓄積、報告する側の活動量、そして脆弱性を探す道具の進歩です。

その傍証として、2026年は10月末時点ですでに、集計した8つのエコシステムすべてで年間件数が過去最多を更新しています（npm 3,535件、pip 2,439件、Go 2,163件、Composer 1,432件、Maven 943件）。Critical だけ見ても同じで、npm 404件、pip 273件、Go 267件はいずれも過去最多です。この1年で開発者の利用率がどの言語でも2倍になったわけではなく、GitHub の再レビュー作業や、AI を使った脆弱性探索の広がりなど、報告する側の変化が大きいと見るのが自然です。原因の切り分けは別の分析が必要ですが、「件数は報告する側の活動量を強く反映する」という点は、この年次推移からも裏づけられます。

4. 言語そのものの脆弱性：処理系の CVE

ここまでの数字はすべて「その言語で書かれたライブラリ」の脆弱性です。「言語自体が脆弱か」という問いに答えるには、処理系（インタプリタ、コンパイラ、標準ライブラリ、ランタイム）そのものの CVE を見る必要があります。NVD（米国の脆弱性データベース）で製品が各処理系に紐づく CVE を取り出したのが次の表です。

累計では PHP が760件で、Java の833件と並んで突出しています。Python の5倍、Node.js の4倍です。ただし、これは歴史の長さを反映した数字でもあります。図7に PHP 本体の CVE を年別に示します。

PHP 本体の CVE は2007年（114件）と2016年（120件）に大きな山があります。2007年は研究者が1か月に集中して PHP の脆弱性を公開した「Month of PHP Bugs」の年で、2016年はファジング（自動入力生成によるテスト）が普及し、unserialize や画像処理など C で書かれたパーサの境界外読み書きがまとめて見つかった年です。一方、PHP 7 以降の2021〜2023年は年7〜8件で、同じ期間の Node.js（18件）、Go（28件）、Java（26件）、.NET（21件）を下回ります。処理系そのものに限れば、近年の PHP は「脆弱性が多い言語」ではなく、むしろ少ない部類です。

重大度の分布は逆です。PHP 本体の CVE は Critical が17.6%で、100件以上ある処理系の中では最も高く、弱点の分類も境界外書き込み（CWE-119）と境界外読み取り（CWE-125）が上位を占めます。PHP 本体は C で書かれているため、見つかる脆弱性はメモリ安全性の問題で、1件あたりの重さはライブラリの XSS よりはるかに重い、ということです。Java と .NET の Critical の割合が5%以下なのは、ランタイムがメモリ安全な言語で書かれた部分が多いことと、四半期ごとの定例パッチで中低レベルの CVE が大量に発行される運用の両方が効いています。

この表には読み方の注意が3つあります。第一に、NVD の製品紐づけ（CPE）は2024年以降、NVD 側の処理の遅れで付与が追いついておらず、2024年以降の件数はどの処理系も過小です。そのため年平均は2021〜2023年で取りました。第二に、Java の833件には Oracle の定例パッチで発行される大量の低重大度 CVE が含まれ、Rust の24件はコンパイラと標準ライブラリに限った数字です（Rust ではメモリ安全性の問題の多くが crates 側で報告されます）。第三に、処理系の CVE は「その言語で書かれたコード」ではなく「その言語を動かす C/C++ のコード」の脆弱性であり、第1節で触れた「PHPの脆弱性」と「PHPで書かれたアプリの脆弱性」の違いそのものです。

5. WordPress という、もう一つの分母

図1〜4は Composer（Packagist）に登録されたライブラリの話です。しかし PHP の脆弱性が実際に報道される場面の大半は WordPress のプラグインとテーマであり、これらは Packagist にも GitHub Advisory Database にもほとんど載っていません。

W3Techs の調査では、サーバーサイド言語が判明しているウェブサイトの約70%が PHP で動き、WordPress は全ウェブサイトの39.5%、CMS が判明しているサイトの58.3%を占めます（2026年10月28日時点）。つまり「世の中の PHP サイト」の過半は WordPress です。

WordPress のセキュリティ企業 Patchstack の年次レポートによると、2025年に WordPress エコシステムで新たに報告された脆弱性は11,334件で、前年の7,966件から42%増えました。内訳は91%がプラグイン、9%がテーマで、WordPress 本体は6件（いずれも低リスク）です。公開時点で開発者側の修正が存在しなかった脆弱性は46%にのぼります。

これを図2と同じ土俵に載せたのが図5です。2025年の1年間に報告された脆弱性を、登録数1,000件あたりで比べています（WordPress は公式ディレクトリの約76,000プラグインを分母にしました）。

Composer は1,000パッケージあたり1.07件、Maven は0.93件、npm は0.11件です。WordPress プラグインは135.7件で、Composer の約127倍、npm の1,000倍を超えます。横軸を対数にしないと他のエコシステムが見えなくなる差です。

種類も Composer とは違います。Patchstack の2025年上半期の集計では、XSS が34.7%、CSRF が19.0%、ローカルファイルインクルージョンが12.6%、アクセス制御の不備が10.9%、SQL インジェクションが7.2%で、上位5つで約85%を占めます。57.6%は認証なしで悪用でき、20.6%は投稿者権限で悪用できます。重大度では、Patchstack が「大規模な自動攻撃に使われる可能性が高い」と判定した High が2025年の全体の17%でした。CSRF とアクセス制御の不備が上位に入るのは、WordPress 特有の権限モデルとフックの仕組みの上で、権限確認を書き忘れた拡張が多いことを示しています。

「PHPは脆弱性が多い」という印象の大部分は、言語でも WordPress 本体でもなく、この一つの巨大なプラグイン経済から来ていると見るのが自然です。図2・図3で見た Composer の残差（2倍強）と、WordPress プラグインの100倍超という差は、同じ言語の上で「どういう作り手が、どういう仕組みで」書いているかの差です。

6. 残差を説明する4つの要因

ここまでのデータから、普及率で説明できない差を生む要因を4つに整理します。

6.1 脆弱性の「種類」が言語ごとに違う

GitHub Advisory Database のアドバイザリに付いた弱点分類（CWE）を、今回の集計から並べます。

PHP では XSS が3割を占め、これは他のどのエコシステムより高い比率です。XSS と SQL インジェクションは MITRE の「2025年 最も危険なソフトウェア弱点トップ25」でも1位と2位であり、PHP の脆弱性は「古典的なウェブの弱点」に強く偏っています。第2.5節で見た「PHP は Critical の比率が最も低い」という結果は、この XSS の多さの裏返しです。

これは言語の設計と無関係ではありません。PHP はもともと HTML の中にコードを埋め込む言語として生まれ、echo で変数をそのまま出力できます。出力時のエスケープを開発者の規律に委ねる構造では、書く人が増えるほど XSS も増えます。一方、Laravel の Blade や Symfony の Twig のようなテンプレートエンジンは既定でエスケープするため、モダンなフレームワーク上では同じ事故は起きにくくなっています。問題は、WordPress のプラグイン文化がそのレールの外側で成立していることです。

なお NuGet の最上位が境界外書き込みであることは、C# のライブラリに同梱されたネイティブコードの脆弱性が数えられていることを示しており、「パッケージの言語」と「脆弱性の言語」が一致しないことの例でもあります。

6.2 エコシステムの「作り手」の層が違う

Packagist や WordPress は参入障壁が低く、個人や小規模ベンダーが書いた拡張がそのまま世界中のサイトで動きます。Patchstack は、有料（プレミアム）コンポーネントは研究者がコードを入手しにくいため精査されにくく、実際に悪用された脆弱性が無料のものの3倍にのぼると報告しています。レビューの目が届かない場所にこそ脆弱性が残り、それがある日まとめて見つかる構造です。

Java の Maven が常に PHP の隣にいて、Critical に絞ると PHP を上回るのも同じ理由で説明できます。Maven には企業向けの大きなフレームワークやミドルウェア（アプリケーションサーバー、ビルドツール、ログライブラリ）が集中しており、1パッケージあたりのアドバイザリ数は全エコシステムで最も高い部類です。デシリアライズの脆弱性のように任意コード実行に直結するものが多く、1件あたりの重さが違います。npm のような「1関数のパッケージが数百万個」という構造とは対照的で、図2の傾きが0.48にとどまる理由の一つがここにあります。

6.3 「探す人」の数と報告の仕組み

脆弱性は、見つける人がいて初めて数えられます。WordPress には Patchstack や Wordfence のようなバグバウンティを運営する企業が複数あり、研究者がプラグインを機械的に走査する体制が整っています。Patchstack 自身も、2025年には AI で生成された低品質な報告が急増し、選別の負荷が上がっていると述べています。Go の2025年の構成比が GitHub の掘り起こしで6ポイント動いたこと、2026年に全エコシステムで件数が過去最多になったこと（第3節）、PHP 本体の CVE が2016年にファジングの普及で一度に120件見つかったこと（第4節）も含め、報告件数は「脆弱性の量」と同じくらい「報告する側の活動量」を反映しています。

6.4 修正までの速さ

Veracode の「State of Software Security 2025」は、脆弱性が見つかってから半分が修正されるまでの期間（半減期）を言語別に出しています。

PHP の半減期は227日で、Java や C++ よりは速く、Python や JavaScript よりは遅い中位です。残差で PHP と並ぶ Java が修正でも最も遅いことは、Maven に企業向けの大型ソフトウェアが多いという6.2の見方と整合します。

メモリ安全性については、C/C++ が Mend の集計で半分を占めることが言語設計そのものに起因する唯一の明確な例です。Google は Android の新規コードをメモリ安全な言語に寄せた結果、脆弱性に占めるメモリ安全性の問題の割合が2019年の76%から2024年には24%に下がったと報告しています。PHP、Java、Python、JavaScript はいずれもメモリ安全な言語なので、ライブラリの脆弱性ではこの軸は横並びです。メモリ安全性が効いてくるのは第4節の処理系の話で、PHP 本体の CVE の重さはそこから来ています。

7. 開発の現場で何を変えるべきか

このデータから、私たちが引き出した含意は次の3つです。

1. 言語を変えるより、レールを変える。 PHP で書くこと自体が危険なのではなく、エスケープやクエリ組み立てを開発者の手作業に任せる書き方が危険です。既定でエスケープするテンプレートエンジンと、プリペアドステートメントを強制する ORM の上に乗れば、PHP の脆弱性の3割強を占める XSS と SQL インジェクションの大部分は構造的に消えます。これは当社のSQLインジェクションの記事で書いた多層防御の考え方と同じです。

2. 依存関係の「数」と「誰が書いたか」を見る。 WordPress の脆弱性の91%はプラグインで、46%は公開時点で修正がありません。プラグインを一つ入れることは、レビューされていないコードをサイトの権限で動かすことと同じです。プラグインの棚卸しと、更新が止まったものの除去は、言語選定より先にやるべき対策です。

3. 件数ではなく「重大度 × 修正の速さ」を計測する。 第2.5節のとおり、件数の多さと重大なものの多さは一致しません。Veracode のデータでは、重大度が高くても修正は1か月しか早まりません。第3節で見たように、報告件数は今後も報告側の活動量に引っ張られて増え続けます。見つけたあと放置される Critical が、発見数の多さ以上にリスクを決めます。依存関係の脆弱性通知を受けてから本番に反映するまでの日数を、重大度別にチームの指標として持つことを勧めます。

まとめ

• 「言語別の脆弱性数」に公式統計はなく、代理指標の選び方で順位が変わる。素の累計件数では npm（JavaScript）が最多で、PHP は4位。
• 件数は普及率と正比例しない。両対数の回帰ではパッケージ数に対する傾きが0.48、開発者利用率に対する傾きが0.73で、普及率で説明できるのはばらつきの4割以下。
• 相関を取り除いた残差では、PHP（Composer）が2つの分母の両方で最上位（2.1〜2.4倍）、Java（Maven）が常にすぐ隣。JavaScript は普及率どおりで、C# は最も少ない。
• 重大度を入れると順位が変わる。PHP は Critical の比率が8エコシステム中最低（10.0%）で、Critical 件数の残差では Java が PHP を上回る。PHP は「数は多いが軽いものが多い」、Java は「数はやや少ないが重いものが多い」。
• 処理系そのものでは、PHP 本体の累計 CVE は760件と最多級だが、2021〜2023年は年7〜8件で Node.js・Go・Java・.NET より少ない。ただし Critical の比率は17.6%と処理系の中で最も高く、C で書かれたパーサのメモリ安全性の問題が中心。
• 時系列では、PHP の利用率が3分の2に下がる間に件数は2.6倍に増えた（r = −0.89）。利用率の動きにかかわらず全言語で件数が増えており、主因は報告する側の活動量にある。
• WordPress プラグインは2025年の1年間で登録数1,000件あたり136件で、Composer の約127倍。「PHPは脆弱性が多い」という印象の大部分はここから来ている。
• 残差の正体は言語そのものより、（1）XSS に偏った弱点の種類、（2）参入障壁の低いプラグイン経済、（3）報告する側の活動量、（4）修正までの速さ、の4つにある。

集計の方法と参考資料

• アドバイザリ件数は、GitHub Advisory Database の公開リポジトリ（github/advisory-database、コミット 45f4266、2026年10月28日）の github-reviewed 配下37,293件を、affected[].package.ecosystem でエコシステム別に数えました。複数エコシステムにまたがるアドバイザリは各エコシステムに1件ずつ数えています。年別集計は、GitHub の公開日ではなく CVE 番号の年（CVE 番号がないものは公開日の年）を使い、GitHub 側の一括レビューによる年のずれを避けました。弱点分類は database_specific.cwe_ids、重大度は database_specific.severity（Critical / High / Moderate / Low）で数えています。
• 登録パッケージ数は packages.ecosyste.ms の各レジストリの値（2026年10月28日）、開発者利用率は Stack Overflow Developer Survey 2017〜2025年の「全回答者」の値です。回帰は両対数の最小二乗法、相関係数は Pearson の r です。
• 処理系の CVE は NVD の API（virtualMatchString に cpe:2.3:a:php:php など各製品の CPE を指定、2026年10月28日）で取得し、CVE 番号で重複を除いたうえで公開年と CVSS（NVD の Primary 評価、v4.0 → v3.1 → v3.0 → v2 の順）で集計しました。Java は oracle:jdk と oracle:openjdk、.NET は microsoft:.net・.net_core・.net_framework・asp.net_core の合算です。NVD の CPE 付与は2024年以降遅れているため、2024年以降の件数は過小です。
• WordPress の件数は Patchstack の年次・半期レポート、プラグイン数は公式ディレクトリの2026年10月時点の第三者集計（約76,000）を用いました。有料プラグインはこの分母に含まれないため、WordPress の密度はやや過大に出ます。

参考資料（取得日はいずれも2026年10月下旬）:

• GitHub Advisory Database / github/advisory-database
• A year of open source vulnerability trends: CVEs, advisories, and malware（GitHub Blog）
• NVD Vulnerabilities API
• ecosyste.ms Registries API
• Stack Overflow Developer Survey 2025: Technology（2017〜2024年版も同サイト）
• Which Programming Language Has the Most Vulnerabilities in 2026?（Safeguard） ― 分母の選び方で先行する分析。本記事はその分母を使い、集計と回帰を独自に行ったものです
• The Most Secure Programming Languages, Ranked（Mend）
• State of WordPress Security in 2026（Patchstack） / 2025 mid-year vulnerability report（Patchstack）
• Usage statistics of WordPress（W3Techs） / Usage statistics of PHP（W3Techs）
• 2025 CWE Top 25 Most Dangerous Software Weaknesses（MITRE）
• State of Software Security 2025（Veracode）
• The number of Android memory safety vulnerabilities has tumbled（Help Net Security）
• 2025 saw an explosion in CVEs（The Stack）