Версии GitHub Enterprise Server до 3.21.5 содержат несколько уязвимостей. Их эксплуатация позволяет выполнить произвольный код, обойти ограничения безопасности и подменить отправителя локальных почтовых сообщений. Часть проблем требует аутентифицированного доступа, другая не нуждается в учетных данных. Обновление 3.21.5 закрывает все известные сценарии.
Детали уязвимостей
GitHub Enterprise Server - это корпоративная версия платформы GitHub, которую устанавливают на собственные серверы организаций. Такие инсталляции хранят приватный код, а также интегрированы в процессы разработки и выпуска продуктов. Поэтому выполнение кода на самом сервере может затронуть не отдельный репозиторий, а всю среду разработки. Особенно это важно для компаний, где исходные тексты считаются одним из главных активов.
Первую и наиболее заметную проблему обозначили идентификатором CVE-2026-19118. Она связана с состоянием гонки - ситуацией, когда между проверкой объекта и его обработкой может произойти постороннее действие. Система сначала подтверждает безопасность загруженного файла, а затем начинает работать с ним. Атакующий в этот промежуток способен заменить проверенный файл собственным содержимым. После такой подмены сервер обрабатывает файл как доверенный, и код атакующего выполняется на экземпляре. Для атаки достаточно учетной записи с правом записи в репозиторий.
Второй сценарий затрагивает управляющий программный интерфейс Manage API. В уязвимых версиях соответствующая точка принимает запросы без аутентификации. Через нее можно передать поддельную конфигурацию кластера. При обработке такой конфигурации сервер отправляет подготовленные внешние запросы на узел, указанный атакующим. Если злоумышленник способен перехватить исходящее соединение, он получает управляющий токен. Токен можно использовать повторно, то есть он не ограничен одной операцией. Эта проблема получила идентификатор CVE-2026-18730. В описании уточняется, что конфигурации с высокой доступностью данным способом не затрагиваются.
Третий сценарий связан с предварительными скриптами, которые выполняются до принятия изменений в репозиторий. Такие скрипты в документации GitHub называются pre-receive hook. Их обычно применяют для проверки кода, запуска тестов или запрета нежелательных коммитов. Уязвимость CVE-2026-76851 позволяет пользователю, который может настроить или изменить такой скрипт, перенаправить доверенный внутренний запрос на привилегированный внутренний сервис. В результате на сервере выполняется произвольный код. Для эксплуатации должна быть включена сетевая доступность предварительных скриптов.
Отдельно в обновление вошла защита от почтовой проблемы CVE-2023-51764. Она связана с поведением почтового сервера Postfix и использованием нестандартных последовательностей команд SMTP, то есть протокола передачи электронной почты. Атакующий может отправить сообщение с такими последовательностями через почтовый сервис, который передает их без изменений. Уязвимый Postfix интерпретирует подобный трафик иначе, чем ожидалось. GitHub оценил этот случай для своего продукта как низкоопасный, однако изменил конфигурацию Postfix. Такой шаг закрывает обход почтовых фильтров и подмену адреса отправителя для сообщений, которые доставляются локально.
Все три проблемы высокого уровня были сообщены через программу вознаграждений GitHub Bug Bounty. В официальном описании релиза сведения о реальных атаках с использованием этих уязвимостей не приводятся. Тем не менее обновление стоит установить всем, кто использует GitHub Enterprise Server до версии 3.21.5. Патч выпущен для ветки 3.21, а заметки о релизе размещены в документации GitHub.
Корпоративный сервер часто связан с другими внутренними системами: системами непрерывной интеграции, хранилищами артефактов и инструментами управления конфигурацией. Возможность выполнить код на таком сервере может открыть доступ к этим связанным компонентам. Отдельного внимания заслуживает первая уязвимость, поскольку для нее достаточно обычной записи разработчика с правом записи. Наличие нескольких проблем в разных частях сервера подчеркивает, что обновление корпоративных инсталляций не стоит откладывать даже при отсутствии признаков активной эксплуатации.
Ссылки
