Критическая уязвимость в Gogs открывает путь для незаметных атак на цепочки поставок ПО

В мире открытого программного обеспечения вновь обнаружена опасная брешь, способная подорвать доверие к целым проектам. На этот раз под удар попал Gogs - популярный инструмент для самостоятельного размещения сервисов Git, который используют тысячи команд разработчиков по всему миру. Выявленная уязвимость, получившая идентификатор CVE-2026-25921, позволяет неавторизованным злоумышленникам незаметно подменять крупные файлы в любых репозиториях. Это создаёт идеальные условия для масштабных компрометаций цепочек поставок программного обеспечения, когда вредоносный код может быть внедрён в легитимные проекты без ведома их создателей.

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

Суть проблемы заключается в некорректной реализации работы с Git Large File Storage (LFS) - системой для управления большими файлами, такими как бинарные сборки, наборы данных или медиафайлы. Вместо хранения таких файлов непосредственно в Git, LFS заменяет их текстовыми указателями, а сами данные размещаются на удалённом сервере. Уязвимость в Gogs коренится в трёх фундаментальных архитектурных просчётах. Во-первых, все объекты LFS хранятся в единой глобальной директории без привязки к конкретному репозиторию. Путь к файлу генерируется исключительно на основе его идентификатора объекта (Object ID, OID), что означает общее хранилище для всего экземпляра Gogs. Во-вторых, и это ключевая ошибка, сервер не проверяет соответствие загружаемого файла его заявленному криптографическому хешу SHA-256, который и используется в качестве OID. Приложение слепо доверяет данным от клиента. В-третьих, код сервера разрешает клиентам повторно загружать и перезаписывать существующие файлы, исходя из ошибочного предположения, что одинаковый OID гарантирует идентичное содержимое.

Эксплуатация этой уязвимости не требует высокой квалификации и может быть проведена удалённо. Атака начинается с того, что злоумышленник находит в репозитории жертвы OID целевого объекта LFS, например, важной библиотеки или исполняемого файла. Далее атакующий инициирует загрузку файла в свой собственный репозиторий, но намеренно указывает OID, принадлежащий жертве. В процессе загрузки передаётся поддельный файл, содержащий бэкдор или иное вредоносное содержимое. Поскольку Gogs не проверяет целостность, он сохраняет этот файл, автоматически перезаписывая легитимный объект в глобальном хранилище. В результате, когда пользователи или системы автоматической сборки будут загружать этот файл из исходного, казалось бы, доверенного репозитория, они незаметно получат вредоносную полезную нагрузку. Ни веб-интерфейс, ни командная строка Git не покажут никаких предупреждений о подмене, что делает атаку чрезвычайно скрытной и опасной.

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

После ответственного раскрытия уязвимости исследователем zjuchenyuan, сопровождающие Gogs выпустили официальный патч. Разработчикам и администраторам настоятельно рекомендуется немедленно обновить свои экземпляры Gogs до версии 0.14.2 или новее. Это обновление вводит обязательную проверку, гарантирующую, что загружаемый объект LFS в точности соответствует своему заявленному хешу SHA-256. Однако, одного обновления может быть недостаточно. Специалистам по кибербезопасности следует вручную проверить целостность уже существующих объектов LFS, чтобы убедиться, что некоторые файлы не были скомпрометированы до установки заплатки. Если немедленное обновление невозможно, в качестве временной меры можно ограничить сетевой доступ к экземпляру Gogs или отключить регистрацию новых пользователей, чтобы предотвратить создание злоумышленниками репозиториев для размещения вредоносных файлов.

Этот инцидент служит напоминанием о важности проверки целостности данных на всех уровнях. Даже в инфраструктуре, построенной на принципах открытости и доверия, слепая вера в корректность предоставленных клиентом метаданных может привести к фатальным последствиям. Для команд разработки данный случай должен стать поводом пересмотреть процессы обеспечения безопасности цепочки поставок, уделив особое внимание не только внешним зависимостям, но и целостности внутренних систем контроля версий.

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

Ссылки