PHP の重大な脆弱性 ― 自分の事業や取り組みのサイトを確認しよう
退役軍人の事業、市民団体、教育プロジェクトのサイトは、たいてい WordPress で作られている ― つまり PHP で動いている。10月21日、この言語にパスワードなしでサーバーを奪える穴が二つ見つかった。わかりやすく説明する。誰に関係するのか、委託先に何を聞けばよいのか、委託先がいない場合はどうするのか。
- 何が起きたのか — 大半のサイトが動いている言語 PHP に、重大な穴が二つ見つかった。10月21日に修正版が出ている。PHP 8.5.12、8.4.27、8.3.36、8.2.35 である。
- 誰に関係するのか — WordPress、Joomla、OpenCart でサイトを持っているすべての人 ― 工房を営む個人事業主から、ページが一枚だけの市民団体まで。
- 何をすべきか — サイトやホスティングを保守している相手に一文だけ書く。「PHP は2026年10月21日のバージョンに更新されていますか」 ― そして回答を文書でもらう。
多くの退役軍人が兵役の後に自分の事業を始め、市民プロジェクトに取り組み、あるいは教育の取り組みを立ち上げる。そしてほぼ必ず、どこかの段階でサイトができる。作られたのはたいてい WordPress である。速く、安く、多くの場合は知り合いか、もう長く連絡の取れていないフリーランスの手による。
2026年10月21日、PHP チームは緊急アップデートを公開し、欧州のサイバーインシデント対応チーム CERT-EU は緊急警告を公表した。原因は、危険度の評価が 10点中9.2点という二つの脆弱性である。これらは攻撃者に、あなたのサーバー上で自分のコードを実行させる。ログインもパスワードも、あなたの側のどんな操作も必要ない。
以下、余計な専門用語を使わずに説明する。何が起きたのか、なぜ最も小さなサイトにも関係するのか、そしてホスティング会社に今日のうちに書き送るべき三つの文は何か。
何が見つかったのか
脆弱性は2件あり、いずれも9.2点と評価され、いずれも同じ結果につながる。認証なしにサーバー上で他人のコードが実行されるという結果である。
CVE-2026-109618 — メモリ不足時の異常終了
PHP の設定 memory_limit：メモリを使いすぎたリクエストは強制的に中断される。問題は、その中断のされ方である。PHP は、リクエストの内部データが半分しか埋まっていない時点で中断することがある。たとえばアップロードフォームから送られたファイルを解析している最中である。そのようなリクエストの後片付けは、未完成のデータを本物とみなし、存在したことのないメモリを解放しようとする。そしてそのメモリには、攻撃者が以前のリクエストで置いたものが入っている可能性がある。
CVE-2026-109619 — 前のリクエストの残骸
2つ目の穴は、サーバーが前の訪問者を完全に「忘れ」ないという話である。あるリクエストに属していた内部状態が、メモリの解放を生き延びることがある。たとえば致命的なエラーのあとだ。同じワーカープロセスに入った次のリクエストは、通常の初期化がそれをゼロに戻す前に、その残骸を利用できてしまう。
ウェブリクエストを処理する PHP の構成はすべて危険にさらされている。PHP-FPM、Apache のモジュール mod_php, php-cgi、FrankenPHP、LiteSpeed。PHP チームが最も危険とみなすのは、まさに Apache と mod_php の組み合わせであり、これは今も多くの安価なホスティングで標準となっている。
実証用のエクスプロイトは、認証なしのたった1件のリクエストで成立する。サイト自身のコードが動き始める前の段階である。つまり、セキュリティプラグインも、複雑なパスワードも、二要素認証もここでは役に立たない。攻撃は一段下の層で起きているからだ。
どのバージョンが危険か
これらのバージョンより下のものはすべて脆弱である。
| PHP のブランチ | 安全なバージョン |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
| PHP 8.1 以前 | サポートなし |
もう一つのリスク区分は、外からは見えないが内部に PHP が組み込まれている商用・オープンソース製品である。管理パネル、ネットワーク機器、監視カメラシステム、社内ポータルなどだ。このようなソフトの一覧は、 オランダの NCSC のリポジトリで公開されている.
「うちは小さなサイトだから」が通用しない理由
誰もあなたのサイトを個別に探してはいない。侵入の実例が公開されると ― すでに公開されている ― 数時間のうちに自動スキャナーが動きだし、インターネット全体を順番に当たっていく。大企業のサイトであろうと、サービスが五つしかない工房のページであろうと関係ない。問題になるのは、サーバーが脆弱なバージョンで応答するかどうかだけである。
その後の筋書きは決まっている。サーバーに他人のコードが置かれ、サイトは迷惑メールや他人の広告ページを配りはじめ、ドメインはブラックリストに載り、そこから出すメールは顧客に届かなくなる。小さな事業にとっては痛みが二重である。サイトは唯一の店先であることが多く、立て直しには数週間と、予定していなかった出費がかかる。
そのあとに必ず続くものについても、別に注意しておきたい。こうした報道の後には「専門家」が動きだし、サイトの持ち主に自分から連絡してくる。「脆弱性があります、急いでアクセス権をください」というものである。サイトとホスティングのアクセス権は、自分が知っていて、保守の対価を払っている相手にだけ渡すこと。
何をすべきか — 手順
- 自分のバージョンを確認する。 ホスティングの管理画面では「PHP バージョン」または「PHP Selector」という項目、自社サーバーではコマンド
php -v。確認すべきなのはサイト自身が動いているバージョンであり、コマンドラインに入っているものではない。両者はしばしば異なる。 - 同じブランチの中で更新する。 8.2.29 から 8.2.35 への移行は同じブランチ内の修正であり、互換性は保たれ、サイトが壊れることはない。8.2 から 8.4 への移行と混同してはいけない。そちらは確認が必要になる。
- 8.1 以前を使っている場合 — これらのブランチにはサポートがない。状況の深刻さを踏まえ、PHP のセキュリティチームは 7.4、8.0、8.1 向けにも最小限の修正を出し、一部のホスティング事業者は独自ビルドを維持している。しかし正しい判断はサポートされているブランチへの移行であり、次回ではなく今、計画するほうがよい。
- ハンドラーを再起動する。 再起動しないかぎり、
php-fpmや Apache のワーカープロセスは古いコードで動き続け、更新は実質的に効かない。 - 結果を確認する。 最も簡単なのは
phpinfo()を置いた一時ページを使い、確認後すぐに削除する方法か、再起動後に管理画面の「PHP バージョン」の項目を見る方法である。
ホスティング利用者の多くは、手を動かす必要はない。大手事業者は修正を事前に受け取り、自社のマシンを自分で更新している。サポートに「PHP は2026年10月21日のバージョンに更新済みか」と一行書いて送り、回答を文書で受け取るとよい。
今すぐ更新できない場合
サイトが古く、更新に準備が必要なこともある。その場合は、攻撃の機会を狭める暫定的な対策がある。
- メモリ不足を侵入口にさせない：
memory_limit=-1、アプリケーション側から上書きできない形で指定し、どのプールやディレクトリも制限を元に戻していないことを確認する。 - 小さくする設定は
post_max_sizeで、ファイルのアップロードがないサイトは8M、アップロードが必要なら32M とし、upload_max_filesizeはそれより低く保つ。 - 無効にする設定は
session.upload_progress.enabledで、さらにすべてのワーカープロセスを再起動する。 - PHP 8.5 で追加的に無効化する対象は
fatal_error_backtraces; - リクエストのサイズと複雑さをウェブサーバーまたはプロキシの層で制限する。
これらの対策のどれも、環境を安全にするものではない。既知の経路をふさぐだけであり、問題を完全に閉じるのは更新だけである。
それも不可能なら、CERT-EU は単純で歓迎されない解決策を勧めている。修正を適用して確認が済むまで、脆弱なサービスを公開インターネットから外すことである。
出典
- CERT-EU, Security Advisory 2026-018「Critical Vulnerabilities in PHP」
- php.net のアップデート公開のお知らせ
- CVE-2026-109618 の技術的な説明 と CVE-2026-109619
自分のサイトが何で作られていて、誰が責任を持っているのかわからないなら、それ自体が、次のニュースを待たずに調べるべき理由である。点検を外部に依頼することもできる。たとえば SmartGT、クラスターのデジタル資産を支えているチームである。
記事の著者 — SmartGT。一次情報： 「PHP の重大な脆弱性：更新を後回しにしてはならない」.