2026年10月21日、PHPプロジェクトは2件の重大な脆弱性に対する修正を公開し、CERT-EUも同日にセキュリティアドバイザリ2026-018を発行しました。どちらも深刻度は9.2で、認証なしのリモートコード実行として説明されています。WordPressサイトやオンラインショップ、そのほかのPHPアプリケーションを運用している場合は、お客様にも関係があります。対処は設定の変更ではなく、アップデートです。この記事では、判明している内容、攻撃が入り込む経路、そして取るべき対応を説明します。情報の時点:2026年10月22日、CERT-EUアドバイザリのバージョン1.1に基づきます。
何が起きたのか
- セキュリティリリースを予告PHPがセキュリティ版を事前に予告
- 修正を公開8.5.12、8.4.27、8.3.36、8.2.35
- CERT-EUアドバイザリ 2026-0182件とも9.2と評価
- 概念実証コードが出回る攻撃は未確認だが、可能性は高まっている
PHPは10月20日にセキュリティリリースを予告し、10月21日の13:30 UTCに修正を公開しました。CERT-EUはアドバイザリに「Critical Vulnerabilities in PHP」という題を付け、CVE-2026-109618とCVE-2026-109619の2件のCVEを挙げています。評価はいずれも9.2です。CERT-EUはさらに、技術的な詳細がすでに公に議論されており、最初の概念実証(Proof of Concept)コードが出回り始めていると記しています。アドバイザリは実際の攻撃を確認しているわけではありませんが、そのために攻撃者がすでに脆弱性を悪用している可能性が高まったとしています。緊急の案件として扱ってください。
影響を受けるのは誰か
影響を受けるのは、サポート対象ブランチでは修正版より前のすべてのPHPリリース、そしてサポートが終了したすべてのブランチです。
| ブランチ | 影響を受ける範囲 | 修正されたバージョン |
|---|---|---|
| PHP 8.5 | 8.5.12未満 | 8.5.12 |
| PHP 8.4 | 8.4.27未満 | 8.4.27 |
| PHP 8.3 | 8.3.36未満 | 8.3.36 |
| PHP 8.2 | 8.2.35未満 | 8.2.35 |
| PHP 8.1以前 | すべてのバージョン | 通常のアップデートはなし。PHPセキュリティチームが7.4、8.0、8.1向けに最小限のソースコード・バックポートを公開 |
CERT-EUは、PHP-FPM、mod_phpを使うApache、php-cgi、FrankenPHP、LiteSpeedを挙げています。PHPチームによれば、最もリスクが高いのはmod_phpです。PHPを組み込んでいる製品も影響を受ける可能性があり、CERT-EUはオランダのNCSCによる一覧を参照するよう案内しています(この記事の末尾に記載)。アップロードフォームがあるかどうかにかかわらず、Webリクエストを処理しているインストールはすべて対象です。
攻撃者が最初の脆弱性に到達する方法
ログインは誰にも必要ありません。CERT-EUによると、実証された攻撃では、認証なしの1回のリクエストだけで、アプリケーションのコードが実行される前に攻撃を引き起こせることが示されています。多くの方が見落とすのはこの点です。WordPressが最新であるか、プラグインにパッチが当たっているか、問い合わせフォームが保護されているかは関係ありません。リクエストは、まずPHPエンジンに届きます。
最初の脆弱性であるCVE-2026-109618は、次のように動作します。
- PHPが処理するアドレスにリクエストが届きます。ログインもアカウントも不要です。
- PHPがリクエスト本文の読み取りを始めます。CERT-EUは例として、フォーム形式のファイルアップロードの解析を挙げています。
- PHPは
longjmp()でmemory_limitを強制します。上限を超えると、実行中の処理から一気に抜け出してリクエストを終了します。 - これがリクエストの内部データを組み立てている最中に起きると、そのデータは中途半端な状態になります。
- その後の後始末では、不正なデータが正しいものとして扱われ、一度も初期化されていないメモリが解放されます。そのメモリには、攻撃者が操作できた以前の割り当ての内容が残っていることがあります。
- そこから先は、サーバー上でのコード実行につながるとアドバイザリは説明しています。
最後の段階を攻撃者がどう操作するかは、意図的に記載しません。入り口がお客様のアプリケーションではないことさえ分かれば十分であり、だからこそアプリケーションの内側にあるものでは止められません。
2つ目の脆弱性:メモリより長く残る状態
CVE-2026-109619は、仕組みは異なりますが、結果は同じです。PHPはリクエストごとに内部状態を保持しています。致命的エラー(Fatal Error)など特定の失敗の後、その下にあるメモリは解放されているのに、状態だけが残ることがあります。同じワーカーが次に処理するリクエストは、通常の方法でリセットされる前に、この古くなった状態を使ってしまう可能性があります。攻撃者には、同じワーカーに届く2回のリクエストが必要です。CERT-EUは結果を最初の脆弱性と同じ、リモートコード実行と評価しています。
今日やるべきこと
サーバーのPHPは8.5.12、8.4.27、8.3.36、8.2.35より古いですか。または8.1以前ですか。
- はい両方の脆弱性の影響を受けます。次の質問へ進んでください。
- いいえWebサーバーが実際に実行しているのがこのバージョンであれば、両方の脆弱性は修正済みです。
今日、更新できますか。
- はい更新し、すべてのPHPワーカーを再起動して、実行中のバージョンを確認してください。
- いいえ修正されるまで、サーバーを公開ネットワークから切り離してください。制限はリスクを下げるだけです。
- 実際にサイトを動かしているPHPのバージョンを確認してください。コマンドラインで
php -vを実行すると、コマンドライン用のバージョンが表示されますが、Webサーバーが使うものとは異なる場合があります。php-fpm -v、ホスティングのコントロールパネル、またはphpinfo()を呼び出すページで確認してください。共用ホスティングの場合は、事業者にお問い合わせください。 - 修正版へ更新してください: 8.5.12、8.4.27、8.3.36、または8.2.35です。ディストリビューションは、バージョン番号を変えずに修正だけを取り込むことがよくあります。そのため、ご利用元のセキュリティ情報でCVE番号を探してください。コンテナでは、更新済みのベースイメージから再ビルドしてください。PHPチームは、リリース当日の時点でrpms.remirepo.netには更新がなかったと注記しており、ディストリビューションのパッケージまたはソースからのビルドを推奨しています。
- すべてのPHPワーカーを再起動してください。ディスク上のファイルを更新しても、すでに動いているプロセスは変わりません。PHP-FPMまたはWebサーバーを再起動し、その後で実行中のバージョンをもう一度確認してください。
- 今日中に更新できない場合は、サーバーを公開ネットワークから切り離してください。修正を適用して確認するまでの措置です。CERT-EUは、これらの脆弱性を完全に修正できるのはアップデートだけだと明言しています。
- PHP 8.1以前をお使いの場合は、事業者にバックポートを問い合わせるか、サポート対象のブランチへ移行してください。これらのバージョンには通常のアップデートが提供されません。
リスクを下げるが、修正にはならない回避策
CERT-EUは、攻撃を難しくする対策を挙げています。ただし、それらでインストールが安全になるわけではないと、はっきり述べています。アップデートの準備を進める間の措置として使い、アップデートの代わりにはしないでください。
- CVE-2026-109618への対策: アプリケーションが上書きできない形で
memory_limit=-1を設定します。たとえばFPMプールのphp_admin_valueを使い、どのプール、ディレクトリ、アプリケーションの設定でも有限の上限が再設定されていないことを確認してください。post_max_sizeは小さく設定し(アップロードなしなら8M、ありなら32M)、upload_max_filesizeをそれより小さく保ちます。リクエストサイズ、フィールド数、multipartの部品数、ヘッダー数、ネストの深さは、Webサーバーまたはプロキシで制限してください。コンテナやcgroupのメモリ上限は可用性の境界として使えますが、脆弱なメモリ割り当て失敗を引き起こしかねないRLIMIT_ASやRLIMIT_DATAは使わないでください。 - CVE-2026-109619への対策:
php.ini、FPMプール、またはリクエスト解析より前に効くサーバー設定でsession.upload_progress.enabled=0を設定し(ini_set()や.user.iniでは不可)、すべてのワーカーを再起動します。PHP 8.5では、あわせてfatal_error_backtraces=0を設定してください。初期化の前に診断メッセージを出力してしまう、リクエストごとの不正または古い設定は削除し、攻撃者が到達できる致命的エラーや実行タイムアウトは修正してください。
SilentShieldにできること、できないこと
これはボットの問題ではありません。製品ページがそう受け取れるように書くよりも、そのことをはっきりお伝えします。この攻撃は、当社のものも、CAPTCHAも、お客様のアプリケーション内のプラグインやファイアウォールルールも、リクエストを目にする前にPHPエンジンを直撃します。フォームに付けたボット対策では止められませんし、止められると言う人がいたら、それは誤りです。完全な対処は、PHPのアップデートだけです。
SilentShieldのAPIとダッシュボードはPHPで書かれていません。WordPressプラグインとPHP SDKはお客様自身のPHPの中で動くため、これらについてはお客様のサーバーで更新する必要があります。更新後も、ボットやフォームスパムに対するこれまでの保護は従来どおり役立ちます。ただ、それはこの問題への答えではありませんでした。