PHPの重大な脆弱性でパッチ適用が急がれる理由｜CVSS9.2・修正版8.5.12までの仕組み

PHPに、認証なしで外部からプログラムを実行されるおそれのある重大な脆弱性が2件見つかり、2026年10月21日に修正版が公開されました。私はPHPを「古くて、もう使う人が減っている言語」だと思っていたのですが、調べると世界のウェブサイトの約7割で動いている言語でした。さくらインターネットやCygames、pixivが緊急メンテナンスを発表したのも、これで納得がいきます。

この記事は、2026年10月時点で公開されているgihyo.jpの技術解説、GMO Flatt Securityの解説、ITmedia、日経クロステック、PHP公式マニュアル、W3Techsの統計をもとに、PHPが何をしている言語なのか、今回の脆弱性がなぜ乗っ取りにつながるのか、何を確認すればよいかを整理したものです。最新の情報はPHP公式の告知で確認してください。

• 修正版は PHP 8.5.12・8.4.27・8.3.36・8.2.35 で、CVSS v4.0 のスコアは2件とも9.2
• PHPはブラウザではなくサーバーで動くため、ページを見るだけの人が操作することはない
• 原因は、リクエストの処理後にメモリの状態が正しく片づかない不具合（解放後のメモリの使用）
• 設定による緩和策はあるが、完全な対処は修正版への更新

PHPの脆弱性で何が起きたのか

2026年10月20日（協定世界時）、PHPのセキュリティチームは、2件の重大な脆弱性を直すセキュリティリリースを予告しました。ITmedia NEWSによると、詳細や影響を受けるバージョンは公開と同時に示すとして、全てのPHPユーザーに修正版をすぐ適用できるよう準備を求めていました。

2件の脆弱性は、どちらも認証なしで攻撃が始まります

CVE番号は CVE-2026-109618 と CVE-2026-109619 です。gihyo.jp によると、どちらも認証なしのリモートからコードを実行されるおそれがあります。ログインしていない相手から送られたリクエストだけで、サーバー上でプログラムを動かされる可能性があるということです。

インターネットに公開された機器やソフトの弱点が狙われる流れは、サイバー攻撃が日本を狙う理由とVPN機器の弱点でも整理しています。今回は、その対象がウェブサイトを動かす言語そのものだった点が違います。

CVSS9.2は「緊急」にあたる数字です

ITmedia NEWSの説明では、CVSSは0〜10の数値で脆弱性の深刻さを表し、9.0以上が最も深刻な「Critical（緊急）」です。今回の2件は、CVSS v4.0 でどちらも9.2と評価されました。

PHPはウェブサイトのどこで動いているのか

PHPの公式マニュアルは、PHPを「広く使われているオープンソースの汎用スクリプト言語」で、特にウェブ開発に適し、HTMLに埋め込めると説明しています。日経クロステックも、PHPをウェブサイトの構築などに使われる言語と書き、CMSのWordPressもPHPを使うと伝えています。

ブラウザに届くのは、PHPが作った結果だけです

公式マニュアルによると、PHPはクライアント側で動くJavaScriptと違い、コードがサーバーで実行され、その結果だけがクライアントに送られます。ブラウザを使う側は、出力を作ったコードを見ることができません。

今回の脆弱性が重いのは、この「サーバーで実行される」部分が攻撃の入口になるからです。ページを見る側のスマートフォンやパソコンではなく、ウェブサイトを動かしている側のサーバーが狙われます。

69.3%という数字は何の割合か

W3Techsの2026年10月22日付の集計では、サーバー側の言語が判明しているウェブサイトのうち69.3%でPHPが使われています。分母は「世界の全サイト」ではなく、サーバー側の言語が分かったサイトです。それでも、10サイトのうち約7サイトという規模で、緊急メンテナンスが相次いだ理由の一つになります。

📊 読者投票 受付中（現在2票）。あと3票で結果を公開します。

メモリの不具合が、なぜサーバーの乗っ取りにつながるのか

GMO Flatt Securityの解説によると、根本の原因は不適切な状態管理による Use After Free（解放後のメモリの使用）です。使い終わって解放したはずのメモリを、プログラムがあとから使ってしまう不具合を指します。

CVE-2026-109618は、メモリ不足で処理が途中で止まる問題です

gihyo.jp の説明では、リクエスト用の内部データを初期化している途中でメモリの確保に失敗すると、処理が中断され、不完全な状態が残ります。そのあとのリクエスト終了処理が、この不完全なデータを使うと、リモートコード実行につながるおそれがあります。

CVE-2026-109619は、前のリクエストの状態が消えない問題です

もう1件は、処理を終えたリクエストの内部状態が消去されない場合がある、という問題です。ワーカー（リクエストを処理する担当プロセス）に解放済みメモリへの参照が残り、同じワーカーが次のリクエストでその古い参照を使うと、リモートコード実行につながるおそれがあります。

攻撃は「仕込む役」と「使う役」の組み合わせです

Flattの解説は、攻撃を2段階で説明しています。1段階目は、攻撃用のリクエストの処理中に、メモリ上に不完全なデータを残すこと。2段階目は、別のリクエストの処理でその残ったデータが使われ、予期しない動きが起きることです。公式の告知ではこの2つが Producer と Consumer と呼ばれています。

攻撃が成り立つには、この組み合わせがサーバーで有効になっている必要があります。既知の例が、ext/session の Session Upload Progress 機能で、これは初期設定でオンです。Flattは、109619の組み合わせの記述は大まかで、ほかの経路が存在する可能性もあると書いています。

私は最初、サーバーが乗っ取られるのは「パスワードを破られたとき」だと思い込んでいました。今回の仕組みはそうではなく、言語の実行環境が前のリクエストの後片づけに失敗したところから始まります。パスワードの強さは関係ありません。

公開までの経過と、緊急メンテナンスが相次いだ理由

2024年の指摘から、情報の流出までの流れ

gihyo.jp によると、2024年の外部セキュリティ監査で指摘された問題を直す過程で、CVE-2026-109618につながる兆候が見つかっていました。Califは、同じ根本原因によるリモートコード実行を報告しています。

2026年10月20日には、CVE番号などがオンライン上に流出しました。PHPプロジェクトは、当初22日だった公開を21日に前倒ししました。ITmedia NEWSも、詳細が漏れたり悪用の証拠が見つかったりした場合は、予定より早く公開される可能性があると書いていました。

事業者が先にサービスを止めた理由

日経クロステックは、さくらインターネットが一部サービスの機能を停止し、CygamesとpixivもPHPの脆弱性に関する緊急メンテナンスを発表したと伝えています。Flattの解説によると、悪用コードはすでにインターネット上に出回り始めています。

修正版が出るまでの時間は、守る側にとっていちばん弱い時間です。詳細が出たあとに攻撃が始まるまでの猶予がほとんどないため、サービスを止めて待つ判断が現実的な選択肢になります。

見出しの熱と私の温度には、少し差があります。「ウェブが止まる」という言い方は大げさで、実際に止まったのは、対応が間に合わなかった一部のサービスです。それでも、止めなければ守れない場面があったことは事実だと考えています。

古いバージョンのPHPはどうなるのか

修正版は4系統、7.4と8.0・8.1は最小限の修正です

gihyo.jp によると、修正版は PHP 8.5.12、8.4.27、8.3.36、8.2.35 です。サポートが終わっている PHP 7.4、8.0、8.1 には、最小限の修正がソースコードの形で提供されました。Flattは、8.1以前はサポートが終了しており、安全とは判断できないとして、サポート対象のバージョンへの移行を強く勧めています。

PHP公式のサポート表では、セキュリティサポートの終了は、8.2が2026年末、8.3が2027年末、8.4が2028年末、8.5が2029年末です。8.2に更新した場合も、年末にはサポートが切れます。

7系と5系は、PHPを使うサイトの約3分の1です

W3Techsの集計では、PHPを使うサイトのバージョン別の割合は、8系が65.3%、7系が26.9%、5系が7.7%です。

7系と5系を合わせると 26.9％＋7.7％＝34.6％。全体に対しては 69.3％×0.346≒24％で、サーバー側言語が判明しているサイトの約4分の1にあたります。

この数字は、サイトが公開しているバージョン情報をもとにした集計であり、実際の安全性とは別です。サーバー事業者によっては、表示は古いまま独自に修正を入れている場合もありますが、外からは確かめられません。W3Techsの数字は、古い系統が残っている規模の目安として読むのが妥当です。

今すぐできる対応と、設定による緩和策の限界

サイトを自分で運営している人は、まず、使っているPHPのバージョンを確認します。レンタルサーバーなら契約先の管理画面や案内で確認できます。WordPressの管理画面で更新するのはWordPress本体で、PHPはサーバー側に入っているものです。この2つは別々に更新が必要になります。

公式が示している緩和策

gihyo.jp は、完全な対処ではないとしたうえで、次の緩和策を挙げています。

• memory_limit=-1（メモリ不足を狙う脆弱性向け。アプリから上書きできないようにし、全ワーカーを再起動する）
• session.upload_progress.enabled=0（内部状態の脆弱性向け。php.iniなど、リクエスト解析前に適用される場所で設定する）
• fatal_error_backtraces=0（PHP 8.5のみ）

Flattはこれに加えて、post_max_size で巨大なリクエストを断る、multipart bodyが不要なら遮断する、といった対応も挙げています。109619では session.upload_progress.enabled=0 だけでは一部の攻撃しか防げません。設定は時間稼ぎで、根本の対策は修正版の適用です。

侵害を疑うときに見る場所

Flattは、更新後も、ログに攻撃の痕跡がないかを調べ、サーバー内のデータが盗まれていないかを確認するよう勧めています。クラウドの場合は、サーバーが持つ権限（IAMロールなど）を確認し、ほかの環境に広がっていないかを見ます。データを盗んでから脅す手口は、ランサムウェアの二重恐喝の記事で仕組みを書いています。

修正版への更新にも、デメリットと注意点があります

更新は急ぐ必要がありますが、手間がかからないわけではありません。主な注意点は3つです。

• 古いPHP（7.4、8.0、8.1）は、修正が最小限のソースコードの形でしか出ておらず、そのままパッケージとして入れられない環境が多い
• メジャーな系統をまたぐ移行では、プラグインや自作コードが動かなくなる場合がある
• 緩和策の設定を入れたあとに、そのまま放置しやすい（設定は完全な対処ではない）

「更新すると壊れるかもしれない」という不安は現実的です。今回は悪用コードがすでに出回っているとFlattが書いているため、壊れる可能性と乗っ取られる可能性を比べると、更新を先送りする理由は小さくなっています。

立場別に見る、確認する順番の判断基準

リスクが最も高いのは mod_php で、gihyo.jp は、アプリケーションのコードが動く前に、認証なしのリクエストで攻撃が成立することが確認されたと書いています。PHP-FPMでも成立が確認されていますが、アプリケーション側の処理に依存します。実行方式によって危険度が変わるため、バージョンだけでなく実行方式も確認します。

PHPの脆弱性でよくある誤解

PHPのサイトは、全部危険なのですか？

いいえ、修正版に更新されていれば、この2件の対象ではなくなります。ITmedia NEWSの時点では、影響するバージョンは未公表で、CERT-EUは外部情報をもとにPHP 5以降の全バージョンが影響を受ける懸念があるとしていました。更新状況によって結果は変わります。

サイトを見ただけで、自分のパソコンが感染しますか？

PHPのコードはサーバーで実行され、ブラウザには結果だけが送られます。今回の攻撃の対象はウェブサイトを動かしているサーバーで、閲覧する側のパソコンやスマートフォンがこの脆弱性で直接攻撃されるという説明は、確認した資料にはありませんでした。ただし、サイトの情報が盗まれていれば、利用者のメールアドレスなどに影響が出る可能性は別に残ります。

設定を1行変えれば、更新しなくて済みますか？

いいえ、gihyo.jp は、設定による緩和策は完全な対処ではないと書いています。Flattも、109619では session.upload_progress.enabled=0 だけでは一部の攻撃しか防げないとして、根本対策はパッチだと説明しています。

まとめ：PHPの脆弱性は、サーバー側のバージョンと実行方式を確認します

2026年10月21日に公開された修正版は、8.5.12、8.4.27、8.3.36、8.2.35です。2件の脆弱性は、リクエストの処理後にメモリの状態が片づかないことが原因で、認証なしでコードを実行されるおそれがあり、CVSS v4.0 では2件とも9.2と評価されました。

PHPはウェブサイトの69.3%で使われているため、影響は広く、事業者が先にサービスを止める対応も出ました。確認するのは、PHPのバージョン、実行方式、契約先の更新状況の3つです。設定による緩和策は時間稼ぎにとどめ、サポート対象のバージョンへの更新を進めてください。

📊 読者投票 受付中（現在0票）。あと5票で結果を公開します。