Нов сериозен риск за самостоятелно хостваните Git платформи

Непоправена zero-day уязвимост в Gogs позволява на атакуващи да постигнат отдалечено изпълнение на код (RCE) върху интернет-достъпни инстанции на платформата. Проблемът засяга популярната self-hosted Git услуга, разработена като по-лека алтернатива на GitLab и GitHub Enterprise.

Уязвимостта все още няма официално CVE обозначение, но според изследователи по сигурността е с критична степен на опасност. Засегнати са последните версии на Gogs – 0.14.2 и 0.15.0+dev.

Атаката изисква само обикновен потребителски акаунт

Според откривателя на проблема – старшия изследовател по сигурността Йона Бърджес от Rapid7 – експлоатацията не изисква административни права. Достатъчен е стандартен потребителски акаунт.

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

По подразбиране Gogs използва:

• активирана свободна регистрация;
• неограничено създаване на репозитории;
• автоматично присвояване на собственост върху създадените проекти.

Тази комбинация значително улеснява атаките срещу публично достъпни инстанции.

Как работи експлойтът

Уязвимостта представлява argument injection flaw, при която злонамерен branch name може да инжектира параметъра --exec в процеса git rebase по време на операцията „Rebase before merging“.

Това позволява изпълнение на произволни команди директно върху сървъра.

Според анализа на Rapid7 успешната атака може да позволи:

• пълно компрометиране на Gogs сървъра;
• достъп до всички repositories, включително private проекти;
• кражба на API токени, SSH ключове и 2FA тайни;
• извличане на password hashes;
• модификация на source code;
• lateral movement към други системи в мрежата.

Проблемът напомня предишни критични уязвимости

Изследователят отбелязва, че новата zero-day прилича на вече коригирани argument injection уязвимости като:

• CVE-2024-39933
• CVE-2024-39932
• CVE-2026-26194
• CVE-2024-39930

Разликата е, че настоящият проблем засяга различен кодов път – функцията Merge(), която никога не е била защитена.

Разработчиците на Gogs все още не са публикували patch

Йона Бърджес е уведомил поддръжниците на Gogs още на 17 март. Те са потвърдили получаването на доклада на 28 март, но до момента няма публикувана корекция или официален статус относно проблема.

Това създава сериозен риск, особено предвид големия брой интернет-достъпни инстанции.

Над 2400 Gogs сървъра са изложени онлайн

Според данни на Shadowserver Foundation в интернет са видими над 2400 Gogs сървъра. Най-много от тях се намират в:

• Азия – около 1894;
• Европа – около 319.

Платформата Shodan открива над 1000 IP адреса с Gogs fingerprint.

Това означава, че потенциалната атакуваема повърхност остава значителна.

Предишна zero-day вече беше използвана при реални атаки

През декември екипът на Gogs коригира друга критична RCE уязвимост – CVE-2025-8110. Тя вече е била активно експлоатирана срещу стотици сървъри.

Изследователи от Wiz Research установиха, че много Gogs инстанции използват отворена регистрация по подразбиране, което създава „масивна атакуваема повърхност“.

По-късно CISA добави CVE-2025-8110 към каталога си с активно експлоатирани уязвимости и разпореди на федералните агенции в САЩ да защитят системите си.

Защо проблемът е особено опасен за DevOps среди

Gogs често се използва в малки DevOps среди, вътрешни разработки и организации, които предпочитат self-hosted инфраструктура. В много случаи платформата се разгръща без допълнителни защитни механизми и остава публично достъпна.

Това превръща подобни zero-day уязвимости в сериозна заплаха за:

• supply chain атаки;
• компрометиране на source code;
• кражба на чувствителни корпоративни данни;
• последващо проникване в инфраструктурата.

Докато няма официален patch, експертите препоръчват:

• деактивиране на публичната регистрация;
• ограничаване на достъпа до Gogs инстанциите;
• изключване на „Rebase before merging“;
• наблюдение за подозрителни pull requests и branch names;
• поставяне на платформата зад VPN или reverse proxy с допълнителна автентикация.