Blog

2026年10月21日、PHPに認証なしで外部からコードを実行されるおそれのある、深刻な脆弱性2件の修正版が公開されました。自分でサーバーを構築・管理している方は、次の定期保守を待たず、PHPの緊急更新を進めてください。PHP公式も即時の更新を強く推奨しています。

一方、共有レンタルサーバーなどでPHPの更新を事業者が担っている場合、利用者が自分で修正プログラムを当てる必要はありません。まず確認するのは、契約中のサービスの対応状況です。今回は、何が起きる問題なのか、誰が今すぐ動くべきなのかを分けて説明します。

最初に、自分で更新する環境かを確認してください

「レンタルしているから、自分には関係ない」とは限りません。借りているVPSでも、OSやPHPを自分で管理しているなら一番上です。反対に、事業者が対策済みと案内し、利用者の操作も不要なプランなら、利用者が重ねてPHPを更新する必要はありません。

どんな脆弱性で、どう実行されるのか

PHPは、WordPressやECサイト、問い合わせフォームなどのプログラムをサーバー上で動かす仕組みです。今回の問題は、特定のWordPressプラグインではなく、その土台であるPHP本体のメモリー管理にあります。

外部から細工されたHTTPリクエストが届き、WebサーバーからPHPへ渡る。その入力の処理や後片付けでメモリーの扱いが崩れ、条件がそろうと、攻撃者の用意した処理がPHPの実行権限で動いてしまう。これが今回の「リモートコード実行」です。実行権限やアクセスできる範囲に応じ、サイトの改ざんや情報の読み取りなどにつながるおそれがあります。サーバー全体の管理者権限を必ず奪われる、という意味ではありません。

1件目は、メモリー不足で止まった後の不正な処理です

CVE-2026-109618では、PHPが内部データを作り終える前にメモリー不足で処理を中断すると、未完成のデータが残る場合があります。その後の終了処理が、このデータを正常なものとして扱ってしまいます。

たとえば、細工されたファイル送信形式のリクエストを解析する際に、多くのメモリーを使わせる経路が説明されています。単に「サーバーの搭載メモリーが少ない場合だけ」の話ではなく、PHPに設定した使用上限へ攻撃者の入力で到達させることも問題になります。

特にApacheのmod_phpという構成では、起動に失敗しても終了処理へ進むため、WordPressなどのアプリケーションが動き始める前に攻撃が成立する実証があります。WordPressへのログインや、不正なPHPファイルの事前設置を必要としない経路です。PHP開発元による1件目の技術説明で確認できます。

2件目は、前のアクセスの情報を次の処理で使ってしまう問題です

CVE-2026-109619では、あるリクエストの処理が致命的なエラーなどで終わった後に、その処理用メモリーへの参照が残る場合があります。メモリー自体は解放されているのに、同じワーカー、つまりリクエストを処理するプロセスが次のリクエストを受けると、初期化前に古い参照を使ってしまいます。

この「すでに解放したメモリーを使う」状態を、攻撃者が都合のよい状態へ誘導できると、コード実行につながります。セッションやエラー処理など複数の経路があり、特定の設定を一つ無効にすれば全部解決、という問題ではありません。2件目の公式説明も、完全な修正を含む版への更新を求めています。

どちらも、普通のアクセスがすべて攻撃になるわけではありません。また、HTTPにコマンドの文字列を書けば必ずそのまま実行される、という仕組みでもありません。攻撃が届く処理、PHPの構成、メモリーの状態などの条件があります。

対象のPHPバージョンと修正版

サポート中の系列では、次の版より前が対象です。系列ごとの修正版を確認してください。

PHP 8.1以前の古い系列も、古いから今回の対象外になるわけではありません。PHP開発元の通常サポートは終了しています。今回、7.4・8.0・8.1向けに最小限のソース修正も提供されましたが、通常サポートが復活したわけではないため、配布元の対策状況を確認するか、サポート中の系列への移行が必要です。

ただし、LinuxのOSパッケージには、元のバージョン番号を保ちながらセキュリティ修正を取り込む「バックポート」があります。たとえばUbuntu公式の今回の修正情報には、8.3.6から始まる番号でも修正済みのパッケージが載っています。先頭の数字だけで未対応と決めず、利用している配布元の修正済みパッケージ番号と照合してください。

公開サイトを自分で管理している方は、緊急対応を

PHP公式は、Webリクエストを処理するPHP全般を対象に挙げています。mod_phpが最も高いリスクとされていますが、PHP-FPM、php-cgi、FrankenPHP、LiteSpeedだから対象外とは判断できません。

CERT-EUも、検証用の攻撃コードが流通し始めているとして、即時の修正を勧めています。更新できない場合には、インターネットに公開しているアプリケーションを、修正と確認が済むまで公開ネットワークから隔離することも検討するよう求めています。CERT-EUの注意喚起は、公開された攻撃実証と、実際の被害確認を同じものとしては扱っていません。

今回のように重大な脆弱性の事前告知がある場合、未修正の自主管理サーバーでは、詳細の公表前から一般アクセスを遮断して備える判断ができます。「公表前」はサイトを新しく公開する前ではなく、脆弱性の情報や技術詳細が世の中に出る前、という意味です。公表後すぐに攻撃される可能性を考え、修正までの無防備な時間を作らないためです。

この記事の時点では、すでに詳細が公表されています。まだ未対策で、すぐには更新を完了できない場合は、管理者とサービス停止の影響を確認し、今からでも外部アクセスの制限を検討してください。

無停止にこだわって未修正のPHPを公開し続けるのは避けてください。順序は「PHPに届く手前でアクセスを制限 → 修正版を適用 → 再起動・動作確認 → 制限を解除」です。制限はWebサーバー、プロキシ、ファイアウォールなどで行います。WordPressなどのアプリケーションの処理前に起こる攻撃もあるため、WordPressが動いてからメンテナンス画面を出すだけでは代わりになりません。事業者が対策済みの共有レンタルサーバーまで、一律に閉鎖する話ではありません。

管理者には、複数のPHPや別ドメイン、旧サイトも含め、実際に使っているPHPを確認してもらいます。バックアップと復旧手順を確保し、修正版または配布元の対策済みパッケージを適用したら、案内に従いPHP-FPMやApacheなどの対象プロセスを再起動してください。コマンドラインの php -v だけでなく、実際にWeb側で動くPHPへの反映を確かめます。

制限を解除する前に、表示、ログイン、問い合わせ送信、ECならカートや購入の動作も確認します。古い系列からの移行で互換性が問題になる場合も、無期限に延期せず、当面の制限と移行予定を管理者と決めてください。

レンタルサーバー利用者は、更新ボタンより事業者の告知を

共有レンタルサーバーを使っている方は、サービスのお知らせで、今回の2件への対応を確認してください。「順次対応中」なら、自分のサーバーやPHP系列の完了時期が分かるかを見ます。古い系列を利用中の場合は、利用者が対応済みの系列へ切り替える操作を求められていないかも確認します。

告知だけでは判断できなければ、サポートへ「このプランで使っているPHPは、CVE-2026-109618とCVE-2026-109619への対策が済んでいますか。利用者側の操作は必要ですか」と聞けば、確認点が伝わります。

WordPressの更新ボタンを押すだけでは、PHP本体は修正されません。WordPress公式のPHP更新案内も、PHPのバージョンはサーバー側で設定され、ホスティングの設定や事業者への依頼が必要になると説明しています。

また、WAFやセキュリティプラグインが入っていること、アップロード機能を使っていないことだけで、対応不要とは判断しないでください。PHP公式が示す設定変更も一部の攻撃経路を減らすもので、更新の代わりになる完全な対策ではありません。

PHPを動かさず、HTMLなどを配信するだけの環境には、今回のPHP更新は必要ありません。ただし、見えるページが静的でも、フォームや管理画面、同じサーバーの別サイトでPHPを使っていないかは分けて確認します。

今回は、サイトを作り直すかを決める前に、稼働中のPHPへの対策を済ませる案件です。更新後も不審なファイルや動作が見つかっているなら、更新しただけで侵害前の状態へ戻ったとは扱わず、管理者へ調査を依頼してください。

誰がPHPを管理しているか分からない、制作会社とサーバー会社のどちらへ頼めばよいか整理できない場合は、契約先と現在の保守範囲をそろえて、ウェブモへ既存サイトについてご相談ください。

情報確認：2026年10月22日0時53分（日本時間）。公開後に情報が更新される可能性があるため、対応時にはPHP開発元と利用中の事業者の最新情報も確認してください。