Azure Linux 3.0でlibssh2を利用している場合は、インストール済みの完全なRPMリリース番号を確認し、libssh2-1.11.1-5.azl3以降へ更新してください。CVE-2026-66035は、SSHクライアントが悪意のあるSSHサーバーとEncrypt-then-MAC（ETM）暗号を交渉した際、認証前にヒープ領域を破壊される可能性がある脆弱性です。CVSS v3.1は7.5のHigh、脆弱性分類はCWE-122です。(NVD)
MSRCのFirstFixedには「azl3 libssh 0.10.6-8」「azl3 libssh2 1.11.1-4」が掲載されています。一方、Azure Linuxの公式パッケージ履歴では、CVE-2026-66035の修正パッチを追加した際にlibssh2のReleaseが4から5へ更新され、実際の配布リポジトリにも1.11.1-5.azl3が公開されています。このため、2026年8月2日時点では1.11.1-4.azl3で対応完了とせず、公式リポジトリから提供される最新パッケージ、少なくとも1.11.1-5.azl3以降を適用するのが安全です。(Microsoft Security Response Center)
CVE-2026-66035の要点と対応結論
CVE-2026-66035の概要を整理すると、次のとおりです。
| 項目 | 内容 |
|---|---|
| 対象 | Azure Linux 3.0で利用されるlibssh2 |
| 脆弱性 | ETM暗号処理時のヒープバッファーオーバーフロー |
| 攻撃条件 | libssh2を使うクライアントが悪意のあるSSHサーバーへ接続する |
| 発生タイミング | SSHユーザー認証より前 |
| CVSS v3.1 | 7.5 High |
| CVSSベクター | AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H |
| CWE | CWE-122：Heap-based Buffer Overflow |
| 上流の影響範囲 | libssh2 1.11.1まで |
| Azure Linuxでの推奨基準 | libssh2-1.11.1-5.azl3以降 |
| 主な対応 | パッケージ更新、プロセス再起動、コンテナイメージ再構築 |
上流のlibssh2では、バージョン1.11.1までが影響範囲として示されています。ただし、Linuxディストリビューションは脆弱性修正をバックポートするため、Azure Linuxでは上流バージョンが1.11.1のままでも、後ろのRelease番号によって修正状況が変わります。したがって、1.11.1というバージョン部分だけでは安全性を判断できません。(NVD)
実務上の判断は次のようになります。
| 確認結果 | 判断 |
|---|---|
libssh2-1.11.1-5.azl3以降 | CVE-2026-66035の修正パッチを含む |
libssh2-1.11.1-4.azl3以前 | 更新が必要 |
| libssh2が未インストール | OSパッケージとしては対象外。ただし同梱ライブラリやコンテナを別途確認 |
| libsshだけがインストール済み | libssh2とは別ライブラリ。libsshのバージョンだけで修正済みとは判断できない |
ETM暗号交渉時にヒープバッファーオーバーフローが起きる仕組み
ETMは「Encrypt-then-MAC」の略で、暗号化したデータに対してMACによる完全性検証を行う方式です。CVE-2026-66035では、このETMを利用するSSH通信のパケット処理に問題がありました。
攻撃の流れは次のとおりです。
- libssh2を使用するクライアントがSSHサーバーへ接続する
- クライアントとサーバーがETM暗号方式を交渉する
- 悪意のあるサーバーが、暗号ブロックサイズより小さい
packet_lengthを含む不正なパケットを送る - 脆弱なlibssh2が、コピーするデータ量より小さなヒープバッファーを確保する
- バッファーの境界を超えてデータが書き込まれ、隣接するヒープ領域が破壊される
NVDの説明では、特定条件下でヒープ管理情報や隣接オブジェクトが破壊され、プロセスのクラッシュだけでなく、関数ポインターの上書きにつながる可能性も示されています。ただし、実際の影響はCPUアーキテクチャ、メモリアロケーター、アプリケーションの実装などに左右されます。(NVD)
上流の修正コミットでは、復号処理へ進む前に、受信済みデータの合計サイズが「MAC長、パケット長フィールド、暗号ブロックサイズ」を満たしているか検証する処理が追加されました。サイズが不足している場合は復号エラーとして処理を中止し、不適切なメモリーコピーを防ぎます。(GitHub)
影響を受けるのはSSHサーバーではなくlibssh2を使うクライアント
CVE-2026-66035は、Azure Linux上のsshdが外部から不正な接続を受けるだけで直ちに悪用される脆弱性ではありません。主な対象は、libssh2を組み込んで外部のSSHサーバーへ接続するクライアント側アプリケーションです。
たとえば、次のような処理が確認対象になります。
- SFTPやSCPを使うファイル転送バッチ
- バックアップ製品やファイル同期ツール
- libcurlを使ったSFTP・SCP通信
- PHPのSSH2拡張を利用するWebアプリケーション
- libssh2を直接組み込んだ自社アプリケーション
- 外部SSHサーバーからデータを取得するエージェント
- コンテナ内で動作する転送サービス
- ユーザー入力で接続先を変更できるSSH関連機能
危険度は、単にlibssh2がインストールされているかだけでなく、接続先と実行権限を含めて判断します。
| 利用状況 | 対応優先度 | 理由 |
|---|---|---|
| ユーザーが接続先ホストを指定できる | 高 | 悪意のあるSSHサーバーへ誘導される可能性がある |
| 外部企業や不特定のSSHサーバーへ自動接続する | 高 | 接続先の侵害がクライアントへの攻撃につながる |
| ホスト鍵検証を無効にしている | 高 | 偽装サーバーや中間者を排除しにくい |
| root権限のバッチでSFTPを実行している | 高 | メモリー破壊後の影響が大きくなりやすい |
| 接続先を固定し、厳格にホスト鍵を検証している | 中 | 攻撃経路は限定されるが、接続先侵害には対応できない |
| libssh2はあるが利用アプリが不明 | 中 | 依存関係を調査するまで対象外と断定できない |
| libssh2も同梱コピーも存在しない | 低 | 脆弱なコードが実行環境にない |
CVSSベクターでは攻撃元がネットワーク、攻撃条件の複雑さが高、攻撃者の事前権限は不要、クライアント側からの接続が必要と評価されています。CVSS 7.5という数字だけで一律に判断せず、外部SSHサーバーへ接続する処理から優先的に確認することが重要です。(NVD)
修正版の読み方：MSRCのFirstFixedだけで判定しない
MSRCのCVEページでは、Azure Linux 3.0向けのFirstFixedとして次のパッケージ表記が掲載されています。(Microsoft Security Response Center)
azl3 libssh 0.10.6-8 on Azure Linux 3.0azl3 libssh2 1.11.1-4 on Azure Linux 3.0
ただし、Azure Linuxの公式GitHubリポジトリにある修正履歴では、CVE-2026-66035のパッチ追加と同時にlibssh2のReleaseが4から5へ変更されています。SPECファイルにはCVE-2026-66035.patchが追加され、変更履歴にも1.11.1-5でCVE-2026-66035を修正したことが記載されています。(GitHub)
さらに、MicrosoftのAzure Linux 3.0本番リポジトリでは、x86_64とaarch64の両方についてlibssh2-1.11.1-5.azl3が配布されています。1.11.1-4.azl3は2026年7月8日、1.11.1-5.azl3は同年7月29日に公開されており、CVE修正のマージ履歴とも整合します。(Microsoft Packages)
このため、実務では次の基準を採用してください。
libssh2-1.11.1-4.azl3以前は更新対象とするlibssh2-1.11.1-5.azl3以降を修正済みの基準とする1.11.1-6.azl3など、さらに新しい公式版がある場合は新しい版を使う- FirstFixedと完全一致する版へダウングレードしない
- MSRCの表示だけでなく、Azure Linuxのパッケージ履歴と実際のリポジトリを確認する
libssh、libssh2、OpenSSHは別のソフトウェア
名前が似ていますが、次の3つは同一ではありません。
| 名前 | 主な役割 | 確認時の注意 |
|---|---|---|
| libssh | SSH機能を提供する別のライブラリ | libssh2の修正状況は判断できない |
| libssh2 | SSH2クライアント機能を提供するCライブラリ | CVE-2026-66035の実際の修正対象 |
| OpenSSH | sshやsshdを提供する実装 | ssh -Vではlibssh2の版を確認できない |
MSRCにlibssh 0.10.6-8が表示されていても、libssh2が1.11.1-4.azl3のままであれば、CVE-2026-66035への対応完了とは判断しないでください。
Azure Linux 3.0でインストール済みバージョンを確認する手順
OSのバージョンを確認する
最初に、対象ホストがAzure Linux 3.0であることを確認します。
. /etc/os-release
printf 'ID=%s VERSION_ID=%s\n' "$ID" "$VERSION_ID"VERSION_IDが3.0であることを確認してください。Azure Linux以外のコンテナをAzure Linuxホスト上で動かしている場合、ホストとコンテナは別々に調査する必要があります。
libssh2とlibsshの完全なRPMバージョンを確認する
次のコマンドでは、上流バージョンだけでなくAzure LinuxのRelease番号とCPUアーキテクチャまで表示できます。
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_64aarch64環境では、末尾が.aarch64になります。安全性の判断で重要なのは、1.11.1だけでなく-5.azl3まで含めた完全な値です。
よくある間違った確認方法
次のコマンドはOpenSSHのバージョンを表示するため、CVE-2026-66035の確認には使えません。
ssh -Vまた、libssh2はライブラリであり、環境によってはlibssh2 --versionという実行コマンド自体が存在しません。Azure Linuxのパッケージとして導入されている版は、rpm -q libssh2で確認してください。
アプリケーションがlibssh2を読み込むか確認する
対象の実行ファイルが分かっている場合は、動的リンクを確認できます。
ldd /path/to/application | grep libssh2出力例は次のとおりです。
libssh2.so.1 => /usr/lib64/libssh2.so.1ただし、何も表示されないからといって必ずしも安全とは限りません。静的リンク、独自ディレクトリへの同梱、実行時の動的読み込みではlddに現れないことがあります。製品のSBOM、依存関係ファイル、脆弱性スキャナー、ベンダー情報も併用してください。
Azure Linux 3.0のlibssh2を修正版へ更新する手順
Azure Linuxのパッケージ管理ではtdnfを使用します。Microsoftのドキュメントでも、インストール済みパッケージの確認にrpm、パッケージ更新にtdnf upgradeを使用する方法が案内されています。(Microsoft Learn)
更新前に確認すること
本番環境では、更新前に次の項目を確認します。
- SFTPやSCPを実行しているジョブの稼働時間
- 更新後に再起動するサービス
- 冗長構成の切り替え手順
- VMやディスクのバックアップ方針
- コンテナやAKSノードが別管理になっていないか
- 社内リポジトリやプロキシに最新版が同期済みか
ライブラリ更新は実行中のプロセスへ自動的に読み直されません。パッケージ更新だけでなく、利用アプリケーションの再起動まで変更計画に含めてください。
libssh2を個別に更新する
キャッシュを削除してから、libssh2を更新します。
sudo tdnf clean all
sudo tdnf upgrade -y libssh2MSRCに掲載されたlibsshもインストール済みであれば、併せて最新版へ更新します。
rpm -q libssh >/dev/null 2>&1 && sudo tdnf upgrade -y libsshパッケージ間の依存関係や他のセキュリティ修正もまとめて適用する運用であれば、システム全体を更新します。
sudo tdnf upgrade -y対象パッケージを個別更新するか、システム全体を更新するかは、組織のパッチ管理方針と影響試験の範囲に合わせて選びます。ただし、古いパッケージを固定するバージョンロックが設定されている場合は、先に解除または例外登録が必要です。
更新後のバージョンを確認する
更新後に、完全なRPMバージョンを再確認します。
rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' libssh2 libsshlibssh2-1.11.1-5.azl3以降であることを確認してください。さらにパッケージの変更履歴を確認する場合は、次のコマンドを利用できます。
rpm -q --changelog libssh2 | grep -A2 'CVE-2026-66035'変更履歴の表示は補助的な確認方法です。最終的には、インストール済みの完全なRPMリリース番号と、利用しているリポジトリの最新情報で判断します。
libssh2を読み込むプロセスを再起動する
ディスク上の共有ライブラリが更新されても、更新前から動いているプロセスは古いライブラリをメモリー内に保持している可能性があります。
次のようなプロセスを再起動してください。
- SFTP・SCP転送サービス
- バックアップエージェント
- PHP-FPMやWebアプリケーション
- libssh2を使う自社デーモン
- ジョブ実行ワーカー
- 長時間稼働するコンテナ
対象プロセスを特定できない場合は、影響を確認したうえでメンテナンス時間内にOSを再起動する方法が確実です。
接続テストを行う
再起動後は、信頼できるSSHサーバーを使って次の項目を確認します。
- SFTPまたはSCP接続が成功する
- ホスト鍵検証が正常に行われる
- ファイル送受信が成功する
- 転送後のファイルサイズやハッシュが一致する
- アプリケーションログに復号エラーやクラッシュがない
- 定期ジョブが正常終了する
本番の転送処理だけを確認するのではなく、認証、接続、転送、切断まで一連の処理をテストしてください。
コンテナとAKSで見落としやすいポイント
ホストを更新してもコンテナ内は更新されない
Azure Linux 3.0ホストのlibssh2を更新しても、コンテナイメージ内に含まれるlibssh2は変更されません。コンテナ内でSFTPやSCP通信を行う場合は、イメージ側のパッケージを調査します。
RPMベースのイメージであれば、次のように確認できます。
docker run --rm --entrypoint rpm <image-name> -q libssh2実行中のKubernetes Podを確認する例は次のとおりです。
kubectl exec <pod-name> -- rpm -q libssh2ただし、distrolessイメージや最小構成イメージにはrpmコマンドがありません。その場合は、コンテナスキャナー、SBOM、Dockerfile、ビルドログなどから依存関係を確認します。
脆弱なパッケージが含まれていた場合は、稼働中コンテナへ直接パッチを当てるのではなく、次の流れで対応します。
- ベースイメージを更新する
- パッケージ更新を含めてイメージを再ビルドする
- 脆弱性スキャンを実行する
- 新しいイメージをレジストリへ登録する
- Deploymentやジョブを再デプロイする
- 古いイメージの再利用を防止する
AKSノードはノードイメージの更新状況も確認する
AKSでAzure Linux 3.0ノードを使用している場合は、個々のノードへ手作業でパッケージを入れるだけでなく、修正版を含むノードイメージへ更新する運用を検討します。Microsoftは、ノードイメージの自動アップグレードチャネルや、メンテナンス期間内のセキュリティパッチ適用を推奨しています。(Microsoft Learn)
なお、AKSノードのOSとPod内のコンテナは別の管理対象です。
| 対象 | 必要な対応 |
|---|---|
| AKSノードOSのlibssh2 | ノードイメージ更新、OS更新チャネルの確認 |
| Pod内のlibssh2 | コンテナイメージの再構築と再デプロイ |
| アプリに静的リンクされたlibssh2 | アプリケーション自体の再ビルド |
| ベンダー製エージェント | ベンダーの修正版へ更新 |
すぐに更新できない場合の一時対策
一時対策は攻撃経路を狭めるものであり、ヒープバッファーオーバーフロー自体を修正するものではありません。更新が完了するまでの短期間に限定して使用します。
- SSH・SFTPの接続先を許可済みIPアドレスやFQDNに限定する
- ファイアウォールやNSGで不要な外向きSSH通信を遮断する
- ユーザー入力から接続先ホストやポートを直接指定できないようにする
- SSHホスト鍵を事前登録し、厳格に検証する
StrictHostKeyChecking=noなどの検証無効化設定を廃止する- ファイル転送処理を非特権ユーザーで動かす
- 外部SSHサーバーへ接続する処理を専用ワーカーへ隔離する
- 信頼性を確認できない接続先への自動転送を一時停止する
ホスト鍵検証を有効にしても、正規の接続先サーバー自体が侵害されている場合は防げません。最終的な対策は、修正版のlibssh2へ更新することです。
対応時によくある失敗
| 失敗例 | 問題点 | 正しい対応 |
|---|---|---|
ssh -Vだけを確認する | OpenSSHの版しか分からない | rpm -q libssh2を実行する |
1.11.1だけを比較する | Azure Linuxのバックポートを判定できない | 1.11.1-5.azl3まで確認する |
MSRCの1.11.1-4で止める | 公式のCVEパッチ追加はRelease 5 | 1.11.1-5.azl3以降へ更新する |
libssh 0.10.6-8だけを確認する | libsshとlibssh2は別ライブラリ | 両パッケージを個別に確認する |
| VMホストだけを更新する | コンテナ内に脆弱なコピーが残る | イメージを再ビルドして再配備する |
| パッケージ更新後に再起動しない | 実行中プロセスが旧ライブラリを保持する | サービスやコンテナを再起動する |
| FirstFixedへダウングレードする | 後続のセキュリティ修正を失う | 利用可能な最新の公式版を維持する |
| libssh2未導入だけで対象外と判断する | アプリが独自コピーを同梱している可能性がある | SBOMやバイナリ依存関係も調査する |
CVE-2026-66035への対応で今すぐ行うこと
Azure Linux 3.0を運用している場合は、次の順序で対応します。
rpm -q libssh2 libsshでインストール状況を確認するlibssh2-1.11.1-4.azl3以前を更新対象として抽出するtdnfでlibssh2-1.11.1-5.azl3以降へ更新する- libssh2を使用するサービスやジョブを再起動する
- コンテナ、AKSノード、静的リンクされたアプリも別途調査する
- 信頼できるSSHサーバーを使ってSFTP・SCPの接続試験を行う
- ホスト鍵検証と外向きSSH通信の制御を見直す
特に注意したいのは、MSRCのFirstFixed表示とAzure Linuxの実際のパッケージ修正履歴に差がある点です。CVE-2026-66035のパッチ追加が公式履歴で確認できるのはlibssh2-1.11.1-5.azl3であるため、1.11.1-4.azl3を残さず、利用可能な最新のAzure Linux 3.0向けパッケージへ更新してください。(GitHub)
コメント