PHP脆弱性の公開問題｜契約がなくても責任は残る

脆弱性の公開を判断する専門家には、その場にいない運用者への責任がある。契約に署名していなくても、公開によって他人の準備時間を縮める影響は消えない。PHPの修正公開を巡る今回の対立は、誰がいつ情報を出せるかという判断を、発信者と開発元だけで完結させる危うさを示した。

PHP Foundationは、Chainguardによる修正済みイメージの先行配布を公開時刻の合意違反だと批判した。Dan Lorenc氏は、攻撃が始まったとの情報を受けて配布したと説明する。どちらの判断も、利用者を守るためという理由を掲げている。評価するには、それぞれが守ろうとした利用者の範囲まで考える必要がある。¹²

公開調整が守る、更新に間に合う時間

2026年10月は、主要な実行環境のセキュリティ更新が近い時期に重なった。修正対象の性質も、告知の形も異なる。³⁴⁵⁶⁷⁸

実行環境	公表日	問題の種類
PHP	10月21日3	メモリ破損を通じた遠隔コード実行3
Node.js	10月21日4	Brotliの遠隔コード実行など4
Go	10月19日（公式リリース履歴）5	中間証明書の信頼性への対応6
Oracle Java	10月21日（個別アラート）7	JSSEに関するデータの読み取り・改変など8

この背景に照らすと、公開調整の価値は理解しやすい。運用者は、告知を読んだ瞬間にシステムを置き換えられるわけではない。普段利用する配布元から修正版を受け取り、サービスを継続できると判断して初めて導入できる。攻撃に役立つ情報だけが先に広がれば、その判断に使える時間が減る。

PHP Foundationが公開を一日前倒ししながら即時公開を避けた理由も、配布元が更新パッケージを準備していたためだという。¹ これは開発元の都合として切り捨てられない。修正を用意した人と、それを通常の経路で受け取る人との距離を埋めるための時間だった。

もちろん、公開を待つあいだにも危険は残る。調整は無期限の秘密保持を正当化しない。それでも、関係者が足並みをそろえる意味はある。情報を得た人だけが先に守られる状況をできるだけ短くする。その便益は、調整の会議に参加できない運用者にも及ぶ。

「契約がない」では答えられないこと

J4ck3LSyNは、修正前のPHPを対象にしたPoCの資料をXで告知し、続く投稿で違法行為や契約上の義務を否定した。「Social contracts are meaningless in todays world」とも述べている。PoCの動作は独立に検証されておらず、本人の弁明は適法性を確定する資料にはならない。PHP Foundationも、この人物を最初の情報流出元として特定していない。¹⁹¹⁰

この立場には、考慮すべき点がある。参加に同意していない第三者へ、開発元が一方的に秘密保持を要求できるという前提は危うい。公開を遅らせる側にも説明責任がある。社会契約という曖昧な言葉で、保守側への批判まで封じるべきではない。

それでも、契約がないという説明だけでは不十分だ。専門知識を使って情報を公開する行為は、同意していない運用者の状況も変える。攻撃への応用を容易にする情報なら、発信者が引き受けない対応負担を他人に発生させ得る。契約の当事者かどうかを確認しても、その影響は評価できない。

職業上の責任を問うなら、公開によって何を改善できるのか、誰の危険が増えるのか、その選択を説明できるかが基準になる。社会契約を無意味として片づける姿勢は、この説明を省いてしまう。発信する自由を重視する立場ほど、その自由が他人の備えに与える影響へ答える必要がある。

Chainguardの早期配布には、別の評価が必要だ

Chainguardが先に公開したのは、修正済みのイメージだった。Lorenc氏によると、他のセキュリティ企業から攻撃の発生を聞き、研究者との協議を経て配布を決め、関係者へ直ちに通知した。成果物は顧客以外にも無償で公開したと説明している。² PoCの公開を告知して社会契約を否定した投稿とは、行為の内容も弁明も異なる。

早期配布を支持する理由は強い。すでに攻撃されているなら、導入できる修正版を手元に置いたまま待つ判断にも被害の危険が伴う。誰でも入手できるようにした点も評価すべきだ。顧客限定の保護だったと決めつけると、誰でも修正版を入手できるようにした利点を見落とす。

ただし、無料で公開されていることと、すべての運用者がすぐ利用できることには隔たりがある。別の配布元を前提に動くサービスにとって、外部の修正済みイメージはそのまま導入できるとは限らない。導入には別途判断が要る。その間も、公開された修正は攻撃側が問題箇所を調べる手掛かりになり得る。Foundationの批判は、この時間差に向けられている。¹

Chainguardの公開方針は、攻撃の発生や詳細の公知化による前倒しを認め、通知と調整の継続も掲げる。¹¹ 方針を示すことには意味がある。それを適用したという説明だけで、PHP側が前倒しに同意したことにはならない。

早期配布の判断を評価するには、すぐ守れる利用者への便益に加え、ほかの経路で更新を待つ人に残す危険も考えなければならない。公開時刻をそろえる判断にも、準備できた企業から配る判断にも、それぞれ取り残す利用者がいる。Lorenc氏の説明は前者への反論として説得力を持つが、後者への答えは十分に示していない。

公開前の攻撃は、待つ判断の負担を重くする

AWSは、10月17日にMadPotでPHPの脆弱性を狙う攻撃の試みを観測したと報告した。実際のシステムで成功したかは不明としている。¹² これは、公開までは攻撃側も何もできなかったという見方を退ける材料になる。Chainguardの配布より前の観測であり、攻撃全体を同社の行動の結果として説明することもできない。¹¹²

この観測は、Lorenc氏が述べた緊急性を支える。ただし、判断の時点で関係者が何を知っていたかまでは証明しない。²¹² 攻撃がすでに始まっている可能性を前に、予定時刻を守れば十分だとは言い切れない。公開を待つ側は、その待ち時間が防御にどれだけ役立つのかを、改めて説明する必要がある。

同時に、攻撃の試みが見つかったという事実から、あらゆる公開方法が正当化されるわけではない。AWSの報告は、PHP側の同意を示す資料でも、先行配布による被害の増減を測った資料でもない。¹² すでに情報を得た攻撃者がいる状況でも、公開がさらに多くの人へ手掛かりを渡す影響は残る。

だからこそ、緊急時には調整の価値が高まる。待つ危険と公開する危険を、異なる利用者を抱える関係者が持ち寄れるからだ。一社が把握した切迫感には重みがある。その一社から見えにくい利用者の事情も、同じ判断に反映されるべきだ。

PHP側も、判断の停滞には答える必要がある

公開調整への支持は、保守側への白紙委任を意味しない。PHP Foundationによると、問題の兆候は2024年に見つかっていた。当時は具体的な攻撃経路が分からず、修正案は互換性などの難点を抱えていた。合意を重視する判断方法と詳しい開発者の不足が重なり、修正は停滞した。Foundation自身も構造的な失敗だったと認めている。¹

当時の判断を、後から判明した危険性だけで裁くのは公平ではない。広く使われる言語の根幹を変えれば、修正によって別の不具合を生むおそれもある。¹ 確実な攻撃経路が分からない段階で、難しい修正をためらった事情には理解の余地がある。

それでも、慎重な検討がいつまでも結論を出せない状態に変われば、利用者は残された危険を引き受け続ける。人手不足は遅れの理由になる。期限を設けず判断を保留することまで正当化はしない。全員の賛成を待って決まらないなら、どこかで結論を引き受ける権限が必要になる。

Foundationは多数決を含む判断方法の変更を進めているという。¹ この対応は、資金を増やすことと同じくらい重要だ。詳しい人を雇っても決定できなければ停滞する。決定権だけを与えても、修正を作り検証する人が足りなければ進まない。人員と権限をそろえて初めて、慎重さを維持したまま修正を終えられる。

AIが速めても、責任の所在は決まらない

PHP Foundationは、AIを報告の検証などに使いつつ、判断とパッチ作成は人が担ったと説明している。Lorenc氏も、AIを使って同じ問題を独立に発見できたことを早期公開の判断材料に挙げた。¹² 発見が速くなるほど、防御側が得られる時間を楽観しにくくなる。

そこで公開調整を省いてしまえば、発見の速さを配布の速さへ変えられる組織が有利になる。ほかの利用者にも修正を届ける仕事は残ったままだ。AIは問題を探す手助けをしても、互換性への懸念を誰が引き受けるか、危険を承知でいつ公開するかという権限を割り振ってはくれない。

公開の遅れを批判することも、先行配布の利益を認めることも必要だ。その評価を、契約に署名したかどうかで終えてはならない。専門家の判断は、説明を聞く機会もなかった運用者の準備時間を変える。

今回問われるのは、事情を知り修正も持っている側が、まだ通常の更新経路を待つ人まで含めて判断できるかだ。公開する自由と、公開を調整する権限には、ともにその責任が伴う。その判断には、修正版をすぐ使えない人の事情も含まれていなければならない。

参考文献

Footnotes

1. The PHP Foundation — 発見と判断停滞の経緯、配布元の準備時間、Chainguardへの批判、体制変更とAIの役割に関する当事者の説明。https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/ ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹

2. Dan Lorenc・LinkedInでの公開説明 — 攻撃情報を受けた判断、研究者との協議と通知、修正済み成果物の無償一般公開、AIによる独立した発見。https://www.linkedin.com/posts/danlorenc_i-wanted-to-share-what-happened-with-the-share-7518756991520120832-QX2_/ ↩ ↩² ↩³ ↩⁴

3. PHP公式・2026年ニュースアーカイブ — 修正公開日と遠隔コード実行につながる問題の説明。https://www.php.net/archive/2026.php#2026-10-21-5 ↩ ↩² ↩³

4. Node.js公式・October 2026 Security Releases — 公開日とBrotliなどの修正内容。https://nodejs.org/en/blog/vulnerability/october-2026-security-releases ↩ ↩² ↩³

5. Go公式・Release History — 公式履歴に記された修正版の公開日。https://go.dev/doc/devel/release ↩ ↩²

6. Go公式脆弱性DB — 中間証明書を拒否する修正の目的と条件。https://pkg.go.dev/vuln/GO-2026-6809 ↩ ↩²

7. Oracle・Java向け個別セキュリティアラート — 個別アラートの公開日と対象製品。https://www.oracle.com/security-alerts/alert-cve-2026-91403.html ↩ ↩²

8. Oracle・個別アラートのリスク記述 — JSSEへの入力条件とデータへの影響。https://www.oracle.com/security-alerts/cve-2026-91403verbose.html ↩ ↩²

9. J4ck3LSyN・Xへの投稿（公式oEmbed） — 契約や適法性に関する本人の主張と、社会契約を否定した発言。https://publish.twitter.com/oembed?url=https%3A%2F%2Fx.com%2FJ4ck3LSyN%2Fstatus%2F2112994746608365909&omit_script=true ↩

10. J4ck3LSyN・PoC資料の告知（X公式oEmbed） — 修正前のPHPを対象とする資料を公開したとする本人の告知。https://publish.twitter.com/oembed?url=https%3A%2F%2Fx.com%2FJ4ck3LSyN%2Fstatus%2F2112728631118385153&omit_script=true ↩

11. Chainguard・Coordinated Vulnerability Handling Policy — 攻撃や詳細の公知化による前倒しと、通知・調整についての同社方針。https://www.chainguard.dev/legal/coordinated-vulnerability-handling-policy ↩

12. AWS Security Blog — 10月17日のMadPotでの攻撃の試みと、実環境での成否に関する留保。https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/ ↩ ↩² ↩³ ↩⁴