CVE-2026-109619

運営者はclaudeに託して寝ました。後で確認するそうです はじめに 2026年10月21日、PHPに認証不要のRCEが2件出た。CVE-2026-109618とCVE-2026-109619、通称PHP2Shellだ。RCEは、リモートから任意のコードを実行できる脆弱性のこと。 自分のハニーポットにもう来ているのか。それだけを確認するつもりだった。 ところがローカルのELKを起動しようとしたら、Docker Desktopにこんな通知が出ていた。 Security update: eMudhra certificate compromise 先にこちらを片付けることにした。前半（1〜4章）がeMudhraの対応、後半（5章）がPHP2Shellの確認だ。 1. eMudhraの中間CA鍵漏えい 何が起きたか インドの認証局eMudhraの中間CA証明書8本の秘密鍵が漏えいした。内訳はTLS用が6本、コード署名用が2本。いずれも2025年4月の鍵生成セレモニーで作られたものだ。 しかも原因は、誰かに盗まれたことではない。Mozillaの記録によると、秘密鍵が256通り未満しかありえない極端に弱い値だった。公開されている証明書から、総当たりで一瞬で秘密鍵を求められる。eMudhraは、鍵生成の手順ミスで弱い鍵が使われたと暫定的に説明している。 見つけたのは外部の研究者で、8本すべてについて「秘密鍵を握っている証拠」を添えて報告した。 「漏えい」というより、実質的に最初から鍵が公開されていたのと同じだ。 中間CAの秘密鍵漏えいは、どれぐらいヤバいのか 「秘密鍵が漏れた」と聞いても、パスワード漏えいと同じくらいの話に聞こえるかもしれない。実際は桁が違う。 まず、HTTPSの「鍵マーク」がどう成り立っているかを整理する。 【平常時】 ルート証明書 : 鍵は金庫の中。PCには最初からコピーが入っている │ 署名 ▼ 中間CA証明書 : 日々の発行はこの鍵で行う │ 署名 ▼ サーバ証明書 : サイトに接続すると届く（example.com） PCの確認：サーバ証明書 → 中間CA → ルート と署名を上にたどり、 手元の信頼ストアにあるルートに着いたら「本物」→ 鍵マーク ブラウザやcurlは、受け取った証明書の署名を上にたどって、手元の信頼ストア（百数十本のルートが入っている）にあるルートまで行けるかを確認する。たどり着ければ「本物」と判断する。 逆に言うと、PCが確かめているのは「信頼しているルートの系列の鍵で署名されたか」だけだ。その鍵を使ったのが本当に認証局自身なのかまでは分からない。 そして、ルートや中間CAは「どのドメインの証明書を出してよいか」を原則として制限されていない。インドの認証局でも、google.comの証明書を発行できてしまう。だからこそ認証局は厳しい監査を受け、鍵はHSMという専用機器から出さない決まりになっている。 その中間CAの鍵が漏れた。つまり、誰でも、どのドメインの「本物の」証明書でも作れる状態になった。 【中間CAの鍵が漏れると】 ルート ── 署名 ──→ 中間CA（鍵が漏れた） │ │ 攻撃者が中間CAの鍵で署名 ▼ 偽のサーバ証明書 google.com / 銀行 / 何でも │ ▼ あなたのPC：「ルートまでたどれた。本物だ」→ 鍵マーク 漏えいの範囲ごとに比べると、こうなる。 ...