Kyoto.go #68 の LT 会で話した内容をブログに残します。
2026年10月19日にリリースされた Go 1.27.3 / 1.26.10。変更は crypto/x509 のセキュリティ修正1件だけでした。
対応する CVE は CVE-2026-111943 です。
背景には、認証局の秘密鍵が簡単に復元できてしまう問題がありました。Go チームへの問題の通知からリリースまで約7時間半。Go で初めて URGENT トラックが使われた対応でもあります。
この事例を通して、Go 本体の修正が脆弱性 DB や派生ディストリビューションに反映され、アプリケーションの更新につながるまでを追います。
このリリースの対応については Go Blog でも記事が上がっています。
発端
問題があったのは、インドの認証局 eMudhra が emSign ブランドで運用する8つの中間 CA です。
使われていた楕円曲線 P-384 では、本来は約 2384 通りの候補から秘密鍵をランダムに選びます。
しかし、今回の秘密鍵の整数値はいずれも256未満でした。256ビット未満という意味ではなく、候補が最大255通りしかない状態です。数マイクロ秒で復元できてしまいました。(Mozilla の報告)
HTTPS の証明書検証では、サーバーの証明書から中間 CA、信頼済みのルート CA へと署名をたどります。
信頼済みのルート CA
└─ 中間 CA
└─ example.com のサーバー証明書
中間 CA の秘密鍵が分かると、攻撃者は管理していないドメインの証明書も作れてしまいます。今回の8つのうち、6つは TLS 用、2つはコード署名用でした。(詳細: Apple の説明)
TLS では、攻撃者が通信を横取りでき、接続元が問題の中間 CA を信頼している場合、偽の証明書を使った中間者攻撃（MITM）が可能になります。ログイン情報や API トークンの窃取、通信内容の改ざんにつながる問題です。
なぜ Go 本体で対応するのか
Go の標準ライブラリには TLS 証明書の検証機能が含まれています。net/http や crypto/tls で TLS サービスに接続すると、接続先が提示する証明書が有効かどうかを確認するために、この検証機能が呼び出されます。
Windows と macOS では、この検証をプラットフォームの API に委譲しています。一方、Linux にはそのような API がないため、Go 独自の検証実装を使います。
Linux には証明書の失効確認を行う統一的な組み込みの仕組みがありません。また、他のプラットフォームでも、利用者にプラットフォームの更新が届かない可能性があります。
こうした利用者にも速やかに修正を届けるため、Go チームは URGENT トラックのセキュリティリリースで、Go 側でも問題の証明書への信頼を取り除くことが最善だと判断しました。(Go Blog)
Go のセキュリティ対応は3つのトラックに分かれる
Go Security Policy では、セキュリティ問題を次の3つに分けています。
| トラック | 修正の進め方 | リリース |
|---|---|---|
| PUBLIC | 公開で議論・修正 | 次の定期マイナーリリース |
| PRIVATE | 非公開で修正 | 通常は3〜7日前に予告し、次の定期マイナーリリース |
| URGENT | 非公開で修正 | 即座に専用リリース。予告がない場合もある |
Go チームは、利用方法によって影響が変わることから、HIGH / CRITICAL といった重大度ラベルや CVSS スコアを付けていません。トラックが、チームの判断する影響の大きさや広さを示す手掛かりになります。
今回は、鍵の情報が広く知られる前に防御を届けるために URGENT が選ばれ、事前予告もありませんでした。
修正コミット
修正では、対象の中間 CA を公開鍵情報（SPKI）の SHA-256 ハッシュで識別し、それらを含む証明書チェーンを検証結果から除外します。
修正は非公開の Gerrit でレビューされ、公開 Gerrit に移されてから約1分でマージされました。その形跡は、Go 1.27 向け修正のコミットメッセージ に残っています。
Change-Id: I43172dd50560eb7d1a80bc2554a67234d3029501
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/6380
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/6400
Reviewed-on: https://go-review.googlesource.com/c/go/+/851165
非公開の go-internal-review と公開の go-review が並んでいます。公開からマージまでの短さは、レビュー時間の短さを意味するわけではありません。
当初の公開 Issue では、eMudhra の名前や鍵の弱さには触れず、特定の中間証明書への信頼をブロックすることと、即座の更新を強く推奨することが伝えられていました。
理由を追記した CL 852085 では、攻撃者が容易に悪用方法を知ることのないよう、説明を曖昧にしたとされています。差分や説明が攻撃の手掛かりになるため、まず防御を届けることが優先されました。
全体のタイムライン
| 時点 | 対応 |
|---|---|
| 10月17日 | 研究者が各社に報告。数時間以内に Chrome と Firefox が問題の中間 CA をブロック |
| 10月19日 | Go チームへの通知から約7時間半で Go 1.27.3 / 1.26.10 をリリース |
| 10月19日 | Apple が端末上で問題の TLS 用中間証明書のブロックを開始 |
| 10月20日 | Mozilla が emSign のルート証明書を NSS の信頼ストアから削除する対応を発表 |
| 10月21日 | Go の脆弱性 DB で GO-2026-6809 を公開。govulncheck による影響確認につながる |
| 10月22日 | eMudhra がグローバル SSL/TLS 証明書事業からの撤退を発表 |
日付は各資料の表記に合わせています。Go のリリース発表は日本時間では10月20日です。
修正が利用者に届くまで
脆弱性 DB に入ったので、リリース通知に加えて、govulncheck で問題が検出されるようになりました。
フォークや標準ライブラリのコピーには、個別の修正取り込みが必要で、例えば Microsoft の Go ディストリビューションでは、v1.27.3-1 で上流の更新を取り込んでいます。
Go の標準ライブラリは通常バイナリに組み込まれるため、ツールチェーンを更新するだけでは配布済みのプログラムは変わりません。アプリケーションを再ビルドし、バイナリやコンテナイメージを配布して、実行環境を入れ替えるところまで必要です。
まだ対応していない場合は、修正バージョンの Go に更新、再ビルド再デプロイやりましょう