Утечка GitHub Grafana 2026:
Безопасность токенов для веб-разработчиков

Что произошло: хронология утечки GitHub Grafana

16 мая 2026 года Grafana Labs — компания, стоящая за популярной платформой мониторинга и визуализации данных с открытым исходным кодом — сообщила о серьёзном инциденте безопасности. Злоумышленник получил привилегированный токен GitHub, предоставляющий доступ к их GitHub-среде, и скачал всю приватную кодовую базу компании.

Это сообщение вызвало шок в сообществе разработчиков. Grafana обеспечивает работу дашбордов для более чем 7 000 организаций, включая 70% компаний из списка Fortune 50. Хотя компания подтвердила, что данные клиентов и личная информация не пострадали, этот инцидент поднимает критически важные вопросы о безопасности токенов GitHub, которые должен задать себе каждый веб-разработчик.

Утечка была обнаружена, когда сработал один из тысяч развёрнутых канареечных токенов (canary tokens) Grafana — цифровых ловушек, которые выглядят как настоящие учётные данные. Этот сигнал немедленно уведомил команду безопасности о присутствии злоумышленника в их среде. К тому моменту атакующий уже скачал всю кодовую базу.

Как работала атака: вектор Pwn Request

Атака использовала хорошо известный, но часто неправильно настраиваемый триггер GitHub Actions — pull_request_target. Понимание этой уязвимости критически важно, потому что это тот же класс неправильной конфигурации, который привёл к атакам на цепочку поставок npm в инциденте Mini Shai-Hulud — и к бесчисленному множеству других утечек.

pull_request vs pull_request_target

GitHub Actions предлагает два способа запуска workflow при pull request:

pull_request запускает workflow в контексте форк-репозитория. У него нет доступа к секретам целевого репозитория. Это безопасный вариант по умолчанию — злонамеренный автор PR не может украсть секреты, потому что workflow работает в изолированном окружении.

pull_request_target запускает workflow в контексте целевого репозитория. У него есть полный доступ к секретам репозитория: токенам GitHub, облачным учётным данным, API-ключам и всему остальному в хранилище секретов Actions. Этот триггер предназначен для workflow, которым требуется доступ на запись к репозиторию — например, для комментирования PR, добавления меток и т.д.

Опасность возникает, когда workflow с pull_request_target проверяет код из PR и выполняет скрипты из него. Поскольку workflow работает в контексте целевого репозитория, любой вредоносный код в PR получает доступ ко всем секретам.

Опасный паттерн workflow

Вот опасный паттерн, который ищут атакующие:

# ОПАСНО — никогда так не делайте
name: PR Workflow
on:
  pull_request_target:
    types: [opened, synchronize]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}  # ❌ Проверяет код из PR

      - name: Run CI
        run: |
          npm ci
          npm test  # ❌ Автор PR контролирует, что здесь выполняется
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}  # ❌ Секреты доступны непроверенному коду
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_KEY }}    # ❌ Облачные учётные данные под угрозой

Злоумышленник отправляет PR с вредоносным кодом в скриптах package.json или конфигурации CI, который извлекает переменные окружения. Когда workflow запускается по триггеру pull_request_target, он проверяет код злоумышленника, выполняет его, и атакующий получает секреты.

Как злоумышленник извлёк токен

Основываясь на анализе StepSecurity апрельского инцидента Grafana 2025 года (который использовал аналогичный вектор) и майском раскрытии 2026 года, цепочка атаки, вероятно, выглядела так:

1. Разведка: Злоумышленник нашёл публичный репозиторий Grafana с workflow pull_request_target, который проверял код из PR и выполнял скрипты из него.
2. Отправка вредоносного PR: Злоумышленник форкнул репозиторий и отправил pull request, содержащий обфусцированный код кражи учётных данных.
3. Автоматический запуск: Workflow pull_request_target автоматически запустился на PR в контексте целевого репозитория с доступом к его секретам.
4. Извлечение учётных данных: Вредоносный код извлёк GITHUB_TOKEN и другие доступные секреты из окружения runner-а.
5. Эксфильтрация: Украденный токен был отправлен на сервер злоумышленника через HTTP-запрос или DNS-запрос.
6. Скачивание кодовой базы: Имея привилегированный токен, злоумышленник клонировал приватные репозитории Grafana и скачал всю кодовую базу.
7. Вымогательство: Злоумышленник (заявивший о связи с CoinbaseCartel) потребовал выкуп в обмен на публикацию украденного исходного кода.

Кто такой CoinbaseCartel?

Группа вымогателей, взявшая на себя ответственность за атаку на Grafana — CoinbaseCartel, появилась в сентябре 2025 года. По данным исследователей угроз, в неё входят участники ShinyHunters и Lapsus$ — двух известных киберпреступных групп.

CoinbaseCartel управляет сайтом утечки данных (DLS), где они публикуют список жертв и угрожают опубликовать украденные данные, если выкуп не будет выплачен. На их портале значатся более 100 жертв, и, по их собственным словам, они «отстают с публикацией многих утечек» — что предполагает, что их активность по взломам превышает то, что было публично раскрыто.

Почему Grafana отказалась платить выкуп

Grafana Labs публично отказалась платить выкуп, сославшись на официальную позицию ФБР по выплатам выкупов. В своём заявлении компания сказала:

«Основываясь на нашем операционном опыте и опубликованной позиции ФБР, которая отмечает, что выплата выкупа не гарантирует возврат данных и только стимулирует дальнейшую преступную деятельность, мы определили, что правильный путь — не платить выкуп.»

Это важный прецедент. Крупная компания, создающая open-source инфраструктуру, используемую 70% компаний Fortune 50, выбрала трудный, но принципиальный путь. Это чёткий сигнал атакующим: вымогательство кодовой базы не будет вознаграждено.

Как защитить токены GitHub и CI/CD пайплайны

Утечка Grafana — это не экзотическая zero-day уязвимость. Она эксплуатирует ошибку конфигурации, которая встречается в тысячах репозиториев. Вот практическая стратегия защиты для каждого разработчика и команды.

1. Аудит триггеров workflow

Проверьте каждый файл workflow в вашем репозитории:

# Найдите все использования pull_request_target
grep -rn "pull_request_target" .github/workflows/

Для каждого результата:

• Используйте pull_request — он работает в контексте форка без доступа к секретам
• Если pull_request_target необходим, никогда не проверяйте код из PR:

# БЕЗОПАСНО — не проверяет и не выполняет код из PR
name: PR Labeler
on:
  pull_request_target:
    types: [opened, labeled]

jobs:
  label:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/labeler@v5
        with:
          repo-token: ${{ secrets.GITHUB_TOKEN }}

2. Используйте fine-grained токены

GitHub отказался от классических токенов с полным доступом repo в 2025 году. Если вы всё ещё используете их, переключитесь на fine-grained токены (FGPATs):

• Ограничьте токены конкретными репозиториями
• Предоставьте минимальные разрешения — доступ только на чтение, если запись не требуется
• Установите дату истечения — никогда не используйте токены без срока действия
• Используйте токены на уровне репозитория, а не организации

3. Принцип наименьших привилегий в CI/CD

Каждый workflow job должен запрашивать минимальные необходимые разрешения:

name: Secure Workflow
on:
  push:
    branches: [main]

# Явно укажите минимальные разрешения
permissions:
  contents: read
  issues: none
  pull-requests: none
  checks: write
  packages: none

jobs:
  test:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

4. Используйте OpenID Connect (OIDC) для облачных развёртываний

Вместо хранения долгоживущих учётных данных AWS, Azure или GCP в GitHub Secrets, используйте OpenID Connect (OIDC) для генерации краткосрочных токенов на каждый запуск workflow:

name: Deploy with OIDC
on:
  push:
    branches: [main]

permissions:
  id-token: write   # Требуется для OIDC
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsDeployRole
          aws-region: us-east-1

      - name: Deploy
        run: aws s3 sync ./build s3://my-bucket

5. Сканирование секретов и мониторинг

• Включите GitHub Advanced Security — защита от публикации блокирует коммиты с секретами
• Используйте сканирование секретов — обнаруживайте существующие токены в репозиториях
• Разверните канареечные токены — именно они помогли Grafana обнаружить атаку
• Мониторьте журналы аудита — следите за необычными паттернами доступа

6. Требуйте подтверждения для workflow из форков

В настройках репозитория включите «Require approval for all external contributors»:

• Перейдите в Settings → Actions → General → Fork pull request workflows
• Выберите «Require approval for all external contributors»

7. Немедленная ротация секретов при подозрении

Если вы подозреваете, что какой-либо токен скомпрометирован, выполните этот чеклист:

• Отзовите скомпрометированный токен — удалите его из GitHub, npm и т.д.
• Смените все секреты, доступные через этот токен — перегенерируйте ключи API
• Проверьте журналы доступа — изучите логи аудита GitHub и облачных провайдеров
• Проверьте недавние изменения кода — ищите несанкционированные коммиты
• Уведомите заинтересованные стороны — следуйте плану реагирования на инциденты

Связь с атаками на цепочку поставок

Утечка Grafana — не изолированный инцидент. Это часть более широкого тренда, где атакующие нацеливаются на CI/CD пайплайны как на вектор атаки. Атака на npm Mini Shai-Hulud — которая скомпрометировала 170+ npm-пакетов, включая TanStack, Mistral AI и UiPath — использовала другой вектор входа (скрипты npm install), но была нацелена на то же самое: учётные данные, доступные в CI/CD-среде.

Для более глубокого погружения в то, как работают атаки на цепочку поставок на уровне npm, включая технический разбор preinstall-хуков и механизмов кражи учётных данных, смотрите моё руководство: Mini Shai-Hulud: атака на цепочку поставок npm 2026.

Вместе эти инциденты говорят о ясном тренде: CI/CD пайплайны — это новый периметр. Будь то через скомпрометированные npm-пакеты или неправильно настроенные GitHub Actions, атакующие всё чаще нацеливаются на инфраструктуру автоматизации, которой разработчики доверяют по умолчанию.

Что это значит для разработчиков и владельцев бизнеса

Если вы разработчик или владелец бизнеса, нанимающий разработчика, утечка Grafana подчёркивает критический сдвиг в приоритетах безопасности.

Для разработчиков

• Проверьте свои GitHub Actions workflow уже сегодня. Каждый триггер pull_request_target — потенциальная уязвимость.
• Используйте fine-grained токены с минимальными разрешениями.
• Переключитесь на OIDC для облачных развёртываний.
• Включите шлюзы одобрения для PR из форков.
• Следите за рекомендациями GitHub по безопасности.

Для владельцев бизнеса

При найме веб-разработчика безопасность CI/CD должна быть частью разговора. Спросите о:

• Управлении токенами — используют ли они fine-grained токены? Регулярно ли меняют секреты?
• Безопасности workflow — знают ли они об уязвимости Pwn Request? Аудитируют ли свои Actions workflow?
• Защите цепочки поставок — есть ли у них процесс реагирования на инциденты?

Когда я создаю веб-приложения для клиентов, безопасность CI/CD встроена в процесс с первого дня — правильно ограниченные токены, проверенные триггеры workflow, OIDC для облачных развёртываний и регулярные аудиты безопасности. Если вы ищете разработчика, который серьёзно относится к безопасности пайплайнов, давайте обсудим ваш проект.

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

Оставайтесь в безопасности — стройте с уверенностью

Утечка GitHub Grafana — это сигнал тревоги для всей экосистемы разработки. Безопасность CI/CD пайплайнов больше не опция — это фундаментальное требование для любого серьёзного веб-проекта. Один неправильно настроенный триггер workflow может открыть доступ ко всей вашей кодовой базе, а инструменты для предотвращения этого бесплатны и хорошо документированы.

Если вы создаёте веб-приложение и хотите разработчика, который относится к безопасности CI/CD как к приоритету первого уровня — свяжитесь со мной. Я full-stack разработчик с 20+ годами опыта, и каждый мой проект строится с усиленными CI/CD пайплайнами: правильно ограниченные токены, проверенные триггеры workflow, OIDC для облачных развёртываний и регулярные аудиты безопасности.