GitHub Enterprise Server закрыл утечку памяти в Git-сервисе по SSH

GitHub зарегистрировал и устранил уязвимость CVE-2026-118237 в Git-сервисе GitHub Enterprise Server — компоненте, который сам продукт называет babeld. По данным официальных release notes GitHub Enterprise Server, патч вошёл в версии 3.22.3, 3.21.8 (вышла 3 ноября 2026 года), 3.20.10 и 3.19.14 — компания закрыла проблему сразу во всех поддерживаемых ветках, а не только в последней. Уязвимость нашли и сообщили через собственную программу GitHub Bug Bounty, публичного эксплойта на момент публикации патча зафиксировано не было.

Как работает утечка

Суть бага — в деталях реализации SSH-рукопожатия. Когда сервер должен доказать клиенту владение хостовым ключом, он подписывает идентификатор сессии; длина этого идентификатора определяется алгоритмом дайджеста. В уязвимой версии babeld размер буфера под идентификатор сессии выставлялся по длине дайджеста, который действовал в момент инициализации сессии, а не пересчитывался заново при смене алгоритма. Если у пользователя уже есть учётная запись и SSH-доступ к серверу, он может инициировать re-key на алгоритм с более длинным хешем — тогда в подписываемый блок попадает не только корректный идентификатор, но и прилегающая к нему память процесса. Клиент получает эти байты обратно вместе с легитимной подписью, и часть утечки потенциально восстановима.

Кого это касается

Риск — только для self-hosted GitHub Enterprise Server с доступом по SSH; GitHub.com и GitHub Enterprise Cloud уязвимость не затрагивает, поскольку это специфика сборки on-prem дистрибутива. Но для компаний, которые держат собственный git-сервер (чаще всего так делают именно ради контроля над исходным кодом и инфраструктурой CI/CD), это ровно тот случай, когда «мы же сами хостим git, значит безопаснее» перестаёт быть аргументом без дисциплины патчинга. Утечка требует уже существующей учётной записи — то есть страдают в первую очередь организации, где доступ к git-серверу выдан широкому кругу подрядчиков или бывших сотрудников, а ревизия прав никто системно не проводит.

Что сделать команде

• Обновить self-hosted GitHub Enterprise Server минимум до 3.22.3 / 3.21.8 / 3.20.10 / 3.19.14 в зависимости от текущей ветки
• Сверить список учётных записей с SSH-доступом к серверу: отключить тех, кому доступ уже не нужен по факту проекта
• Проверить, не осталось ли в журналах аудита нетипичных re-key-событий с момента последнего обновления
• Для организаций без постоянной команды безопасности — отдать регулярную ревизию конфигурации git-инфраструктуры и прав доступа на сторону: например, команде, которая проводит независимый аудит кода и CI/CD-конфигурации и ловит такие расхождения между тем, «как должно быть», и тем, как сервер настроен на самом деле
• Не откладывать патч: CVSS 5.3 — это «умеренно», но при активном использовании git-сервера подрядчиками риск накопления утечки растёт со временем