PHPの重大な脆弱性の修正が前日に予告されたのは、公開と同時に攻撃が始まりうる種類の脆弱性について、利用者が公開時刻に一斉に更新できるよう先に準備させるためです。PHP公式が書いている目的は「公開されしだい更新できるよう今から準備を」で、以下の理由1〜4は、事前告知という手法の一般的なしくみ（distros リスト・OpenSSL の方針）から整理したものです。これは「事前告知（pre-announcement／pre-notification）」という手法で、中身は伏せて日時と深刻度だけを知らせ、OSの配布元には先にパッチを渡し、詳細が漏れたら前倒しで公開する、という組み合わせでできています。PHP公式は2026年10月20日（UTC。日本時間では21日早朝）、翌21日14:00 UTC（日本時間23:00）のセキュリティリリースを予告しました。脆弱性そのものの影響と修正版はPHPの重大脆弱性php2shellは自分のサイトも対象？修正版と確認手順で解説しています。
【結論】
- なぜ予告するか：修正版が出れば、差分から欠陥の場所を突き止められるおそれがあります。「公開＝攻撃開始の合図」になりうるため、公開時刻に更新できる体制を先に作らせます。
- 何が書かれるか：日時・件数・深刻度だけ。中身・影響バージョン・修正版は公開と同時に出し、配布元には先にパッチを渡します。
- 運用側の使い方：PHPがどこで動いているかの棚卸し、公開時刻の作業枠の確保、レンタルサーバーなど配布元のお知らせの確認を、予告を見た時点で始めます。
10月20日の事前告知に書かれていたこと・書かれていなかったこと
PHP公式の告知「Upcoming Critical PHP Security Release」（PHP公式 2026年ニュースアーカイブ）の要点です。
| 書かれていたこと | 書かれていなかったこと |
|---|---|
| 公開日時：2026年10月21日（水）14:00 UTC（日本時間23:00） | 脆弱性の中身（どの機能の、どんな欠陥か） |
| 件数と深刻度：critical（重大）な脆弱性2件、どちらもCVSS v4.0で9.2 | CVE番号・影響を受けるバージョン・修正版の番号 |
| 依頼：公開されしだい更新できるよう、今から準備を | 更新できない場合の緩和策 |
| 留保：詳細が公になるか悪用の証拠が出れば前倒しすることがある | 配布元にパッチをいつ渡したか |
告知は「Full details, affected versions, and the fixed versions will be published with the release.（詳細・影響バージョン・修正版はリリースと同時に公開する）」とあり、実際に21日、CVE-2026-109618・109619の2件と修正版8.5.12・8.4.27・8.3.36・8.2.35が公表されました。GitHub上のアドバイザリ（GHSA）の公開時刻は13:34 UTC（日本時間22:34）です。
理由1：修正版の公開そのものが攻撃の手がかりになるから
PHPはオープンソースで、修正版はソースコードでも配布されます。修正の前後を見比べれば、どこを直したかが分かります。オープンソースの脆弱性を配布元に非公開で共有する「distros」メーリングリストの規約（oss-security：distros リスト）も、「In case the fix is already in a publicly accessible repository, we generally consider the issue public（修正が誰でも見られるリポジトリにあれば、原則として公開済みとみなす）」としています。
この規約に沿えば、修正の公開は脆弱性の公開と同じ扱いになります。PHPの予告が「prepare now so they can upgrade as soon as the release is available（公開されしだい更新できるよう、今から準備を）」と求めたのは、この「公開＝攻撃開始の合図」に利用者を間に合わせるためと考えられます。
実際、CERT-EUは公開当日の注意喚起（Security Advisory 2026-018）で「initial proofs of concept (PoCs) have begun to circulate（初期の概念実証コードが出回り始めた）」とし、すでに悪用されている可能性が高まったと評価しました。
理由2：中身を伏せたまま「準備」だけを先に始めさせられるから
中身を書けば、修正版がない状態で攻撃の手がかりを渡すことになります。「重大な修正が、いつ出るか」だけなら、渡る情報を最小限にしたまま利用者は準備を始められます。
IPAの10月21日の「事前準備のお願い」（IPA：【事前準備のお願い】PHPのセキュリティリリース公開予定について）は、この使い方の典型です。IPAは悪用を確認していないとしたうえで、次を求めました。
- 開発・運用しているプログラムのうち、PHPを利用しているものの棚卸し
- 公開後、速やかにセキュリティリリースを適用できる準備
- 製品や機器の内部でPHPが使われている場合は、開発元・提供元の情報の確認
影響バージョンが分からなくても、どこでPHPが動き、誰が更新するかは先に調べられます。
理由3：配布元に先にパッチを渡し、公開日にそろえて出せるから
多くのサーバーは、PHPをLinuxディストリビューションのパッケージやレンタルサーバー経由で使っています。PHP公式のアドバイザリ（PHP公式：セキュリティアドバイザリ（2026年10月21日））は「Linux distributions and LTS vendors received the patches in advance（Linuxディストリビューションと長期サポート〈LTS〉ベンダーは事前にパッチを受け取っている）」としています。公開日に配布元のパッケージもそろえば、利用者はいつもの手順で更新できます。
配布元に非公開で情報を渡す代表的な仕組みが、前述の「distros」リストです（PHPが今回これを使ったかどうかは、公式の告知に書かれていません）。
| 項目 | distros リストの規約（要旨） |
|---|---|
| 対象 | まだ公開されていない（まもなく公開される）オープンソースの脆弱性 |
| 参加者 | Debian・Red Hat・SUSE・Ubuntu・Amazon Linux・AlmaLinux など各ディストリビューションのセキュリティ担当 |
| 非公開の期間 | 「The maximum acceptable embargo period … is 14 days」＝最長14日。7日未満が望ましい |
| 受け取った側の義務 | 合意した公開日時まで、公開・共有もほのめかすことも禁止。原則として修正以外に使わない |
理由4：「漏れたら前倒し」の留保で、待つあいだのリスクに備えるから
PHPの予告には「We reserve the right to release earlier should details of either vulnerability become public, or should evidence of active exploitation appear in the wild.（いずれかの詳細が公になるか、実際の悪用の証拠が見つかれば、前倒しで公開する権利を留保する）」とありました。
待つあいだに詳細が漏れたり攻撃が始まったりすれば、待つ意味はなくなります。利用者にとっては「予定より早く来ることもある」という意味で、準備は告知を見た時点から始める必要があります。
先に受け取る側にも縛りがあります。distros リストは漏洩時の報告と調査を義務づけ、OpenSSLのセキュリティ方針（OpenSSL：Security Policy）は、公開前に漏らした組織を今後の事前通知の対象から外すことがあると定めています。なお、今回のGHSAの公開時刻（13:34 UTC）は予定の14:00 UTCより早いものでしたが、留保によるものかどうかは公式の告知に書かれていません。
前例：OpenSSLとDrupalの事前告知
事前告知はPHPだけの手法ではありません。原文で確認できた2つの前例と比べます。
| OpenSSL（方針） | Drupal（PSA-2018-001） | PHP（2026年10月） | |
|---|---|---|---|
| 予告の時期 | 通常、リリースの1週間前 | 2018年3月21日（1週間前） | 2026年10月20日（前日） |
| 予告に書くこと | 予定日時と深刻度のみ。「No further information about the issues will be given.」 | 日時（3月28日18:00〜19:30 UTC）・深刻度・対象バージョン・CVE番号（CVE-2018-7600） | 日時・件数・深刻度 |
| 配布元への先行提供 | Critical・High・Moderateは、OS配布元などに詳細とパッチを通常2週間前に | 予告に記載なし | ディストリビューション・LTSベンダーが事前に受領 |
| 実際の公開 | ― | 3月28日 SA-CORE-2018-002（CVE-2018-7600・リモートコード実行） | 10月21日 CVE-2026-109618／109619 |
Drupalの予告（Drupal：PSA-2018-001）は、攻撃コードが「within hours or days（数時間から数日で）」作られうるとして、その時間帯に更新作業の時間を確保するよう求めました。1週間後のSA-CORE-2018-002は、サイトが完全に乗っ取られるおそれのあるリモートコード実行の脆弱性でした。予告に中身を書かない点は3者に共通し、配布元に先に渡す点はOpenSSLの方針と今回のPHPに共通します。
欠点と限界：予告は攻撃者にも届く
- 攻撃者も「大物が来る」と分かる：CERT-EUは、予告に続けて「Public reports indicated that these vulnerabilities could lead to remote code execution（公開の報告で、リモートコード実行につながりうると示されていた）」と書いており、予告の段階で注目が集まっていたとみられます。IPAは「サポート終了の古いPHPを利用し続けているウェブサイト・ウェブサービスも見受けられます」とし、「極めて短時間で攻撃を実行する可能性」に触れています。
- 準備の時間が短いことがある：今回は予告（php.net の掲載は10月20日20:32 UTC）から公開（21日13:34 UTC）まで約17時間で、OpenSSLの方針やDrupalの前例（1週間）より短いものでした。
- 予告段階の情報は不確か：IPAは予告時点で影響バージョンを「確認できていません」とし、当時のCERT-EUの注意喚起にあった「PHP 5以降」という記載を紹介しました。公開後のCERT-EU（v1.1）は、8.2〜8.5の修正版より前と8.1以前を対象としています。
- 配布元が全員、当日に出せるとは限らない：CERT-EUは、ボランティア運営のリポジトリ（rpms.remirepo.net）は「will not have updates on release day（公開当日には更新されない）」としています。
- サポート終了版は恩恵を受けにくい：PHP 8.1以前はPHPプロジェクトからの更新がありません（7.4・8.0・8.1向けに最小限のソースのバックポートはあり）。
運用側は事前告知をどう使うか
- 受け取り口を決める：php.net のニュースやIPAの情報に加え、レンタルサーバーやクラウドの利用者は契約先のお知らせも見ます。
- 棚卸し：PHPが動いているサーバー・サイト・製品と、バージョン・実行方式（PHP-FPM、mod_php、LiteSpeedなど）を書き出します。
- 作業枠の確保：公開時刻を日本時間に直します。今回は23:00でした。更新・再起動・動作確認を誰がいつ行うかを決めます。
- 更新の経路を確かめる：自前ビルドか、ディストリビューションのパッケージか、レンタルサーバー任せか。経路によって「公開と同時に直せるか」が変わります。
- 当日直せない場合を調べる：緩和策は公式が「完全ではない」としています。内容はPHPの重大脆弱性php2shellの解説にまとめています。
当サイトの実例：レンタルサーバーの配布は公開日に間に合うとは限らない
当サイトの記録では、2026年10月22日時点で、お名前.com レンタルサーバー（RSプラン）のPHP 8.4は8.4.21で、修正版8.4.27より前でした。PHP公式の公開の翌朝の時点では、修正版はまだ届いていませんでした。手順と経過はお名前.comのPHPを7.4から8.4に変更する手順｜php2shell対応に記録しています。PHP公式が「先にパッチを受け取った」と書いているのはLinuxディストリビューションとLTSベンダーです。レンタルサーバーや製品の利用者は、予告を見た時点で「自分の配布元はいつ出すのか」を確かめておく必要があります。国内の攻撃事例は2026年 国内の情報漏えい・サイバー攻撃一覧にまとめています。
よくある質問
事前告知が来たら、すぐにPHPを更新する必要がありますか？
予告の時点では修正版はまだ出ていないため、更新はできません。この段階では、PHPを使っているサーバーや製品の棚卸しと、公開時刻にすぐ更新できる準備を進めます。IPAも予告の段階では棚卸しと準備を求めていました。
なぜ脆弱性の中身を先に教えてくれないのですか？
修正版がない状態で中身が広まると、攻撃の手がかりになるおそれがあるためと考えられます。PHPの予告は、詳細・影響バージョン・修正版はリリースと同時に公開するとしていました。OpenSSLの方針も、予告では日時と深刻度以外は出さないとしています。
予告された日時より早く公開されることはありますか？
ありえます。PHPの予告は、詳細が公になった場合や実際の悪用の証拠が見つかった場合には、前倒しで公開する権利を留保していました。予定時刻を待たず、告知を見た時点から準備を始めることが大切です。
レンタルサーバーなら事前告知は気にしなくてよいですか？
更新は事業者が行いますが、修正版がいつ配布されるかは事業者によります。当サイトの記録では、2026年10月22日時点でお名前.com RSプランのPHP 8.4は8.4.21で、修正版8.4.27より前でした。契約先のお知らせを確認してください。
PHPはセキュリティリリースのたびに事前告知を出しますか？
PHP公式の2026年のニュースアーカイブで確認できた範囲では、事前告知は10月20日の1件だけで、5月・7月・9月のセキュリティリリースの前には見当たりませんでした。確認したページには、予告を出す条件の説明もありませんでした。
あわせて読みたい：修正版の公開後、各社はいつ配布したか（対応状況まとめ）
まとめ
- 事前告知は、公開と同時に攻撃が始まりうる脆弱性について、公開時刻に一斉に更新できるよう準備させる手法です。
- PHPの10月20日の予告は日時・件数・深刻度だけを伝え、配布元には事前にパッチを渡し、漏洩や悪用があれば前倒しする留保をつけていました。
- OpenSSLは方針として通常1週間前に予告し、Drupalも2018年に1週間前の予告を出しています。
- 予告は攻撃者にも届きます。棚卸し・作業枠の確保・配布元のお知らせの確認を、予告を見た時点で始めます。
参考（確認日：2026年10月22日）
- PHP公式：Upcoming Critical PHP Security Release（2026年10月20日の事前告知）
- PHP公式：セキュリティアドバイザリ（2026年10月21日）／2026年のニュースアーカイブ
- GitHub（php/php-src）：GHSA-w8hw-w9fx-j79w（CVE-2026-109618）／GHSA-6wmf-4rv5-p3rp（CVE-2026-109619）
- IPA：【事前準備のお願い】PHPのセキュリティリリース公開予定について（2026年10月21日）
- CERT-EU：Security Advisory 2026-018 Critical Vulnerabilities in PHP
- Openwall（oss-security）：Operating system distribution security contact lists（distros）
- OpenSSL：Security Policy（Prenotification policy）
- Drupal：PSA-2018-001／SA-CORE-2018-002
コメント