CVE-2026-66032対策：Azure Linux 3.0のlibssh2修正版と更新手順

CVE-2026-66032への対策は、Azure Linux 3.0に導入されているlibsshとlibssh2の完全なパッケージバージョンを確認し、少なくともlibssh 0.10.6-8.azl3、libssh2 1.11.1-4.azl3以降へ更新することです。MSRCは、この2つをAzure Linux 3.0向けのFirstFixedとして掲載しています。(Microsoft Security Response Center)

ただし、FirstFixedは「最初に修正された版」であり、固定して導入すべき推奨版ではありません。2026年8月2日時点のAzure Linux 3.0公式x86_64リポジトリには、より新しいlibssh2 1.11.1-5.azl3も公開されています。通常は-4へ固定せず、構成済みの公式リポジトリから取得できる最新版へ更新してください。(Microsoft Packages)

CVE-2026-66032の修正版と対応基準

MSRCが示しているAzure Linux 3.0向けの修正基準は、次のとおりです。

パッケージ	FirstFixed	対応基準
`libssh`	`0.10.6-8.azl3`	`0.10.6-7.azl3`以前なら更新
`libssh2`	`1.11.1-4.azl3`	`1.11.1-3.azl3`以前なら更新

libsshとlibssh2は名前が似ていますが、別々のSSHライブラリです。CVE-2026-66032の技術的な問題はlibssh2で発生しますが、MSRCのFirstFixedにはAzure Linux 3.0向けパッケージとして両方が掲載されています。そのため、運用上は片方だけでなく、導入済みの両パッケージを確認するのが確実です。(Microsoft Security Response Center)

FirstFixedと最新版は同じ意味ではない

FirstFixedは、脆弱性の修正が最初に含まれたバージョンです。たとえば、次のどちらも修正基準を満たします。

libssh2-1.11.1-4.azl3.x86_64
libssh2-1.11.1-5.azl3.x86_64

1.11.1-5.azl3が利用できる環境で、わざわざ1.11.1-4.azl3へダウングレードする必要はありません。セキュリティ更新では、FirstFixed以上であり、かつ利用中の公式リポジトリが提供する最新版を選ぶのが基本です。

CVE-2026-66032はどのような脆弱性か

CVE-2026-66032は、libssh2のSFTP処理に存在する二重解放、いわゆるDouble Freeの脆弱性です。

項目	内容
CVE番号	CVE-2026-66032
対象	libssh2を利用するSSH・SFTPクライアント処理
脆弱性分類	CWE-415：Double Free
CVSS v3.1	8.8（High）
CVSS v4.0	8.7
主な影響	ヒープ破損、プロセス停止、条件次第で任意コード実行につながる可能性
公開日	2026年7月24日

NVDの説明では、libssh2 1.11.1までのsrc/sftp.cにあるsftp_open()で問題が発生します。悪意のあるSSHサーバーが細工したSFTP応答を返すことで、認証済みのクライアント側で同じメモリー領域が二度解放される可能性があります。(NVD)

二重解放とは

プログラムは、不要になったメモリーを解放して再利用できる状態にします。二重解放は、すでに解放した同じメモリー領域を、誤ってもう一度解放してしまう問題です。

CVE-2026-66032では、概ね次の流れで問題が起こります。

libssh2を利用するクライアントがSSHサーバーへ接続し、認証する
クライアントがSFTPでファイルを開こうとする
悪意のあるサーバーが、通常とは異なる細工された応答を返す
応答データのバッファーが一度解放される
後続処理でエラーが発生すると、同じポインターが再び解放される
ヒープ領域が破損し、プロセス停止やメモリー操作につながる可能性が生じる

glibc環境では、条件がそろうと重複したメモリー割り当てや関数ポインターの上書きにつながる可能性も指摘されています。ただし、脆弱性が存在するだけで、必ず任意コード実行まで成功するわけではありません。実際の影響は、アプリケーションの実装、メモリー配置、保護機構などに左右されます。(NVD)

上流の修正内容

上流のlibssh2では、Gitコミット5e4776146552d898b9c0e1b313cd093fa8dc92d0で修正されています。修正内容は、メモリーを解放した直後にポインターへNULLを代入し、後続処理で解放済みのポインターが再利用されないようにするものです。(GitHub)

概念的には、次のような修正です。

SSH2_FREE(session, data);
data = NULL;

変更行数は少なくても、解放済みポインターを残さないための重要な修正です。

SSHサーバーを公開しているだけで影響を受けるのか

CVE-2026-66032は、悪意のあるSSH・SFTPサーバーから応答を受け取るクライアント側で発生する脆弱性です。そのため、Azure Linux 3.0でSSHサーバーを公開しているという理由だけで、直ちにこの脆弱性が悪用されるわけではありません。(NVD)

特に確認すべきなのは、次のような処理です。

取引先や外部サービスへSFTP接続するバッチ
バックアップデータをSSH・SFTPで転送するエージェント
CI/CD環境から成果物をSFTP送信する処理
libssh2を組み込んだ独自アプリケーション
外部管理のSSHサーバーからファイルを取得する連携システム
ベンダー製品に内蔵されたファイル転送機能
コンテナ内で動作するSFTPクライアント

接続先が侵害された場合や、DNS・接続設定の改ざんなどによって偽のサーバーへ誘導された場合も、攻撃対象になり得ます。

また、CVSSの「利用者操作あり」は、必ずしも人間が画面をクリックすることを意味しません。設定済みの定期バッチや自動転送処理が攻撃者のサーバーへ接続する場合も、脆弱な処理が実行される可能性があります。

Azure Linux 3.0で導入済みバージョンを確認する方法

OSがAzure Linux 3.0か確認する

最初に、対象ホストのOSを確認します。

cat /etc/os-release

主要な項目だけ確認する場合は、次のコマンドでも構いません。

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

Azure Linux 3.0では、概ね次の情報が表示されます。

NAME="Microsoft Azure Linux"
ID=azurelinux
VERSION_ID="3.0"

別のLinuxディストリビューションでは、修正版のバージョン番号やパッケージのリリース表記が異なります。1.11.1-4.azl3という判定基準は、Azure Linux 3.0に対して使用してください。(GitHub)

libsshとlibssh2の完全なバージョンを確認する

次のコマンドで、パッケージ名、バージョン、リリース番号、アーキテクチャを確認できます。

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

結果の見方は次のとおりです。

確認結果の例	判定
`libssh2 1.11.1-3.azl3.x86_64`	FirstFixed未満。更新が必要
`libssh2 1.11.1-4.azl3.x86_64`	MSRCの修正基準を満たす
`libssh2 1.11.1-5.azl3.x86_64`	FirstFixedより新しい修正版
`libssh 0.10.6-7.azl3.x86_64`	FirstFixed未満。更新が必要
`libssh 0.10.6-8.azl3.x86_64`	MSRCの修正基準を満たす
`package libssh is not installed`	そのRPMパッケージは未導入

パッケージが未導入の場合、脆弱性対策のために新規インストールする必要はありません。ただし、アプリケーション内にコピーされたライブラリや、静的リンクされたlibssh2までは、この確認だけでは判定できません。

「1.11.1」だけで判定してはいけない

Azure LinuxなどのLinuxディストリビューションでは、上流バージョンを変更せず、修正パッチをバックポートして配布する場合があります。

そのため、次のように上流バージョンだけを確認すると、正しく判定できません。

1.11.1

確認すべきなのは、Azure Linux固有のリリース番号を含む完全な表記です。

1.11.1-4.azl3

脆弱性スキャナーが1.11.1だけを見て警告を継続する場合は、すぐに誤検知として除外せず、次の情報を確認してください。

RPMの完全なVERSION-RELEASE
パッケージの提供元
MSRCのFirstFixed
コンテナイメージのダイジェスト
実行中プロセスが読み込んでいるライブラリ
SBOMやビルド時の依存関係

修正版であることを示す証跡として、rpm -qの結果とMSRCのFirstFixed情報を記録しておくと、監査やスキャナー判定の確認に利用できます。

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

Azure Linux 3.0では、RPMパッケージの更新にtdnfを使用します。(Microsoft Learn)

パッケージ情報を更新する

sudo tdnf makecache

libsshとlibssh2を更新する

対象を限定して更新する場合は、次のコマンドを実行します。

sudo tdnf update -y libssh libssh2

OSに導入されているほかの更新もまとめて適用する運用では、次のコマンドを使用します。

sudo tdnf upgrade -y

本番環境では、いきなり全台へ適用するのではなく、検証環境、少数の本番ホスト、全体展開の順に進めると安全です。ファイル転送やバックアップなど、libssh2を利用する可能性がある処理の動作確認も計画に含めてください。

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

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

2026年8月2日時点のx86_64リポジトリを利用している環境では、次のような結果になる可能性があります。

libssh 0.10.6-8.azl3.x86_64
libssh2 1.11.1-5.azl3.x86_64

アーキテクチャ、更新チャネル、ミラーへの反映状況によって、実際に取得できる最新版は異なる場合があります。重要なのは、libsshが0.10.6-8.azl3以上、libssh2が1.11.1-4.azl3以上であることです。(Microsoft Packages)

アプリケーションがlibssh2を使用しているか確認する

既知の実行ファイルを調べる

信頼できる実行ファイルについては、次のようにリンク先を確認できます。

ldd /path/to/application | grep -E 'libssh2|libssh'

例として、次のような表示があれば、そのアプリケーションは共有ライブラリ版のlibssh2を読み込んでいます。

libssh2.so.1 => /usr/lib64/libssh2.so.1

出所不明の実行ファイルに対してlddを実行するのは避けてください。安全性を優先する場合は、readelfで依存関係を確認します。

readelf -d /path/to/application \
  | grep NEEDED \
  | grep -E 'libssh2|libssh'

ファイルがRPMで管理されているか確認する

ライブラリのパスが判明したら、次のコマンドで所属パッケージを確認できます。

rpm -qf /usr/lib64/libssh2.so.1

RPM管理下であれば、次のようなパッケージ名が表示されます。

libssh2-1.11.1-5.azl3.x86_64

「file is not owned by any package」と表示された場合は、アプリケーションやベンダー製品が独自に配置したライブラリである可能性があります。

手動配置されたライブラリを探す

sudo find /usr /opt \
  \( -name 'libssh2.so*' -o -name 'libssh.so*' \) \
  -print 2>/dev/null

/opt/<製品名>/lib/などに別のlibssh2が存在する場合、OSのRPMを更新しても、そのコピーは更新されません。製品ベンダーの修正版、アプリケーションの再ビルド、または依存ライブラリの差し替えが必要です。

静的リンクはrpmやlddだけでは見つからない

libssh2が実行ファイルへ静的に組み込まれている場合、rpm -qやlddでは検出できないことがあります。

静的リンクやアプリケーション同梱版については、次の情報から確認します。

SBOM
ビルドスクリプト
ソースコードの依存関係
ベンダーのセキュリティ情報
コンテナイメージのスキャン結果
バイナリ解析結果
CI/CDで記録されたビルド時のパッケージ一覧

OSパッケージの更新だけで対応完了とせず、実際に稼働しているアプリケーションがどのlibssh2を使用しているか確認することが重要です。

コンテナ環境での修正方法

ホスト側のAzure Linux 3.0を更新しても、コンテナイメージ内のパッケージは更新されません。反対に、コンテナイメージを更新しても、AKSなどのノードOSは更新されません。

次の2層を分けて管理してください。

更新対象	必要な対応
ホスト・AKSノード	OSパッケージまたはノードイメージを更新
ワークロードコンテナ	ベースイメージを更新して再ビルド・再デプロイ

Azure Linux 3.0ベースイメージを再ビルドする

Azure Linux 3.0の公式ベースイメージを利用する例です。

FROM mcr.microsoft.com/azurelinux/base/core:3.0

RUN tdnf update -y \
    && tdnf clean all

mcr.microsoft.com/azurelinux/base/core:3.0は、Azure Linux 3.0の公式ベースイメージとして提供されています。(Microsoft Artifact Registry)

キャッシュされた古いベースイメージを使わないように、再ビルド時は--pullと--no-cacheを付けます。

docker build \
  --pull \
  --no-cache \
  -t example/app:2026-08-02 .

ビルド後、コンテナ内のバージョンを確認します。

docker run --rm example/app:2026-08-02 \
  rpm -q libssh libssh2

パッケージが未導入の場合は、そのコンテナのRPMレイヤーには対象パッケージがありません。ただし、アプリケーションがライブラリを同梱している可能性は別途確認が必要です。

Distrolessイメージなど、tdnfやrpmを含まないコンテナでは、実行中コンテナへ更新を追加するのではなく、修正済みのベースイメージから再ビルドしてください。

AKSでAzure Linuxノードを使用している場合

AKSの管理対象ノードでは、個々のノードへSSH接続して恒久的なパッケージ更新を行うより、修正を含むノードイメージへ更新する方法が基本です。

特定のノードプールを更新する場合は、次のように実行します。

az aks nodepool upgrade \
  --resource-group <リソースグループ名> \
  --cluster-name <AKSクラスター名> \
  --name <ノードプール名> \
  --node-image-only

クラスター全体のノードイメージを更新する場合は、次のコマンドを使用できます。

az aks upgrade \
  --resource-group <リソースグループ名> \
  --name <AKSクラスター名> \
  --node-image-only \
  --yes

更新前にはPod Disruption Budget、ノード数、サージ設定、メンテナンス時間、ステートフルワークロードへの影響を確認してください。AKSでは、セキュリティ修正を継続的に取り込むため、ノードOSイメージの自動アップグレードチャネルを利用する方法も推奨されています。(Microsoft Learn)

なお、ノードイメージを更新しても、Podで使用しているアプリケーションコンテナのlibssh2は更新されません。ワークロードイメージの再ビルドと再デプロイも別途実施してください。

すぐに更新できない場合の一時対策

更新まで時間が必要な場合は、攻撃経路を減らすため、次の一時対策を検討します。

外部SSH・SFTPサーバーへの自動接続を一時停止する
接続先を信頼できるIPアドレスに限定する
アウトバウンドのTCP 22番通信を必要な宛先だけに制限する
DNSや接続先ホスト鍵の変更を監視する
外部管理のSFTPサービスを利用する処理を分離する
対象サービスを権限の低い専用アカウントで動作させる
バッチ実行環境をネットワーク的に隔離する

これらは悪用可能性を下げるための一時的な緩和策です。二重解放そのものを修正するものではないため、最終的には修正版への更新が必要です。

対応の優先度を判断する基準

優先度	環境の例
高	修正版未満の`libssh2`があり、外部または取引先のSFTPサーバーへ接続する
高	バックアップ、CI/CD、データ連携が自動的にSSH・SFTP接続する
高	ベンダー管理の接続先など、自組織で完全に制御できないサーバーへ接続する
中	修正版未満だが、接続先が閉域内の管理サーバーに限定されている
中	`libssh2`は導入済みだが、利用アプリケーションを特定できていない
低	RPM、コンテナ、アプリケーション同梱版のいずれにも`libssh2`が存在しない
対応済み	`libssh2 1.11.1-4.azl3`以上、`libssh 0.10.6-8.azl3`以上で、関連プロセスも再起動済み

接続先が内部サーバーだけであっても、侵害や設定ミスの可能性は残ります。修正版未満であれば、通常の更新サイクルへ確実に組み込んでください。

対応時に起こりやすい失敗

libssh2の「1.11.1」だけを見て判断する

上流バージョンだけでは、Azure Linuxのバックポート状況を判断できません。必ず1.11.1-4.azl3のように、リリース番号まで確認します。

FirstFixedへ正確に固定する

1.11.1-4.azl3は最低限の修正基準です。1.11.1-5.azl3などの新しい版が公式リポジトリにある場合は、最新版を優先します。

ホストだけ更新してコンテナを放置する

コンテナのファイルシステムはホストから分離されています。ホスト更新後も、古いイメージから起動したコンテナには脆弱なライブラリが残る可能性があります。

更新後にサービスを再起動しない

ディスク上のファイルが更新されても、起動済みプロセスが旧ライブラリを保持していることがあります。対象サービスの再起動または再デプロイまでを更新作業に含めます。

rpmの結果だけで対応完了とする

RPM管理外のライブラリ、静的リンク、アプリケーション同梱版は別途確認が必要です。特にベンダー製エージェントや独自ビルドのアプリケーションでは注意してください。

OpenSSHのバージョンだけを確認する

CVE-2026-66032はlibssh2の脆弱性です。sshd -Vやssh -VでOpenSSHのバージョンだけを確認しても、libssh2の導入状況は判定できません。

CVE-2026-66032への対応を完了するチェックリスト

まず、すべてのAzure Linux 3.0環境で次のコマンドを実行してください。

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

そのうえで、次の状態まで確認します。

libsshが導入済みなら0.10.6-8.azl3以上
libssh2が導入済みなら1.11.1-4.azl3以上
利用可能な場合はFirstFixedではなく公式リポジトリの最新版を導入
関連するSSH・SFTPクライアント処理を再起動
コンテナイメージを更新して再ビルド
AKSではノードイメージとワークロードイメージを別々に更新
RPM管理外および静的リンク版のlibssh2を確認
SFTP転送、バックアップ、データ連携の動作を検証
脆弱性スキャンを再実行
完全なパッケージバージョンと更新日時を記録

CVE-2026-66032は、外部からSSHサーバーへ侵入される単純な脆弱性ではなく、libssh2を利用するクライアントが悪意のあるSSHサーバーへ接続した際に問題が発生します。まず導入済みバージョンを確認し、修正版未満なら公式リポジトリの最新版へ更新してください。最後に、サービスの再起動、コンテナの再デプロイ、実際のSFTP処理の検証まで完了して、対応済みと判断することが重要です。

この記事を書いた人

佐藤健司

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

CVE-2026-66032対策：Azure Linux 3.0のlibssh2修正版と更新手順

CVE-2026-66032の修正版と対応基準

FirstFixedと最新版は同じ意味ではない

CVE-2026-66032はどのような脆弱性か

二重解放とは

上流の修正内容

SSHサーバーを公開しているだけで影響を受けるのか

Azure Linux 3.0で導入済みバージョンを確認する方法

OSがAzure Linux 3.0か確認する

libsshとlibssh2の完全なバージョンを確認する

「1.11.1」だけで判定してはいけない

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

パッケージ情報を更新する

libsshとlibssh2を更新する

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

関連サービスを再起動する

アプリケーションがlibssh2を使用しているか確認する

既知の実行ファイルを調べる

ファイルがRPMで管理されているか確認する

手動配置されたライブラリを探す

静的リンクはrpmやlddだけでは見つからない

コンテナ環境での修正方法

Azure Linux 3.0ベースイメージを再ビルドする

AKSでAzure Linuxノードを使用している場合

すぐに更新できない場合の一時対策

対応の優先度を判断する基準

対応時に起こりやすい失敗

libssh2の「1.11.1」だけを見て判断する

FirstFixedへ正確に固定する

ホストだけ更新してコンテナを放置する

更新後にサービスを再起動しない

rpmの結果だけで対応完了とする

OpenSSHのバージョンだけを確認する

CVE-2026-66032への対応を完了するチェックリスト

この記事を書いた人

コメント

コメントするコメントをキャンセル

CVE-2026-66032対策：Azure Linux 3.0のlibssh2修正版と更新手順

CVE-2026-66032の修正版と対応基準

FirstFixedと最新版は同じ意味ではない

CVE-2026-66032はどのような脆弱性か

二重解放とは

上流の修正内容

SSHサーバーを公開しているだけで影響を受けるのか

Azure Linux 3.0で導入済みバージョンを確認する方法

OSがAzure Linux 3.0か確認する

libsshとlibssh2の完全なバージョンを確認する

「1.11.1」だけで判定してはいけない

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

パッケージ情報を更新する

libsshとlibssh2を更新する

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

関連サービスを再起動する

アプリケーションがlibssh2を使用しているか確認する

既知の実行ファイルを調べる

ファイルがRPMで管理されているか確認する

手動配置されたライブラリを探す

静的リンクはrpmやlddだけでは見つからない

コンテナ環境での修正方法

Azure Linux 3.0ベースイメージを再ビルドする

AKSでAzure Linuxノードを使用している場合

すぐに更新できない場合の一時対策

対応の優先度を判断する基準

対応時に起こりやすい失敗

libssh2の「1.11.1」だけを見て判断する

FirstFixedへ正確に固定する

ホストだけ更新してコンテナを放置する

更新後にサービスを再起動しない

rpmの結果だけで対応完了とする

OpenSSHのバージョンだけを確認する

CVE-2026-66032への対応を完了するチェックリスト

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル