2年前に兆候はあった。直せなかったのは、決められなかったから

• 問題の兆候は2024年の外部監査の作業中に見つかっていた
• 直せなかった理由は合意制で決められなかったことと、人手不足。財団は「構造的な失敗」と認めた
• 財団いわく、AIにできないのは「長年の設計をどう直すか決めること」

PHPの脆弱性について、「実は2年前から兆候があった」という報道が出ている。

出どころはPHP財団自身の声明だった。読むと、なぜ直せなかったのかを、本人たちがかなり率直に書いている。今週書いてきた一連の記事の、答え合わせのような内容だった。

2024年に、何があったか

財団の説明はこうだ。

2024年、PHPは数年ぶりの外部セキュリティ監査を受けた。（中略）Quarkslabが報告した問題の1つを直している最中に、PHP財団が契約しているコア開発者が、CVE-2026-109618の背後にあるメモリ不足の問題の最初の兆候を見つけた。2024年には悪用の可能性が理論上は考えられたが、具体的な経路は見つからず、影響のはっきりした他の問題に埋もれた。

つまり最初に気づいたのは人間だった。監査で見つかった別の問題を直している途中に、隣にあった穴に気づいている。

ただ「たぶん危ない」までで、「こうすれば破れる」は示せなかった。そこで止まった。

なぜ直せなかったのか

ここが本題になる。技術的に難しかったのではなく、決められなかった。

直し方はいくつも作られていた。だが、どれも代償があった。

• 後方互換性が壊れる
• 新たにサービス妨害の余地が生まれる
• 外部の拡張機能の多くに変更が必要になる。その調整は不可能に見えた

そのうえで、こう書かれている。

PHPのセキュリティチームは合意に基づいて動いており、どれを選ぶか決めかね、間違った選択を出したときの影響を恐れた。リモートでコードを実行される既知の経路が無かったこと、エンジンを深く知るコア開発者が少なく多くの責任を抱えていたことも重なり、修正作業は何か月にもわたって止まっては再開を繰り返した。

そして、この一文が続く。

取り繕うつもりはない。この遅れは構造的な失敗であり、セキュリティチームの意思決定の仕組みと、人手の不足の両方が原因だった。

全員が納得するまで決めない、の弱点

合意制は、ふだんは良い仕組みだ。誰かが独断で壊すことを防げる。

だがどの選択肢にも代償があるとき、全員が納得する案は存在しない。だから決まらない。決まらないまま、時間だけが過ぎる。

しかも「破れる経路が見つかっていない」ことが、先延ばしを正当化してしまう。急ぐ理由が無いように見える。

財団は対応として、多数決で決められるように、妥協を促すように手順を変え始めているとしている。

2年後、何が変わったか

経緯は今朝の時点で報道されていたものより細かかった。

「たぶん危ない」が「実際に破れる」に変わったのが8月11日だった。そこから全員の最優先になった、と書かれている。

財団の資金が無ければ、複数人をフルタイムで当てることは不可能だった。最後は週末も、昼夜を問わず作業していたという。

AIで、報告が増えすぎている

見落とせない数字もあった。

7月1日以降、チームは15件のCVEを公表し、無効、重複、または再現できなかった報告を100件以上処理した。

AIで脆弱性探しが速くなったぶん、確かめる仕事が増えている。本物1件に対して、確かめて捨てた報告が何倍もある。

そのうえで、こう書かれている。

AIは報告の検証や、同じ根本原因を持つ報告のまとめに役立っている。だがすべての判断は人が下し、すべての修正は人が手がけている。

AIでできないこと

今週、SNSで「今のAIやツールを組み合わせれば、そんなに人手は要らないのでは」という問いが広く読まれていた。

財団の声明が、ほぼそのまま答えになっている。

道具にできないのは、エンジンの長年の設計判断に対する正しい修正を決め、互換性の代償を比べ、修正を審査することだ。それにはPHPのコード全体を知る経験豊富な技術者が必要で、今日、その人数はあまりに少ない。

探すのはAIが速くなった。決めるのは速くならない。

今週AIが穴を見つけた話と攻撃側がAIを使っている話を書いた。両側でAIが速くなると、詰まるのは、間に立って決める人の数になる。

COBOLの書き換えの記事でも、OpenAI自身が「本番には専門家の審査が要る」と書いていた。同じ話だと思う。

公表の直前に、何が漏れたか

声明には、協調した公表が崩れた経緯も書かれていた。日本時間に直して並べる。

財団は動画が攻撃コードの開発を加速させたとしている。

Chainguardの件については厳しい書き方だった。他の配布元と同じく事前に修正を受け取っていたのに、一方的に禁止期間を破った。修正の入った実物が出れば、攻撃者はそこから逆算して研究できる。財団は「何週間にもわたる多くの関係者の作業を軽視した」と書いている。

なお公開の時点では、機能する攻撃コードは確認されていなかったとされる。

今週の数字の説明がついた

昨日書いた攻撃が数百万件に増えた記事で、公表前の10時間で数千件来ていたと書いた。

その理由が、この時系列だったことになる。番号が漏れ、動画が出て、修正入りの実物が先に出た。防御側の窓は、最後の1日で隙間だらけになっていた。

財団が求めていること

声明の最後は、資金の要請で締めくくられていた。

• PHPで製品やサービスを作っている企業に、依存度に見合った支援を
• ホスティング事業者、クラウド、配布元に
• PHPでサービスを動かしている政府や公共機関に、継続的な投資を

2024年の監査はドイツの公的機関（Sovereign Tech Agency）の資金で行われた。

世界のウェブの大部分で動いているのに、中を深く知る人は少数で、その人件費は寄付頼み。今回それが、2年の遅れという形で表に出た。

今週日本の総理まで注意を呼びかけたが、直す側の人手には誰も触れていなかった。そこは考えさせられた。

まとめ

• 兆候は2024年の外部監査の作業中に、財団の契約開発者が見つけていた
• 当時は破れる経路が見つからず、他の問題に埋もれた
• 直し方はあったがどれも代償があり、合意制で決められなかった
• 財団は「意思決定の仕組みと人手不足による構造的な失敗」と認めた
• 8月11日、AIを使った監査で「実際に破れる」と示され、最優先に
• 7月以降、CVE15件、無効などの報告100件以上を処理
• AIにできないのは「長年の設計をどう直すか決めること」
• 公表前にCVE番号の流出、実演動画、修正入りイメージの先行公開が重なった

出典

• The PHP Foundation「Today’s PHP Security Release, and How We’re Strengthening PHP Security」（2026年10月21日。2024年の監査と兆候、修正が止まった理由、「構造的な失敗」、体制の変化、報告の件数、AIの役割、公表前の漏えいの経緯、資金の要請。引用の日本語は筆者による訳。時刻は日本時間に換算）
• The PHP Foundation「PHP Core Security Audit Results」（2024年の監査の概要）

本記事は2026年10月23日時点の公表内容に基づく。漏えいの経緯はPHP財団の説明によるもので、名前の挙がった企業側の見解は確認していない。最新の情報は公式の発表で確認すること。本記事は法的な助言ではない。