Michael JohnsonЕсли вы обновили Git в терминале, работа ещё не закончена: отдельные приложения и сборочные среды могут запускать собственную копию. 10 ноября 2026 года проект Git выпустил исправления шести уязвимостей — от выполнения кода при рекурсивном клонировании до повреждения памяти при слиянии. Поэтому проверять нужно каждую среду, которая обрабатывает репозитории или их содержимое, а не только результат команды git --version в вашей оболочке.
Что изменилось в обновлении
Исправления вошли в Git 2.56.1 и перенесены в поддерживаемые ветки: 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 и 2.50.2. Обновление устраняет шесть проблем в разных частях Git — при работе с путями, ссылками, подписями, бинарными патчами, слияниями и потоками импорта. Разбор уязвимостей и рекомендация обновиться опубликованы GitHub 10 ноября; заметки к выпуску Git 2.56.1 перечисляют CVE, исправленные в этой серии.
Практическое следствие — обновить Git, используемый в трёх местах: на рабочих компьютерах, в автоматизации и внутри приложений, которые включают собственную сборку Git. Именно последний пункт легко упустить: обновление системного пакета не меняет автоматически версии в каждом клиенте или образе сборки.
Почему рекурсивный clone заслуживает внимания
Самая наглядная цепочка начинается с рекурсивного клонирования недоверенного репозитория. Из-за усечения длины пути очень длинная запись могла пройти проверку под одним именем, а затем попасть на диск под укороченным. В описанном Git сценарии это позволяло заменить файл .git подмодуля символической ссылкой на каталог с вредоносной конфигурацией или хуками. При последующем обращении Git мог выполнить код, заданный атакующим.
Важно для практики: речь идёт о специально подготовленном репозитории и соответствующей операции. Командам, которые регулярно клонируют проекты с внешних источников с параметром --recurse-submodules, стоит приоритетно обновить клиентские и автоматизированные среды. Исправление отклоняет чрезмерно длинные пути до того, как их длина будет усечена.
Другие точки, где Git обрабатывает недоверенные данные
Ещё одна проблема возникает при клонировании пустого репозитория через Git protocol v2. Сервер мог передать ссылку HEAD с именем ветки, содержащим компоненты обхода каталогов; позднее операция обновления ветки могла записать файл за пределами ожидаемой директории ссылок. В исправленных версиях Git проверяет такую цель и другие имена ссылок, полученные по протоколу.
Отдельные уязвимости затрагивали операции слияния и патчами. При обработке подписей фиксированный массив рассчитывал максимум на две подписи; специально сформированное сообщение с большим числом подписей могло вызвать запись за границы массива и повреждение памяти. При применении бинарного патча проверка размера учитывала исходное представление, хотя сжатые данные способны раскрыться в существенно больший объём. Теперь Git проверяет заявленный несжатый размер до обработки.
Большие слияния также могли привести к переполнению при расчёте необходимого буфера и последующей записи за его границы. Это касается в том числе хостингов и приложений, которые сливают недоверенное содержимое. Наконец, три возможности git fast-import получили ограничения для команд из входного потока: rewrite-submodules-from и rewrite-submodules-to могли читать произвольные файлы, а export-pack-edges — создавать файлы или дописывать данные в существующие. Теперь эти возможности блокируются, если явно не указан флаг --allow-unsafe-features; использовать его следует только для доверенного генератора потока.
Где искать отдельные копии Git
Для разработчика достаточно начать с инвентаризации источников запуска Git. Проверьте версию в терминале и используйте штатную проверку обновлений для IDE и настольных Git-клиентов. Затем проверьте образы CI, контейнеры, runner-ы и серверные задания, которые выполняют clone, merge, применяют бинарные патчи или запускают fast-import. Само наличие свежего Git на хосте не гарантирует, что приложение обращается именно к нему.
В организациях полезно сверить не только исходные образы, но и уже развёрнутые рабочие среды: постоянный runner или внутренний сервис мог сохранить старый бинарный файл после обновления базового образа. Для GitHub Enterprise Server GitHub указывает исправленные версии 3.19.15, 3.20.11, 3.21.9 и 3.22.4. Компания сообщила, что уже развернула исправления на github.com и GitHub Enterprise Cloud, включая варианты с размещением данных. Выпуски GitHub Desktop и GitHub Copilot app с исправленным Git координируются; исправленные версии для Codespaces и GitHub Actions также ещё должны появиться.
Как снизить риск до обновления
Если немедленно поставить исправление нельзя, временно ограничьте операции с недоверенными данными: клонируйте репозитории только с доверенных серверов, избегайте рекурсивного клонирования непроверенных проектов, не сливайте их содержимое и не применяйте полученные от них бинарные патчи или потоки fast-import. Эти меры сокращают контакт с конкретными уязвимыми сценариями, но не заменяют обновление.
Главный практический вывод прост: исправление Git нужно искать там, где программа действительно выполняет Git. Команда в терминале — только одна из таких точек; клиенты разработки, CI и сервисы обработки репозиториев требуют отдельной проверки.
