libssh2に脆弱性10件、公式の最新版は2024年のまま CVE-2026-66032

2026年7月24日、libssh2（リブエスエスエイチツー）という部品に4件の脆弱性がまとめて公表されました。CVE-2026-66032／CVE-2026-66033／CVE-2026-66034／CVE-2026-66035の4件です。これで2026年に公表されたlibssh2の脆弱性は10件になりました。

libssh2は、プログラムが他のサーバーへSSH（暗号化された遠隔接続）やSFTP（暗号化されたファイル転送）でつなぎに行くときに使う共通部品です。名前を知らなくても使っている可能性が高いもので、たとえばファイルのダウンロードで広く使われるcurl（カール）は、SFTP接続をこの部品にやらせています。Gitの操作をプログラムから行うlibgit2も、SSH接続の実装として「libssh2、またはOpenSSHの呼び出し」を選べる作りです。PHPで社外サーバーとファイルをやり取りするssh2拡張にいたっては、libssh2そのものが動作要件です。

今回の10件には、他のCVE記事とは違う特徴が2つあります。ひとつは、壊されるのが接続される側ではなく、つなぎに行った側だということ。もうひとつは、開発元の最新版が2024年10月の1.11.1のまま更新されていないことです。「最新版に上げてください」で終われない話なので、確認方法と、いま何がどこまで直っているのかを実際に手元で確かめて整理します。

2026年に公表された10件の一覧

10件を並べる前に、点数の読み方を一つ。危険度は深刻さを0〜10で表す国際的な共通スコア「CVSS」で、いま移行期のため新しい4.0版と従来の3.1版の両方が付いています。数字が食い違うものがありますが、これは評価方法の違いによるもので、どちらかが間違っているわけではありません。

10件のうち4件は「認証前」、つまりログインが成立する前の、暗号方式を決めたり最初の挨拶をやり取りしたりする段階で成立します。鍵やパスワードが正しいかどうかは関係ありません。相手のサーバーに接続を試みた時点で勝負がついている、という意味です。

1件だけ番号が「CVE-2025-」で始まっていますが、これは番号の予約が2025年だっただけで、公表されたのは2026年6月18日です。脆弱性の管理表で年別に並べていると、この1件だけ去年の欄に落ちて見落としやすくなります。

危ないのは「こちらが接続しに行く先」

この10件で手を出せるのは、こちらが接続しに行く先のサーバーを用意できる、あるいは既に乗っ取っている人間です。ここが普通の脆弱性と向きが逆です。公開しているサーバーを守れば済む話ではなく、たとえば取引先から「ここへ毎晩ファイルを取りに来てください」と指定されたSFTPサーバー、社内の踏み台として使っている中継サーバー、あるいはプログラムが自動でつなぎに行く先――そのどこかひとつが相手側の都合で悪意ある挙動に変わったとき、被害を受けるのは取りに行ったこちら側です。

取引先指定のSFTPサーバーが悪意ある側に回ったとき、実際に仕掛けてくるのは、SSHの決まった手順の中で、長さや個数を書く欄にわざと異常な数字を入れて返し、接続してきたプログラムの記憶領域を壊すことです。SSHは接続の最初に「これから使う暗号はこれ」「この長さのデータを送る」といった申告をやり取りします。その申告を素直に信じて領域を用意する処理に穴があるため、申告と実物をずらされると、用意した箱からはみ出して書き込みが起きます。認証前に成立する4件は、まさにこの申告のやり取りだけで完結します。

社内の踏み台にせよ、取引先指定のSFTPサーバーにせよ、そこから先の展開は軽重2つに割れます。軽いほうは、そのプログラムが落ちる・固まることです。毎晩のファイル連携が黙って止まり、翌朝データが揃っていない、という形で表に出ます。重いほうは、壊した記憶領域を足がかりに接続しに行った側のサーバーで、そのプログラムの権限のまま命令を実行されることです。認証情報や鍵を扱うバッチ処理が動いている場所なので、そこから先へ広がります。実際、6月公表のCVE-2026-55200については攻撃を再現するコードが公開された記録がNVDに残っており、机上の空論ではありません。同じ「つなぎに行った側が壊される」構図は、端末ソフトのTera Termの脆弱性でも起きています。

自分が使っているかを1分で確かめる

libssh2は「使っている自覚がない」部品の代表です。いちばん早いのは、curlに聞くことです。手元のUbuntu 26.04 LTSで実行した結果がこれです。

$ curl -V
curl 8.18.0 (x86_64-pc-linux-gnu) libcurl/8.18.0 OpenSSL/3.5.5 zlib/1.3.1
  brotli/1.2.0 zstd/1.5.7 libidn2/2.3.8 libpsl/0.21.2 libssh2/1.11.1
  nghttp2/1.68.0 librtmp/2.3 mit-krb5/1.22.1 OpenLDAP/2.6.10
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns
  ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp ws wss

1行目にlibssh2/1.11.1と出ています。つまりこのcurlは、scpとsftpの処理をlibssh2にやらせているということです。curlを直接使っていなくても、多くの言語のHTTPライブラリはlibcurlを内側で呼んでいます。

どの実体ファイルにつながっているかまで確かめるなら、次の1行です。

$ ldd $(which curl) | grep ssh
	libssh2.so.1 => /usr/lib/x86_64-linux-gnu/libssh2.so.1

$ dpkg -l | grep libssh2
ii  libssh2-1t64:amd64  1.11.1-1ubuntu0.26.04.3  amd64  SSH2 client-side library

ここで見落としやすい点がひとつあります。curl -Vに出る「1.11.1」は開発元が付けた版番号で、ディストリが後から当てた修正は反映されません。Ubuntuのパッケージ番号のほうが実態を表しています。上の例では1.11.1-1ubuntu0.26.04.3の末尾の.3が「3回目の修正入り」を意味します。1.11.1という表示だけを見て「全部の穴が開いている」と判断すると過大に、逆に「Ubuntuだから安全」と判断すると過小になります。判断材料はパッケージ番号のほうです。

Windowsやコンテナ内の自前ビルドを含めて、依存関係の棚卸しを定期的に回す方法はOSSの依存を貼るだけで点検する仕組みにまとめてあります。今回のような「間接的に入っている部品」は、Nettyの脆弱性のときと同じで、人力の記憶では追い切れません。

それぞれ何が起きるのか（7月24日公表の4件）

CVE-2026-66035: 認証前に記憶領域を書き換えられる

4件のうち、いちばん先に成立するのがこれです。SSHでは接続開始時に暗号方式を決めますが、その中に「先に暗号化してから改ざん検出用の値を付ける（Encrypt-then-MAC）」という方式があります。NVDの説明によれば、この方式を使う経路で、相手が申告するデータ長を暗号の1ブロック分より小さい値にすると、確保した箱より1ブロック近く多く書き込まれます。書き込まれる先は、隣の領域の管理情報です。ログインの前に成立するため、鍵もパスワードも防波堤になりません。修正はコミット42e33d8です。

CVE-2026-66033: 暗号方式を選ばせるだけで、接続元が落ちる

こちらも認証前です。AES-GCMという暗号方式を選んだときの計算に、引き算の結果がマイナスになる箇所があります。プログラムの世界ではマイナスの長さが巨大な正の数として扱われるため、ほぼ上限いっぱいの長さでのデータ複写が走り、その場で強制終了します。壊されるというより「確実に落とされる」性質のもので、悪意あるサーバーは接続してきた相手を選んで止められます。夜間バッチが毎回ここで死ぬ、という形になります。修正はコミットa2ed82dです。

CVE-2026-66032: SFTPを開いた直後に、同じ場所を二度手放す

10件のなかで3.1版の評価がいちばん高い（8.8）のがこれです。SFTPでファイルを開く要求に対し、サーバーが「成功」という応答を特定の形で返すと、受け取ったデータを片付けたあとで、もう一度同じ場所を片付けてしまいます。NVDの説明では、この状態を使って領域の管理表を混乱させ、本来別々のはずのデータを重ねて配置できるとされています。成立にはSFTPセッションの確立、つまり認証の通過が必要です。ただしファイル連携の相手先というのは、こちらが正規の鍵を持って毎晩ログインしに行く先そのものです。修正はコミット5e47761です。

CVE-2026-66034: 鍵の一覧を取りに行くと、記憶領域の中身が漏れる

サーバーに登録された公開鍵の一覧を取得する機能（publickeyサブシステム）の応答処理です。応答に含まれる「コメントの長さ」をそのまま信じて読み進めるため、実際のデータより長い値を返されると、隣接する領域まで読み出してしまいます。NVDによれば、ここで漏れるのは記憶領域の配置を示す値で、攻撃側にとっては「次に何をどこに置けばいいか」の答え合わせになります。さらに後片付けの経路で、初期化されていない場所を解放する動作も伴います。修正はコミットa13bb6cです。

5月・6月に公表されていた6件

7月の4件だけが特別なわけではありません。同じ「相手のサーバーに壊される」型が、5月から続けて出ています。

CVE-2026-55200: 通信の長さ欄に上限がなく、コード実行に至る

4.0版で9.2と、10件で最も重い評価です。SSHのデータを読む処理が、相手の申告する長さに上限を設けていませんでした。NVDの記述は「遠隔の攻撃者が記憶領域を破壊し、任意コード実行に至る」と明記しています。この1件については攻撃を再現するコードが公開された記録が参考情報として登録されており、10件のなかで唯一、実際に動く道具の存在が確認できます。修正はコミット7acf3dfです。

CVE-2026-55199: 拡張機能の個数に0xFFFFFFFFと書かれて止まる

鍵交換の途中でサーバーが送る「これから使う拡張機能はこれだけあります」という個数に、上限いっぱいの値を書かれると、その回数だけ空回りします。NVDによれば60秒を超えてCPUを使い切るとされ、しかもSSHの接続タイムアウト設定はこの種の空回りには効きません。認証前です。修正はコミット1762685です。

CVE-2025-15661: シンボリックリンクの確認で、領域の外まで読む

SFTPでリンク先の実体パスを問い合わせたときの応答処理です。返ってきた長さを検証せずに複写するため、記憶領域の中身が漏れるか、その場で落ちます。NVDは通信経路上の盗聴者（中間者）でも成立し得るとしており、悪意あるサーバーだけが条件ではありません。修正はコミット2dae302です。

CVE-2026-58050 / CVE-2026-58051: 鍵一覧の処理に2件

7月のCVE-2026-66034と同じ、公開鍵の一覧を扱う処理から出た2件です。CVE-2026-58050は属性の個数を掛け算するときに桁があふれ、32ビット環境で足りない大きさの箱が確保されます。CVE-2026-58051は、一覧を広げるときに新しい領域をゼロで埋めないため、解析に失敗して後片付けへ回ったとき、中身が定まらない場所を解放してしまいます。同じ機能から3か月で3件出ている計算になります。

CVE-2026-7598: 利用者名の長さの計算があふれる

10件のうち最も古い5月1日の公表で、パスワード認証の処理で利用者名とパスワードの長さの計算があふれるというものです。Red Hatはこの1件について自社の更新情報を公開済みで、Ubuntuも5月5日の更新で対処しています。修正はコミット256d04bです。

なぜ「最新版に上げてください」と書けないのか

libssh2の話が面倒になるのは、ここからです。libssh2の公開リリースを古い順に見ると、1.11.0が2023年5月、1.11.1が2024年10月16日。それ以降、新しいリリースは出ていません。開発元サイトの表記も「libssh2 1.11.1, released on 2024-10-16」のままです。

一方で修正は動いています。10件すべてに対応するコミットや変更依頼（プルリクエスト）が本流に入っています。つまりソースコードの最新は直っているのに、配布物としての最新は2年近く前のままという状態です。「1.11.1まで該当」と書かれた脆弱性情報が10件並んでいるのに、上げ先として指定できる番号が存在しない。ここが普通のCVE記事と決定的に違います。

この隙間を埋めているのが、UbuntuやDebianのような配布元です。彼らは1.11.1というバージョンはそのままに、修正コミットだけを個別に取り込んで配ります。手元のUbuntu 26.04で実際にパッケージの変更記録を開くと、それがはっきり見えます。

$ zcat /usr/share/doc/libssh2-1t64/changelog.Debian.gz | head -30
libssh2 (1.11.1-1ubuntu0.26.04.3) resolute-security; urgency=medium

  * SECURITY UPDATE: Multiple security issues in publickey
    - debian/patches/CVE-2026-58051.patch: fix potential OOB read in
      libssh2_publickey_list_fetch().
    - debian/patches/CVE-2026-58050.patch: cap variable-length packet element
      sizes.
    - CVE-2026-58050
    - CVE-2026-58051

 -- Marc Deslauriers <marc.deslauriers@ubuntu.com>  Tue, 07 Jul 2026 14:23:05 -0400

7月7日に6月公表分が入り、その前の6月29日にはCVE-2025-15661・CVE-2026-55199・CVE-2026-55200の3件が入っています。そして、7月24日公表の4件はここに入っていません。この記事の執筆時点で、Ubuntu 26.04に配られている最新のlibssh2パッケージは1.11.1-1ubuntu0.26.04.3であり、その中身は7月7日で止まっています。

ディストリ別の対応状況（7月29日時点）

Debianについては、公式の追跡表が1件ずつ状態を公開しています。Ubuntu 26.04の列は、上に載せたパッケージの変更記録を実際に読んで確認したものです。

読み方を3つ書きます。ひとつめ、7月24日の4件は、いま普通に使われている版のどこにも入っていません。入っているのはDebianの開発版（unstable）だけで、これは日々変わる実験用の版です。ふたつめ、Debian 12（bookworm）は6月分も含めて手つかずです。追跡表では「open」、つまり未対応のまま置かれています。みっつめ、6月28日公表の2件（CVE-2026-58050・58051）はDebian側で「undetermined（判定前）」のままです。Ubuntuは7月7日に取り込んでいるので、同じ穴に対する判断が配布元によって割れています。

RHEL系については、Red HatがCVE-2026-7598の情報を公開しています。7月分の扱いは各社の公開情報を確認してください。

ディストリの更新を待つ間にできること

上げ先が無い以上、やることは「更新」ではなく「減らす」と「見張る」になります。

まず、配布元の更新は当然として、apt list --upgradableなどで自動更新が実際に効いているかを確かめてください。ここが止まったまま何か月も経っている環境が、いちばん危険です。6月分の3件は多くの環境で既に配られているので、それすら当たっていないなら、まずそこを直すのが先です。

次に、接続先を絞ることです。この10件は「自分がつなぎに行った先」からしか成立しません。裏を返せば、つなぎに行く先が自社管理下のサーバーだけなら、成立条件はかなり厳しくなります。危ないのは、相手先が用意したSFTPサーバー、外部から指定されたURLをそのまま渡している処理、そして利用者が接続先を自由に入力できる画面です。特に3つめ――利用者が入力したホスト名にサーバー側から接続しに行く作りは、この脆弱性群では最悪の組み合わせになります。攻撃者が自分のサーバーを入力すればいいだけだからです。

3つめに、libssh2を避けられる場面では避けることです。ファイル転送をcurlや自作プログラムでやっているなら、OpenSSHのsftp／scpコマンドを呼ぶ方式へ切り替えるだけで、この10件の射程からは外れます。libgit2も、SSH接続の実装としてOpenSSHの呼び出しを選べる作りになっています。速度や実装の都合で選んだ部品が、いま更新の止まった側にある――という認識を持っておくだけでも判断は変わります。

最後に、自社製品にlibssh2を同梱している場合です。ディストリの更新は届きません。修正コミットを自分で取り込むか、次のリリースを待つかの判断が要ります。同じ「部品の側が止まっている」状況は、暗号ライブラリBouncy Castleの脆弱性やnode-forgeの署名検証の欠陥のときにも起きました。

よくある質問

Q. SSHサーバーを公開していません。関係ありますか？

関係します。今回の10件は、サーバーを公開しているかどうかではなく、プログラムが他所のSSH／SFTPサーバーへつなぎに行くかどうかで決まります。取引先とのファイル連携、社外リポジトリからの取得、バックアップの送信――こうした「こちらから出ていく通信」があれば対象です。

Q. OpenSSHの脆弱性とは違うのですか？

別物です。sshコマンドやSSHサーバーとして動くOpenSSHと、libssh2は独立した実装です。OpenSSHを最新にしても、libssh2の穴は塞がりません。逆に、SSH接続をOpenSSHのコマンド呼び出しでやっている処理は、libssh2の10件の対象外です。

Q. curl -Vに1.11.1と出ました。10件全部が開いているということですか？

いいえ。そこに出るのは開発元が付けた版番号だけで、配布元が当てた修正は反映されません。Ubuntu・Debianなどのパッケージ番号（例：1.11.1-1ubuntu0.26.04.3）を見てください。上の対応表のとおり、6月分までは配られている環境が多く、7月24日の4件が残っている、という状態が典型です。

Q. 実際に攻撃されている事例はありますか？

この記事の執筆時点で、米国CISAが公開する「実際に悪用が確認された脆弱性の一覧（KEV）」に、今回の10件は載っていません。ただしCVE-2026-55200については、攻撃を再現するコードが公開された記録が脆弱性情報の参考資料として登録されています。悪用の観測報告と、道具の存在は別の話です。後者は既にあります。

Q. 開発が止まっているということですか？

いいえ。修正コミットも変更依頼も継続して本流に入っており、コードは動いています。止まっているのはリリースの発行です。開発元が次の版をいつ出すかについて、この記事の執筆時点で公表された予定は確認できていません。

更新履歴

参照元

• ▸ NVD - CVE-2026-66035（認証前のヒープバッファオーバーフロー / 2026年7月24日公開）
• ▸ NVD - CVE-2026-66033（認証前の整数アンダーフロー / AES-GCM）
• ▸ NVD - CVE-2026-66032（sftp_open()の二重解放 / CVSS 3.1で8.8）
• ▸ NVD - CVE-2026-66034（publickeyサブシステムの境界チェック欠落）
• ▸ VulnCheck - libssh2 heap buffer overflow via ETM cipher negotiation（CVE-2026-66035の報告元）
• ▸ VulnCheck - libssh2 double-free heap corruption via sftp_open（CVE-2026-66032の報告元）
• ▸ libssh2 公式サイト（最新版の表記：1.11.1, released on 2024-10-16）
• ▸ GitHub - libssh2 リリース一覧（1.11.1が2024年10月16日で最新）
• ▸ Debian Security Tracker - libssh2（版ごとの対応状況）
• ▸ Ubuntu - libssh2 1.11.1-1ubuntu0.26.04.3 の変更記録（5月5日・6月29日・7月7日の3回分）
• ▸ Red Hat - CVE-2026-7598
• ▸ PHP Manual - ssh2拡張の動作要件（libssh2 1.2以降が必要）
• ▸ libgit2 - SSH実装としてlibssh2かOpenSSH呼び出しを選択できる旨の記載