GitHub Actions の govulncheck で「Vulnerability #1: GO-2026-6809」（CVE-2026-111943）：crypto/x509 の脆弱性と、直った Go 1.26.10・1.27.3
GO-2026-6809（CVE-2026-111943）は2026年10月21日に公開されました。漏れた eMudhra の中間 CA への Go の答えで、システムの信用の一覧が古くても、crypto/x509 の Verify がその中間 CA を拒むようになりました。1.26.10 より前のすべての版と、1.27.0〜1.27.2 にはこの一覧がありません（GO-2026-6809）。変わったのはコードでなく脆弱性のデータベースなので、前の日に通った同じコミットの検査が、main の定期の実行でも開いているすべてのプルリクでも落ちるようになります。直し方は、Go 1.26.10 か 1.27.3 以降でビルドし、検査することです。
見え方
govulncheck（calciotto #29 から）：
Vulnerability #1: GO-2026-6809
Distrust compromised intermediate certificates in crypto/x509
More info: https://pkg.go.dev/vuln/GO-2026-6809
Standard library
Found in: crypto/x509@go1.26.9
Fixed in: crypto/x509@go1.26.10
Example traces found:
#1: cmd/perfsetup/main.go:118:12: perfsetup.main calls fmt.Printf, which eventually calls x509.Certificate.Verify
Your code is affected by 1 vulnerability from the Go standard library.
...
exit status 3
govulncheck は、コードが呼んでいる脆弱性を見つけると 3 で終わり、ステップが失敗します。TLS でつなぐプログラムのほとんどが Verify を呼びます。たどった道は net/http や crypto/tls、または上のように govulncheck が fmt から見つけた道です。Trivy は、イメージの中の Go のバイナリーに同じものを、パッケージ stdlib・重大度 HIGH・直った版 1.26.10 と 1.27.3 として出します。
ワークフローで Go の版が決まるところ
効くのはビルドや検査をする Go の版なので、その版が決まるところを直します：
actions/setup-goにgo-version-file: go.modを渡すと、toolchainの行があればその版を、無ければgoの行を使います（setup-go）。そこを上げます：go 1.26.10（かtoolchain go1.26.10）、1.27 なら 1.27.3。報告の直しの多くは、この1行です。- ワークフローに固定した
go-version: '1.26.9'、.go-versionや.tool-versionsのファイル、pre-commit の設定：それぞれ上げます。'1.26'や'1.26.x'のような範囲は、まずランナーにある中でいちばん新しい版を使います。イメージが追いついていなくても 1.26.10 を取ってくるように、check-latest: trueを足します。 golang/govulncheck-actionは自分で Go を入れます。go-version-inputの既定はstable、check-latestの既定は true です。go-version-fileも渡すと、setup-go はgo-versionを優先するので、ファイルが使われるのはgo-version-input: ''にしたときだけです。そのときは、ファイルの版を上げます。- Docker のビルド：
FROM golang:1.26.9やgolang:1.27.2は、ワークフローが何を入れても古いライブラリーでバイナリーを作ります。ビルドの段をgolang:1.26.10かgolang:1.27.3にし、イメージとリリースのバイナリーを作り直して出し直します。バイナリーは、作ったときのライブラリーを持ち続けるからです。
自分でビルドせずに配っているバイナリー（イメージに写したよそのツールなど）は、直った Go で作られた上流のリリースでしか直りません。それまでは、理由を書いた .trivyignore の行で、ほかの検査を役に立つまま保ちます。
見分け方
- 上げたあとの
go: go.mod requires go >= 1.26.10 (running go 1.26.9; GOTOOLCHAIN=local)：ジョブがGOTOOLCHAIN=localにしているので、Go が新しいツールチェーンを取ってきません。代わりにジョブで新しい版を入れます（GOTOOLCHAINとgo-version-fileは Go 1.24 がイメージから消える）。 - 上げたあとも別の ID で検査が落ちるなら、別の勧告です。その「Found in」の行を同じように読みます。
- curl・git・Python・Node.js・Java は Go の一覧を使いません。そちらはeMudhra の中間 CA をまだ信用しているランナーへ。
失敗したジョブを IntelliJ IDEA から見るなら
Pipeline Inbox for GitHub Actions Workflows は、Lesstep が作っている JetBrains IDE（2024.1 以降）のプラグインです。すべてのリポジトリの実行を、ジョブ・ステップと一緒に IDE のツールウィンドウに並べるので、main で赤くなった定期の検査がすぐ分かり、いまのブランチの実行はステータスバーに出ます。読むのは無料、失敗したジョブの再実行・キャンセル・ワークフローの実行・デプロイのレビューは Pro（月 US$1.50・30日の無料試用つき）です。
GitHub と GitHub Actions は GitHub, Inc. の商標、Go は Google LLC の商標、Docker は Docker, Inc. の商標、IntelliJ IDEA は JetBrains s.r.o. の商標です。このページはそのいずれとも提携しておらず、承認も受けていません。
ほかに：ランナーと eMudhra の中間 CA の鍵の漏れ · Go 1.24 がイメージから消える · IntelliJ IDEA で使える GitHub Actions のプラグインの比較 · English