はじめに

本記事では、2026年10月に公表され、同月21日に修正版が公開されたPHPの脆弱性がどのようなものか、簡易的にかみ砕いて解説します。

この件では、高市総理がXで異例の「大至急のお願い」を発信しました。

皆様に、今夜に対応して頂きたい大至急のお願いです。
多くのウェブサイトで使用されているPHPに関し、PHPのセキュリティチームが、重大な２件の脆弱性に関する注意喚起を行っています。
（高市早苗 @takaichi_sanae より一部引用）

「PHPってなに？」「何がそんなに危ないの？」という方にも分かるように、順番に説明していきます。

本記事は2026年10月22日時点の情報をもとにしています。最新情報は必ず PHP公式サイトや国家サイバー統括室の発信をご確認ください。

そもそもPHPとは？

PHPは、Webサイトの裏側（サーバー）で動くプログラミング言語です。

たとえばブログの記事一覧を表示したり、ログイン処理をしたり、ネットショップの注文を受け付けたりする部分で使われています。次のような有名なソフトもPHPで作られています。

ソフト	用途
WordPress	ブログ・企業サイト（CMS）
Drupal / Joomla	CMS
MediaWiki	Wiki（Wikipediaでも使われているソフト）
phpBB	掲示板
Magento	ECサイト
Laravel / Symfony	Webアプリ開発用のフレームワーク

普段意識していなくても、私たちが見ているWebサイトのかなりの割合がPHPで動いています。

何が起きたのか？

PHP本体に、ログインなしで、外部からサーバーを乗っ取れる重大な脆弱性が2件見つかりました。

このような脆弱性は「リモートコード実行（RCE）」と呼ばれます。
かみ砕くと「インターネットの向こうから、他人のサーバーで好きな命令を実行できてしまう」状態です。

乗っ取られると、たとえば次のようなことが起こり得ます。

サイトの書き換え（改ざん）
保存されている個人情報やパスワードの盗み出し
ウイルスの設置や、他のサイトを攻撃する踏み台としての悪用

ポイント：アプリではなく「PHP本体」の問題

今回いちばん怖いのはここです。

普段の脆弱性は「WordPressのこのプラグインが危ない」のように、特定のアプリの問題であることが多いです。今回は土台であるPHP本体に穴があります。そのため、PHPで動いていれば、上に乗っているアプリの種類に関係なく影響を受けます。

2つの脆弱性をかみ砕くと

技術的な詳細は公式のアドバイザリに載っていますが、ここではレストランにたとえて説明します。

① CVE-2026-109618：メモリ不足を悪用するもの

たとえ： 料理の途中で停電が起き、作りかけの料理を「完成品」として出してしまう

PHPは、メモリが足りなくなるとエラーで処理を中断します。このとき、内部のデータが中途半端な状態で残ってしまいます。その後の後片付けの処理が、この壊れたデータを「正しいデータ」として扱ってしまい、攻撃につながります。

② CVE-2026-109619：前のリクエストのデータが残るもの

たとえ： 前のお客さんの伝票が片付けられずに残っていて、次のお客さんの注文として処理してしまう

PHPは、1つのリクエスト（ページへのアクセス）が終わると、使ったデータを片付けます。ところが一部のデータが片付けたはずなのに参照だけ残る状態になります。同じワーカー（処理担当）が次のリクエストを処理するときに、その古いデータを使ってしまいます。

影響を受けるのは？

Webリクエストを処理しているPHPはすべてが対象です。

PHP-FPM
Apache + mod_php
php-cgi
FrankenPHP
LiteSpeed

公式は、特に mod_php が最も危険としています。アプリのコードが動く前に、ログインなしのリクエスト1つで攻撃が成立する実証例があるためです。

話題になった攻撃デモ動画について

この脆弱性は、セキュリティ企業 FearsOff の CTO である Kirill Firsov 氏がXに投稿したデモ動画でも大きな話題になりました（脆弱性自体は、セキュリティ企業 Calif と Wiz がそれぞれ独自に発見したと報じられています）。

動画では、脆弱性を突く攻撃コードを使い、次のサイトを次々に乗っ取っています。

WordPress 7.1.3
MediaWiki 1.46.2
phpBB 3.3.17
Magento 2.4.9
Joomla 6.2.0
Laravel 13.36.0 / 8.83.29
Symfony 8.1.9
Drupal 11.4.10

どのサイトも、攻撃を実行するとサーバー上でコマンドを実行できた証拠が表示されます。アプリが違っても同じ攻撃1つで乗っ取れることが、「PHP本体の問題」であることをよく表しています。

なお、動画に映っているのは攻撃の実行画面と結果だけで、攻撃コードそのものは公開されていません。ただし、この脆弱性の攻撃コード（PoC）はすでに別の経路で出回っているとされ、実際に悪用も確認されています。

攻撃先は「自分のPCの中」

動画で攻撃しているのは、実在する誰かのWebサイトではありません。アドレス欄はどれも 127.0.0.1（「このPC自身」を指す特別なアドレス）です。投稿者は自分のPCの中に検証用のサイトを立ち上げ、それを攻撃しています。このような環境を「ローカル環境」と呼びます。

他人のサーバーを許可なく攻撃することは、不正アクセス禁止法などの法律に触れるおそれがあります。そのため、自分で用意した環境で攻撃の成立を示すのが、セキュリティ研究の一般的なやり方です。

話題に便乗して「攻撃コードはこちら」と称し、マルウェア入りのファイルやリポジトリを配るケースがよくあります。興味本位でダウンロードしたり実行したりしないでください。

何をすればいい？

1. PHPを使っているか確認する

自分（自社）のWebサイトがPHPで動いているかを確認します。WordPressなどのCMSを使っているなら、ほぼ確実にPHPです。レンタルサーバーの場合は、管理画面でPHPのバージョンを確認できることが多いです。

サーバーに入れる場合は、次のコマンドで確認できます。

php -v

php -v で表示されるのはコマンドライン用のPHPです。Webサーバーが使っているPHPとバージョンが違うこともあります。確実に確認したい場合は phpinfo() をWeb経由で表示して確認してください（確認後はファイルを必ず削除しましょう）。

2. 修正版にアップデートする（最優先）

次のバージョンで修正されています。

ブランチ	修正版
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

Linuxのパッケージ（apt / dnf など）でPHPを入れている場合は、配布元から更新パッケージが出ていないか確認してください。
PHP 8.1以前は公式サポートが終了しています。ただし今回は深刻度が高いため、7.4〜8.1向けにも最小限の修正パッチが提供されています。この機会にサポート中のバージョンへの移行も検討しましょう。

3. すぐ更新できない場合は「緩和策」

公式は「完全な解決策はアップデートのみ」と明言したうえで、あくまで一時しのぎとしてリスクを下げる設定を紹介しています。緩和策は穴そのものを塞ぐものではないため、最終的には必ずアップデートしてください。

① CVE-2026-109618 向け

memory_limit = -1
post_max_size = 8M   ; 値は一例（公式は「控えめに」とのみ指定）。アップロードが必要なら 32M など

memory_limit = -1 はメモリ上限をなくす設定です。一見危なそうですが、「メモリ上限に達したときのエラー処理」にバグがあるため、あえて上限を外して発火条件を踏ませないという対策です。
上限を外すぶん、サーバーのメモリを使い切るおそれがあるので、公式はコンテナや cgroup でのメモリ制限の併用を勧めています。
ただし RLIMIT_AS / RLIMIT_DATA は使わないでください。逆に脆弱な処理経路を誘発するため、公式が明確に非推奨としています。

② CVE-2026-109619 向け

session.upload_progress.enabled = 0
fatal_error_backtraces = 0   ; PHP 8.5 の場合

設定は php.ini や、PHP-FPM・Apache の設定ファイルで行い、全ワーカーを再起動してください。
ini_set() や .user.ini での設定は効きません。

また総理のポストにもあるとおり、パッチをすぐ当てられない場合は、サイトを一時的に停止するのもリスクを下げる有効な手段です。

4. 侵入されていないか確認する

アップデートで穴は塞がりますが、すでに仕掛けられた不正なファイルは消えません。次の点も確認してください。

見覚えのないファイルがWeb公開ディレクトリに増えていないか
アクセスログに不審なリクエストがないか

まとめ

PHP本体に、ログインなしでサーバーを乗っ取れる重大な脆弱性が2件見つかった
WordPress、Laravel など、PHPで動くものはアプリを問わず影響あり
攻撃コードはすでに出回っているとされ、一刻も早いアップデートが必要
対応は 「PHPを使っているか確認 → 修正版へ更新 → 無理なら緩和策 or 一時停止 → 侵入の痕跡を確認」

「自分には関係ない」と思っていても、会社のサイトや昔作ったブログがPHPで動いていることはよくあります。この機会にぜひ一度確認してみてください。

参考