В libssh2 обнаружена критическая ошибка CVE-2026-55200, которая позволяет вредоносному или скомпрометированному SSH-серверу повредить память на подключающемся клиенте. Для атаки не нужны учетные данные и не требуется действие пользователя. Уязвимость затрагивает версии libssh2 до и включая 1.11.1, а публичный proof-of-concept уже опубликован.
Что произошло
Сообщается о критической уязвимости CVE-2026-55200 в libssh2 — библиотеке SSH для клиентской стороны. Ошибка позволяет удаленному SSH-серверу спровоцировать повреждение памяти на подключающемся клиенте, а в худшем случае — добиться выполнения кода.
По данным источника, уязвимости присвоен CVSS 4.0 score 9.2. Проблема затрагивает все выпуски libssh2 до и включая 1.11.1.
Почему это важно
libssh2 используется не как серверный компонент, а как библиотека, встроенная в клиентские приложения и утилиты. Среди возможных примеров источником названы curl, Git, PHP, агенты резервного копирования, обновляторы прошивок и часть устройств и appliance-решений.
Для владельцев сайтов и администраторов это означает, что риск может быть не только у серверов, которые принимают SSH-подключения, но и у систем, которые сами подключаются к внешним SSH-узлам. Особенно это касается VPS, контейнеров и программ с вложенными или статически собранными зависимостями.
Как проявляется ошибка
Уязвимость находится в функции, которая обрабатывает входящие SSH-пакеты во время handshake. Она некорректно проверяет длину пакета: значение, заданное атакующей стороной, может привести к переполнению целого числа при расчетах размера буфера.
В результате библиотека выделяет слишком маленькую память, а затем записывает в нее слишком большой пакет. Такой сценарий относится к классу integer overflow to buffer overflow и может использоваться как примитив для выполнения кода.
Что известно о подтверждении и исправлении
Исследователь Tristan Madani сообщил об ошибке. По данным источника, исправление было объединено через pull request #2052 12 июня, а CVE опубликован VulnCheck 17 июня.
Также сообщается, что публичный proof-of-concept уже доступен в архиве exploitarium. При этом речь идет не о готовом удаленном эксплойте, а о локально проверенном сценарии и harness для воспроизведения проблемы. Для реального использования против приложения итоговый результат будет зависеть от конкретной сборки, allocator'а, защитных механизмов и того, как именно программа встраивает libssh2.
Что делать администраторам и пользователям VPS
Главная задача сейчас — найти все места, где используется libssh2. Это касается не только пакетных установок, но и статически собранных или встроенных копий, которые менеджер пакетов может не показать.
Практические шаги:
- Провести инвентаризацию приложений и утилит, которые могут использовать libssh2.
- Проверить, есть ли вендорский патч или backport, и обновить сборку с исправлением.
- Уделить особое внимание клиентам, которые подключаются к внешним SSH-серверам.
- До установки исправления ограничить исходящие SSH-подключения только доверенными узлами.
- Проверять host key и отслеживать необычные падения клиентов или аномалии, связанные с размером пакетов.
Статус обновлений
По данным источника, готового официального релиза libssh2 с исправлением на момент публикации еще не было: патч находился в основной ветке, а дистрибутивы и downstream-проекты переносили его в свои сборки самостоятельно.
Для части пользователей это означает, что безопасность будет зависеть не от номера версии в исходниках, а от того, включен ли патч в конкретную поставку пакета или встроенную библиотеку.
Связанные уязвимости
В сообщении также упомянуты еще две ошибки из того же набора: CVE-2026-55199, которая может вызвать отказ в обслуживании из-за цикла CPU, и CVE-2025-15661, связанная с heap over-read в SFTP. Их также стоит проверить вместе с основным исправлением.
Что это значит для инфраструктуры
Для VPS и серверов эта новость важна прежде всего как напоминание, что риск часто приходит не только через демоны, слушающие порт 22, но и через клиентские библиотеки в служебных утилитах. Если на хосте есть резервное копирование по SSH, автоматическая синхронизация, Git-пайплайны или обновление прошивок, такие компоненты тоже нужно включать в аудит зависимостей.
Публичный PoC повышает вероятность быстрой проверки на практике, поэтому откладывать инвентаризацию и обновление не стоит.
