У сфері кібербезпеки виявлено серйозну загрозу, що зачіпає безліч систем у всьому світі. Мова йде про критичну вразливість CVE-2026-55200 у популярній клієнтській бібліотеці libssh2, для якої днями було опубліковано робочий концепт експлуатації (Proof-of-Concept, або PoC). Цей баг отримав оцінку 9.2 за шкалою CVSS v4.0. Головна небезпека полягає в тому, що помилка дозволяє зловмиснику виконати довільний код (Remote Code Execution, або RCE) на боці клієнта без автентифікації чи дій з боку користувача. Достатньо лише того, щоб клієнт спробував підключитися до скомпрометованого чи ворожого SSH-сервера.

Щоб зрозуміти рівень загрози, варто оцінити роль самої бібліотеки. libssh2 є фундаментальним інструментом у сучасній розробці програмного забезпечення. На відміну від OpenSSH, яка зазвичай працює як серверний демон, libssh2 — це саме клієнтська бібліотека C, що дозволяє розробникам інтегрувати підтримку SSH2 у свої додатки. Вона використовується у величезній кількості софту: від консольних утиліт на кшталт cURL та систем контролю версій Git до модулів у PHP, Python чи Node.js, а також у клієнтах для автоматизації бекапів через SFTP/SCP. Отже, під загрозою опиняється не якийсь один продукт, а вся екосистема додатків, що спираються на цю бібліотеку.

Технічна суть проблеми криється у помилці обробки вхідних пакетів під час встановлення з'єднання. Коли клієнт ініціює підключення до SSH-сервера, відбувається складний процес обміну ключами, узгодження алгоритмів шифрування та передачі параметрів. Якщо сервер контролюється атакуючим, він може надіслати спеціально сформований заголовок або пакет, який спровокує помилку роботи з пам'яттю (зокрема, вихід за межі буфера або псування купи — memory corruption) у процесі клієнта. Оскільки libssh2 у версіях до 1.11.1 включно не виконує належної перевірки довжини полів та структури отриманих даних, це дозволяє перезаписати пам’ять процесу та виконати шкідливі інструкцій у контексті програми, що викликала бібліотеку.

Найбільш реалістичний сценарій атаки виглядає наступним чином: зловмисники зламують легітимний SSH- чи SFTP-сервер компанії-партнера або підміняють публічні репозиторії Git. Також вони можуть створити привабливий для розробників чи адміністраторів публічний сервіс. Коли автоматизований скрипт резервного копіювання, CI/CD-пайплайн або безпосередньо системний адміністратор здійснює спробу з'єднання, шкідливий сервер миттєво експлуатує CVE-2026-55200. У результаті атакуючий отримує повний контроль над сервером автоматизації, робочою станцією розробника або критичним шлюзом компанії. Жодних логінів чи паролів від клієнта для цього не потрібно — експлуатація відбувається до етапу перевірки облікових даних користувача.

Проблема охоплює абсолютно всі релізи libssh2 до версії 1.11.1 включно. Зважаючи на те, що ця бібліотека за замовчуванням постачається у багатьох дистрибутивах Linux (Debian, Ubuntu, Red Hat Enterprise Linux, Alpine) та є частиною багатьох контейнеризованих середовищ, розробникам та системним адміністраторам необхідно терміново вжити заходів для усунення цієї діри в безпеці периметра. Наявність публічного PoC означає, що автоматизовані сканери та хакерські угруповання вже почали створювати інструменти для масового сканування та використання цієї вразливості на практиці.

Що це означає на практиці

Як команда пентестерів, ми рекомендуємо негайно виконати наступні кроки для захисту вашої інфраструктури від CVE-2026-55200:

  • Проведіть інвентаризацію ПЗ та залежностей. Перевірте всі сервери та робочі станції на наявність встановленої бібліотеки libssh2. У системах на базі Debian/Ubuntu це можна зробити командою dpkg -l | grep libssh2, а на Red Hat/CentOS — rpm -qa | grep libssh2. Особливу увагу приділіть серверам автоматизації, де крутяться скрипти синхронізації файлів.
  • Оновіть пакети до виправлених версій. Встановіть останні оновлення безпеки від розробників вашого дистрибутиву Linux. Якщо офіційні репозиторії ще не містять готового патчу для вашої версії ОС, розгляньте можливість тимчасового обмеження використання libssh2 або компіляції бібліотеки з виправленнями з офіційного Git-репозиторію проекту.
  • Обмежте вихідний мережевий трафік (Egress Filtering). Заблокуйте на рівні міжмережевого екрана (Firewall) можливість встановлення вихідних з'єднань по протоколах SSH/SFTP (порти 22, 2222 тощо) з чутливих сегментів мережі до будь-яких невідомих зовнішніх IP-адрес. Дозволяйте вихідні підключення лише до чітко визначеного білого списку (whitelist) довірених серверів.
  • Перевірте контейнери та CI/CD. Проскануйте ваші Docker-образи на наявність вразливих версій libssh2 за допомогою інструментів аналізу складу програмного забезпечення (SCA), таких як Trivy або Grype. Оновіть базові образи у ваших Dockerfile та перезапустіть збірки.
  • Моніторте аномальну активність на клієнтах. Налаштуйте аудит системних процесів за допомогою Sysmon або Auditd. Звертайте увагу на випадки, коли клієнтські утиліти (наприклад, curl або git) після підключення до зовнішніх серверів раптово ініціюють запуск командних оболонок (bash, sh, powershell) або створюють підозрілі мережеві з'єднання на інші порти.