PHP、深刻な脆弱性2件の緊急セキュリティパッチを公開

ブラウザーがページを要求すると、PHPは必要な情報をメモリに置いて処理します。メモリは作業中にしばらく広げておく机、ワーカーはその仕事を受け持つ担当者だと考えてみてください。一人の担当者が要求Aを終えてから要求Bを受け持つこともあるため、要求が終わったらAの一時情報を片付ける必要があります。

ここで扱うのは保存済みの記事ファイルではなく、PHPが実行中に使う一時情報と、その置き場所を示す参照、つまり「どこを読めばよいかを示す住所札」です。住所札だけが残り、その場所がもう片付けられていたら、次の仕事は間違った情報を読んでしまうかもしれません。公式の状態残留の説明

サイトが要求を処理するには、一時的な作業場所であるメモリが必要です。PHPには一つの要求がメモリを使いすぎないよう上限があり、上限に達して処理を止めること自体は保護の仕組みです。では、止まる瞬間に内部の情報が半分しか作られていなかったらどうなるでしょうか。

一つ目の欠陥CVE-2026-109618では、メモリ不足で処理の途中から急に抜けた後、終了処理が作りかけの情報を正しい情報として扱う可能性がありました。書きかけの注文票を、完成済みだと思って次の担当者へ渡す状況に近いものです。サイトが少し遅くなる話とは違い、プログラムが不正なメモリを扱うことで実行の流れまで影響を受け得ます。PHPによる原因説明

修正は、「止めなければならない」ことを記録しておき、安全に止められる実行地点で中断するように変えたものです。その前にさらに高い最終上限に達した場合は、担当するプロセスを直ちに終了する緊急経路も別にあります。図は8.5の修正の流れを単純化したもので、メモリの上限をなくしたり、コンピューター全体の電源を切ったりする修正ではありません。

二つ目の欠陥CVE-2026-109619は、「資料」と「資料の場所を書いたメモ」の寿命がずれる問題です。PHPのワーカーが訪問者Aの要求を終えて一時メモリを解放しても、その中の資料を指す状態の一部が残ることがありました。同じワーカーが次の要求Bを受け持つとき、新しい初期化が終わる前にその古い状態に触れる経路があったのです。公式説明

資料を処分したのに「その資料は3番の棚にある」というメモだけが残っている場面を想像してください。次に3番の棚を開けても、同じ資料があるとは限りません。このたとえが示しているのは、もう無効になった置き場所の情報を信じ続けてしまう点です。実際はPHP内部のメモリの欠陥で、前の訪問者の記事が画面にそのまま残るような現象を指しているわけではありません。

修正では、前の要求が終わるときに残った参照や状態を空にし、終了処理中に再び生じる情報や、次の初期化前のアクセス経路も合わせて扱います。「次のお客さんが来たら片付くだろう」に任せず、今の仕事を終えるときに、次の仕事が間違った情報を手に取らないようにするのが要点です。

PHP 7.4は、PHPプロジェクトの通常サポートが終了した系列です。今回は重大性を踏まえ、古い系列向けに移し替えた最小限の修正コードが特別に提供されました。これをバックポートと呼びます。コードが公開された後も、ホスティング会社がそれをパッケージにまとめて配布し、自分のサーバーに適用するまでには、まだ段階が残っています。公式案内・サポート終了記録

7.4の修正は、8.5とは別に作られた最小限の対応です。危険なメモリエラーが起きたらワーカーを終了し、解放済みの置き場所の情報を空にし、確認されたセッションのアップロード進捗処理の経路をふさぎます。通常のファイルアップロード機能をすべて止める修正ではありません。実際の違いは後半のコード付録にあります。

架空の「ホスティングA社」を例にします。会社と状況は説明用ですが、PHP修正版の番号は実在します。管理画面にPHP 8.3.35と出ていたら、「8.3系列だから大丈夫」で終わらせず、8.3.36または二つの修正をバックポートしたパッケージが提供・適用されたかを尋ねます。7.4.33なら、新しい公式の7.4番号を待つよりも、延長サポートの修正があるか、サポート中の系列へ移る道筋はあるかを尋ねます。

WordPressはPHPの上で動くアプリです。WordPress本体・プラグインを更新することと、サーバーが動かすPHPを直すことは、別の層の作業です。PHP公式の発表は、Web要求を扱うすべてのPHP環境に更新を勧めたうえで、なかでもmod_phpのリスクが最も高いとしています。アプリのコードが動く前に、認証なしの要求で攻撃が起きる例を実証したというのがその理由です。PHP発表・WordPressのPHP更新案内

mod_phpはApache Webサーバーの中でPHPを動かす方式、PHP-FPMは別のPHPワーカーが要求を受けて処理する方式です。一つ目の勧告に、FPMの特定の開始段階の経路には制約があるとの記述があっても、FPM全体が安全だとは読めません。二つ目の勧告には、条件を満たすFPMの経路も検証されたと記録されています。一つ目の条件・二つ目の条件

10月22日朝、私が個人のWordPress運用に使っているCloudwaysで、稼働中のアプリ一つのPHPを実際に変更しました。別のステージング複製を作らず、本番アプリで行った記録です。サイト名・ドメイン・アカウント・サーバー識別子は公開していません。

まず、ファイルとデータベースの復元ポイントを10月22日06:57:52 JSTに確保しました。このアプリのApplication Settings → PHP Settingsで選べる最新の系列は8.4でした。アプリ単位の選択機能を使ったので、今回の変更はこのアプリ単位で、サーバー全体のすべてのPHP環境を変えたわけではありません。Cloudwaysのアプリ別変更手順

Cloudwaysは、PHPの変更成功を通知しました。続けてWordPressのツール → サイトヘルス → 情報 → サーバーを読み込み直すと、Web PHPは7.4.33から8.4.26に変わっていて、実行方式はPHP-FPMを示すfpm-fcgiでした。以下は同じ作業の実際の画面で、製品画面をAIで描き直した画像ではありません。

Cloudwaysは10月22日07:19 JST、PHP公式の推奨する暫定設定を全体に適用し、正式パッチを段階配布中だと発表しました。続く10:02 JSTの更新では、Autonomousの全顧客アプリにパッチを適用済みで、Flexibleでは配布を継続中としています。AutonomousとFlexibleは別のホスティング商品で、今回作業したアプリはFlexibleです。Cloudways公式対応情報

10月22日14:03 JST、同じアプリのWordPressサーバー情報を読み込み直すと、Web PHPは8.4.27、実行方式はfpm-fcgiと表示されました。PHP公式の8.4.27の変更履歴には、今回の二つのセキュリティ勧告への修正が載っています。このアプリで実際にWeb要求を処理するPHPが公式修正版に変わったことを確認できました。今回の再確認ではバージョン変更や設定保存は行っておらず、パッケージが置き換わった正確な時刻は不明です。8.4.27の公式変更履歴

Cloudwaysは10月22日19:11 JST、PHPセキュリティパッチの配布が完了し、全稼働サーバーの更新を終えたと発表しました。19:20 JSTにも同じ内容を掲載し、追加支援が必要な一部の顧客にはサポートから個別に連絡していると説明しています。19:22 JSTには問題の継続監視を案内し、当時のインシデントの状態はmonitoringでした。Cloudwaysの配布完了案内

このアプリの最後の直接観測は、14:03 JSTのWeb PHP8.4.27 / fpm-fcgiです。夜は認証済みのアプリセッションにアクセスできず、追加の実行環境の確認はできませんでした。提供元の全体向け完了発表と午後のアプリ観測をそれぞれの時点で記録し、CLI・予約処理・全プラグイン機能まで点検した結果には広げません。

上の表と下の警告写真は朝07:08 JSTの記録です。14:03 JSTの再確認では、max_input_vars10000、post_max_size100M、送信上限30M、メモリ上限-1、実行時間300秒と表示されました。-1はPHPの該当メモリ上限がない設定で、今回の点検ではこれらを変更していません。誰がいつ、何のために変えたかはこの画面から分からないため、朝の10Mの警告や提供元の暫定措置が今も同じ状態とは断定しません。

バージョンを変えると設定も変わることがあり、今回も入力に関わる上限が二つ変わって見えました。入力上限が変わっただけで故障とはいえませんが、項目の多い設定画面やメニューを保存する機能は試しておきたいところです。今回見たのは上記の閲覧機能までで、全プラグイン機能・投稿保存・ファイル送信・予約処理はまだ試していません。

朝の点検では、この警告を消すためだけに要求の上限を以前の100Mには戻しませんでした。PHPの公式案内には、一部の攻撃経路への露出を減らす暫定策として要求サイズを低く抑える推奨もあります。朝の10Mや入力項目の上限がその措置によるものかは未確認で、午後に変わった値の変更理由も分かっていません。この記録を、上限を引き上げたりメモリ制限を外したりする推奨設定として使わないでください。今回の追加点検では設定を保存していません。PHP公式の暫定策と限界

7.4を当面どう扱うにしても、サポート中の系列へ移る計画は別に立てる必要があります。Cloudwaysの現行のFlexible向け案内では、My Applications → 対象アプリ → Application Settings → PHP Settings → PHP Versionからバージョンを選びます。アカウント・OS・画面によって経路や提供範囲は異なる場合があり、例えば公式文書では8.4にDebian 11または12が必要とされています。Cloudwaysの変更手順

• まず、ファイルとデータベースの最新バックアップと復元方法を用意します。
• WordPress・テーマ・プラグインが対象のPHPに対応しているかを調べ、複製した試験環境で先に変えてみます。
• 対象系列の最終修正パッケージが提供されているかを提供元に尋ねてから、本番へ適用します。同じサーバーの別アプリにどこまで及ぶかも見ておきます。
• 適用後は、記事閲覧・管理者ログイン・検索・問い合わせ・予約・決済など、実際に使う機能を点検します。WordPressのツール → サイトヘルス → 情報 → サーバーでWeb PHPのバージョンを見直し、バックポートなら提供元の修正履歴と一緒に記録しておきます。

PHP公式の案内には、一部の設定で露出を減らす暫定措置もありますが、完全な解決は更新だけだと明記されています。メモリ上限をむやみに外すような設定を、初心者がそのまま真似する解決策としては勧めません。公式措置と限界・サイトヘルスの案内