Git
5 статей с этим тегом
GitLab CVE-2026-110264 (CVSS 10.0) и эксплуатируемая CVE-2026-97229: как проверить и обновить самостоятельно развёрнутый GitLab
21 октября 2026 года GitLab выпустил критические патч-версии 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 и 18.11.13 для Community Edition (CE) и Enterprise Edition (EE). Самая серьёзная уязвимость, CVE-2026-110264 (CVSS 10.0), представляет собой целочисленное переполнение при компиляции специально сформированного регулярного выражения, которое при определённых условиях может позволить неаутентифицированному пользователю выполнить произвольный код на сервере GitLab. Затронуты почти все версии начиная с 7.0. 29 октября CISA добавила родственную уязвимость CVE-2026-97229 (CVSS 10.0, CWE-190) в каталог известных эксплуатируемых уязвимостей (KEV) со сроком 1 ноября. Это ошибка того же рода (целочисленное переполнение в компиляторе регулярных выражений CI/CD, доступное неаутентифицированному пользователю); GitLab исправил её раньше, 12 октября, в версиях 19.4.2, 19.3.5 и 19.2.8, и затронуты только 19.2.0–19.2.7, 19.3.0–19.3.4 и 19.4.0–19.4.1. Кто всё ещё на версиях ниже 19.4.2, 19.3.5 или 19.2.8, подвержен эксплуатируемой уязвимости. Обновление до рекомендованных здесь версий (19.5.1, 19.4.3, 19.3.6, 19.2.9) исправляет и CVE-2026-97229. GitLab.com уже исправлен; самостоятельно развёрнутые установки нужно обновить. Тот же выпуск от 21 октября исправляет две уязвимости высокой степени серьёзности (CVSS 8.2 и 7.5) и другие, но эти исправления есть только в ветках 19.3.6, 19.4.3 и 19.5.1. Корень проблемы — в движке регулярных выражений Ruby (Onigmo); 23 октября Ruby выпустил 4.0.9, 3.4.12 и 3.3.13. Затронуты приложения, которые компилируют regexp из строк, контролируемых злоумышленником, а Regexp.timeout от этих ошибок не защищает. В уведомлениях GitLab не сказано, что CVE-2026-110264 эксплуатировалась, и на 30 октября её нет в KEV. Alpine Linux сообщила, что на ее собственном GitLab 20 и 21 октября была попытка атаки через CVE-2026-97229 и что одно лишь обновление GitLab (до 19.3.6) не закрыло уязвимость, потому что для исправления нужен был еще и пропатченный Ruby; она пересобрала инстанс и не нашла свидетельств того, что код злоумышленника выполнялся. Вывод этого сайта: обновите самостоятельно развёрнутый GitLab сегодня, проверив обязательные остановки, доведите установку до 19.3.6 или новее, а если вы собираете GitLab сами или используете собственный Ruby, проверьте, что и Ruby не ниже 3.3.13, 3.4.12 или 4.0.9. Ruby-приложениям нужно перейти на исправленный Ruby и перестать формировать regexp из пользовательского ввода.
Настройка двухфакторной аутентификации (2FA) на GitHub: приложение-аутентификатор, passkey, коды восстановления и что делать при потере телефона
Руководство по настройке двухфакторной аутентификации (2FA) на GitHub так, чтобы не потерять доступ. С марта 2023 года GitHub поэтапно, группа за группой, требует 2FA от пользователей, которые публикуют код на GitHub.com; после выбора группы даётся 45 дней на подключение и 7 дней льготного периода, после чего GitHub.com недоступен, пока 2FA не включена. GitHub Docs рекомендует приложение-аутентификатор (TOTP) как основной метод и passkey или ключ безопасности как резервный (passkey, ключи безопасности и GitHub Mobile можно добавить только после настройки TOTP или SMS). Позиция этого сайта: типичная проблема с 2FA на GitHub — не захват аккаунта, а то, что вы сами теряете доступ, а поддержка GitHub не может восстановить аккаунт, если утеряны все данные 2FA и все способы восстановления. Сохраните 16 кодов восстановления в менеджере паролей и в тот же день зарегистрируйте второй метод. Заодно перейдите на fine-grained токены со сроком действия, почистите авторизованные приложения и SSH-ключи и проверьте push protection и оповещения Dependabot.
543 699 учётных данных, опубликованных на GitHub, всё ещё работали (исследование 2026 года): почему нужно отзывать, а не удалять, и что делать разработчикам
Компания по безопасности, продающая инструменты поиска секретов, изучила снимок примерно 224 миллионов публичных репозиториев, собранный для обучения LLM, и сообщила, что в конце июля 2026 года 543 699 учётных данных всё ещё проходили аутентификацию. Медианное время с момента раскрытия — 784 дня. Почти все токены npm и GitHub были аннулированы, тогда как 75–88% строк подключения к базам данных всё ещё работали. Более 199 000 действующих учётных данных появились уже после того, как GitHub включил push protection по умолчанию, и больше половины действующих относились к типам, которые push protection по умолчанию не блокирует. Вывод этого сайта: учётные данные, отправленные в публичный репозиторий, нельзя вернуть удалением файла или переписыванием истории, поэтому сначала их нужно отозвать. Отзываются ли утёкшие учётные данные автоматически, зависит от выпустившего их сервиса; строки подключения и многие API-ключи действуют, пока вы сами их не остановите.
Останавливайте секреты до коммита с gitleaks: ловите утечки API-ключей до push
Секреты нельзя «удалить после утечки». Раз закоммиченный, секрет остаётся в истории Git, а раз запушенный — его надо считать утёкшим: ключ нужно отозвать/сменить. gitleaks — бесплатный инструмент, сканирующий весь репозиторий и историю коммитов по regex/энтропии, чтобы найти API-ключи, приватные ключи и токены. Ядро защиты — две проверки: хук pre-commit, останавливающий локально до push, и CI/cron, ловящий то, что просочилось. .gitignore лишь предотвращает новое отслеживание — он не умеет обнаруживать, так что сканер всё равно нужен.
Самохостинг Git vs GitHub: что на самом деле безопаснее?
Самохостинг Git не делает вас «безопаснее» — он перемещает риск. Класс случайной публичной выставленности исчезает, но патчинг сервера, резервные копии и обнаружение секретов в pre-commit переходят на вас. Правильный выбор, если вы продолжаете выполнять эту работу; хуже GitHub, если её забрасываете. Взгляд этого сайта: самохостинг работает только в связке с компенсирующими мерами.