なぜ、修正の前に情報が出たのか：php2shell の経緯から考える
Dixlase（ディクセイラス）を開発している、エクシーディーの柏原（カッシー）です。
先日の記事では、PHP の脆弱性（php2shell）について、Dixlase をお使いの方へのお願いをまとめました。
また「脆弱性は『どの層』で起きたのか」では、今回の問題が PHP そのものの層で起きたことを書きました。
今回は、もう一つの側面を書きます。
php2shell では、修正版が出る前に、情報の一部が外に出ていました。それはなぜだったのか、です。
今回の騒ぎを大きくしたのは、脆弱性の深刻さだけではありません。それ以上に、裏付けの取れない情報が、修正版より先に出回ったことが、騒ぎに一層拍車をかけたと私は考えています。
修正版を早く出し、すぐに更新することは、もちろん大切です。それと同じくらい、修正版の前になぜ情報が出てしまったのかを振り返り、確かめることも大切だと考えています。
先にお断りしておくと、これは誰かを責めるための記事ではありません。
関わった会社や人の名前は出さず、公表された情報と報道をもとに、出典を付けて書きます。
当事者の言い分が分かれているところは、両方を書きます。私の見方を書くところは、そうと分かるように書きます。
この記事は、2026 年 10 月 30 日時点の情報にもとづいています。あとで分かったことがあれば、追記します。
本来の流れ：なぜ、修正の前は伏せておくのか
ソフトウェアの脆弱性は、見つかってすぐに公表されるわけではありません。
修正版を用意し、それを配る人たちに先に渡し、決めた日時に一斉に公開する、という順番をとるのがふつうです。
中身が先に出てしまうと、守る側が更新できるようになる前に、攻撃する側が手がかりを得てしまうからです。
PHP の場合も、報告する人には、公開の場（Issue やプルリクエスト、SNS）に出さないよう求めています。修正ができたら、決めた予定で告知と CVE を出す、としています。
今回も、Linux のディストリビューションや長期サポートの提供元には、修正が事前に渡されていました。
ところが今回は、いくつもの要因が重なり、修正版が出る前に、情報の一部が外に出てしまいました。
次の節から、ここまでに分かっている情報をもとに、その経緯を振り返ります。
出典：PHP Foundation「How the PHP Security Team Handles Your Reports」（2026 年 10 月 14 日）／PHP 公式のセキュリティ告知
何が起きたのか
PHP Foundation は、修正版を出した 10 月 21 日に、経緯の振り返りを公開しています。
それと報道をもとに、起きたことを順に並べます（日本時間。括弧内は出典の UTC）。
- 8 月 11 日：研究者の会社と、もう 1 つの組織が、同じ日に、同じ原因の問題をそれぞれ別に報告した。
- 8 月 24 日：別の研究者の会社も報告した。
- 10 月 17 日：Amazon が、公開より前の攻撃の試みを観測した。どうやって情報を得たのかは分かっていない。
- 10 月 21 日 0 時ごろ（10 月 20 日 15:00 UTC）：2 つの CVE 番号が、誤った公開日と深刻度とともに、掲示板や SNS で出回り始めた。技術的な中身は出ていない。
- 10 月 21 日 4 時 30 分ごろ（10 月 20 日 19:30 UTC）：PHP が、「10 月 21 日 14:00 UTC にセキュリティリリースを出す。2 件で、どちらも深刻度は 9.2」と予告した。中身が公開されたり、悪用の証拠が出たりした場合は早めることがある、としていた。
- 10 月 21 日 5 時ごろ（20:00 UTC）：報告した研究者の会社が、攻撃の実証の動画を誤って公開した。動画は消されたが、複製が広まった。
- 10 月 21 日 8 時ごろ（23:00 UTC）：重要インフラの事業者に伝えたつなぎの対策が、漏れたかもしれない。
- 10 月 21 日 16 時 41 分（7:41 UTC）：修正を事前に受け取っていた配布元の 1 社が、修正の入ったイメージを、一斉の公開より 6 時間以上早く公開した。
- 10 月 21 日 23 時ごろ（14:00 UTC）：PHP が修正版を公開した。もともとの予定から 1 日早めた。
PHP Foundation によると、公開の時点では、実際に動く攻撃コードは確認されていませんでした。
その後、10 月 23 日には、PHP は 3 つ目の脆弱性（CVE-2026-115560）も公表しました。めったにない設定の組み合わせでだけ起きるもので、修正は次の通常のリリースで出す予定です。それまでは、session.upload_progress.enabled を無効にすることを勧めています。
出典（3 つ目の脆弱性）：The Register（2026 年 10 月 23 日）／BleepingComputer（2026 年 10 月 23 日）
出典：PHP Foundation「Today's PHP Security Release, and How We're Strengthening PHP Security」（2026 年 10 月 21 日）／PHP Foundation の Discourse「Upcoming Critical PHP Security Release」（2026 年 10 月 20 日）／Amazon Threat Intelligence／Infosecurity Magazine／Techzine
なぜ、守れなかったのか
起きたことは、一つではありません。
ここでは、確かさの度合いで分けて見ていきます。
確かな誤り
攻撃の実証の動画は、PHP Foundation の言葉でいえば「誤って」公開されたものでした。
PHP Foundation は、この動画で、限られた範囲ながら新しい手がかりが出て、攻撃コードづくりが速まったとしています。
言い分が分かれているもの
修正の入ったイメージを先に公開した配布元について、PHP Foundation は、一方的に取り決めを破ったとしています。修正をバイナリの形で調べられる状態が、ほかの利用者が待っているあいだにできてしまった、という指摘です。
一方、その会社の代表は、海外メディアの取材に対し、何も漏らしていないと否定しています。
代表の説明によると、10 月 16 日に研究者から「PHP に何か来る」と聞き、その夜に自社の AI の仕組みで同じ脆弱性を見つけ、翌 17 日に詳しい説明を受けたうえで、PHP の開発者と協力して修正を試していました。
公開を早めた理由としては、自分たちが簡単に見つけて悪用できたこと、すでに多くの情報が出回っていたこと、悪用の兆しがあったことの 3 つを挙げています。「いつも正しく判断できるとは限らないし、皆が賛成するとも限らない」とも述べています。
これに対して、PHP Foundation の事務局長は、公開より前に悪用に成功した証拠はない、と述べています。
イメージを公開した時刻そのものについては、争いはないようです。どちらの言い分が正しいかは、ここでは判断しません。
出典：PHP Foundation／Techzine／The New Stack（2026 年 10 月 22 日）／The Register（2026 年 10 月 23 日）
一部が分かったもの
10 月 20 日に CVE 番号と公開予定を投稿した人は、その後、同じ掲示板で名乗り出て、謝罪しています。
本人の説明によると、投稿したときはエンバーゴ（公開までの取り決め）があることを知らず、知り合いから「エンバーゴはない」と聞いていました。その知り合いも、さらに別の人から同じように聞いていたそうです。
投稿したのは、PHP をソースからビルドして使っている、同じ立場の人に、更新が急ぎであることを知らせたかったからだ、としています。
公開の予定に影響を与えたことを認め、責任は自分にある、と述べています。
出典：Hacker News の本人の投稿／GIGAZINE
出どころが分からないもの
次のことは、分かっていません。
- 「エンバーゴはない」と伝わった情報が、もとはどこから出たのか
- つなぎの対策は、本当に漏れたのか
- 10 月 17 日に攻撃を試みた人は、どうやって情報を得たのか
PHP Foundation も Amazon も、これらの出どころを示していません。
分からないことは、分からないままにしておきます。
出典：PHP Foundation／Amazon Threat Intelligence
その土台にあったもの
PHP Foundation の振り返りで、いちばん重いのはこの部分だと思います。
原因の一つは、2024 年の外部の監査のときに、すでに兆しが見つかっていました。
ところが、直し方の案がいくつも出て、どれにも別の問題があり、全員の合意で決める進め方だったこともあって、何か月も止まっていました。
PHP Foundation は、これを「構造的な失敗」と書いています。原因として、決め方と、人手や資金の不足の両方を挙げています。
出典：PHP Foundation／The Next Web
騒ぎを大きくしたもの
最初に出回った情報は、実際より重いものでした。
深刻度は最大の 10.0 とされ（PHP の評価は 9.2）、公開日も誤っていて、PHP 5 までさかのぼって影響するとも書かれていました。
番号が出回り始めてから、PHP が予告を出すまでは、およそ 4 時間半ありました。そのあいだは、出回った情報が本当かどうかを確かめる手段がありませんでした。
予告で、重大な脆弱性があること自体は公式に確かめられました。ただ、予告には中身やつなぎの対策は書かれておらず、「すぐに更新できるよう準備を」という呼びかけにとどまっていました。
修正版が出るまでの、さらに 18 時間あまりのあいだ、PHP を使う人の多くは、何をすればよいかが分からないままでした。そこに、攻撃の実証の動画も加わりました。
出典：Infosecurity Magazine／PHP Foundation／PHP Foundation の Discourse「Upcoming Critical PHP Security Release」（2026 年 10 月 20 日）
脆弱性の深刻さそのものに加えて、PHP のセキュリティチームが発表するまで裏付けの取れない情報が、修正版より先に出回ったこと。重大な脆弱性があること自体は結果として本当でしたが、深刻度や公開日のように、不正確な部分も含まれていました。これが、騒ぎを大きくした要因だったと私は考えています。
私の見方
並べてみると、一人の誤りで起きたことではないと考えています。
人の誤りや判断と、修正を長く止めてしまった体制の弱さが、重なったのだと思います。
AI で、秘密を保つのが難しくなった
今回、私がいちばん考えさせられたのは、ここです。
同じ原因の問題が、AI を使って調べていた複数の組織から、それぞれ別に報告されていました。
先にイメージを公開した配布元の会社も、自社の AI の仕組みで同じ問題を見つけたと話しています。
また Amazon は、AI を使った分析で、修正の内容から攻撃を組み立てるのが速く、安くなっていると指摘しています。
出典：PHP Foundation／Techzine／Amazon Threat Intelligence
ここからは私の見方です。
同じ問題を知る人が増えるほど、修正が出るまでの秘密は守りにくくなります。そして、修正に時間がかかるほど、守らなければならない期間は長くなります。
AI で見つける人が増えたいま、「修正の前は伏せておく」という仕組みそのものに、これまでより大きな負荷がかかっているのだと思います。
今回は、情報そのものは人から人へ伝わったのに、「まだ伏せておくべきもの」という取り決めは、一緒に伝わっていませんでした。秘密を知る人が増えると、その取り決めを全員にきちんと届けることも、難しくなるのだと思います。
同じ日の Node.js
同じ 10 月 21 日には、JavaScript の実行環境である Node.js も、セキュリティの修正版を出しています。
Node.js は、10 月 19 日までに、中身を伏せたまま「10 月 21 日にセキュリティリリースを出す。最も高い深刻度は HIGH」と予告していました。
そして予定どおり、22.23.4、24.22.1、26.12.1 を公開しました。
修正された 10 件のうち 1 件（Brotli の処理でのリモートコード実行）は、AI を使うセキュリティのチームが見つけたものです。
Node.js の公式のお知らせには、情報の漏えいや、実際の攻撃についての記述はありません。私が調べた範囲でも、漏えいの報告は見当たりませんでした。
出典：Node.js「Wednesday, October 21, 2026 Security Releases」／Private DevOps
PHP の件と比べると、Node.js のリリースは、静かに進んだように見えます。違いとして、次のことが挙げられます。
- 使われている規模：W3Techs によると、サーバー側の言語が分かるウェブサイトのうち、PHP は 69.3%、JavaScript は 8.1% です。ただし、アクセスの多い上位 1,000 サイトに限ると、JavaScript は 31.8%（PHP は 59.2%）になります。また、これはウェブサイトについての数字で、API や開発の道具など、ウェブサイト以外での使われ方は含まれていません。
- 脆弱性の広さ：PHP の 2 件は、ウェブのリクエストを処理する PHP すべてが対象でした。Node.js の 10 件は、DNS の名前解決、TLS の証明書の確認、Brotli の展開など、それぞれ特定の機能に関わるものです。
- 公開までの流れ：どちらも、中身を伏せた予告を出していました。ただ、PHP の予告は CVE 番号が出回ったあとに出たものでした。Node.js は、予告から予定どおりの公開まで進み、情報が先に出たという報告は見当たりません。
出典：W3Techs「Usage statistics of server-side programming languages」（2026 年 10 月 22 日時点）／Node.js「Wednesday, October 21, 2026 Security Releases」
どれがどのくらい効いたのかを測った出典はありません。ここからは私の見方ですが、使われている規模と、影響の広さの違いに、手順どおりに公開まで進めたことが重なって、静かなリリースになったのだと考えています。
どちらがよい、という話ではありません。脆弱性の重さも、関わった組織の数も違います。
ただ、同じように AI で見つかった脆弱性でも、予告から公開までを手順どおりに進められた例として、覚えておきたいと思います。
PHP Foundation が進めていること
PHP Foundation は、振り返りのなかで、次のような改善を挙げています。
- 2026 年 5 月に、エコシステムのセキュリティチームを作った
- セキュリティの判断を、全員の合意ではなく、多数決で決められるようにする
- 開発者を増やす
- PHP に頼っている企業、ホスティングの会社、政府などに、資金の協力を求める
うまくいかなかったことを、自分たちの言葉で「構造的な失敗」と書いて公開したことは、大事な一歩だと私は考えています。
Dixlase として考えること
Dixlase は、PHP の上で動いています。今回、私たちにできたのは、何をすればよいかを早くお伝えすることと、インストーラーを直して更新しやすくすることでした。詳しくは、先日の記事「PHP の脆弱性（php2shell）について：Dixlase の対応」にまとめています。
PHP の脆弱性（php2shell）について：Dixlase の対応
今回のことから、二つのことを考えています。
一つは、情報がいつも予定どおりに出るとは限らない、ということです。
だからこそ、使う側は、修正版が出たらすぐ更新できる仕組みを持っておくことが大切です。Dixlase も、そのための仕組みを整えていきます。
もう一つは、Dixlase も、脆弱性の報告を受ける側だということです。
［要確認：Dixlase の脆弱性の報告の窓口（SECURITY.md など）と、その扱い方を一言］
規模は違っても、報告を受けてから、決めて、直して、伝えるまでを止めないこと。今回の振り返りは、私たちにとっても他人ごとではありません。
おわりに
修正の前に情報が出たことは、誰か一人を責めて終わる話ではないと思います。
大きな騒ぎになったことで、多くの人が早く更新に動いた面もあったと思います。ただ、その速さを支えたのは、公表の前から修正を準備し、配布元に渡していた人たちの働きでもありました。
AI で、脆弱性が見つかるのも、攻撃が作られるのも速くなっています。報告を受ける側、配る側、使う側のそれぞれが、同じことが起きにくい仕組みを、一緒に作っていく必要があると考えています。
この記事は、2026 年 10 月 30 日時点の情報にもとづいています。新しく分かったことがあれば、追記します。
ご意見や感想は、GitHub の Issue や SNS で、気軽にお寄せください。
更新履歴
- 2026-10-30：公開
