結論：守るべきは「SSHサーバ」ではなく「SSH接続を張る側」
今回の脆弱性CVE-2026-55200は、SSHサーバを運用しているかどうかとは無関係に影響します。攻撃が成立するのは、libssh2を組み込んだプログラムが攻撃者の用意した悪性SSHサーバに接続したときだからです。つまり対策の出発点は「自社のサーバを守る」ことではなく、「自社のどのソフトウェアが、どこへSSH接続を張っているか」を棚卸しすることにあります。
libssh2はOpenSSHのようなSSHサーバ製品ではなく、アプリケーションにSSH/SCP機能を組み込むためのCライブラリです。curl、Git、PHP、各種バックアップエージェント、ファームウェア更新機構、ネットワーク機器のファームウェアなどに広く同梱されており、静的リンクされている場合は「入っていること自体に気づきにくい」点が今回の本質的な厄介さです。本記事は、情シス・SRE・組み込み/OSS内製を抱える組織が、最短で影響範囲を確定し、推移的依存まで含めて潰し込むための手順を整理します。
EMERGENCY RESPONSE
この脆弱性、貴社システムは影響を受けますか？
影響範囲の一次評価を無料で実施。致命的脆弱性は24時間以内にアラートし、パッチ適用・恒久対応まで伴走します。
何が起きたか：transport_readのpacket_length未検証による整数オーバーフロー
CVE-2026-55200は、libssh2のパケット受信処理ssh2_transport_read()（transport.c）に存在する、CWE-680（整数オーバーフローからのバッファオーバーフロー）に分類される欠陥です。SSHハンドシェイク中に受信するパケットのpacket_lengthフィールドに上限チェックがなく、これを32ビット演算でバッファ確保サイズの計算に使うため、巨大な値（例：0xffffffff）が与えられると桁あふれして極端に小さなサイズに化けます。結果として、小さく確保したヒープ領域に対し、後続処理が本来の大きなパケットを書き込もうとし、ヒープのアウトオブバウンズ書き込みが発生します（出典：NVD「CVE-2026-55200」、GitHub Advisory Database「GHSA-r8mh-x5qv-7gg2」）。
深刻度は、CNAであるVulnCheckによるCVSS 4.0で9.2 Critical、NISTによるCVSS 3.1基本値では9.8 Criticalと評価されています（出典：NVD「CVE-2026-55200」、初期解析 2026年6月26日）。攻撃には認証もユーザー操作も不要で、クライアントがサーバへ接続した瞬間のトランスポート交渉段階で発火します。
影響範囲は1.11.1以前のすべてのバージョンです。修正はアップストリームのコミット97acf3d（PR #2052）として2026年6月12日にmasterへマージされ、packet_lengthがLIBSSH2_PACKET_MAXPAYLOADを超える場合に演算前で拒否するガードが追加されました（出典：libssh2 GitHubリポジトリ、PR #2052）。安定版リリースとしての反映状況や各ディストリビューションでのバックポート提供状況は、利用中の配布元の最新情報で確認してください。
なお2026年6月29日には、ローカル検証用のトリガースキャフォールドと制御下のRCEハーネス、Pythonで実装された最小の悪性SSHサーバを含むPoCがGitHub上で公開されたと報じられています（報道による）。報告では「すぐに使える遠隔エクスプロイトではない」とされていますが、悪用可能性が公に示された以上、対応の優先度は上がったと考えるのが妥当です。
「クライアント側RCE」を過大評価も過小評価もしないために
この脆弱性は「サーバを立てていなければ無関係」でも「接続するだけで誰でも踏める」でもありません。条件は明確で、libssh2を使うプログラムが信頼できないSSHサーバ（攻撃者が制御するか侵害したサーバ）に接続したときにだけ成立します。逆に言えば、接続先が常に自社管理下の信頼できるサーバに限定されている経路は、相対的にリスクが低いと整理できます。リスク評価の軸は「使っているか」ではなく「どこへ接続しているか」だという点が、今回の独自の注意点です。
参考として、libssh2では2019年のCVE-2019-3855（1.8.1で修正）が、同じくtransport read周辺の整数オーバーフローで「悪性サーバが接続クライアント上でコードを実行しうる」ほぼ同型の問題でした。同じ箇所の同じクラスの欠陥が再来した形であり、SSHクライアントライブラリのパケット長検証が構造的に間違えやすい領域であることを示唆します。
まず押さえる事実サマリ
| 項目 | 内容 |
|---|---|
| CVE番号 | CVE-2026-55200 |
| 種別 | CWE-680 整数オーバーフロー→ヒープOOB書き込み（クライアント側RCE） |
| 脆弱な関数 | ssh2_transport_read()（transport.c） |
| 深刻度 | CVSS 4.0 9.2 / CVSS 3.1 9.8（いずれもCritical） |
| 影響バージョン | libssh2 1.11.1 以前すべて |
| 成立条件 | 認証・操作不要。悪性SSHサーバへ接続した瞬間に発火 |
| 修正 | コミット97acf3d（PR #2052、2026年6月12日マージ）で上限チェック追加 |
| PoC | 2026年6月29日に公開と報道（ローカル検証用ハーネス中心） |
| 関連 | CVE-2026-55199（libssh2のプレ認証DoS）も同時期に公表 |
実務手順：「接続する側」を洗い出す棚卸しチェックリスト
OpenSSHのバージョンだけ見て安心しないことが重要です。libssh2はアプリに埋め込まれて動くため、以下の順で「接続する側」を機械的に洗い出します。
- 明示的に使っているツールの確認：curl（
curl -Vの出力にlibssh2/x.x.xが含まれるか）、Git（SSH越しのフェッチ・プッシュ実装）、PHP（ssh2拡張）、各種SCP/SFTPクライアントを列挙する。 - 自動化・運用基盤の確認：バックアップエージェント、CI/CDのデプロイ経路、構成管理ツール、監視エージェント、IaCのプロビジョナがSSHでリモートへ接続する箇所を洗う。
- 組み込み・機器の確認：ファームウェア更新機構、ネットワーク機器、ストレージ/NAS、IoTゲートウェイなど、内部でlibssh2を静的リンクしている可能性がある製品をベンダー公表で確認する。
- 接続先の信頼区分：洗い出した各経路について「接続先は自社管理の固定サーバか／第三者・可変・インターネット上のサーバか」を分類し、後者を優先対応に回す。
- 静的リンクの取りこぼし対策：OSのパッケージ更新だけでは、アプリにバンドルされた静的なlibssh2は更新されない。ベンダー提供のアプリ側アップデートが必要なものを別管理する。
- 暫定緩和：即時更新が難しい経路は、SSH接続先を信頼済みホストに限定し、想定外の宛先への外向きSSHを監視・遮断する。
SBOMで推移的依存を洗い出す
最大の盲点は、自分が直接使っている意識のない「推移的依存」です。あるアプリがcurlやGitライブラリ経由でlibssh2を引き込んでいるケースは、ソースコードのgrepでは見えません。SBOM（ソフトウェア部品表）を起点に、コンポーネント名libssh2と、それを取り込むlibcurl等を再帰的に検索することで、機械的に取りこぼしを減らせます。
- コンテナイメージ・ビルド成果物・配布バイナリに対してSBOM（SPDX/CycloneDX形式）を生成する。
- SBOM内を
libssh2およびそれを依存に含むcurl/libcurlで検索し、バージョンを突き合わせる。 - バージョンが
1.11.1以前、または不明（静的リンクで版が読めない）なものを「要確認」として一覧化する。 - 一覧をオーナー（製品ベンダー／内製チーム）と接続先信頼区分で分類し、修正版追従またはベンダー問い合わせのアクションに落とす。
この一連の作業は単発の脆弱性対応にとどまらず、次に同種のライブラリ脆弱性が出たときに「数時間で影響範囲を出せる体制」を作る投資でもあります。属人的なgrepではなく、SBOMを継続生成し依存を可視化しておくことが、サプライチェーン型リスクへの再現性のある備えになります。
いつGXOに相談すべきか
次のような状態に心当たりがあれば、依存可視化と脆弱性対応プロセスの整備を検討するタイミングです。
- libssh2やcurlなどがどの製品・どのビルドに入っているか、社内で即答できない。
- SBOMを生成・運用しておらず、推移的依存の棚卸しが毎回手作業になっている。
- 静的リンクされたOSSの更新追従が、ベンダー任せで管理しきれていない。
- 古い組み込み機器・自社製ファームウェアにOSSが埋め込まれており、棚卸しの起点がない。
GXOでは、SBOM作成と依存コンポーネントの棚卸しを含むセキュリティ診断で、こうした「どこに何が入っているか分からない」状態の解消を支援しています。検知後の継続的な脆弱性ウォッチと是正運用までを伴走で回したい場合はセキュリティ運用の伴走（月額リテイナー）が、静的リンクされた古いOSSを抱えるレガシーな内製システムやファームウェアの作り直しを見据える場合はレガシー刷新の要件定義が起点になります。
FAQ
Q. SSHサーバを運用していなければ関係ない？ A. いいえ。今回はクライアント側の脆弱性で、libssh2を組み込んだプログラムが悪性SSHサーバへ接続したときに成立します。サーバ運用の有無ではなく「どこへSSH接続を張っているか」で評価してください。
Q. OpenSSHを更新すれば対策になる？ A. なりません。OpenSSHとlibssh2は別物です。curl・Git・バックアップ・ファーム更新など、libssh2を取り込んでいるアプリ側の更新が必要です。
Q. すぐに更新できない経路はどうすれば？
A. 接続先を自社管理の信頼済みサーバに限定し、想定外の宛先への外向きSSHを監視・遮断する暫定緩和を取りつつ、修正版（コミット97acf3d相当）への追従計画を立ててください。
