Някой публикува 204 експлойт файла в GitHub за софтуер, който почти сигурно използвате, без да уведоми разработчиците. Създателите разбраха по същия начин, по който и атакуващите – чрез четене на страницата. 🧐

Профилът се казва „bikini“, а проектът – „exploitarium“. Той представлява архив от готов за стартиране зловреден код за софтуер, който лежи в основата на голяма част от технологиите, които използвате. Първите записи датират от 23 юни, а до 27 юни страницата вече събираше харесвания и стотици коментари, което означаваше, че защитници и атакуващи четяха едни и същи експлойти по едно и също време.

Обикновено сериозните грешки следват поверителен път. Първо уведомявате разработчика, той получава определен времеви прозорец за отстраняване на уязвимостта и обществеността научава за нея едва след като има налична корекция за сигурност. Този ред съществува с една цел: да даде на хората, работещи със софтуера, преднина пред тези, които искат да пробият защитата.

README файлът на exploitarium отхвърля това правило. В него се посочва, че нито едно от откритията не е докладвано на разработчиците преди публикуването, и се приканват читателите да ги докладват и да си припишат заслугите. Така че преднината я няма. За повечето от нещата там не е съществувало решение в деня на публикуването им.

Първоначално се говореше за около 130 файла, но тази информация бързо остаря. Екипът на SpiderLabs от LevelBlue прегледа хранилището и преброи 204 проследени файла в 35 проекта за експлойти, като бяха добавяни по две или три папки на седмица поне до 4 юли.

Нови записи само през първата седмица на юли:

Целите са инструментите, върху които е изграден модерният софтуер:

  • AnyDesk и RustDesk за отдалечен достъп
  • FFmpeg, PHP, OpenVPN, Ghidra, 7-Zip

Само една папка за инструмента objdump съдържа 41 отделни файла. Това е най-големият единичен запис в архива и знак за това колко работа е вложена в него.

Не всичко в тази купчина е еднакво опасно и това е част от проблема. Някои папки изглеждат като маловажни резултати от автоматизирано тестване. Други са сериозни. Една обаче се откроява над останалите – уязвимост в libssh2, проследена като CVE-2026-55200, която присъства от първия ден в първата партида на 23 юни.

libssh2 е малка библиотека, която позволява на програмите да комуникират чрез SSH – протоколът, който машините използват за защитена връзка помежду си. Вероятно никога не сте я инсталирали умишлено. Тя идва вградена в инструменти, които вече използвате, като curl, Git и много PHP версии. Когато някой от тях осъществява защитена връзка, libssh2 често е компонентът, който извършва самата комуникация.

Проблемът е в частта от кода, която чете входящ пакет.

Всеки SSH пакет започва с деклариране на собствената си дължина. Библиотеката libssh2 чете това число, но никога не проверява дали то не е абсурдно голямо. Изпращането на пакет с огромен деклариран размер води до препълване на буфера при изчисленията за заделяне на памет. Библиотеката заделя твърде малък буфер, а следващата стъпка записва данни директно извън неговите граници.

Това е презаписване на памет извън границите на хийпа (out-of-bounds write on the heap). Този тип компрометиране на паметта води до ситуация, в която атакуващ може да изпълни код, който никога не е бил предвиден да се стартира.

Два фактора влошават ситуацията. Това се случва по време на четене на пакета, преди каквато и да е оторизация или проверка на ключове, така че няма парола или потребителски профил, които да попречат. Освен това става въпрос за клиентската страна на SSH, така че опасността идва от неочаквана посока – компрометиран сървър може да атакува машина, която се свързва с него.

Това засяга много повече системи, отколкото изглежда на пръв поглед:

  • всичко, което прави изходящи SSH връзки чрез curl или Git
  • автоматизирани системи за компилация и CI среди, които съдържат libssh2 по невнимание

Оценката на уязвимостта е 9.2 от 10 по скалата на CVSS 4.0 и засяга libssh2 до версия 1.11.1 включително.

Решението е добавянето на една проверка, която отхвърля всеки пакет с дължина над позволения максимум, преди това число да повлияе на изчисленията за паметта. Корекцията беше въведена в commit 97acf3d. Има обаче една уловка. Когато статията беше написана, тази корекция за сигурност съществуваше само в този коммит, но не и в официално пусната версия, така че изтеглянето на последната стабилна версия не беше достатъчно.

Все още няма данни уязвимостта да се използва активно. Тя не е в списъка на CISA за активно експлоатирани уязвимости. Въпреки това има публично достъпен работещ прототип за атака (proof-of-concept), като за него не е необходимо масово сканиране. Нужна е само машина, която се свързва към грешен адрес – компрометирано огледало (mirror), отровено DNS съобщение или среда за компилация, насочена към сървър, който е преминал под чужд контрол.

Има и обрат в начина, по който уязвимостта достигна до света. Правилният път беше извършен първо. Проблемът беше докладван чрез VulnCheck, корекцията беше внедрена в основния код на libssh2, а CVE беше публикувано на 17 юни с благодарности към изследователя Тристан Мадани. Едва на 23 юни работещият прототип се появи в exploitarium в папка, кръстена на CVE идентификатора, който вече притежаваше.

Така че най-значимото откритие в архива всъщност не е било неразкрита zero-day уязвимост, а работещ експлойт за проблем, който вече е бил коригиран и публично известен.