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 та сервіси обробки репозиторіїв потребують окремої перевірки.
