Goの脆弱性情報まとめ

Go本体（標準ライブラリとgoコマンド）と、よく使われるモジュールのうち、2026年に公表され、悪用の確認（米CISAのKEV）、深刻度が緊急、または利用の多い部分に当たるものを選びました。11月1日に確認した内容です。

Go本体の10月の2件とgRPC-Goは、10月30日版のKEVに載っていません。Goの脆弱性データベースの記録には深刻度の欄が無く、Go本体の脆弱性にGoチームはCVSSの値を出していません。[4][7]

Goは、新しい系列が2つ出るまで1つの系列をサポートし、その間に安全性の修正を小さな版（1.26.1、1.26.2など）で出します。決まった終了日はなく、新しい系列が出た日に2つ前の系列のサポートが終わります。[1]

日付はgo.devのリリース履歴の記載です。Go 1.25向けには10月の更新が出ていないため、10月に直った脆弱性は1.25.14にも残ります。今上げる先は1.27.3か1.26.10です。1.26に上げる場合は、次の系列の1.28が出るとサポートが終わる点を見込んでおきます。[1]

Goの公式の道具はgovulncheckです。Goの脆弱性データベース（vuln.go.dev）と照合し、ソースを解析する場合は、脆弱な関数を自分のコードが呼んでいるかまで調べます。[8][9]

go install golang.org/x/vuln/cmd/govulncheck@latest

# モジュールのディレクトリで、ソースを解析する
govulncheck ./...

# 呼び出しの経路をすべて表示する
govulncheck -show traces ./...

# ビルド済みのバイナリを解析する
govulncheck -mode binary ./bin/server

結果のうち「Your code is affected」の欄は、脆弱な関数への呼び出しの経路があるものです。「Informational」の欄は、読み込んでいるパッケージに脆弱性はあるものの呼び出しの経路が無いもので、公式の手引きは対応が要らない場合があるとしています。脆弱性が見つかると終了コードが0以外になるため、CIでそのまま止められます（-jsonや-format sarifの出力では0のままです）。[8][9]

バイナリの解析では呼び出しの経路は出ません。到達しないコードも報告される場合があります。[8]

1. 依存の版をgo.modとgo.sumで確かめる：実際にビルドに使う版は、go list -m allで一覧にできます。直接書いていないモジュール（間接の依存）も含みます。なぜ入っているかはgo mod why -mで調べます。
2. 依存を上げて記録する：go get golang.org/x/net@v0.62.0のように版を指定して上げ、go mod tidyでgo.modとgo.sumをそろえてから、govulncheckをもう一度実行します。
3. 本番で動いているバイナリを確かめる：go version -mは、バイナリを作ったGoの版と、組み込まれたモジュールの版を表示します。コンテナの場合は、docker cpでバイナリを取り出して確かめるか、govulncheck -mode binaryに渡します。[10]

go list -m all | grep golang.org/x/net
go mod why -m golang.org/x/net

# バイナリを作ったGoの版と、組み込まれたモジュール
go version -m ./bin/server

Goに特有の罠は3つあります。

• 標準ライブラリの修正は、新しいGoでビルドし直して配備するまで本番に入りません。Goはライブラリをバイナリに組み込むため、サーバーのGoを入れ替えても、動いているプログラムは古いままです。
• go.modのgoの行は、必要な最低の版です。ビルドに使われるGoは、CIで入れたGo（golang:1.26のイメージなど）と、toolchainの行・GOTOOLCHAINの設定で決まります。[11]
• Goの脆弱性データベースへの収録は、提供元の公表より遅れる場合があります。EchoのCVE-2026-118264は、10月23日の公表から11月1日時点まで未収録でした。govulncheckの結果に加え、使っているフレームワークの告知も見ます。