PHPはなぜ脆弱性で話題になるのか？誕生から現在までの歴史で考える | UNIX Cafe

確認日：2026年10月25日

PHPの脆弱性「PHP2shell」が話題になり、サイト管理者への更新が呼びかけられています。「PHPってよく脆弱性がニュースになるけど、使い続けて平気なのかな？」と疑問に思う方も多いのではないでしょうか。

この疑問を解消するためには、「PHP本体の欠陥」、「PHPで作られたサイトの問題」、「更新されない環境」を分けて考える必要があります。

個人のホームページ用ツールからWebの基盤へと成長した歴史をたどりながら、問題が生まれる背景と、現在のPHPで改善されてきたことを整理します。

対応をお急ぎの方は、前回の記事、「PHP2shell（CVE-2026-109618/109619）とは？」を確認してください。

今回、PHPの何が問題になったのか

PHPは、サーバー上でWebページの表示やフォームの送信処理などを行うプログラミング言語です。サイトのプログラムを実行するソフトウェアも「PHP」と呼ばれます。今回問題になったのは、その実行環境に当たるPHP本体です。

IPAは2026年10月22日、CVE-2026-109618とCVE-2026-109619について注意喚起を公開しました。作業領域であるメモリが足りなくなったときの処理や、処理後に残った内部状態の扱いに問題があり、遠隔の第三者によって意図しないコードを実行される可能性があります。この2件の組み合わせが「PHP2shell」と呼ばれています。

• IPAの注意喚起

共通の実行基盤に欠陥があると、その上で動く多くのサイトで確認や更新が必要になります。個々のサイトの担当者が書いたコードに不備がなくても、対応が求められる点が重要です。

ただし、PHPを使う全サイトで同じ条件の攻撃が成立するという意味ではありません。Webサーバーとの連携方式などによって条件が変わります。また、影響する範囲の広さと、実際に被害が発生したかどうかは別の情報として読む必要があります。

• PHP公式の検証結果

PHPは、小さな個人用ツールから始まった

1994〜1997年：ホームページのための道具

PHPの原点は、Rasmus Lerdorf（ラスマス・ラードルフ）氏が1994年に作った、C言語によるCGIプログラム群です。CGIは、Webサーバーからプログラムを動かすための仕組みです。当初の目的は、自分のオンライン履歴書へのアクセスを追跡することでした。

「Personal Home Page Tools」と名付けられたこの道具は、1995年にソースコードが公開されました。初期の開発を通じてフォーム処理やデータベース連携などの機能が整えられ、1997年にはPHP/FI 2.0の正式版が公開されます。

最初から現在のような大規模なWebサービスを想定していたわけではなく、Webで必要になる機能を増やしながら、プログラミング言語へと育っていったのです。

1998〜2004年：Webアプリケーションを作る言語へ

1998年のPHP 3では言語の構造が刷新され、名称も現在の「PHP: Hypertext Preprocessor」になりました。2000年のPHP 4では、プログラムの実行を担う「Zend Engine」を導入。2004年のPHP 5では、処理やデータをまとまりとして扱うオブジェクト指向の機能が強化されました。

HTMLに処理を埋め込み、データベースと連携してページを作れる手軽さは、PHPを理解するうえで欠かせません。用途が広がるにつれて、作りやすさに加え、大きなプログラムを整理し、保守するための機能も求められるようになりました。

• PHP公式の歴史

その後の主な転換点を並べると、次のようになります。

時期	主な出来事
1994〜1997年	PHP ToolsからPHP/FIへ。個人用ツールから言語へ成長
1998〜2004年	PHP 3・4・5。構造の刷新と実行エンジンの進化
2005〜2010年	Unicode対応を目指したPHP 6の開発と中止
2015年	PHP 7。性能改善と型宣言の充実
2020年以降	PHP 8系。言語機能や実行方式の改良を継続

PHP 6は、言語の中核にUnicode対応を組み込む計画でしたが、実装上の難しさから中止されました。これは、PHPで日本語などを扱えないという意味ではありません。一部の機能はPHP 5系に取り込まれ、次の大きな更新はPHP 7として公開されています。

• PHP 6・7の名称を検討した公式文書

この経緯は、言語を発展させる難しさを示しています。ただし、個人用ツールとして生まれたことや、PHP 6が実現しなかったことを、現在の脆弱性の直接の原因とすることはできません。

「PHPの脆弱性」は、どこにある問題なのか

PHPに関するニュースには、異なる場所の問題が含まれています。対応先を整理すると、次のように分けられます。

問題の所在	例	主に確認・更新するもの
PHP本体・拡張機能	メモリ管理などの欠陥	PHPの実行環境・拡張機能
CMS・プラグインなど	認証や入力処理の欠陥	該当する製品・追加機能
個々のサイトのプログラム	SQLインジェクション、XSS	サイトのコード・設計
サーバーの設定・運用	過剰な権限、更新の放置	設定・保守体制

CMSは、WordPressのように記事やページを管理するソフトウェアです。プラグインは、その機能を追加する部品です。これらに見つかった問題と、PHP本体の問題は、修正する対象が異なります。

たとえば、PHP本体を更新しても、サイト独自のログイン処理にある欠陥が自動で直るわけではありません。反対に、サイトのコードを丁寧に見直しても、PHP本体のメモリ管理の欠陥は修正できません。どの部分の問題なのかを確かめることが、対策の出発点になります。

脆弱性を生む要因と、問題が残り続ける理由

過去には、入力を扱い間違えやすい仕組みがあった

かつてのPHPには、外部から届いた値をプログラムの変数として自動で使えるようにする、register_globalsという設定がありました。有効な環境では、利用者が送った値と、プログラム内部で用意した値を区別しにくくなり、実装によっては意図しない値を処理に使う原因になりました。

また、magic_quotesという自動エスケープの仕組みもありました。エスケープとは、特別な意味を持つ文字を通常のデータとして扱える形にする処理です。しかし、一律に文字を加工しても、データの使い道に応じた安全対策にはなりません。

こうした機能は、PHP 5.4で削除されています。古いPHPの設計が安全な実装を難しくしていた面はありますが、その問題を現在のPHPにもそのまま当てはめると、状況を見誤ります。

• PHP公式：利用者からの入力
• PHP 5.4のリリース告知

「動くコード」と「安全なコード」の間には差がある

たとえば、検索フォームの入力をそのままデータベースへの命令文につなげても、普通の検索語なら期待どおり動くかもしれません。しかし、入力した文字が命令の一部として解釈されると、想定外の検索や操作につながるおそれがあります。これが「SQLインジェクション」です。

対策の基本は、命令の形と入力値を分離する「パラメーター化クエリ」を使うことです。PHPではPDOなどを通じて利用できますが、PDOを使っていても、入力値を命令文へ直接つないでしまえば問題は残ります。

• PHP公式：SQLインジェクション

画面への表示には別の対策が必要です。利用者の入力がブラウザーでスクリプトとして動いてしまう「XSS」を防ぐには、HTMLなど出力先の文脈に応じたエスケープを行います。データベース用に処理したから、画面に出しても安全とは限りません。

• OWASP：XSS対策

PHPの手軽さは便利ですが、安全性まで自動で保証するものではありません。この点は、ほかの言語でWebサイトを作る場合にも共通します。

PHPを動かす内部実装にも、メモリ管理の難しさがある

PHPでサイトを作る人は、通常、メモリの確保や解放を細かく書く必要がありません。その仕事を、C言語を中心に実装されたPHP本体が引き受けています。

• PHP本体のソースコード

内部では、どのデータをいつまで使い、いつ片付けるのかを正しく管理しなければなりません。今回のCVE-2026-109619は、使い終わったメモリを指す情報が残り、次の処理で使われてしまう問題です。

• PHP公式セキュリティアドバイザリ

入力を安全に扱うアプリケーションでも、その下にある実行基盤に欠陥があれば、基盤の更新が必要です。PHPのコードの書き方と、PHP自体を動かす仕組みの安全性は、分けて考える必要があります。

長く動いているサイトには、更新の壁がある

古いPHPを新しくすると、以前の書き方やプラグインが動かなくなる場合があります。動作確認に必要な資料がない、作った担当者がいない、検証環境や予算を用意できない、といった事情が重なると、更新は難しくなります。IPAも今回の注意喚起で、こうした保守上の課題を挙げています。

• IPAの保守・移行に関する説明

これは、脆弱性そのものが生まれる理由とは別に、修正版が公開されても、更新されないサイトに脆弱性が残り続ける理由です。「今も動いている」というだけでは、安全性や今後の保守を判断できません。

利用範囲の広さが、問題の目立ちやすさにもつながる

PHPはさまざまなWebアプリケーションや製品で使われています。そのため、共通部分に重大な欠陥が見つかれば、多くの利用者が確認を求められます。ここから、PHPが大きな話題になる背景には、利用範囲の広さもあると考えられます。

• IPAの注意喚起

ただし、ニュースの多さや脆弱性の識別番号であるCVEの件数だけで、「PHPは他の言語より危険」とは判断できません。本体だけを数えるのか、プラグインまで含めるのかによっても結果は変わります。比較するなら、対象範囲、期間、深刻度などの条件をそろえる必要があります。

「脆弱性が多い」という印象の中には、過去の仕様、実行基盤の欠陥、サイトの作り方、更新の遅れが混在しています。それぞれに原因と対策があります。

PHPは、昔のままではない

PHP 7・8で進んだ改善

2015年のPHP 7では、性能やメモリ効率が改善され、関数が受け取る値や返す値の型を指定する機能も充実しました。たとえば「ここでは整数を扱う」とプログラムに示すことで、値の扱いの誤りに気付きやすくなります。

• PHP 7.0公式発表

2020年のPHP 8.0では、複数の型を指定するUnion型などが加わりました。また、実行時に機械語へ変換して処理を高速化するJITも導入されています。JITの効果は処理内容によって異なり、一般的なWebサイトが一律に大幅高速化するわけではありません。

• PHP 8.0公式発表

こうした進化は、開発しやすさや性能の改善につながっています。ただし、型宣言はSQLインジェクションを防ぐ仕組みではなく、JITもセキュリティ機能ではありません。新しい機能を使うことと、必要な安全対策を行うことは、両方が必要です。

現在の機能と、サポート状況を確認する

2026年10月25日時点で、PHP公式のサポート対象は8.2〜8.5です。8.2・8.3はセキュリティ修正のみの段階で、8.4・8.5は通常の不具合修正も受けられます。8.2のセキュリティサポートは2026年12月31日までです。

• PHP公式サポート状況

サポート対象の系列を使っていることと、修正版を適用していることは別です。 PHP 8系だから大丈夫と考えず、実際に動いている細かいバージョンや、提供元による修正状況を確認する必要があります。

使い続けるなら、何を確認すればよいか

サイトの管理者は、次の順に整理すると、必要な作業を判断しやすくなります。

1. 実際にWebサイトを動かしているPHPと、その管理者を確認する。
2. PHP本体、CMS、プラグイン、依存ライブラリを、それぞれ更新対象として把握する。
3. サポート期限と更新予定を決め、バックアップと動作確認の手順を用意する。
4. 自作部分では、入力処理、データベース操作、画面への出力、認証や権限を見直す。

レンタルサーバーでは、PHP本体の更新を提供元が管理している場合があります。その場合は、サービスの案内や管理画面で対応状況を確認します。OSの配布元が古い系列に修正を取り込んでいる場合もあるため、表示されたバージョン番号だけで判断せず、提供元の情報と照合してください。

PHP2shellへの具体的な対応は、IPAの対策案内とPHP公式の告知を確認してください。10月23日にはセッション関連の追加案内も出ており、最初の修正版の情報だけで確認を終えないことが必要です。

PHPの歴史から見えてくること

PHPは、個人の便利ツールから、多くのWebサイトを支える言語へと成長してきました。その過程では、安全な実装を難しくする古い仕組みが削除され、プログラムを整理し、不具合に気付きやすくする機能も増えています。

それでも、実行基盤の欠陥、サイトの実装、更新されない環境には、それぞれの対応が必要です。PHPのニュースを見たときは、自分のサイトのどの部分が影響を受け、誰が修正や更新を担うのかを確認する。その積み重ねが、使い続けるための安全性につながります。