25 августа 2026 года Агентство по кибербезопасности и безопасности инфраструктуры США (CISA) внесло CVE-2026-60004 в свой каталог известных эксплуатируемых уязвимостей (Known Exploited Vulnerabilities) и установило 28 августа крайним сроком устранения для федеральных гражданских ведомств. Уязвимость находится в Gitea — сервере с открытым исходным кодом для размещения репозиториев, который многие команды разворачивают на собственной инфраструктуре вместо облачного сервиса.

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

Что на самом деле произошло

Согласно бюллетеню безопасности, опубликованному разработчиками Gitea, уязвимость позволяет пользователю с обычным доступом на запись к любому репозиторию отправить специально сформированный патч на эндпоинт diffpatch. Это размещает на сервере исполняемый Git-хук, который затем выполняет команды оболочки от имени учётной записи, под которой работает сервис. Уязвимы версии с 1.17 по 1.27.0, а исправление вышло в 1.27.1.

Критически важная деталь — насколько низок порог входа. Доступ на запись к репозиторию — не редкая привилегия, а в конфигурации по умолчанию, где открыта самостоятельная регистрация, любой может создать учётную запись и самостоятельно достичь этого порога. Поэтому Национальная база данных уязвимостей США (NVD) оценивает её на 9.8 из 10 по шкале CVSS — такая оценка присваивается уязвимостям, которые эксплуатируются удалённо, не требуют сложной аутентификации и полностью нарушают конфиденциальность, целостность и доступность.

В том же бюллетене отмечается, что успешная эксплуатация раскрывает гораздо больше, чем код: учётные данные, секреты, базы данных, подключённые репозитории, токены OAuth и внутренние сервисы, до которых может дотянуться сервер. Злоумышленник уходит не с текстовыми файлами. Он наследует позицию сервера внутри вашей сети.

Почему сервер кода опаснее вашего сайта

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

  • Исходный код ваших систем, включая логику ценообразования, правила скидок и проверки прав доступа.
  • Конфигурационные файлы и переменные окружения с паролями баз данных, ключами платёжных шлюзов и учётными данными для государственных API.
  • Ключи развёртывания, позволяющие отправить обновление прямо на рабочие серверы.
  • Доступ по внутренней сети к другим машинам, которые вообще не открыты в интернет.

Такое сочетание означает, что скомпрометированный сервер кода — это не отдельный инцидент, а стартовая площадка. Злоумышленнику, владеющему вашими ключами развёртывания, не нужно взламывать вашу бухгалтерскую систему. Ему достаточно отправить ей обновление, которое он подписал сам.

Настоящая брешь: системы, которые никому не принадлежат

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

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

Что сделать на этой неделе

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

  • Запросите письменный перечень всех внутренних систем, работающих на ваших серверах, и для каждой — ответственного по имени, конкретного человека, а не отдел.
  • Запросите номер версии каждого используемого инструмента с открытым исходным кодом и дату его последнего обновления. Если вы используете Gitea, убедиться, что у вас 1.27.1 или более поздняя версия, — вопрос двух минут.
  • Отключите самостоятельную регистрацию во всех внутренних инструментах. Нет никакой операционной причины держать страницу регистрации на сервере кода открытой для интернета.
  • Задайте один неудобный вопрос: если бы секреты с этого сервера украли сегодня, сколько дней ушло бы на замену их всех? Если ответа нет, значит, ответ — вы не сможете.

Добавьте к этому регуляторное измерение. Внутренние системы компании обычно содержат персональные данные клиентов или сотрудников, а защита этих данных — юридическая обязанность организации в соответствии с Законом о защите персональных данных (PDPL). Взлом, который начинается в инструменте разработчика и заканчивается в вашей базе данных клиентов, не считается внутренним техническим делом.

Позиция Origami

Мы воспринимаем этот инцидент как подтверждение того, что повторяем в каждом проекте: безопасность — это не функция, добавляемая к готовому продукту, а свойство того, как продукт построен. Разница между компанией, которая выстоит, и компанией, которая падёт, не в том, сколько средств защиты она купила, а в том, знает ли она, что у неё работает, кто за это отвечает и когда это обновлялось в последний раз.

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

Заключение

Уязвимость, из-за которой регулятор установил жёсткий срок, находилась не в клиентском интерфейсе. Она была во внутреннем инструменте, который считался скрытым от посторонних глаз. В этом и урок: системы, которые никогда не попадают в презентацию, — именно те, что хранят ключи. Начните с инвентаризации, назначьте каждой системе владельца и сделайте обновления рутиной, а не реакцией на заголовок. Компании, которые переживают инциденты такого рода, не умнее других. Они просто знают, чем владеют.

Источники