Критическая уязвимость в библиотеке libssh2 позволяет удалённо выполнять код

libssh2

В библиотеке libssh2, широко используемой клиентской реализации протокола SSH, обнаружена критическая уязвимость, позволяющая удалённому злоумышленнику выполнять произвольный код. Проблема получила идентификатор CVE-2026-55200 и оценку CVSS 9,2 по десятибалльной шкале, что относит её к категории критических. Уязвимость затрагивает версии libssh2 до 1.11.1 включительно; исправление выпущено в коммите 7acf3df основного репозитория. Ошибка была обнаружена и ответственно раскрыта исследователем безопасности Тристаном Мадани.

Уязвимость CVE-2026-55200

Причина уязвимости кроется в недостаточной проверке размера входящих пакетов в функции "ssh2_transport_read()", расположенной в файле "transport.c". Речь идёт о целочисленном переполнении, классифицированном как CWE-680, которое в определённых условиях приводит к переполнению буфера (buffer overflow). Логика обработки пакетов не проверяет верхнюю границу поля "packet_length", задающего длину передаваемого SSH-пакета. Злоумышленник может отправить манипулированное значение, превосходящее выделенные лимиты памяти. В результате библиотека выделяет недостаточный буфер, а затем при записи данных выходит за его границы, повреждая соседние области кучи (heap corruption). Такое повреждение памяти позволяет атакующему перезаписать смежные структуры и добиться выполнения собственного кода в контексте уязвимого приложения.

Для эксплуатации не требуется проходить аутентификацию, а сложность атаки оценивается как низкая. Вектор атаки сетевой, взаимодействие с пользователем не нужно. Это делает уязвимость особенно опасной в средах, где libssh2 встроена в автоматизированные сервисы, встраиваемые системы или серверную инфраструктуру, обрабатывающую SSH-соединения. Злоумышленнику достаточно подключиться к приложению, использующему уязвимую версию библиотеки, и отправить специально сформированный SSH-пакет с подменённым полем "packet_length". Отсутствие проверок границ в коде функции приводит к записи данных за пределы выделенной области, после чего атакующий может внедрить вредоносную полезную нагрузку и получить контроль над системой.

Libssh2 - популярная библиотека, используемая во множестве инструментов: от утилит передачи файлов и систем автоматизации до пользовательских SSH-клиентов. Она часто встраивается в приложения статически, что осложняет её обнаружение стандартными средствами управления пакетами. В корпоративных средах это создаёт значительную поверхность атаки: организации могут эксплуатировать уязвимые версии, даже если основные системные компоненты обновлены. По оценкам специалистов, непроверенные инсталляции libssh2 могут оставаться незамеченными в цепочках сборки сторонних продуктов.

Разработчики проекта уже выпустили патч, который исправляет некорректную логику проверки размера пакета. Изменения вводят строгий контроль границ поля "packet_length" до того, как происходит выделение памяти и последующая обработка. Разработчикам приложений, использующих libssh2, настоятельно рекомендуется обновиться до исправленной версии или применить коммит 7acf3df из официального репозитория на GitHub. В качестве временных мер защиты предлагается ограничить доступ к SSH-сервисам только доверенными хостами, настроить фильтрацию сетевого трафика на уровне межсетевых экранов и организовать мониторинг необычной SSH-активности. Признаками попыток эксплуатации могут стать аномально большие SSH-пакеты или неожиданные сбои приложений, связанные с libssh2.

Обнаружение CVE-2026-55200 подчеркивает сохраняющуюся проблему ошибок безопасности памяти в широко распространённых библиотеках. Подобные дефекты - следствие недостаточной проверки входных данных в реализациях сетевых протоколов. Для организаций, использующих libssh2, приоритетом должно стать оперативное применение патча и проведение аудита зависимостей, чтобы выявить и устранить уязвимые экземпляры библиотеки во всех средах. Тенденция к усилению контроля границ при обработке протокольных пакетов наблюдается во многих проектах, и данный случай служит ещё одним напоминанием о необходимости тщательной валидации всех входящих параметров на этапе разработки.

Ссылки

Комментарии: 0