policies

脆弱性を見つけたら Issue に書いちゃだめ？ エンバーゴと非公開の報告 脆弱性を見つけても、Issue や SNS など、だれでも見られる場所には書きません。修正と説明を公開の日にそろえて出す約束（エンバーゴ）があるので、SECURITY.md を見て非公開で報告します。 報告から一斉公開までの流れ、どこを見ていれば公開を知れるか、事前の告知が出たら準備することは、元の動画で解説しています。画面の下の関連動画から見られます。 ※ 事例は、PHP の公式の告知と、投稿した本人の謝罪の投稿で確かめられる範囲だけを扱っています（2026年10月26日時点）。投稿した方は個人のため、名前は出していません。 ■ 元の動画 脆弱性のエンバーゴとは？ PHP の RCE で見る、公開日まで情報を伏せる理由と報告のしかた ■ 出典 PHP「Upcoming Critical PHP Security Release」（2026年10月20日） php.net PHP「Vulnerability Disclosure Policy」（CC BY 4.0） github.com/php/policies/blob/main/security-classi… CERT/CC「The CERT Guide to Coordinated Vulnerability Disclosure」 certcc.github.io GitHub Docs「Coordinated disclosure of security vulnerabilities」（CC BY 4.0） docs.github.com GitHub Docs「Privately reporting a security vulnerability」（CC BY 4.0） docs.github.com ■ クレジット VOICEVOX:ずんだもん #脆弱性 #セキュリティ #GitHub

PHP のパッチは普段いつ出るのか。php2shell で初めての事前予告と、25分早い公開と、2年止まった修正 2026年10月21日の夜、日本時間23時の「PHP 修正版の公開」を待って待機していた人は多かったと思います。 私もそのひとりでした。そして待ちながら、ふと引っかかったことがあります。PHP のセキュリティ修正って、そもそも普段は予告なんてしていましたっけ。 前回の記事『修正版は23時のはずが22時31分に出ていた。php2shell で日本の約200組織が止まった夜の時系列』では、あの夜に何が起きたかを時刻つきで記録しました。この記事はその続きで、PHP の修正が普段いつどう出るのか、php2shell で何が異例だったのか、次回どこを購読しておけばよいかが分かります。 想定読者は、PHP を使っている、または基盤に PHP が含まれるサービスを運用しているエンジニアと運用担当者です。脆弱性の技術的な中身や対策手順は扱いません。 23時のはずが、22時31分から出ていた 当夜に国内で何が起きたかの時系列は、前回の記事を参照してください。ここでは PHP 側の「出し方」だけを追います。 予告は「14:00 UTC」、日本時間で23時ちょうどでした。「around」も「no later than」も付いていない、幅のない書き方です。 ところが実際には、修正版は23時より前から取得できました。一次記録（リポジトリの push 記録、ページの Last-Modified、GitHub API の公開時刻）で確認できた順番は次のとおりです（差は秒単位の記録から算出しています）。 時刻（JST） 公開されたもの 予告の23:00との差 22:31 修正版の配布ファイル（tarball）を公開リポジトリへ push 約28分前 22:33〜22:34 php.net の告知5本（1回の push でまとめて）、リリースページ、配布ページ 約26〜27分前 22:34 GitHub のセキュリティ勧告（GHSA）2件 約26分前 22:35 サポート終了版向けパッチのブランチ 約24分前 22:48〜22:54 Windows 版、CVE レコード 約5〜11分前 23:00 php.announce のメール告知（23:00:28 と 23:00:57 の2通） 予告どおり 23:06〜23:09 GitHub Release 4件 7〜9分後 配布物と勧告が22時31分から35分にかけて続けて上がり、メールだけがきっちり23時。これが事実です。 普段の PHP は公開時刻を決めておらず、たとえば9月24日のリリースでは4本の告知が UTC の10時04分から15時28分まで、約5時間半に散らばっていました。今回は逆に4バージョンの告知を1回の push にまとめ、勧告と配布物を数分間に揃えています。ただし「勧告と php.net の告知が先に出て、メールと GitHub Release が後から追う」順序自体は9月24日と同じで、その普段どおりの順序を23時の手前に置いた結果、予告より前に見えた、と整理できます。 言えることと、言えないこと ここからは推測です。私は「23時に配布物と告知と勧告が揃うように、約25分前から順に載せていった段取り」が最も自然だと考えています。根拠は、告知5本が前夜に執筆済みで1回の push でまとめて出ていること、php.net はミラーや CDN への反映に時間がかかること、2人のリリースマネージャーがメール告知を23時の1分以内に送っていることの3つです。 ただし、PHP 側が「早めた」「準備ができ次第出した」と述べた記録は見つかりませんでした。予告文には「詳細が公になるか悪用の証拠が出たら早める権利を留保する」とありますが、この約25分がその条項の発動だと PHP が述べた記録もありません。 ! 「21時59分に公開されていた」という情報が国内で広まりましたが、これは誤りです。21時59分は php.net のリポジトリに刻まれた作業時刻（rebase の時刻）で、公開ではありません。実際の push は22時33分でした。したがって「約1時間の前倒し」も誤りで、実際は約25分です。 PHP のセキュリティリリースは普段いつ出るのか: 4週ごとの木曜に、黙って出す この「予告つき、時刻合わせ」の出し方は、PHP の平時とはかけ離れています。平時のセキュリティ修正は、報告から公表まで次の6段階を通ります。 1. 報告は非公開で届く。 窓口は GitHub の Private Vulnerability Reporting か security@php.net で、報奨金はありません。 2. 深刻度は High / Medium / Low の3段階。 High と Medium は非公開のセキュリティ用リポジトリで修正します。 3. CVE は PHP Group が自分で振る。 PHP Group は2019年から CNA（CVE 採番機関）で、外部の審査待ちに依存しません。 4. 修正は4週ごとの定例リリースに同梱する。 曜日は木曜が慣例で、臨時リリースは「高リスクの問題」の例外扱いです。報告者への目安も「通常は次の月次リリース」と書かれています。 5. 公表は「Released!」記事に一言。 php.net の「PHP 8.x.y Released!」記事に「This is a security release」と添えられるだけで、技術詳細は GitHub Security Advisory（GHSA）と CVE に載ります。 6. 日時の事前予告はしない。 php.net のニュース記事は2015年1月から2026年10月までで889件ありますが、公開日時を事前に予告した記事は、今回の2026年10月20日（UTC。日本時間では21日未明）の1件だけでした（2015年より前は未確認です）。 つまり平時の PHP は、利用者から見ると「木曜の朝に起きたら新しいバージョンが出ていて、よく読むとセキュリティ修正が入っていた」という静かな出方をします。 今回の php2shell で異例だったこと 平時の流れを頭に置いたうえで、今回の php2shell（CVE-2026-109618 / CVE-2026-109619）の公表を並べます。「手順の変化」と「人と組織の変化」の2つに分けました。 # 項目 普段の PHP 今回 手順の変化 1 日時の事前予告 しない 10月20日に日時を予告 2 リリース日 4週ごとの定例木曜 定例日10月22日を1日前倒し 3 告知の形 「Released!」記事に一言 別立ての勧告記事で緩和策まで 4 サポート終了版 更新しない 7.4〜8.1 にソースパッチ 人と組織の変化 5 事前共有の相手 主要ディストリ 重要インフラ事業者にも緩和策 6 協調の範囲 セキュリティチームと報告者 OpenAI が政府・インフラと調整 7 修正までの期間と意思決定 次の月次リリースが目安 2年近く停滞、多数決へ転換 順に補足します。 予告（1）は、php.net ニュースで少なくとも2015年以降で初めてでした。 予告の原文はこうです。 The PHP security team would like to give advance notice of an upcoming security release. It is scheduled for Wednesday, 21 October 2026 at 14:00 UTC. It addresses two critical vulnerabilities, both rated CVSS v4.0 9.2. All PHP users are encouraged to prepare now so they can upgrade as soon as the release is available. We reserve the right to release earlier should details of either vulnerability become public, or should evidence of active exploitation appear in the wild. 出しているのは日時、件数、深刻度だけです。予告が出た時点ではすでに CVE 番号2件が SNS で出回っていたので、予告に含まれる情報は流出していた分より少ないことになります。少なくとも「予告が先に攻撃者へ情報を与えた」という順序ではありません。 Foundation は、予告はもともと出す計画で、流出を受けて前倒しして出したと書いています。ただし「なぜ事前予告という手段を選んだのか」そのものは書かれていません。説明があるのは1日前倒しの理由で、「ディストリがまだパッケージング中で、即時リリースでは多くの利用者に簡単な更新手段がない」という趣旨でした。 リリース日（2）は、もともと定例日でした。 直近の定例リリースが9月24日（木）で、その4週後が10月22日（木）です。PHP は「普段どおりの定例日に出す予定を、予告付きの特別扱いにしたうえで、情報流出を受けて1日前倒しした」というのが正確な姿です。 告知の形（3）とサポート終了版（4） は、別立ての勧告記事で影響する構成と暫定緩和策まで詳述し、7.4 / 8.0 / 8.1 向けには最小限のソースパッチを専用ブランチで提供しました（正式リリースではありません）。 事前共有（5）と協調（6） では、一部の重要インフラ事業者に緩和策を先行提供し、OpenAI が Cloudflare などのインフラ事業者や米政府機関との調整まで担いました。報告者側の動画の誤公開と、配布先の先行公開は次の節で扱います。 「日時だけ先に出す」は PHP にとっては初めてでも、業界全体では珍しい手法ではありません。主なプロジェクトの公開ポリシーを並べておきます。 プロジェクト 日時の事前予告 詳細の事前共有 PHP（平時） しない 主要ディストリに共有する規定のみ OpenSSL する。通常1週間前に日時と深刻度だけ 重大なものは OS ベンダー等へパッチ付きで通常2週間前 Django する。約1週間前に日時と深刻度 同時期に OS ベンダー等へ詳細とパッチを署名付きで送る curl 一般向けの規定なし Linux ディストリの非公開リストに7日前以内に草案とパッチ Rails しない 誰にも事前通知しない（漏洩リスクを避けるため、と明記） Linux カーネル しない 修正ができ次第出す。延期は最大7日、例外で14日 PHP は今回、平時の Rails 寄りの「黙って出す」運用から、OpenSSL 寄りの「日時だけ先に出す」運用へ、一回限りで切り替えた形になります。 php2shell はなぜ漏れたのか。4つの穴と、特定できない最初の流出元 協調開示は「予定日の2日前まではうまくいっていた」と PHP Foundation は書いています。崩れ方は1つではなく、性質の違う4つの穴が1日のうちに重なりました。 穴1: 出所不明の投稿。 10月20日15時（UTC）ごろ、CVE 番号2件と「CVSS 10.0」「公表は10月22日」という情報がフォーラムと SNS に出回り始めました。確認できる最古の公開投稿は Hacker News への書き込みで、投稿者は「信頼できる情報源から聞いた」と書き、翌朝には「協調開示の対象かと尋ねたら違うと言われた」と釈明しています。情報源の身元は書かれておらず、PHP Foundation も最初の流出元を名指ししていません。 穴2: 報告者の動画。 同日20時（UTC）ごろ、報告者の一社である Calif が攻撃の実演動画を誤って公開した、と PHP Foundation は書いています。元の投稿は削除されましたが、複製が SNS に広まりました。Calif 自身がこの件を説明した記述は、今回の調査では見つかっていません。 穴3: 配布先の判断。 10月21日の朝（UTC。時刻は Foundation の記述と Hacker News 上の指摘で食い違います）、修正を事前に受け取っていた Chainguard が、修正入りのコンテナイメージを公開予定より前に公開しました。Foundation はこれを「一方的に禁輸（公開まで伏せる約束）を破った」と非難し、Chainguard の CEO である Dan Lorenc は Hacker News で「野良で攻撃が出たので早めに出す判断を私がした」と述べています。 穴4: 公的な追認。 10月20日18時26分（UTC）、セキュリティ企業 watchTowr が X で、CVE 番号つきで「本物だと確認できる」と公に追認しました。流出した情報に信頼性を与えた形です。 PHP セキュリティチームの Alexandre Daubois は個人ブログで、投稿、動画、追認を並べて「待たないことを選んだ人が何人もいて、PHP はそのせいで公開を1日早めた」と述べています。犯人探しをしても特定できる相手はおらず、言えるのは「最初の流出元は不明で、そのあとに報告者の誤公開、配布先の判断、第三者の追認が重なった」までです。OpenAI は「通知範囲の広さと漏洩リスクをどう比べるべきか」と問いを公開し、意見を募っています。 PHP Foundation が「構造的な失敗」と認めた、修正が2年近く止まっていた理由 技術的なトレードオフだけでなく、意思決定の仕組みと人手の不足が修正を止めていた、というのが Foundation 自身の説明です。 7つの異例のうち、Foundation が最も重く受け止めているのはこの「2年の停滞」です。 経緯は Foundation のブログに書かれています。2024年、外部のセキュリティ企業 Quarkslab による監査（OSTIF 経由、ドイツの Sovereign Tech Agency の資金）が行われました。その指摘を直す過程で、Foundation 契約のコア開発者が、メモリ不足時の処理に問題の兆候があることを見つけました。 ところが修正は進みませんでした。修正案は複数あったものの、どれも「後方互換の破壊」「新たなサービス拒否の余地」「多数のサードパーティ拡張の改修が必要」のいずれかを伴いました。全会一致で動くチームはどの案も選べず、任意コード実行に至る具体的な経路も見つかっておらず、エンジンの深部を知る少人数は多忙でした。 動いたのは2026年です。7月30日にセキュリティ企業 Calif が OpenAI の「Patch the Planet」枠で PHP の監査を始め、8月11日に無条件のリモートコード実行を報告しました。同じ日に OpenAI も独立して同じ根本原因を報告し、ここから修正が本格化します。 Foundation はこの遅れを「構造的な失敗だった」と認めました。今後は、トレードオフで行き詰まった修正を早く経営層へ上げる仕組みを作り、意思決定を全会一致から多数決に変えると表明しています。The Next Web は「PHP は2024年に知っていたが、修正で合意できなかった」と見出しを付けました。 PHP の脆弱性情報はどこで購読するか 今回「23時」の情報を SNS の伝言で知った人は、次に向けて一次情報の購読先を1つ持っておくと楽になります。 php.announce メーリングリスト: リリース告知と、今回のような予告が配信されます。購読は php.net のメーリングリスト一覧から。 GitHub の php/php-src の Security advisories ページ: 技術詳細と暫定緩和策はここに載ります。 使っているディストリのセキュリティ情報: Debian の debian-security-announce、Ubuntu の USN、Red Hat の RHSA など。多くの人に実際に更新が届くのはここです。 JVN iPedia: 日本語で CVE 番号から検索できます（今回の CVE の掲載は、執筆時点で未確認です）。 サポート終了版（8.1 以前）を使っている場合は、PHP 本体からは原則として更新が来ません。今回のソースパッチは例外措置と考えて、サポート版へ移行するか、LTS を提供するベンダーと契約するのが現実的です。 まとめ 今回の PHP の公表で異例だったのは、「予告したこと」そのものより、「予告とリリースを前倒しせざるを得ない状況（情報流出）になったこと」と、「その手前で修正が2年近く止まっていたこと」だと私は読んでいます。 次に PHP が「Upcoming Critical PHP Security Release」のような予告を出したとき、それは普段の「定例日の木曜に黙って出す」流れとは違う扱いのサインです。そのときに慌てないよう、購読先を1つ増やしておくのをおすすめします。 この記事の根拠は主に PHP の公式ポリシー文書、php.net の記録、PHP Foundation のブログ、各社の公開発言で、一覧を下に置きます。 参考リンク php-src SECURITY.md php/policies: security-classification php/policies: release-process php.net: Upcoming Critical PHP Security Release（10月20日の予告） php.net: Security advisory（10月21日） PHP Foundation: How the PHP Security Team Handles Your Reports（10月14日） PHP Foundation: Today's PHP Security Release and How We're Strengthening PHP Security（10月21日） PHP Foundation: PHP Core Security Audit Results（2024年監査） php.announce アーカイブ OpenAI: Coordinated disclosure of critical vulnerabilities Alexandre Daubois: CVE-2026-109618 php2shell rumors The Record: PHP Foundation statement（Chainguard CEO の談話） The Next Web: PHP Foundation structural failure OpenSSL Security Policy Django Security Policies curl Security Process Rails Security Policy Linux kernel: Security bugs 前回の記事: 修正版は23時のはずが22時31分に出ていた。php2shell で日本の約200組織が止まった夜の時系列