CVE-2026-66033の修正方法：Azure Linux 3.0のlibssh2更新手順と修正版の見分け方

CVE-2026-66033への対処は、Azure Linux 3.0に導入されているlibssh2の完全なRPMバージョンを確認し、1.11.1-5.azl3以上へ更新することです。1.11.1-4.azl3以前であれば、更新が必要と判断してください。

MSRCのFirstFixed欄には「azl3 libssh 0.10.6-8」「azl3 libssh2 1.11.1-4」と掲載されています。しかし、Azure Linux公式のlibssh2.specでは、CVE-2026-66033の修正パッチが追加されているのは1.11.1-5です。1.11.1-4の変更履歴には別の脆弱性しか記載されていません。そのため、実務ではMSRCの表示だけで更新を止めず、最新のlibssh2 1.11.1-5.azl3以上を安全基準として確認する必要があります。(Microsoft Security Response Center)

本記事では、CVE-2026-66033の仕組み、影響を受ける条件、Azure Linux 3.0での確認コマンド、更新手順、コンテナやAKSで見落としやすいポイントまで具体的に解説します。

CVE-2026-66033の概要

CVE-2026-66033は、SSH2プロトコルを実装するクライアント向けCライブラリlibssh2に存在する整数アンダーフローの脆弱性です。

悪意のあるSSHサーバーへlibssh2を利用するクライアントが接続し、SSHハンドシェイク中にAES-GCM暗号が選択されると、認証前の段階でクライアントプロセスがクラッシュする可能性があります。公開情報上の主な影響はサービス拒否であり、任意コード実行が確認された脆弱性としては扱われていません。(NVD)

項目	内容
CVE番号	CVE-2026-66033
対象	Azure Linux 3.0のlibssh2
脆弱性の種類	整数アンダーフロー
主な分類	CWE-191
影響	クライアントプロセスのクラッシュ、サービス拒否
発生タイミング	SSH認証前のAES-GCMネゴシエーション時
CVSS v3.1	7.5 High
CVSSベクター	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
実務上の修正基準	libssh2 1.11.1-5.azl3以上

NVDではCWE-191に加え、整数アンダーフローの結果として発生する境界外読み取りを示すCWE-125も併記されています。(NVD)

AES-GCM交渉時にサービス拒否が発生する仕組み

問題が存在するのは、OpenSSLを利用した暗号処理関数ssh2_cipher_crypt()です。

AES-GCMの処理では、暗号化対象となるデータ長をおおむね次のような減算で求めます。

cryptlen = blocksize - aadlen - authentication_tag_length;

blocksizeがAADや認証タグの合計より小さいにもかかわらず減算すると、符号なし整数がゼロ未満を表現できないため、非常に大きな値へ回り込みます。これが整数アンダーフローです。

その大きな値がメモリコピーの長さとして使用されると、境界外のメモリアクセスが発生し、プロセスが即座にクラッシュします。攻撃成立までの流れは次のとおりです。

• libssh2を使用するアプリケーションがSSHサーバーへ接続する
• 接続先サーバーがAES-GCM暗号を選択させる
• 認証前の暗号処理で不正な長さの計算が行われる
• 境界外アクセスが発生してクライアントプロセスが停止する

上流の修正では、デバッグビルドでしか有効にならない検査に依存せず、通常のリリースビルドでも境界値を検証する処理が追加されました。長さを減算する前に、blocksizeがバッファー内に収まることと、AADおよび認証タグの合計以上であることを確認します。(GitHub)

影響を受けるのはSSHサーバー側ではなくクライアント側

CVE-2026-66033で特に間違えやすいのは、脆弱な側がSSH接続を受け付けるサーバーではなく、SSHサーバーへ接続するクライアント側である点です。

Azure Linux 3.0でSSHの22番ポートを外部公開しているだけでは、今回の脆弱性の直接的な成立条件にはなりません。問題になるのは、Azure Linux上のアプリケーションがlibssh2を利用して外部へSSHまたはSFTP接続する場面です。

具体的には、次のような環境を優先して確認します。

• 外部事業者のSFTPサーバーへ定期接続している
• 顧客や利用者が指定したSSHサーバーへ接続するサービスを運用している
• データ連携、バックアップ、ファイル転送を自動実行している
• CI/CDジョブからSSHまたはSFTP接続している
• 自社開発アプリケーションがlibssh2を直接リンクしている
• 接続失敗時に自動再試行する常駐プロセスを運用している

接続先が侵害された場合も、悪意のあるサーバーと同様の応答を返される可能性があります。「普段接続している取引先だから安全」とは限らないため、接続先の信頼性だけを根拠に更新を見送るべきではありません。

MSRCのFirstFixed表示とAzure Linux公式SPECに差がある

2026年8月2日時点のMSRCのFirstFixed欄には、Azure Linux 3.0向けとして次のパッケージが掲載されています。

• azl3 libssh 0.10.6-8
• azl3 libssh2 1.11.1-4

一方、Microsoftが公開しているAzure Linux 3.0のパッケージSPECでは、次のように記録されています。

パッケージ	バージョン	公式SPECの変更内容
libssh	0.10.6-8	CVE-2026-0968の修正
libssh2	1.11.1-4	CVE-2026-55199、CVE-2025-15661の修正
libssh2	1.11.1-5	CVE-2026-66033を含む複数の修正

libsshとlibssh2は名称が似ていますが、別のライブラリです。Azure Linux公式のlibssh.specを見ると、libssh 0.10.6-8の変更履歴はCVE-2026-0968の修正となっており、CVE-2026-66033の修正とは一致しません。(GitHub)

また、libssh2.specでは、1.11.1-5にCVE-2026-66033.patchが追加され、変更履歴にもCVE番号が明記されています。1.11.1-4には今回のCVEが記載されていません。(GitHub)

情報源間の差が生じた理由は公開情報だけでは断定できません。安全側に判断するため、次の基準を採用してください。

Azure Linux 3.0では、libssh2を利用可能な最新パッケージへ更新し、少なくとも1.11.1-5.azl3以上であることを確認する。

libssh2 1.11.1-4へ更新しただけで対応完了と判断したり、libssh 0.10.6-8だけを更新したりしないことが重要です。

Azure Linux 3.0で該当するか確認する方法

OSのバージョンを確認する

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

cat /etc/os-release

出力のVERSION_IDなどから、Azure Linux 3.0であることを確認してください。

複数台を管理している場合は、対象VM、VM Scale Sets、管理用ホスト、コンテナイメージを分けて一覧化します。ホストOSだけを調査して、コンテナ内のパッケージを見落とさないようにしてください。

libssh2の導入バージョンを確認する

次のコマンドで、パッケージ名、上流バージョン、RPMリリース、CPUアーキテクチャをまとめて表示できます。

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

確認結果は次のように判断します。

確認結果	判断
libssh2-1.11.1-5.azl3以上	公式SPEC上、CVE-2026-66033の修正を含む
libssh2-1.11.1-4.azl3以前	更新が必要
package libssh2 is not installed	ホストのRPMパッケージは直接の対象外。ただしコンテナや組み込み版は別途確認
バージョンが判別できない	パッケージ管理外のバイナリや静的リンクを調査

libsshも併せて確認する場合は、次のように実行します。

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

ここでlibssh-0.10.6-8.azl3だけが表示されても、libssh2の修正を確認したことにはなりません。

RPMの変更履歴でCVE番号を確認する

導入済みパッケージの変更履歴にCVE番号が含まれるか確認します。

rpm -q --changelog libssh2 | grep -F 'CVE-2026-66033'

次のような内容が表示されれば、RPMの変更履歴上は修正パッチが含まれています。

Patch for CVE-2026-66035, CVE-2026-66034, CVE-2026-66033, CVE-2026-66032

ただし、変更履歴だけではなく、必ず完全なRPMバージョンも併せて記録してください。監査や脆弱性管理では、次の2点を証跡として残すと判断しやすくなります。

rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' libssh2
rpm -q --changelog libssh2 | grep -F 'CVE-2026-66033'

libssh2を必要とするRPMを確認する

直接の依存関係を調べる場合は、次のコマンドを利用できます。

rpm -q --whatrequires libssh2

ただし、この結果だけで利用状況を完全には把握できません。次のようなケースは表示されないことがあります。

• アプリケーションがライブラリを動的に読み込んでいる
• 独自の配置先へlibssh2.soをコピーしている
• アプリケーションに静的リンクしている
• コンテナ内に別のlibssh2が存在する
• 言語ランタイムやベンダー製品に同梱されている

RPMの確認に加えて、SBOM、コンテナイメージの構成、アプリケーションのビルド定義も確認してください。

Azure Linux 3.0でlibssh2を更新する手順

Azure Linuxでは、パッケージ管理にTiny DNFのtdnfを使用します。Microsoftのドキュメントでも、パッケージ一覧の確認にはtdnf list、更新にはtdnf updateを使用する手順が案内されています。(Microsoft Learn)

リポジトリ情報を更新する

古いキャッシュを参照しないように、最初にメタデータを削除します。

sudo tdnf clean all

利用可能なlibssh2のバージョンを確認します。

tdnf list libssh2

ここで1.11.1-5.azl3以上が表示されることを確認してください。

libssh2を更新する

対話形式で更新する場合は、次のコマンドを実行します。

sudo tdnf update libssh2

自動化されたメンテナンス処理で確認を省略する場合は、次のように実行できます。

sudo tdnf update -y libssh2

個別パッケージだけでなく、同時期に公開された他のセキュリティ修正も適用する方針であれば、事前検証後にシステム全体を更新します。

sudo tdnf update

本番環境では、いきなり全台へ適用せず、検証環境、少数の本番ホスト、全体展開の順で進めると、依存関係やアプリケーション互換性の問題を早期に検出できます。

更新結果を確認する

更新後、完全なRPMバージョンを再確認します。

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

期待する出力例は次のとおりです。末尾のアーキテクチャは環境によって異なります。

libssh2-1.11.1-5.azl3.x86_64

続けて、変更履歴も確認します。

rpm -q --changelog libssh2 | grep -F 'CVE-2026-66033'

両方を確認できた時点で、パッケージ更新の証跡として保存します。

利用中のサービスを再起動する

共有ライブラリのファイルを更新しても、すでに起動しているプロセスは更新前のコードをメモリ上に保持していることがあります。

libssh2を使用しているサービスを特定できる場合は、そのサービスを再起動します。

sudo systemctl restart <service-name>

利用プロセスを確実に特定できない場合や、複数の常駐サービスが利用している場合は、メンテナンス時間内にOSを再起動する方法が確実です。

sudo reboot

更新後は、SFTP接続、SSH連携、定期転送、監視ジョブなど、実際の業務フローもテストしてください。

1.11.1-5以上がリポジトリに表示されない場合

tdnf updateを実行しても1.11.1-4.azl3から更新されない場合は、次の点を確認します。

有効なリポジトリを確認する

tdnf repolist
tdnf list libssh2

Azure Linux 3.0用の正式なリポジトリが有効になっているか確認します。

キャッシュを再作成する

sudo tdnf clean all
tdnf list libssh2

組織内のミラーリポジトリを利用している場合は、Microsoft側のパッケージがまだ同期されていない可能性があります。ミラーの同期時刻、同期エラー、公開承認フローを確認してください。

除外や固定設定を確認する

パッケージ更新を固定する設定や、特定パッケージを更新対象から除外する設定があると、修正版が公開されていても更新されません。

構成管理ツール、イメージ作成処理、リポジトリ設定、更新スクリプトを確認します。インターネット上の非公式なRPMを個別にダウンロードして導入するのではなく、Microsoftの正式なAzure Linuxリポジトリから更新してください。

コンテナイメージ内のlibssh2も更新する

Azure Linuxホストを更新しても、その上で動作するコンテナ内のlibssh2は更新されません。コンテナには独立したファイルシステムとパッケージがあるためです。

Azure Linuxベースのコンテナイメージでは、Dockerfileなどのビルド定義に更新処理を追加します。

RUN tdnf update -y libssh2 \
    && tdnf clean all

更新後はイメージを再ビルドし、レジストリへ登録してからワークロードを再デプロイします。

稼働中のKubernetes Pod内で確認する例は次のとおりです。

kubectl exec <pod-name> -- \
  rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' libssh2

コンテナがパッケージマネージャーを含まない最小構成やdistroless構成の場合は、実行中のコンテナで更新しようとせず、ベースイメージとビルド工程を修正してください。

また、アプリケーションへlibssh2を静的リンクしている場合、OSやコンテナのRPMを更新しても組み込み済みコードは置き換わりません。修正済みソースを使用してアプリケーションを再ビルドし、再配布する必要があります。

AKSのAzure Linuxノードでの対応

AKSのAzure Linuxノードでは、ノードへ個別にSSH接続してパッケージを書き換える運用は避け、更新済みノードイメージへ切り替えるのが基本です。

クラスター内の全ノードプールについてノードイメージだけを更新する例は次のとおりです。

az aks upgrade \
  --resource-group <resource-group> \
  --name <cluster-name> \
  --node-image-only \
  --yes

特定のノードプールだけを更新する場合は、次のコマンドを使用します。

az aks nodepool upgrade \
  --resource-group <resource-group> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --node-image-only

Microsoftは、ノードイメージの自動アップグレードチャネルまたはメンテナンス期間内のセキュリティパッチ適用も推奨しています。(Microsoft Learn)

ただし、ノードイメージを更新しても、Podとして動作するアプリケーションコンテナ内のlibssh2までは更新されません。

• ノードOSに含まれるlibssh2はノードイメージ更新で対応する
• アプリケーションコンテナ内のlibssh2はイメージ再ビルドで対応する

この2つを別々に確認する必要があります。

すぐに更新できない場合の一時的な緩和策

恒久対策は修正版への更新です。更新まで時間が必要な場合に限り、次の対策で攻撃成立の可能性や影響範囲を抑えます。

SSHとSFTPの接続先を制限する

ネットワークポリシー、ファイアウォール、プロキシなどを使用し、SSHまたはSFTPの外向き接続先を業務上必要なホストに限定します。

IPアドレスだけでなく、接続先ホスト、ポート、利用サービス、管理責任者まで整理してください。

信頼できない接続先へのジョブを停止する

利用者が入力した接続先や、不特定の外部サーバーへ接続する処理は、修正版を適用するまで停止または隔離します。

外部事業者への定期転送を止められない場合は、対象プロセスを他の重要サービスから分離し、クラッシュが業務全体へ波及しない構成にします。

AES-GCMを一時的に無効化する

アプリケーションがSSH暗号アルゴリズムの許可リストを設定できる場合は、互換性を検証したうえで次のAES-GCM方式を一時的に除外する方法があります。

[email protected]
[email protected]

設定方法は、libssh2を利用するアプリケーションやライブラリの実装によって異なります。グローバルな設定だけで必ず無効化できるとは限りません。

また、暗号方式の変更は接続先との互換性に影響します。この方法は更新までの一時対策であり、修正版の適用を不要にするものではありません。

認証情報や受信側ファイアウォールだけに依存しない

この脆弱性はSSH認証前に発生します。パスワードを変更する、多要素認証を導入する、Azure Linux側の受信ポートを閉じるといった対策だけでは、外向き接続を行うクライアント側の問題は解消しません。(NVD)

対応時によくある失敗

失敗例	問題点	正しい対応
libsshだけを更新する	libssh2とは別パッケージ	rpm -q libssh2で個別に確認する
1.11.1だから修正済みと判断する	Azure Linuxは同じ上流版へパッチをバックポートする	1.11.1-5.azl3のようにRPMリリースまで比較する
MSRCの1.11.1-4だけを基準にする	公式SPECではCVEパッチが1.11.1-5に含まれる	利用可能な最新の1.11.1-5.azl3以上へ更新する
ホストOSだけを更新する	コンテナ内のパッケージは変わらない	イメージを再ビルドして再デプロイする
更新後にサービスを再起動しない	起動中プロセスが古いコードを保持する可能性がある	関連サービスを再起動するかOSを再起動する
脆弱性スキャナーの上流版だけを見る	1.11.1という文字列だけではバックポートを判定できない	完全なRPM版と変更履歴を証跡として登録する
静的リンク版を見落とす	RPM更新でアプリ内のコードは置き換わらない	修正済みソースでアプリを再ビルドする

脆弱性スキャナーで検出が残る場合の判断方法

上流のlibssh2では、1.11.1までが影響対象として登録されています。一方、Azure Linuxでは上流バージョンを1.11.1のまま維持し、RPMリリース-5で修正をバックポートしています。(NVD)

そのため、スキャナーが上流のバージョン番号だけを比較すると、修正版の1.11.1-5.azl3でも検出が残ることがあります。

誤検知の確認には、次の情報をそろえます。

rpm -q --qf '%{NAME} %{EPOCHNUM}:%{VERSION}-%{RELEASE} %{ARCH}\n' libssh2
rpm -q --changelog libssh2 | grep -F 'CVE-2026-66033'

証跡として残す内容は次のとおりです。

• 対象ホストまたはコンテナの識別情報
• Azure Linuxのバージョン
• 完全なRPMバージョン
• CPUアーキテクチャ
• CVE番号を含むRPM変更履歴
• 更新日と再起動日
• アプリケーションの動作確認結果

スキャナー側には、Azure LinuxのベンダーアドバイザリーやRPMリリースを評価できる最新フィードを適用します。単に例外登録するのではなく、1.11.1-5.azl3以上であることを確認したうえで、期限と根拠を付けて判定してください。

対応の優先順位を決める基準

次の環境は優先度を高くします。

• インターネット上のSSHまたはSFTPサーバーへ接続する
• 外部事業者が管理する接続先を利用する
• 利用者が接続先を自由に指定できる
• ファイル転送処理が自動再試行される
• クラッシュすると重要なジョブ全体が停止する
• 同一プロセス内で複数の重要機能を提供している

接続先が社内の管理されたサーバーだけであっても、パッケージが導入されている場合は計画的に更新してください。内部サーバーが侵害された場合や、DNS・経路・接続設定が書き換えられた場合には、悪意のある応答を受ける可能性があります。

ホストにlibssh2がなく、コンテナ、静的リンク、ベンダー製品への組み込みもないことを確認できた場合は、直接の対象外として記録できます。

CVE-2026-66033対応で実施すべきこと

最初に、Azure Linux 3.0上の完全なRPMバージョンを確認します。

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

1.11.1-4.azl3以前であれば、正式なAzure Linuxリポジトリから更新します。

sudo tdnf clean all
sudo tdnf update libssh2

更新後は、1.11.1-5.azl3以上であることと、変更履歴にCVE番号が含まれることを確認します。

rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' libssh2
rpm -q --changelog libssh2 | grep -F 'CVE-2026-66033'

最後に、libssh2を利用するサービスを再起動し、SSH・SFTP連携の動作を確認します。コンテナ環境ではイメージを再ビルドし、AKSではノードイメージとアプリケーションコンテナを別々に更新してください。

MSRCのFirstFixed表示だけを見るとlibssh2 1.11.1-4で修正済みと判断しやすいものの、Azure Linux公式SPECではCVE-2026-66033のパッチは1.11.1-5に含まれています。実運用では特定の古い版へ固定せず、利用可能な最新のlibssh2へ更新するのが安全です。