Утечка Grafana оказалась не историей про «сложную многоходовку», а про один пропущенный токен в GitHub Actions. После атаки через заражённые npm-пакеты TanStack компания отозвала множество секретов, но одного токена хватило, чтобы злоумышленники добрались до приватных репозиториев. Для любой команды, которая живёт на CI/CD и пакетных зависимостях, это неприятно знакомый сценарий: проблема уже вроде локализована, а хвост всё равно прилетает в продакшен-процессы и внутренние данные.
О деталях инцидента сообщает BleepingComputer. По данным издания, цепочка началась после компрометации десятков пакетов TanStack в рамках кампании Shai-Hulud, которую связывают с хакерами TeamPCP. Вредоносный код в этих пакетах крал учётные данные из окружения разработчиков и CI. Когда один из заражённых пакетов попал в CI/CD-процесс Grafana, встроенный инфостилер сработал уже внутри GitHub-окружения компании и вывел workflow-токены наружу.
Дальше всё развивалось по классике инцидент-менеджмента, только с неприятной оговоркой. Grafana сообщила, что обнаружила вредоносную активность 1 мая 2026 года и сразу запустила план реагирования, включая ротацию GitHub workflow tokens. Но один токен выпал из этого процесса. И именно через него атакующие получили доступ к приватным репозиториям компании. Позже внутри Grafana пересмотрели первоначальные выводы и признали, что один из GitHub workflow, который сначала считали незатронутым, на деле тоже был скомпрометирован.
Это важная деталь не только для понимания самого взлома, но и для оценки зрелости защитных процессов. Утечка Grafana произошла не потому, что компания ничего не заметила или не отреагировала. Наоборот, компрометацию увидели, токены начали отзывать быстро. Сбой случился на более приземлённом уровне: инвентаризация секретов и уверенность, что «этот workflow нас не касается», оказались неточными. В 2026 году именно такие ошибки выглядят опаснее экзотических zero-day: инфраструктура усложняется быстрее, чем команды успевают держать её в голове целиком.
Ранее Grafana уже подтверждала, что злоумышленники похитили исходный код, и заявляла, что платить выкуп не будет. Теперь компания уточнила картину: кроме кода, нападавшие скачали операционную информацию и часть бизнес-данных. Речь, по словам Grafana, идёт об именах и адресах электронной почты деловых контактов, которые используются в профессиональном взаимодействии. Компания отдельно подчёркивает, что это не данные из production-систем и не информация из Grafana Cloud. По текущим результатам расследования, клиентские production-системы и рабочие операции заказчиков затронуты не были.
Для пользователей это, пожалуй, самая практическая часть заявления. Grafana утверждает, что кодовая база во время инцидента не модифицировалась, поэтому версии ПО, которые пользователи скачивали в этот период, считаются безопасными. Дополнительных действий от клиентов пока не требуется. Оговорка «пока» тут, конечно, висит в воздухе, потому что расследование продолжается, а финальная картина supply-chain-инцидентов редко складывается за один апдейт. Но сам факт отсутствия изменений в репозитории важен: это снижает риск второго акта, где компрометация внутренних систем превращается в массовую доставку бэкдора пользователям.
Контекст у этой истории шире одной компании. Атака на TanStack показывает, насколько болезненным остаётся рынок JavaScript-зависимостей и npm-цепочек поставки. Компрометируется не обязательно конечный вендор и даже не его CI напрямую. Достаточно внедриться в популярный пакет, который автоматически подтянется в сборку, тесты или внутренний пайплайн. Дальше вредоносный код работает уже от имени доверенного процесса. Если в окружении лежат токены GitHub, облачные ключи, секреты для публикации или доступы к артефактам, атакующему не нужно изобретать ничего особенно изощрённого. Он просто пользуется тем, что бизнес сам аккуратно подготовил для удобной автоматизации.
Для русскоязычных команд разработки и DevOps отсюда следует несколько неприятно конкретных выводов. Первый: ротация секретов после инцидента должна быть не «массовой», а полной и проверяемой. Формулировка «мы отозвали значительное число токенов» звучит обнадёживающе ровно до момента, когда один оставшийся токен открывает дверь в приватные репозитории. Второй: оценка затронутых workflow не может строиться только на первоначальной гипотезе. Если пайплайн сложный, лучше считать подозрительным всё, что хоть как-то касалось заражённой зависимости, и потом уже сужать периметр. Третий: защищать нужно не только production, но и саму инженерную фабрику — CI, package registry, GitHub Actions, сборочные runner'ы, сервисные аккаунты и корпоративные почтовые данные.
Есть и менее очевидный слой последствий. Даже если клиентские данные и production не тронуты, кража исходников, операционной информации и контактов бьёт по компании сразу в нескольких направлениях. Это дополнительная нагрузка на юридическую и коммуникационную команды, риск таргетированных фишинговых кампаний по деловым контактам, а также потенциальный источник конкурентной или репутационной боли. У supply-chain-атак давно нет узкой специализации: из одной технической точки входа они быстро превращаются в бизнес-инцидент.
Утечка Grafana ещё раз показывает простую вещь: в эпоху автоматизации самый опасный секрет не тот, который сложно украсть, а тот, про который команда забыла после правильной, но неполной реакции. Чем больше компаний завязывают разработку на внешние пакеты и GitHub-автоматизацию, тем меньше смысл обсуждать только «был ли взлом» и тем больше смысл спрашивать, насколько быстро и без слепых зон можно отозвать весь машинный доступ после первого сигнала о компрометации.