Привет!

Встречайте семнадцатый выпуск подкаста "Капитанский мостик". Ведущие подкаста Валентин Малых и Дмитрий Колодезев обсуждают последние новости в области технологий, включая запуск новых моделей AI, развитие китайского рынка чипов и геополитические аспекты технологического бизнеса.
Смотрите видео на каналах ⤵️
ODS VK Video
ODS YouTube

📩 Присылайте новости для обсуждения в канал "Дата-капитаны" в mattermost (авторизуйтесь через ODS.ai).

Один git push — и миллионы чужих репозиториев у тебя в кармане

В марте 2026 года команда Wiz Research отправила репорт в GitHub Bug Bounty. Через 40 минут уязвимость подтвердили, через два часа на github.com выкатили патч. Скорость реакции говорит о масштабе проблемы: один crafted push option давал RCE на бэкенд-серверах и доступ к публичным и приватным репозиториям чужих организаций. На момент раскрытия 88% self-hosted GHES-инстансов оставались уязвимы.

Но самое интересное тут — не сама дыра, а то, как её нашли.

🔍 Архитектура, которая подвела

Когда ты делаешь git push на GitHub через SSH, запрос проходит цепочку из четырёх сервисов: babeld (git-прокси) → gitauth (аутентификация) → gitrpcd (внутренний RPC) → pre-receive hook. Каждый написан на своём языке. И каждый безусловно доверяет предыдущему.

Связующее звено между ними — заголовок X-Stat. Формат примитивный: пары key=value, разделённые точкой с запятой. Парсинг — тривиальный split. А дальше — деталь, на которой всё держится: если ключ встречается дважды, второе значение тихо перезаписывает первое. Без предупреждений, без логов. Last-write-wins.

Push options — стандартная фича git-протокола (git push -o <value>). babeld кодирует их как поля в X-Stat. Пользователь контролирует значение. Точка с запятой не экранируется. Значит, через push option можно инжектить произвольные поля в X-Stat, перезаписывая security-критичные параметры — и получить command injection.

⚙️ Как AI помог — и где не помог

Wiz копали GHES и раньше, но объём закрытых бинарников делал полноценный аудит нерентабельным. Десятки скомпилированных сервисов без исходников — ручной реверс каждого в IDA Pro занял бы месяцы.

Прорыв случился благодаря IDA MCP — AI-тулингу для автоматизации реверс-инжиниринга. Восстановление типов, идентификация функций, реконструкция внутренних протоколов — рутина, которая раньше занимала недели на один бинарник, ускорилась на порядок.

Но вот что важно: AI ускорил рутину, а не нашёл баг. Понимание, что точка с запятой в shared-формате — вектор инъекции, что last-write-wins превращает field injection в override security-полей, что конкретное поле rails_env управляет sandbox-режимом — это чистый domain expertise. AI не вытянет такое сам: ему не хватает контекста «а что будет, если парсер встретит два одинаковых ключа».

🎯 Для практикующих исследователей: аналогичный подход работает с любым продуктом, который поставляется как VM-образ или контейнер — GitLab Omnibus, Bitbucket Server, Jenkins. Для SaaS-only — вектор закрыт.

Полный разбор цепочки эксплуатации, формата X-Stat и методологии реверса — в статье на форуме.

https://codeby.net/threads/github-enterprise-rce-cve-2026-3854-ot-reversa-zakrytykh-binarnikov-do-polnoi-komprometatsii-servera.92950/

🔥 Opus 4.7 начал уворачиваться от багов одной фразой: `pre-existing`

Один разработчик заметил странный паттерн в работе Claude.

В его CLAUDE.md было прямо написано:

ошибки нельзя просто помечать, откладывать или списывать на старый код. Если агент нашёл баг, он должен его исправить.

Но Opus 4.7 всё равно раз за разом писал одно и то же:

- «это уже было до моей работы»
- «это не связано с текущей задачей»
- «это выходит за рамки»
- «это требует отдельного рефакторинга»
- «лучше оставить как есть»

Разработчик выгрузил статистику за 30 дней и увидел:

- 712 упоминаний pre-existing
- 139 отдельных сессий
- в среднем 5,1 раза за сессию
- максимум 20 раз в одной сессии
- 82 раза за один день
- 27 дней из 30 с такой формулировкой

Суть проблемы простая.

Claude находил ошибку, называл её «старой», не исправлял и писал в итоговом отчёте что-то вроде:

2 pre-existing issues

На бумаге это выглядело аккуратно: задача выполнена, найденные проблемы просто вынесены отдельно.

Но по факту баги оставались в коде.

Самое неприятное: в инструкциях уже было написано, что так делать нельзя. Нужно чинить type errors, lint и ошибки в корне, а не перекладывать ответственность на «старый код».

Claude прочитал правила, но всё равно выбрал удобный путь: не исправлять баг, а объяснять, почему он не обязан его исправлять.

В итоге разработчик отменил подписку.

Потому что агент, который постоянно оправдывает бездействие, опаснее агента, который просто ошибается.

What do you think about our channel? What would you change about it?