libssh2の未認証RCE(CVE-2026-55200)：静的リンクまで含めて影響範囲を棚卸しする

2026年7月に公表された CVE-2026-55200 は、SSHクライアントライブラリ libssh2（1.11.1 以前）の ssh2_transport_read() が packet_length の上限を検証せず、境界外書き込み（ヒープ破壊）を起こす脆弱性だ。NVDのスコアは CVSS 8.1（High）。悪意あるSSHサーバが不正なパケットを送ると、接続したクライアント側で認証前（pre-auth）にメモリ破壊が発生し、RCEに至り得る。upstream の commit 7acf3df で修正されている。

厄介なのは、libssh2 は curl・Git系クライアント・PHP などに静的リンクされている場合があり、「OSのパッケージを更新しただけ」では取りこぼすことだ。だからまず、自分の環境で誰が libssh2 を使っているかを洗い出す。

1. パッケージ版の libssh2 を確認

Debian/Ubuntu系:

dpkg -l 'libssh2*' 2>/dev/null | grep '^ii'
# ii  libssh2-1:amd64  1.11.0-x  ...  ← 1.11.1以前なら要更新

RHEL系:

rpm -q libssh2

2. 実行ファイルが libssh2 を動的リンクしているか

ldd で共有ライブラリ依存を見る。curl が典型例だ。

ldd "$(command -v curl)" | grep -i ssh2
# libssh2.so.1 => /usr/lib/x86_64-linux-gnu/libssh2.so.1  ← 動的リンク

動的リンクなら、パッケージ更新で libssh2.so を差し替えれば直る。問題は次のケースだ。

3. 静的リンク／同梱バイナリを stringsで炙り出す

ldd に出てこないのに libssh2 を内部に抱えているバイナリは、strings でバージョン文字列を探すと見つかることがある。

# PATH上の実行ファイルから libssh2 の痕跡を探す
for f in $(echo "$PATH" | tr ':' ' '); do
  find "$f" -maxdepth 1 -type f 2>/dev/null
done | while read -r bin; do
  if strings -a "$bin" 2>/dev/null | grep -qiE 'libssh2/[0-9]'; then
    echo "$bin -> $(strings -a "$bin" | grep -oiE 'libssh2/[0-9.]+' | head -1)"
  fi
done

libssh2/1.11.1 などと出てきたら、そのバイナリは自前で libssh2 を抱えている可能性が高い。配布元の更新（再ビルド版）を待つか、自分でビルドし直す必要がある。コンテナイメージなら、ビルドに使ったベースイメージ側の更新も忘れずに。

4. 当座の緩和

パッチ適用までの緩和策は「攻撃経路を絞る」ことだ。この脆弱性はこちらが接続しに行くSSHサーバが悪意を持つと成立するため、

• SSHクライアントの接続先を信頼できるホストに限定する（アウトバウンドSSHをファイアウォールで制御）。
• ホスト鍵検証を厳格化し、未知ホストへ不用意に接続しない。
• curl で scp:// / sftp:// を使う自動処理は、接続先が信頼できるか見直す。

5. 直し方

• Debian: testing の libssh2 1.11.1-4 でパッチ取込済み。安定版は各セキュリティトラッカで配信状況を確認。
• Ubuntu / RHEL: 各ディストリのアドバイザリ公開後に apt/dnf でアップグレード。未公開なら commit 7acf3df のバックポート適用可否を確認。
• 静的リンクバイナリ: 配布元の更新版に入れ替えるか、パッチ版 libssh2 で再ビルド。

クラウド上のLinux（AWS/GCP/Azureのゲストマシン）も、基本はゲストOSのディストリ更新で対応する（各社固有アドバイザリではなくパッケージ更新の話になる）。この手の「どのクラウド/OSで、いつ、どう直すか」を1件ずつ整理している脆弱性対応ウォッチにも CVE-2026-55200 を掲載しているので、AWS/GCP/Azure/Linux別の対応状況の当たりを付けるのに使ってほしい。