MENU

CVE-2026-66034とは？Azure Linux 3.0のlibssh2修正版と更新手順

Azure

Azure Linux 3.0でCVE-2026-66034へ対応する場合は、libssh2を1.11.1-5.azl3以上へ更新してください。libssh2 1.11.1-4や、別パッケージであるlibssh 0.10.6-8を修正済みの判定基準にするのは適切ではありません。

Azure Linuxの公式修正差分では、CVE-2026-66034用パッチの追加と同時にlibssh2のリリース番号が4から5へ更新されています。公式RPMリポジトリでも、x86_64版とaarch64版の両方で1.11.1-5.azl3が公開されています。したがって、実際の運用ではlibssh2-1.11.1-5.azl3以降を修正版として確認するのが安全です。(GitHub)

この記事では、CVE-2026-66034の影響、修正版の見分け方、Azure Linux 3.0での確認・更新手順、コンテナーや独自ビルドで見落としやすいポイントまで解説します。

目次

CVE-2026-66034の修正版はlibssh2 1.11.1-5以上

CVE-2026-66034は、SSH通信ライブラリであるlibssh2の公開鍵処理に存在する、境界外ヒープ読み取りの脆弱性です。

主な情報は次のとおりです。

項目内容
CVE番号CVE-2026-66034
対象Azure Linux 3.0のlibssh2
脆弱性の種類境界外ヒープ読み取り
CWECWE-125
CVSS v3.17.5（High）
Azure Linuxでの修正版libssh2-1.11.1-5.azl3以降
更新対象libssh2-1.11.1-4.azl3以前
間違えやすいパッケージlibsshはlibssh2とは別製品

NVDでは、libssh2 1.11.1までが影響対象として説明され、悪意あるSSHサーバーによってヒープ領域の境界外読み取りや未初期化ポインターの解放が引き起こされる可能性が示されています。CVSS v3.1ベクトルはAV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:Hです。(NVD)

一方、Azure Linuxでは上流バージョンを1.11.1のまま維持し、修正パッチをRPMのリリース番号-5.azl3としてバックポートしています。そのため、バージョン番号の前半だけを見て「1.11.1だから脆弱」と判断してはいけません。

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

問題が存在するのは、libssh2の公開鍵サブシステムから公開鍵一覧を取得するlibssh2_publickey_list_fetch()です。

悪意あるSSHサーバーが細工した応答を返すと、クライアント側のlibssh2がサーバー指定のcomment_lenを適切に検証できず、受信バッファーの範囲を超えてヒープメモリーを読み取る可能性があります。

上流の修正では、公開鍵コメントの長さが残りのパケットサイズを超えていないかを確認する境界チェックが追加されています。(GitHub)

攻撃が成立する流れ

想定される流れは次のとおりです。

  1. libssh2を利用するクライアントがSSHサーバーへ接続する
  2. クライアントが公開鍵サブシステムを利用する
  3. 悪意ある、または侵害されたSSHサーバーが細工した公開鍵一覧を返す
  4. libssh2が不正な長さ情報を処理する
  5. ヒープ領域の境界外読み取りやメモリー破損が発生する

重要なのは、Azure Linux上でSSHサーバーを公開しているだけで直ちに攻撃される脆弱性ではない点です。脆弱なlibssh2を使用するアプリケーションが、攻撃者の制御するSSHサーバーへ接続し、該当する公開鍵処理を実行する必要があります。

ただし、接続先が正規のサーバーであっても、そのサーバーや通信経路が侵害されていれば攻撃を受ける可能性があります。

想定される影響

公開されている技術情報からは、主に次の影響が考えられます。

  • プロセスメモリー内の情報漏えい
  • ヒープアドレスなどの漏えいによるASLR回避の補助
  • アプリケーションの異常終了
  • 未初期化ポインターの解放によるメモリー状態の破損

メモリー破損を伴うため軽視はできませんが、公開情報だけを根拠に「任意コード実行が確認されている」と断定するのは避けるべきです。まずはCVSS 7.5のHigh相当として、影響を受けるパッケージを速やかに更新してください。(NVD)

対応を優先すべきAzure Linux環境

CVE-2026-66034の対応優先度は、インターネットからの受信通信だけでなく、Azure Linux上のアプリケーションがどのSSHサーバーへ接続するかで判断します。

優先度利用状況判断
高外部企業や利用者指定のSSH・SFTPサーバーへ接続する接続先を完全には信頼できないため、早急に更新
高CI/CD、バックアップ、ファイル連携処理でlibssh2を使用する自動接続するため、人が不審な接続先に気づきにくい
中接続先を社内サーバーに限定している攻撃面は限定されるが、サーバー侵害に備えて更新
中パッケージは導入済みだが用途を把握できていない依存関係と実行中プロセスを確認したうえで更新
低システムRPMとしてlibssh2が未導入ホストへの直接影響は低いが、コンテナーや同梱ライブラリを別途確認

特に確認したいのは、次のようなシステムです。

  • SFTPによるファイル送受信サービス
  • バックアップやログ転送エージェント
  • CI/CDのデプロイ処理
  • 外部事業者とのデータ連携
  • SSH接続機能を持つ業務アプリケーション
  • libcurlなどを経由してlibssh2を利用するアプリケーション
  • ユーザーが任意のSSH接続先を指定できるサービス

MSRCの表示だけで修正版を判断しない

MSRCのCVEページや、その情報を取り込んだ外部サービスでは、製品名として次のような表記が表示される場合があります。

  • azl3 libssh2 1.11.1-4 on Azure Linux 3.0
  • azl3 libssh 0.10.6-8 on Azure Linux 3.0

しかし、これらの表記をそのまま「FirstFixedの修正版」として運用判定に使うのは避けてください。

Azure Linuxの公式修正プルリクエストでは、CVE-2026-66034.patchが追加された際に、libssh2のリリース番号が4から5へ変更されています。パッケージマニフェストもlibssh2-1.11.1-4からlibssh2-1.11.1-5へ更新されています。(GitHub)

さらに、Azure Linux 3.0の公式RPMリポジトリには、次のパッケージが公開されています。

  • libssh2-1.11.1-5.azl3.x86_64.rpm
  • libssh2-1.11.1-5.azl3.aarch64.rpm

したがって、2026年8月2日時点での実務的な修正判定は、次のようになります。(Microsoft Packages)

導入済みパッケージ判定
libssh2-1.11.1-4.azl3以前更新が必要
libssh2-1.11.1-5.azl3CVE-2026-66034の修正を含む
libssh2-1.11.1-6.azl3など、さらに新しい版原則として修正を含む
libssh-0.10.6-8.azl3別パッケージのため修正判定には使用できない
独自ビルドのlibssh2 1.11.1パッチ適用状況を個別に確認

libsshとlibssh2は別のパッケージ

libsshとlibssh2は名前が似ていますが、別々に開発されているSSHライブラリです。

Azure Linuxのlibssh 0.10.6-8では、パッケージ履歴上、別の脆弱性であるCVE-2026-0968への対応が記録されています。CVE-2026-66034のlibssh2修正を確認する根拠にはなりません。(GitHub)

次のような判断は誤りです。

libssh 0.10.6-8が入っているため、libssh2のCVE-2026-66034も修正済みである

脆弱性スキャン結果や資産台帳を確認するときは、パッケージ名を省略せず、libssh2であることを必ず確認してください。

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

Azure Linuxでは、RPMとTiny DNFのtdnfを使用してパッケージを確認・更新できます。(Microsoft Learn)

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

最初に、対象サーバーがAzure Linux 3.0であることを確認します。

cat /etc/os-release

VERSION_IDなどの情報を確認し、Azure Linux 3.0以外であれば、そのディストリビューション向けのセキュリティ情報を参照してください。

libssh2の導入状況を確認する

次のコマンドを実行します。

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

修正前の例は次のとおりです。

libssh2-1.11.1-4.azl3.x86_64

修正後の例は次のとおりです。

libssh2-1.11.1-5.azl3.x86_64

ARM64環境では、アーキテクチャ部分が次のようになります。

libssh2-1.11.1-5.azl3.aarch64

次のように表示された場合、システムRPMとしてのlibssh2は導入されていません。

package libssh2 is not installed

ただし、RPMが未導入でも、コンテナー、/opt配下のアプリケーション、静的リンクされた実行ファイルにlibssh2が含まれている可能性があります。

libsshとの混同を確認する

念のため、両方のパッケージを同時に確認すると判断しやすくなります。

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

出力例は次のとおりです。

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

この場合、CVE-2026-66034の判定対象は1行目のlibssh2です。

libssh2を修正版へ更新する手順

Azure Linux 3.0で、リポジトリ情報を更新してからlibssh2をアップデートします。

sudo tdnf clean all
sudo tdnf update libssh2

システム全体の未適用更新もまとめて導入する運用であれば、次のコマンドを使用します。

sudo tdnf upgrade

本番環境では、事前に次の点を確認してください。

  • 更新対象パッケージの一覧
  • アプリケーションのメンテナンス時間
  • 再起動可能なサービス
  • ロールバック手段
  • VMまたはディスクのバックアップ方針
  • コンテナーイメージの再ビルド可否

tdnf update libssh2を実行しても更新されない場合は、リポジトリの同期状況、パッケージ除外設定、バージョン固定、社内ミラーの反映状況を確認します。

更新後に修正版が入ったか確認する

更新コマンドが正常終了しただけではなく、実際のRPMバージョンを再確認してください。

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

次のいずれかであれば、Azure Linuxの修正版を導入できています。

libssh2-1.11.1-5.azl3.x86_64
libssh2-1.11.1-5.azl3.aarch64

または、1.11.1-5.azl3より新しいリリースです。

パッケージの変更履歴も確認できます。

rpm -q --changelog libssh2 | head -n 30

脆弱性スキャナーが上流バージョンの1.11.1だけを見て警告を継続する場合は、次の情報を証跡として保存すると説明しやすくなります。

  • rpm -q libssh2の結果
  • RPMの完全なリリース番号
  • パッケージ変更履歴
  • Azure Linux公式の修正差分
  • 更新実施日時
  • 再スキャン結果

Azure Linuxでは上流バージョンを変更せず、ディストリビューション側のリリース番号を上げて修正をバックポートすることがあります。したがって、スキャナー側にも1.11.1-5.azl3を修正版として判定できるルールが必要です。

更新後はlibssh2を利用するプロセスを再起動する

共有ライブラリを更新しても、すでに起動しているプロセスは、更新前のライブラリをメモリー上に読み込んだまま動作することがあります。

libssh2を読み込んでいるプロセスを確認するには、lsofが導入されている環境で次のように実行します。

sudo lsof 2>/dev/null | grep 'libssh2\.so'

対象プロセスを特定できた場合は、該当サービスを再起動します。

sudo systemctl restart <サービス名>

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

sudo systemctl reboot

更新後は、SFTP接続、バックアップ、デプロイ、外部連携など、libssh2を利用する処理の動作確認も行ってください。

コンテナー内のlibssh2も個別に更新する

Azure LinuxホストのRPMを更新しても、その上で動作するコンテナーイメージ内のlibssh2は更新されません。

Azure Linuxベースのコンテナーであれば、コンテナー内から確認します。

docker exec <コンテナー名> \
  rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' libssh2

Kubernetes環境では、対象Pod内で確認します。

kubectl exec -n <名前空間> <Pod名> -- \
  rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' libssh2

脆弱なパッケージが含まれていた場合、稼働中コンテナーだけを直接更新するのではなく、通常は次の手順で対応します。

  1. Dockerfileやベースイメージを更新する
  2. コンテナーイメージを再ビルドする
  3. イメージスキャンを実行する
  4. 新しいイメージをレジストリへ登録する
  5. Deploymentなどを更新して再デプロイする
  6. 古いイメージの利用を停止する

稼働中コンテナーだけを更新すると、Podやコンテナーの再作成時に脆弱な状態へ戻るため注意してください。

独自ビルドや同梱版のlibssh2を確認する

RPMでlibssh2が見つからない場合でも、アプリケーションが独自にライブラリを同梱している可能性があります。

代表的な配置先を検索します。

find /usr/local /opt -type f \
  \( -name 'libssh2.so' -o -name 'libssh2.so.*' \) \
  2>/dev/null

共有ライブラリのキャッシュも確認できます。

ldconfig -p 2>/dev/null | grep libssh2

独自ビルド版のlibssh2 1.11.1を使用している場合、バージョン文字列だけでは修正済みか判断できません。次のいずれかを確認してください。

  • 上流の修正コミットa13bb6c以降を取り込んでいる
  • libssh2_publickey_list_fetch()の境界チェックをバックポートしている
  • 修正済みの新しい上流リリースを使用している
  • アプリケーションベンダーがCVE-2026-66034対応済みと明示している

静的リンクされている場合は、OS側の共有ライブラリを更新しても修正されません。修正版libssh2を使ってアプリケーション自体を再ビルドする必要があります。(GitHub)

CVE-2026-66034対応で起きやすい失敗

libsshだけを更新して対応完了と判断する

CVE-2026-66034の主対象はlibssh2です。

rpm -q libssh2

で確認し、libsshのバージョンだけで判断しないでください。

1.11.1という上流バージョンだけを見る

Azure Linuxの修正はRPMリリース番号-5.azl3に含まれています。

1.11.1-4.azl3：更新が必要
1.11.1-5.azl3：修正済み

比較するときは、1.11.1だけでなく、末尾のリリース番号まで確認します。

ホストだけを更新してコンテナーを見落とす

VMのlibssh2と、コンテナーイメージ内のlibssh2は別々に管理されています。ホストの更新後も、すべての利用中イメージをスキャンしてください。

パッケージ更新後にサービスを再起動しない

ディスク上の共有ライブラリが更新されても、プロセスが古いライブラリを読み込んだままでは、脆弱性対応が完全には反映されません。関連サービスの再起動またはOS再起動までを作業に含めます。

リポジトリキャッシュや社内ミラーが古い

1.11.1-5.azl3が取得できない場合は、次の項目を確認します。

  • tdnf clean allを実行したか
  • Azure Linux 3.0用リポジトリが有効か
  • 社内ミラーへ最新RPMが同期されているか
  • exclude設定でlibssh2が除外されていないか
  • バージョンロックが設定されていないか
  • プロキシやリポジトリ認証でエラーが出ていないか

スキャナーの警告を確認せず例外登録する

バックポート型の修正では、脆弱性スキャナーが上流バージョンだけを比較し、誤検知することがあります。

ただし、警告が出たからといって、すぐに例外登録してはいけません。実際のRPMが1.11.1-5.azl3以上であること、コンテナーや独自ビルドに古いコピーが残っていないことを確認してから、根拠付きで判定してください。

まとめ：確認、更新、再起動、再スキャンまで実施する

CVE-2026-66034への対応では、Azure Linux 3.0のlibssh2を1.11.1-5.azl3以上へ更新します。

対応作業は、次の順番で進めると見落としを減らせます。

  1. rpm -q libssh2で導入済みバージョンを確認する
  2. 1.11.1-4.azl3以前ならtdnf update libssh2を実行する
  3. 1.11.1-5.azl3以上になったことを確認する
  4. libssh2を利用するサービスまたはOSを再起動する
  5. コンテナーイメージと独自ビルド版も調査する
  6. 脆弱性スキャンを再実行する
  7. RPMバージョンと更新日時を対応証跡として保存する

libssh 0.10.6-8は別パッケージであり、CVE-2026-66034の修正版判定には使用できません。また、libssh2 1.11.1-4ではなく、Azure Linux公式の修正差分と公開RPMで確認できるlibssh2 1.11.1-5.azl3以降を基準にしてください。(GitHub)

Azure
セキュリティ更新 脆弱性 Azure Linux libssh2 CVE-2026-66034

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次