はじめに
本記事では、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で動いていることはよくあります。この機会にぜひ一度確認してみてください。