Теряет ли GitHub доверие индустрии?

Почему для некоторых GitHub перестал быть безопасным дефолтом, и что с этим делать — если вы, конечно, не хотите узнать об этом в день блокировки аккаунта или когда ваши закрытые репозитории могут общественным достоянием?

Думаю, для многих GitHub почти стал именем нарицательным. Помню, как я не знал, что такое git, но уже публиковал исходный код маленькой игры на GitHub через загрузку файлов. Многое было другим на тот момент: ИТ не был на пике мейнстрима, ИИ казался чем-то очень далеким и GitHub был де-факто стандартом.

Времена меняются и довольно быстро: теперь многие задаются вопросом так ли перспективен ИТ, появились LLM, которые используются ежедневно, GitHub уже не справляется с нагрузкой, а его приватные репозитории оказывается не такие уж и приватные.

28 апреля 2026 года стало по-настоящему плохим днём для GitHub. Утром CTO платформы опубликовал длинное извинение за кризис стабильности — 8 серьёзных сбоев за два месяца. Этим же днём Wiz Research опубликовал детали критической уязвимости CVE-2026-3854: один обычный git push мог выполнить произвольный код на серверах GitHub.

По порядку разберём и свежие, и давние события с точки зрения обычного разработчика, которые происходят с GitHub сейчас

---

CVE-2026-3854

В марте 2026 года исследователи из Wiz Research обнаружили критическую уязвимость во внутренней инфраструктуре GitHub. Любой авторизованный пользователь мог выполнить произвольный код на серверах, отправив обычный git push со специально сформированными опциями.

Как это работало

Когда вы делаете git push, запрос проходит через цепочку внутренних сервисов GitHub:

SSH -> babeld (proxy) -> gitauth (auth) -> gitrpcd (RPC) -> pre-receive hook

И здесь нужно обратить внимание на X-Stat — внутренний заголовок, передающий секюрити-метаданные между сервисами, начиная с babeld. Это key=value значения, разделённые точками с запятой. Парсер использует last-write-wins — если ключ встречается дважды, побеждает последнее значение.

GitHub поддерживает push options — произвольные строки, которые можно передать с git push -o "habr=bool:true". Проблема в том, что babeld копировал эти значения в X-Stat заголовок без экранирования (прикольно). Точка с запятой внутри push option “вырывалась” из своего поля и создавала новые, контролируемые атакующим параметры.

Цепочка эксплуатации

Далее, в лучших традициях инъекций для неэкранированных заголовков потребовалось три последовательных действия:

1. Отключение песочницы — подмена поля rails_env на non-production значение. Pre-receive hook начинал выполняться без sandbox, с полным доступом к файловой системе.

2. Перенаправление каталога хуков — подмена custom_hooks_dir. Теперь hook-скрипты ищутся в каталоге, указанном атакующим.

3. Path traversal — подмена repo_pre_receive_hooks с path traversal. Указание на любой исполняемый файл в системе.

Как итог, GitHub выполняет произвольный код от имени git-пользователя, без ограничений.

GitHub — это мультитенантная платформа, где пользователь git имеет доступ ко всем репозиториям на ноде. Исследователи подтвердили, что с компрометированной ноды можно было прочитать миллионы репозиториев, принадлежащих другим пользователям и организациям. К нашему или их счастью — они этого не делали. Проверили только свои тестовые аккаунты.

Реакция GitHub

После получения отчёта команде GitHub за 40 минут удается репродуцировать уязвимость внутри и начать работу по незамедлительному фиксу уязвимости. В итоге им удается закрыть эту уязвимость за 6 часов, что заслуживает уважения. Далее, выходит статья Securing the git push pipeline: Responding to a critical remote code execution vulnerability, где они объясняют как такое вообще произошло и благодарности Wiz за подробный отчет об уязвимости.

Это, конечно, хорошо, что такая большая компания упоминает (не все, к сожалению, упоминают вклад комьюнити) и награждает тех, кто добросовестно сообщает о таких уязвимостях или вносит вклад в развитие продукта, не говоря уже о признании того, что такая ошибка есть. И тем более награждает их через Bug Bounty.

Но что важно нам как обычным пользователям в первую очередь — могла ли эта уязвимость быть обнаружена раньше, кем-то другим, кто решил не делиться, а использовать в не совсем честных целях?

В своей статье GitHub пишет:

We logged this path and queried our telemetry for any instance of this anomalous code path being executed. The results were clear:

• Every occurrence mapped to the Wiz researchers’ own testing activity.

• No other users or accounts triggered this code path.

• No customer data was accessed, modified, or exfiltrated as a result of this vulnerability

For GHES customers, exploitation would require an authenticated user with push access on your instance. We recommend reviewing your access logs out of an abundance of caution.

Перевод

Мы зафиксировали этот путь в логах и проверили телеметрию на предмет любых случаев выполнения этого аномального кодового пути. Результаты однозначны:

• Каждое совпадение относится к собственной тестовой активности исследователей Wiz.

• Ни один другой пользователь или аккаунт не инициировал этот кодовый путь.

• Данные клиентов не были получены, изменены или скопированы в результате этой уязвимости.

Для клиентов GHES эксплуатация потребовала бы авторизованного пользователя с правами push на вашем инстансе. На всякий случай рекомендуем проверить ваши логи доступа.

Учитывая текущее положение GitHub, когда CTO извиняется за сбои и когда обнародуется уязвимость, которая может привести к утечке данных — есть большая мотивация недооценить масштаб ошибки. Но мы этого не узнаем, и надеюсь что это будет так, либо узнаем намного позже, чем хотелось бы.

В сухом остатке

Уязвимости есть в любом приложении как и баги — это нормально. Но суть в том, что мы не знаем что уязвимость есть, пока нам кто-то об этом не скажет. Каждый день происходят утечки данных, взламывают пароли и крадут деньги. В сравнении с остальными здесь можно похвалить GitHub. Например, Apple заплатила $1,000 за критическую уязвимость (CVSS 9.8) в Safari, при максимальном бounty в $2M, наверное, посчитав что пользователю нужно сделать слишком много действий для этого. Zoom пыталась купить молчание исследователя через NDA вместо того чтобы быстро исправить дыру, позволившую любой сайт активировать веб-камеру на Mac. А Equifax проигнорировала существующий патч к Apache Struts и потеряла данные 143 миллионов человек. Так что все могло быть намного хуже.

Интересно также то, что при поиске данной уязвимости использовался ИИ:

This research was made possible by AI-augmented reverse engineering tooling, particularly IDA MCP, which allowed us to rapidly analyze compiled binaries and reconstruct internal protocols at a speed that would not have been feasible manually.

Перевод

Это исследование стало возможным благодаря ИИ-инструментам для реверс-инжиниринга, в первую очередь IDA MCP, которые позволили нам быстро анализировать скомпилированные бинарники и реконструировать внутренние протоколы на скорости, недостижимой вручную.

В контексте безопасности ИИ — это обоюдоострый меч, с одной стороны с его помощью можно искать уязвимости и заблаговременно их закрывать, как например, нашумевший Glasswing, который нашел баг в OpenBSD или использовать его для создания эксплойтов.

В своей статье Wiz пишут:

“Мы оцениваем, что потребуется около 12–18 месяцев, прежде чем эти возможности появятся в open-source моделях, которые любой сможет запустить локально и без ограничений. С этого момента придётся исходить из того, что злоумышленники смогут использовать AI для массового поиска и создания эксплойтов к zero-day уязвимостям, а также быстро превращать уже известные (n-day) уязвимости в оружие – в считанные часы после их публичного раскрытия.”

Мы оказались в новой гонке вооружений. С одной стороны ИИ ищет уязвимости раньше атакующих и помогает патчить до раскрытия. С другой — тот же ИИ автономно находит zero-day и пишет к ним эксплойты. Разница лишь в том, кто владеет информацией первым.

Нарушение SLA

В тот же день GitHub выпускает статью: An update on GitHub availability, а до этого еще другую: Addressing GitHub’s recent availability issues, где описывают недавние инциденты и как они решают их. Эти ошибки были вызваны уже не уязвимостью, о которой никто не знал, но из-за неправильных решений самой команды, а также из-за резкого повышения активности из-за ИИ.

Разбор

Разберем к примеру сбой 9 февраля, описанный в статье GitHub.

В начале февраля выходят обновления двух очень популярных клиентских приложений, которые генерируют большой объём API-запросов к серверам. В обновлениях оказались изменения, которые приводили к десятикратному росту трафика чтения. Из-за того что приложения обновляются постепенно — уловить всплеск нагрузки сразу не удается.

Суббота. GitHub выпускает новую модель (скорее всего, это). Нагрузка низкая, всё стабильно. Тогда же принимается решение уменьшить TTL кэша настроек с 12 часов до 2, чтобы люди быстрее увидели новую модель. Больше cache evictions -> больше write load на базу. На тот момент всё работало нормально, поскольку нагрузка в выходные дни значительно ниже, и обнаружить надвигающуюся проблему не удается.

Понедельник. Начинается новая неделя, люди подходят к своим рабочим местам: обновляют софт, работают и пробуют новую модель. Три фактора одновременно давят на кластер баз данных: повышенный трафик начала рабочей недели, массовое обновление клиентских приложений (десятикратный рост read-трафика) и write-нагрузка из-за сокращённого TTL. База уходит в saturation.

Изменение TTL быстро удалось определить как одну из причин, но гораздо дольше пришлось разбираться, почему read-нагрузка продолжала расти. Когда кластер БД перестал справляться, потребовалось отсечь лишнюю нагрузку, но не было средств для точечной фильтрации трафика, чтобы выяснить какой трафик нужно блокировать.

Важные выводы

Расследование инцидента 9 февраля вызвало немало важных вопросов о том, почему настройки пользователей хранились именно в этом кластере баз данных и именно в таком виде. Архитектуру когда-то выбрали ради простоты — в то время моделей было мало, и политик управления ими почти не существовало. Но со временем то, что занимало у одного пользователя несколько байт, выросло до килобайт. Опасность этого не удалось вовремя заметить, потому что нагрузка была видна только во время роллаутов новых моделей и политик — и маскировалась за счёт TTL. Поскольку в этом кластере хранятся данные для аутентификации и управления пользователями, пострадали все сервисы, зависящие от них.

На самом деле, хорошо что GitHub публикует свои расследования таким образом, чтобы люди понимали что происходит внутри. Тем не менее, это не отменяет того факта, что были приняты неверные решения как плановые, так и архитектурные, которые вместе привели к инциденту.

Как итог, учитывая еще несколько других инцидентов — GitHub нарушает свой SLA.

Блокировка GitHub аккаунта

Думаю, не многие задумываются о том, чтобы диверсифицировать свои исходники в разные системы управления (возможно, кроме слитой версии Claude Code). А если скажу, что GitHub может заблокировать ваш аккаунт без предупреждения, без объяснения причин, а поддержка будет молчать неделями? Причем вы даже не сможете выгрузить свои исходники, пока аккаунт заблокирован.

40 дней без доступа

9 ноября 2024 года разработчик под ником pilot2254 обнаружил, что его аккаунт заблокирован. Четыре года работы, 2000 контрибьюшенов. Причем даже email не было, обнаружилось это только тогда, когда он не смог войти в аккаунт.

После обращения в поддержку — первый живой ответ был получен только после 27 дней с уточняющими вопросами (username, location и тд). Причину блокировки объяснили так: “Suspicious login detected. Your account was compromised. A bad actor made changes”. Но в security log — только генерация токенов Copilot с того же IP в Братиславе, откуда юзер всегда заходил. Никаких несанкционированных коммитов, никаких странных действий. Тем не менее, аккаунт вернули, но контрибьюшенов было на 800 меньше, README профиля не отображается, GH Pages не работает корректно и многое другое.

Самое интересное здесь в том, что это не “bad actor” удалил контрибьюшены, а автоматизированная система GitHub как пишет сам автор (pilot2254). А suspicious activity оказалась генерация/перегенерация Copilot токенов. Из-за него заблокировали аккаунт, а дальше система начала удаление. Позже не без проблем все это вернули обратно, на весь процесс возврата и восстановления аккаунта понадобилось более 40 дней.

К сожалению, это не единичные случаи, например, этот случай или вот эти. Вполне возможно, что данные пользователи что-то недоговаривают и преподносят блокировку как ошибку, хотя тем не менее потом им удается получить разблокировку. Вы можете подумать, что вас это не коснется. Этакая системная ошибка, но могут быть ситуации масштабнее.

Office of Foreign Assets Control

Слова “блокировки” и “санкции” в последнее время стали очень популярными, в связи с этим возникает и другой риск потери аккаунта. Дело в том, что GitHub — американская компания (Microsoft), подпадает под OFAC (Office of Foreign Assets Control).

Например, в Иране с 2019 года: блокировка создания аккаунтов, push, discussions, Actions, Codespaces, Copilot. Public repos доступны анонимно. npm (Microsoft/GitHub): публикация пакетов заблокирована. И это не вина GitHub, он мало что может сделать, но делает то что в его силах. В 2026 после эскалации конфликта — ограничения ужесточены.

Sharif University of Technology (SUT) занимала 151-175 место в рейтинге THE в Computer Science и они отрезаны от глобальной экосистемы разработки.

Если сегодня это Иран, то завтра может быть любой другой регион. В системе, где ваши исходники и проекты зависят от решения регулятора другой страны — нужно диверсифицировать проекты. Хотя бы в одну другую или держать локальные копии важных проектов. В нынешнее время нельзя держать все проекты лишь в одном GitHub, случится может что угодно, от случайного бана до решений регулятора.

Безопасна ли сама среда?

GitHub не гарантирует безопасность исполняемого кода в репозиториях. Вы легко можете попасть на малварь, который украдет ваши данные, и с такой же легкостью вы сами можете распространить свои данные случайно. Но это касается не только GitHub, но и других систем, которые нужно учитывать.

Неудаляемые коммиты

Уже многие знают практику использовать переменные окружения в .env файле, добавить его в gitignore и не боятся что ключ/токены утекут. Теперь представим такой случай: пользователь форкает какой-нибудь публичный репозиторий, чтобы запустить самому. Он хочет просто быстро попробовать продукт и хардкодом забивает туда API-ключ. Посмотрел, что работает. Случайно или не случайно закоммитил его в свой форк. GitGuardian сразу ему шлет письмо, что он спалил API-токен и пользователь ведь не дурак, сразу это видит и удаляет свой форк, чтобы токен никто не увидел. Теперь токен никто не увидит, ведь так?

Не совсем, во-первых, за это время какой-нибудь скраппер уже мог украсть токен, поэтому всегда лучше его перегенерировать, но если вы вдруг решили испытать удачу, то во-вторых, даже если вы удалили свой форк, ваш коммит все равно останется, даже если вы не делали PR и ничего с главным репозиторием. Рассмотрим на примере:

1. Возьмем какой-нибудь репозиторий. Например, https://github.com/charmbracelet/glamour

2. Создадим от него форк. Теперь у нас есть своя версия этого репозитория.

3. Давайте теперь добавим какой-нибудь .env файл, имитируя утечку данных

4. Сохраним наш commit hash

5. Удалим наш репозиторий

6. Теперь мы видим, что по старой ссылке коммита — нам выдает 404.

7. Переходим в главный репозиторий от которого мы делали форк и используем там наш commit hash

8. И здесь мы видим наш commit — целый и невредимый, со всеми изменениями и с нашими переменными.

Окей, это уже причина сразу перегенерировать токен, но что если пользователь настолько ленивый, что думает: ну, надо ведь коммит хэш угадать. Справедливо, commit hash использует SHA-1 = 40 hex символов = 160 бит = 2^160 возможных вариантов, примерно 1.46 * 10^48. Но есть такая штука как сокращенная запись хэша. Например, вместо 2bec85324a460ed41b5b4a79fc42602ad40353dc я могу использовать 2bec8 и все равно получу тот же коммит. То есть, необязательно вводить полный хэш, достаточно первые значения. Минимальная длина такой записи всего лишь 4 символа, поэтому можно брутфорсить и смотреть другие коммиты.

Не будем сильно углубляться, но с этим есть вполне неочевидные случаи, которые работают так как задумано, по дизайну GitHub и git. Полную статью с примерами можно почитать здесь. Там же есть случаи, когда мы можем получить доступ к коммитам основного репозитория, который был удален, или получить доступ к данным приватного форка репозитория, когда основной стал паблик. В общем, рекомендую к прочтению.

Фейковые звезды

Тема про фейковые звезды не нова и было бы даже странно, если бы люди не пытались накрутить себе звезды на свои репозитории. Вопрос лишь в том, как с этим борятся? GitHub, например, удаляет репозитории и аккаунты. Когда StarScout пометил 15к+ репозиториев как подозрительные — GitHub очистил почти 90%. А вот развивает ли он свои системы детекции или полагается на других исследователей — вопрос актуальный.

Но насколько эффективна и какая текущая картина? Фейковых звезд довольно много. Это не так страшно, когда кто-то просто хочет раскрутить свой репозиторий, как, например, если оно используется для малварь репозиториев. Например, какой-нибудь репозиторий с крипто-операциями с большим количеством звезд и активностью, или же какая-нибудь программа obhod-blokirovok-2026 с 1к звезд на GitHub.

На эту тему есть интересные статьи, которые можно прочитать:

• Tracking the Fake GitHub Star Black Market with Dagster, dbt and BigQuery

• И его перевод на хабре: https://habr.com/ru/articles/723648/

• Также работа Six Million (Suspected) Fake Stars on GitHub: A Growing Spiral of Popularity Contests, Spam, and Malware

Что же по итогу?

Каждый делает выводы для себя сам, здесь нет единой точки зрения, за исключением того, что нужно либо миррорить исходный код на другие платформы, либо держать бэкап на всякий случай. Менять любой запушенный токен доступа, даже если репозиторий приватный.

Ушла ли эпоха GitHub, потеряла ли индустрия доверие к нему? Определенно, нет. Конечно, есть новости, что, например, ghostty уходит из GitHub или ziglang, но это не критичная масса. Это прецеденты, но основная часть все равно находится на GitHub с богатой инфраструктурой, которая да, страдает, но работы по его исправлению ведутся. Вполне возможно, кто-то не хочет работать с GitHub из-за его политики: покупка его Microsoft’ом или его тесное сотрудничество с правительством. Тем не менее, GitHub занимает лидирующие позиции и скорее всего в ближайшее время ничего кардинально не изменится, но будем смотреть за трендами.

Надеюсь, статья была полезной и вы узнали что-то новое или посмотрели на вещи с другой стороны.

О себе

Я инженер-разработчик в финтехе с разными интересами особенно в области разработки. Изучаю интересные для себя инструменты, проекты и буду делится с этим в своем тг-канале. Подписывайтесь, буду рад каждому.