MENU

CVE-2026-46600対策：Azure Linux 3.0のGo x/net修正版と更新手順

Azure

Azure Linux 3.0でgolangパッケージを使用している場合は、最初にgo versionではなく、RPMの完全なバージョンを確認してください。Go 1.25系は1.25.11-3、Go 1.26系は1.26.4-3が修正版の最低ラインです。これより古い場合は、sudo tdnf update golangで公式リポジトリの修正版以上へ更新します。MSRCはFirstFixedとして、次の2製品を掲載しています。(Microsoft Security Response Center)

  • azl3 golang 1.25.11-3 on Azure Linux 3.0
  • azl3 golang 1.26.4-3 on Azure Linux 3.0

ただし、Azure Linuxのgolangパッケージを更新しただけでは、すでにビルドされたGoアプリケーションやコンテナー内のバイナリまで自動的に修正されるとは限りません。アプリケーションがgolang.org/x/netを使用している場合は、モジュールがv0.56.0以上かを確認し、必要に応じて再ビルドと再デプロイまで行うことが重要です。(Go Packages)

目次

CVE-2026-46600の概要

CVE-2026-46600は、Goのgolang.org/x/net/dns/dnsmessageにおいて、不正なSVCBまたはHTTPSリソースレコードを解析した際にパニックが発生する脆弱性です。

項目内容
CVE番号CVE-2026-46600
影響を受けるコンポーネントgolang.org/x/net/dns/dnsmessage
発生条件不正なSVCBまたはHTTPS DNSレコードを解析する
直接的な影響Goプロセスのパニック、サービス停止の可能性
CVSS基本値7.5
CWECWE-125：境界外読み取り
upstreamの修正版golang.org/x/net v0.56.0
Azure Linux 3.0のFirstFixedgolang 1.25.11-3、golang 1.26.4-3

Goの公式脆弱性データベースによると、SVCBまたはHTTPSレコード内のパラメータ値がメッセージバッファーの範囲を超えるよう細工されていると、解析処理がパニックする可能性があります。影響を受けるのはgolang.org/x/netのv0.56.0より前の版です。(Go Packages)

不正なDNSレコードでパニックが発生する仕組み

SVCBは、サービスへの接続方法や接続先などをDNSで通知するためのリソースレコードです。HTTPSレコードもSVCBを基礎とした形式で、HTTPS接続に利用できる情報を表します。

今回の問題では、これらのレコードに含まれるパラメータ値のサイズと、DNSメッセージ内で実際に利用できるバッファー範囲との整合性が崩れる入力を処理すると、境界外読み取りに至る条件が発生します。その結果、GoのDNSメッセージパーサーがパニックします。(Go Packages)

「パニック」はLinuxのカーネルパニックではない

ここでいうパニックは、Azure Linux全体が停止するカーネルパニックではなく、Goランタイム上のパニックです。

アプリケーション側で適切に回復されなければ、該当するGoプロセスが終了する可能性があります。単一プロセスでサービスを提供している場合や、再起動監視が設定されていない場合は、そのままサービス停止につながります。

一方で、公開されている説明の中心は可用性への影響です。任意コード実行や権限昇格として公表されている脆弱性ではありません。

影響を受けやすい環境

Azure Linux 3.0を使用しているだけで、すべてのサーバーが直ちに攻撃可能になるわけではありません。影響の有無は、Goプログラムが脆弱なdnsmessageパッケージを含み、問題のある解析処理を実際に呼び出すかによって変わります。

特に確認を優先したいのは、次のような環境です。

  1. 外部から受け取ったDNSメッセージをGoで直接解析している
  2. DNSプロキシ、リゾルバー、DNS監視ツールをGoで実装している
  3. SVCBまたはHTTPSレコードを扱うサービスディスカバリ機能がある
  4. golang.org/x/net/dns/dnsmessageを直接または間接的に利用している
  5. インターネットから到達できるサービスで、異常終了時の冗長化がない
  6. ビルド時期や依存モジュールが不明なGoバイナリを運用している

通常の名前解決を行うすべてのGoアプリケーションが一律に該当する、と判断するのは適切ではありません。モジュールの有無に加え、govulncheckなどを使って影響を受ける関数への呼び出し経路も確認します。

3種類のバージョンを混同しない

CVE-2026-46600を調査すると、1.25.11-3、go1.25.11、v0.56.0という異なる形式のバージョンが出てきます。それぞれ意味が異なります。

確認対象バージョン例用途
Azure LinuxのRPMパッケージgolang-1.25.11-3.azl3Azure Linux向け修正の適用判定
Goツールチェーンgo1.25.11Goコンパイラー本体の版確認
Goモジュールgolang.org/x/net v0.56.0アプリケーション依存関係の判定

特に注意したいのが、go versionではRPMのリリース番号である-3を確認できない点です。

例えば、次の2つはどちらもgo versionではgo1.25.11と表示される可能性があります。

golang-1.25.11-2.azl3
golang-1.25.11-3.azl3

しかし、MSRCのFirstFixedは1.25.11-3です。1.25.11-2と1.25.11-3では判定が異なるため、Azure Linux側の確認にはrpm -qを使用します。Azure Linuxのパッケージ定義でも、VersionとReleaseはそれぞれ1.25.11と3、または1.26.4と3として管理されています。(GitHub)

Azure Linux 3.0の修正版と判定基準

MSRCが掲載しているFirstFixedは次のとおりです。

Go系列MSRCのFirstFixedRPM表示の目安
Go 1.25系azl3 golang 1.25.11-3golang-1.25.11-3.azl3以上
Go 1.26系azl3 golang 1.26.4-3golang-1.26.4-3.azl3以上

FirstFixedは「最初に修正された版」であり、必ずこの版へ固定しなければならないという意味ではありません。公式リポジトリに、さらに新しいセキュリティ更新版がある場合は、互換性を確認したうえで新しい版を使用します。(Microsoft Security Response Center)

バージョン出力ごとの判定例

インストール済みパッケージ判定
golang-1.25.11-1.azl3FirstFixed未満
golang-1.25.11-2.azl3FirstFixed未満
golang-1.25.11-3.azl3FirstFixed
golang-1.25.12-1.azl3FirstFixedより新しい
golang-1.26.4-1.azl3FirstFixed未満
golang-1.26.4-2.azl3FirstFixed未満
golang-1.26.4-3.azl3FirstFixed
golang-1.26.5-1.azl3FirstFixedより新しい

1.25.12-1は、Release番号だけを見ると-1ですが、Versionが1.25.12へ進んでいるため、1.25.11-3より新しい版です。単純な文字列や末尾の数字だけで比較しないようにしてください。

また、Go 1.24以前などMSRCのFirstFixedに示されていない古い系列を使用している場合、「一覧にないから安全」とは判断できません。公式リポジトリから、現在サポートされている修正版への移行を検討します。

Azure Linux 3.0で該当状況を確認する手順

Azure Linuxのバージョンを確認する

最初に、対象ホストがAzure Linux 3.0であることを確認します。

grep -E '^(NAME|VERSION|VERSION_ID|ID)=' /etc/os-release

Azure Linux 3.0であることを確認してから、パッケージ調査へ進みます。別のLinuxディストリビューションでは、修正版のパッケージ番号や更新コマンドが異なります。

golangパッケージの完全なバージョンを確認する

次のコマンドで、Version、Release、アーキテクチャをまとめて表示します。

rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' golang

修正済みの出力例は次のとおりです。

golang-1.25.11-3.azl3.x86_64

または次のように、FirstFixedより新しい版でも問題ありません。

golang-1.26.5-1.azl3.x86_64

次のように表示された場合、Azure LinuxのRPMとしてgolangはインストールされていません。

package golang is not installed

ただし、パッケージがインストールされていないことだけで安全とは判断できません。別のサーバーでビルドされたGoバイナリ、コンテナー内のバイナリ、/usr/local/goへ手動導入したGoが存在する可能性があります。

実際に使用しているGoの場所を確認する

複数の方法でGoをインストールしている環境では、tdnfで管理されているGoと、実際に使用しているGoが異なることがあります。

command -v go
go version
readlink -f "$(command -v go)"

表示された実行ファイルがRPMに含まれるかを確認します。

rpm -qf "$(readlink -f "$(command -v go)")"

RPMに属していないと表示された場合、tdnf update golangを実行しても、そのGo実行環境は更新されません。手動配置、開発環境マネージャー、CI/CDツールのキャッシュなど、導入元に応じた更新が必要です。

アプリケーションのx/netバージョンを確認する

Goプロジェクトのディレクトリで、モジュールグラフに含まれるgolang.org/x/netを確認します。

go list -m all | grep '^golang.org/x/net '

次のようにv0.56.0未満が表示された場合は更新対象です。

golang.org/x/net v0.55.0

go.modに直接記載されていなくても、別のモジュールから間接的に利用している可能性があります。そのため、go.modの目視確認だけでなく、モジュールグラフ全体を調べることが重要です。

ビルド済みバイナリを確認する

ソースコードではなく、配布済みバイナリを確認する場合は、埋め込まれたビルド情報を表示します。

go version -m /path/to/application | grep 'golang.org/x/net'

より詳しく影響を調べる場合は、Go公式のgovulncheckを利用できます。

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

ビルド済みバイナリは、次の形式で調査できます。

govulncheck -mode binary /path/to/application

govulncheckは、依存モジュールが存在するかだけでなく、脆弱な関数がコードから実際に呼び出される可能性も分析します。ソースコードとバイナリの両方に対応しています。(Go)

Azure Linux 3.0のgolangパッケージを更新する手順

Azure Linuxでは、パッケージ管理にTiny DNFのtdnfを使用します。Microsoftのドキュメントでも、個別パッケージの更新にはtdnf update パッケージ名という形式が案内されています。(Microsoft Learn)

利用可能なパッケージを確認する

tdnf list golang

ここで解決される更新候補が、FirstFixed以上であることを確認します。

Go 1.25系を維持する必要がある環境で、更新候補がGo 1.26系になる場合は、無条件に本番へ適用せず、ビルド互換性や組織のバージョン固定方針を確認してください。

golangパッケージを更新する

sudo tdnf update golang

更新トランザクションに表示されるバージョンと依存パッケージを確認してから、処理を実行します。

更新候補が表示されないにもかかわらずFirstFixed未満の場合は、次の点を確認します。

  1. Azure Linux 3.0用の公式リポジトリが有効か
  2. 社内ミラーやキャッシュが最新状態か
  3. プロキシやファイアウォールでリポジトリ接続が遮断されていないか
  4. パッケージ更新を抑止する設定がないか
  5. 使用中のイメージやリポジトリがサポート対象か

出所不明のRPMを直接入れるのではなく、原則としてMicrosoftの公式リポジトリ経由で更新してください。

更新後のRPMバージョンを再確認する

rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' golang
go version

最終的なAzure Linuxパッケージの合否判定には、go versionではなくrpm -qの結果を使用します。

アプリケーション側のx/netも更新する

プロジェクト内のgolang.org/x/netがv0.56.0未満の場合は、互換性を確認したうえでv0.56.0以上へ更新します。(Go Packages)

最低修正版へ更新する例は次のとおりです。

go get golang.org/x/[email protected]
go mod tidy
go test ./...

組織内で承認された、より新しいx/netを使用できる場合は、その版を選択しても構いません。

依存関係をvendorディレクトリへ保存しているプロジェクトでは、モジュール更新後に再生成します。

go mod vendor

その後、通常のCI/CDパイプラインを使ってアプリケーションを再ビルドし、テスト環境で動作確認してから本番へ再デプロイします。

パッケージ更新だけで既存バイナリは直らない

Goアプリケーションは、依存するGoコードをビルド時にバイナリへ取り込む構成が一般的です。

そのため、Azure Linuxのgolangパッケージを更新しても、古い環境でビルドされた実行ファイルの中身は変わりません。対応には次の一連の作業が必要です。

  1. ビルド環境のGoパッケージを更新する
  2. golang.org/x/netをv0.56.0以上へ更新する
  3. テストを実行する
  4. アプリケーションを再ビルドする
  5. 新しいバイナリを再デプロイする
  6. 古いインスタンスやPodが残っていないことを確認する

コンテナー環境での注意点

Azure Linux 3.0ホスト上でコンテナーを動かしている場合、ホスト側のgolangパッケージ更新はコンテナーイメージの中身を変更しません。

特にマルチステージビルドでは、最終イメージにGoツールチェーンが含まれていないことがあります。この場合、最終コンテナー内でrpm -q golangが「未インストール」と表示されても、アプリケーションバイナリに脆弱なx/netが組み込まれている可能性があります。

コンテナーでは、次の順序で対応します。

  1. Dockerfileのビルドステージで使用するGo環境を更新する
  2. go.modとgo.sumのx/netを確認する
  3. 必要に応じてv0.56.0以上へ更新する
  4. キャッシュ任せにせず、修正済み依存関係でイメージを再ビルドする
  5. 新しいイメージをレジストリへ登録する
  6. Deploymentやサービスをローリング更新する
  7. 古いイメージのコンテナーが残っていないことを確認する

最終イメージ内のバイナリは、ビルドパイプライン上で次のように検査できます。

go version -m ./application | grep 'golang.org/x/net'
govulncheck -mode binary ./application

更新後に確認する項目

確認項目合格の目安
Azure LinuxのRPM1.25.11-3または1.26.4-3以上
Goモジュールgolang.org/x/net v0.56.0以上
脆弱性スキャンgovulncheckでCVE-2026-46600の到達可能な呼び出しが検出されない
ビルドCI/CDのテストとビルドが成功する
デプロイすべての稼働インスタンスが新しいバイナリまたはイメージへ切り替わっている
サービス監視パニック、異常終了、再起動ループが発生していない
DNS機能SVCB、HTTPSレコードを含む通常の名前解決が正常に動作する

更新直後は、サービスログやコンテナーの再起動回数も確認します。

systemdで管理している場合は、対象サービスの状態とログを確認します。

systemctl status <service-name>
journalctl -u <service-name> --since "30 minutes ago"

Kubernetes環境では、更新後のPodと再起動回数を確認します。

kubectl get pods
kubectl get pods -o wide

CVE-2026-46600対応でよくある失敗

失敗例問題点正しい対応
go versionだけを確認するRPMのRelease番号-3を確認できないrpm -qで完全な版を確認する
golangパッケージがないので安全と判断する外部でビルドされたGoバイナリが存在する可能性があるバイナリのモジュール情報も確認する
Azure Linuxホストだけを更新するコンテナーイメージや既存バイナリは変わらないイメージやアプリケーションを再ビルドする
go.modの直接依存だけを見るx/netが間接依存として含まれる場合があるgo list -m allやgovulncheckを使う
FirstFixedへダウングレードするより新しい修正版を失う可能性がある現在の版がFirstFixed以上なら維持する
更新後に再デプロイしない稼働中の旧バイナリが残る全インスタンスの置き換えを確認する
本番でいきなりGo系列を変更するビルドや動作の互換性問題が起きる可能性があるステージング環境でテストしてから展開する

対応優先度の判断基準

優先度環境の例推奨対応
最優先外部由来のDNSデータを処理し、脆弱なx/netを使用している本番サービス直ちに更新、再ビルド、再デプロイ
高インターネット公開サービスで、バイナリの依存関係が不明バイナリ解析と脆弱性スキャンを優先
高DNSプロキシ、サービスディスカバリ、監視ツール呼び出し経路を確認し、早期更新
通常の早期更新Goをビルド用途だけに使用し、該当コードを実行していない次回ビルド前にツールチェーンを更新
要調査golang RPMはないが、Go製アプリを運用しているバイナリとコンテナーを個別確認

CVSS 7.5であることだけを理由に、すべてのAzure Linuxサーバーを同じ緊急度で扱う必要はありません。一方で、外部由来のDNSレコードを処理するサービスでは、細工された入力による可用性低下につながる可能性があるため、後回しにしないことが重要です。

まとめ

CVE-2026-46600への対応では、Azure LinuxパッケージとGoアプリケーションの両方を確認します。

まず、次のコマンドでAzure Linux 3.0のgolangパッケージを確認してください。

rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' golang

Go 1.25系が1.25.11-3未満、またはGo 1.26系が1.26.4-3未満であれば、公式リポジトリから更新します。

sudo tdnf update golang

続いて、アプリケーション内のgolang.org/x/netがv0.56.0以上であることを確認します。

go list -m all | grep '^golang.org/x/net '
govulncheck ./...

最後に、修正版の依存関係でアプリケーションやコンテナーを再ビルドし、すべての稼働インスタンスを再デプロイします。RPMの更新、依存モジュールの更新、再ビルド、再デプロイの4段階を完了して、はじめて実運用上の対応が完了したと判断できます。

Azure
DNS Go Azure Linux 3.0 x/net CVE-2026-46600

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次