Исследователь безопасности Тристан Мадани опубликовал на GitHub рабочий proof-of-concept для уязвимости CVE-2026-55200 в библиотеке libssh2 ещё до того, как разработчики выпустили официальный релиз с исправлением. Это поставило под удар огромное количество систем, которые даже не знают, что внутри у них живёт уязвимая версия этой библиотеки.
Оценка по шкале CVSS 4.0 составляет 9.2 из 10 — критический уровень. Уязвимость относится к классу CWE-680 (целочисленное переполнение с переходом в переполнение буфера) и срабатывает ещё до аутентификации, без какого-либо взаимодействия с пользователем. Атака направлена не на сервер, а на клиента: вредоносный или скомпрометированный SSH-сервер может атаковать любого, кто к нему подключается.
Техническая суть проблемы находится в функции ssh2_transport_read() в файле transport.c. Во время SSH-рукопожатия функция считывает поле packet_length, которое контролирует атакующий. Проверка отсекала только значения ниже 1, верхняя граница не проверялась вовсе. Арифметика работала в 32-битном пространстве, поэтому значение 0xffffffff оборачивалось в крошечное число. Под это маленькое число выделялся буфер, а затем в него записывался полноразмерный пакет. Классическое out-of-bounds heap write — примитив, который при определённых условиях даёт удалённое выполнение кода. Патч добавил простую проверку: отклонять packet_length выше LIBSSH2_PACKET_MAXPAYLOAD до того, как начнётся какая-либо арифметика.
Это не первый раз, когда в этом месте появляется одинаковая ошибка. В 2019 году вышла версия libssh2 1.8.1, закрывшая сразу девять уязвимостей. Главной среди них была CVE-2019-3855 — почти идентичное целочисленное переполнение в той же функции чтения транспорта, тоже позволявшее вредоносному серверу выполнять код на подключающемся клиенте. Семь лет спустя та же самая ошибка вернулась в тот же самый код.
libssh2 встроена в колоссальное количество программ: curl, Git, PHP, агенты резервного копирования, прошивки обновлений, различные аппаратные устройства. Уязвимы все версии вплоть до 1.11.1 включительно. Самая неприятная часть истории в том, что значительная часть этих копий скомпилирована статически. Это означает, что обновление пакета через apt или yum просто не дотянется до них. Организация может обновить системный libssh2 и при этом оставаться уязвимой через статически слинкованный curl или какой-нибудь агент резервного копирования, поставленный вендором три года назад.
12 июня 2026 года мейнтейнеры влили патч через pull request №2052 (коммит 97acf3d). 17 июня CVE опубликовал VulnCheck. На момент публикации официального тегированного релиза libssh2 с исправлением не существовало — только исходники в основной ветке. Debian уже собрал исправленный пакет в ветке testing; другие дистрибутивы Linux делают бэкпорт самостоятельно.
Репозиторий Тристана Мадани называется "exploitarium" и представляет собой архив эксплойтов, выложенных без предварительного уведомления разработчиков. PoC содержит локально проверенный триггер и управляемый локальный RCE-стенд для CVE-2026-55200. Сам автор признаёт, что архив вышел неполным, часть записей слабая, а фаззинг частично вёлся с помощью ИИ. До надёжного удалённого эксплойта ещё далеко: результат зависит от конкретного бинарника, поведения аллокатора, включённых защит и способа встраивания libssh2 в конкретное приложение. По данным CISA на момент публикации, случаев реальной эксплуатации в дикой природе зафиксировано не было.
В том же пакете исправлений закрыты ещё две уязвимости. CVE-2026-55199 с оценкой 8.2 загоняет подключающийся клиент в бесконечный цикл ЦПУ через поддельное число расширений. CVE-2025-15661 с оценкой 8.3 представляет собой heap over-read в SFTP. NHS England Digital выпустила отдельный advisory с призывом к затронутым организациям обновиться.
Первым шагом должна быть инвентаризация. Нужно найти всё, что линкует libssh2, включая статические и встроенные копии, которые пакетный менеджер не покажет. Особое внимание стоит уделить развёртываниям curl, Git и PHP. Затем применить сборку, включающую коммит 97acf3d, через бэкпорт дистрибутива или сборку из патченных исходников. До появления патча имеет смысл ограничить исходящие SSH-соединения только доверенными серверами, жёстко проверять host keys и следить за аномалиями с пакетами нестандартного размера и необъяснимыми падениями клиентов. Особого внимания заслуживают клиенты, которые подключаются к внешним SSH-серверам или резолвят хосты по именам, которые атакующий может перехватить через DNS.
Главный открытый вопрос не технический: сколько статически слинкованных копий libssh2 останутся уязвимыми просто потому, что их владельцы не знают, что когда-то положили эту библиотеку внутрь своего продукта?
Изображение носит иллюстративный характер
Оценка по шкале CVSS 4.0 составляет 9.2 из 10 — критический уровень. Уязвимость относится к классу CWE-680 (целочисленное переполнение с переходом в переполнение буфера) и срабатывает ещё до аутентификации, без какого-либо взаимодействия с пользователем. Атака направлена не на сервер, а на клиента: вредоносный или скомпрометированный SSH-сервер может атаковать любого, кто к нему подключается.
Техническая суть проблемы находится в функции ssh2_transport_read() в файле transport.c. Во время SSH-рукопожатия функция считывает поле packet_length, которое контролирует атакующий. Проверка отсекала только значения ниже 1, верхняя граница не проверялась вовсе. Арифметика работала в 32-битном пространстве, поэтому значение 0xffffffff оборачивалось в крошечное число. Под это маленькое число выделялся буфер, а затем в него записывался полноразмерный пакет. Классическое out-of-bounds heap write — примитив, который при определённых условиях даёт удалённое выполнение кода. Патч добавил простую проверку: отклонять packet_length выше LIBSSH2_PACKET_MAXPAYLOAD до того, как начнётся какая-либо арифметика.
Это не первый раз, когда в этом месте появляется одинаковая ошибка. В 2019 году вышла версия libssh2 1.8.1, закрывшая сразу девять уязвимостей. Главной среди них была CVE-2019-3855 — почти идентичное целочисленное переполнение в той же функции чтения транспорта, тоже позволявшее вредоносному серверу выполнять код на подключающемся клиенте. Семь лет спустя та же самая ошибка вернулась в тот же самый код.
libssh2 встроена в колоссальное количество программ: curl, Git, PHP, агенты резервного копирования, прошивки обновлений, различные аппаратные устройства. Уязвимы все версии вплоть до 1.11.1 включительно. Самая неприятная часть истории в том, что значительная часть этих копий скомпилирована статически. Это означает, что обновление пакета через apt или yum просто не дотянется до них. Организация может обновить системный libssh2 и при этом оставаться уязвимой через статически слинкованный curl или какой-нибудь агент резервного копирования, поставленный вендором три года назад.
12 июня 2026 года мейнтейнеры влили патч через pull request №2052 (коммит 97acf3d). 17 июня CVE опубликовал VulnCheck. На момент публикации официального тегированного релиза libssh2 с исправлением не существовало — только исходники в основной ветке. Debian уже собрал исправленный пакет в ветке testing; другие дистрибутивы Linux делают бэкпорт самостоятельно.
Репозиторий Тристана Мадани называется "exploitarium" и представляет собой архив эксплойтов, выложенных без предварительного уведомления разработчиков. PoC содержит локально проверенный триггер и управляемый локальный RCE-стенд для CVE-2026-55200. Сам автор признаёт, что архив вышел неполным, часть записей слабая, а фаззинг частично вёлся с помощью ИИ. До надёжного удалённого эксплойта ещё далеко: результат зависит от конкретного бинарника, поведения аллокатора, включённых защит и способа встраивания libssh2 в конкретное приложение. По данным CISA на момент публикации, случаев реальной эксплуатации в дикой природе зафиксировано не было.
В том же пакете исправлений закрыты ещё две уязвимости. CVE-2026-55199 с оценкой 8.2 загоняет подключающийся клиент в бесконечный цикл ЦПУ через поддельное число расширений. CVE-2025-15661 с оценкой 8.3 представляет собой heap over-read в SFTP. NHS England Digital выпустила отдельный advisory с призывом к затронутым организациям обновиться.
Первым шагом должна быть инвентаризация. Нужно найти всё, что линкует libssh2, включая статические и встроенные копии, которые пакетный менеджер не покажет. Особое внимание стоит уделить развёртываниям curl, Git и PHP. Затем применить сборку, включающую коммит 97acf3d, через бэкпорт дистрибутива или сборку из патченных исходников. До появления патча имеет смысл ограничить исходящие SSH-соединения только доверенными серверами, жёстко проверять host keys и следить за аномалиями с пакетами нестандартного размера и необъяснимыми падениями клиентов. Особого внимания заслуживают клиенты, которые подключаются к внешним SSH-серверам или резолвят хосты по именам, которые атакующий может перехватить через DNS.
Главный открытый вопрос не технический: сколько статически слинкованных копий libssh2 останутся уязвимыми просто потому, что их владельцы не знают, что когда-то положили эту библиотеку внутрь своего продукта?
