GitLab закрыл критическую дыру GraphQL: публичные проекты удалялись без авторизации

Коротко о главном

17 августа 2026 года GitLab выпустил внеплановый экстренный патч, закрывающий CVE-2026-19478 (CVSS 9.4): через уязвимость в GraphQL-интерфейсе любой неаутентифицированный атакующий мог без учётной записи удалить или изменить публичный проект и данные его пользователей. Уязвимость затрагивает все self-managed-установки GitLab CE/EE версий с 18.2 по 19.2.3. GitLab.com и GitLab Dedicated уже работают на исправленных версиях. Командам на self-managed нужно обновиться до 19.2.4, 19.1.6, 19.0.8 или 18.11.11.

Это третья критическая уязвимость в GraphQL-компоненте GitLab за 2026 год. Если ваша CI/CD-инфраструктура или разработка под ключ строится на GitLab — обновление нельзя откладывать: эксплуатация не требует ни токена, ни сессии, ни взаимодействия пользователя.

Патч вышел вне обычного двухнедельного расписания безопасности GitLab (второй и четвёртый вторник месяца) — пять дней спустя после плановых обновлений 12 августа, в которых критических проблем не было. Это само по себе сигнал серьёзности: компания не стала ждать следующего окна. Активная эксплуатация не подтверждена, однако PoC технически тривиален — возможности GraphQL-директив широко документированы, а вектор атаки общеизвестен.

Техническая суть уязвимости

CVE-2026-19478 — инъекция кода через GraphQL-директиву. GraphQL в GitLab принимает директивы в запросах, и в уязвимых версиях отдельные директивы обрабатывались без проверки прав доступа. Это означало: любой, кто может отправить HTTP-запрос к публичному экземпляру GitLab, мог сформировать GraphQL-запрос с вредоносной директивой и выполнить мутацию над данными проекта — изменить метаданные, удалить репозиторий, затронуть связанные записи пользователей.

Ключевые характеристики: вектор атаки — сетевой (Network), аутентификация не нужна (None), взаимодействие пользователя не требуется (None), конфиденциальность не нарушается (None), но доступность (High) и целостность (High) страдают критически. Именно это даёт суммарный CVSS 9.4, а не стандартные 10.0: данные не «утекают» атакующему — они уничтожаются или искажаются.

Уязвимость присутствует начиная с GitLab 18.2 — то есть в инсталляциях, не обновлявшихся с начала года. В тестировании безопасности подобный вектор называется IDOR через GraphQL-мутацию: объект публично доступен для чтения, и ошибка в слое авторизации мутаций позволяет записывать данные без прав.

Что именно под угрозой и кого это касается

Под угрозой — только self-managed-установки. Если вы используете GitLab.com или GitLab Dedicated, можете выдохнуть: инфраструктура GitLab обновлена автоматически, и никаких действий с вашей стороны не требуется.

Для команд на self-managed ситуация острее. Публичные проекты — типичная практика для open-source-репозиториев, внутренних порталов документации, демо-стендов, зеркал пакетов. Именно они уязвимы: GitLab API обрабатывает публичные объекты без токена, и ошибочный путь авторизации в GraphQL-директивах открывал мутации для всех.

Затронутые версии: все GitLab CE/EE от 18.2 до 18.11.10 включительно, от 19.0 до 19.0.7, от 19.1 до 19.1.5, от 19.2 до 19.2.3. Исправленные версии: 18.11.11, 19.0.8, 19.1.6, 19.2.4. Если вы не знаете точной версии своего GitLab — это отдельный звонок: отсутствие инвентаризации инфраструктуры само по себе риск.

Контекст: третья GraphQL-уязвимость GitLab за год

CVE-2026-19478 — не первая и не вторая критическая проблема в GraphQL-слое GitLab в 2026 году. Паттерн показателен: GraphQL-интерфейс стал главной поверхностью атаки на платформу. В отличие от REST, GraphQL по своей природе предоставляет единую точку входа с гибкими мутациями; ошибки авторизации в нём системно сложнее обнаружить классическими методами тестирования — именно поэтому они повторяются.

В Security-отчётах исследователей, представленных на Black Hat 2026, эта проблема описана как архитектурный паттерн: API-шлюз принимает все запросы, а проверка прав объекта делегируется каждому резолверу — и один пропущенный случай открывает весь граф. Это не специфика GitLab, это общая проблема GraphQL-архитектур с недостаточным полевым контролем доступа (field-level authorization).

Для DevOps-команд, которые строят внутренние платформы на GraphQL, урок очевиден: unit-тесты резолверов не закрывают авторизационный слой — нужны интеграционные проверки с неаутентифицированными и минимально-привилегированными запросами к каждой мутации.

Что делать прямо сейчас

Если у вас self-managed GitLab, порядок действий прямолинеен:

Определите версию: gitlab-rake gitlab:env:info или Admin Area → Help в веб-интерфейсе. Если версия ниже исправленной порога — обновляйтесь немедленно, не дожидаясь планового окна.

Обновитесь до исправленной версии по своей ветке: 18.11.11, 19.0.8, 19.1.6 или 19.2.4. Обновление GitLab по пакетному менеджеру занимает обычно 5–15 минут с сохранением данных; предварительный бэкап данных и тест в стейджинге — стандартная практика.

Если немедленное обновление невозможно (заморозка релизов, согласование), временная мера — ограничить доступ к GraphQL-эндпоинту на уровне nginx или Cloudflare WAF, требуя аутентификации для всех запросов к /api/graphql. Это снизит риск, но не закроет его полностью.

Проверьте логи GitLab на аномальные GraphQL-запросы с пустым токеном авторизации (заголовок Authorization отсутствует или пуст) и мутациями на удаление/изменение проектов. Если такие запросы есть — оцените, были ли они успешными.

Обновите инвентарь версий GitLab во всех окружениях: dev, staging, CI, зеркала. Уязвимость не делает исключений для «внутренних» инсталляций, если у них есть публичные проекты.

Часто задаваемые вопросы

Затронут ли GitLab.com? Нет. GitLab.com и GitLab Dedicated обновлены автоматически. Действия требуются только для self-managed-установок.

Нужен ли атакующему аккаунт? Нет. CVE-2026-19478 эксплуатируется без учётной записи и без взаимодействия пользователя — только HTTP-запрос к публичному GitLab-экземпляру.

Затронуты ли приватные проекты? Нет. Уязвимость работает через GraphQL-запрос, который GitLab обрабатывает без аутентификации для публичных объектов. Приватные проекты требуют токена уже на этапе чтения и не попадают в этот путь.

Есть ли активная эксплуатация? На момент выхода патча (17 августа 2026 года) подтверждённых атак не зафиксировано. Однако технический вектор прост, а GitLab — популярная инфраструктурная цель. Откладывать патчинг не стоит.

Какой приоритет у этого обновления? Критический. CVSS 9.4, внеплановый выпуск патча, массовое распространение уязвимых версий — GitLab сам квалифицировал это как emergency patch.

Источники

Help Net Security — Critical GitLab flaw allows attackers to modify or delete public projects (CVE-2026-19478), 18 августа 2026 года.

The Hacker News — Critical GitLab GraphQL Flaw Could Let Unauthenticated Attackers Delete Public Projects, 2026.

SecurityWeek — GitLab Patches Critical Code Injection Vulnerability, 2026.

Security Affairs — GitLab Patches Critical Unauthenticated GraphQL Vulnerability, 2026.