Атакующие использовали уязвимости JFrog Artifactory, чтобы получать права администратора на self-hosted-серверах и оставлять бэкдоры в инфраструктуре сборки. По данным The Hacker News, компания Wiz наблюдала такие атаки с 15 августа по 8 сентября; обе дыры к тому моменту уже были исправлены JFrog, поэтому под удар попали прежде всего не обновленные инсталляции.
История неприятна не только владельцам Artifactory. Этот репозиторий часто стоит в середине DevOps-конвейера: из него CI/CD забирает пакеты, образы и артефакты, которым затем доверяют сборки, тесты и продакшен-деплой. Если злоумышленник становится администратором такого узла, он получает не просто красивую панель управления, а удобную позицию для атаки на цепочку поставки ПО.
В атаке связали две ошибки: CVE-2026-42018 и CVE-2026-42016. Первая позволяла без входа в систему получить токен внутреннего анонимного пользователя, даже если anonymous-доступ был отключен. Вторая давала возможность обменять токен с низкими правами на токен с административной областью действия: Artifactory проверял подпись и издателя токена, но недостаточно проверял, что именно этому токену разрешено делать.
По наблюдениям Wiz, сценарий повторялся почти одинаково. Сначала шел неаутентифицированный запрос к token endpoint, после чего сервер отдавал токен для внутреннего anonymous-пользователя. Затем этот токен отправляли в endpoint создания токенов и получали уже администраторский токен. В логах такие действия выглядели как активность token:anonymous, а не как операции нормальной учетной записи. В отдельных случаях путь от первого запроса до создания нового администратора занимал меньше пяти минут. Для команды ИБ это тот самый момент, когда слово anonymous в логах внезапно перестает звучать безобидно.
Цепочка работала не на всех версиях подряд: сервер должен был быть уязвим сразу к обеим ошибкам, а исправление любой из них ломало атаку. Для CVE-2026-42016 JFrog указывает исправление в версии 7.133.11; ветки 7.146 и 7.161 не входят в опубликованный диапазон поражения этой ошибки. CVE-2026-42018 была закрыта в ветке 7.146 еще 28 апреля, а в ветке 7.133 — 12 августа, за три дня до первых атак, которые видела Wiz. Это важная деталь: речь не о zero-day в момент эксплуатации, а о классическом окне между патчем и реальным обновлением у клиентов.
Получив админские права, атакующие действовали по-разному. Wiz не связывает все эпизоды с одним актором. На скомпрометированных серверах создавали новые администраторские учетные записи и оставляли их на месте. Через механизм Groovy-плагинов Artifactory устанавливали вредоносные плагины, что давало выполнение кода на сервере. В некоторых случаях через endpoint выполнения плагинов запускали shell-команды, смотрели файлы и окружение. Еще один сценарий включал dropper: он скачивал бинарник по HTTP, записывал его в доступный на запись каталог вроде /tmp и открывал канал управления. Wiz также видела кастомный Rust-бэкдор с функциями command-and-control в нескольких инцидентах.
Отдельно в той же волне фигурирует CVE-2026-82329 — критическая уязвимость с оценкой 9.8 CVSS. Она эксплуатировалась отдельно с 1 по 8 сентября и опасна тем, что не требует связки с другой ошибкой: неаутентифицированный атакующий с сетевым доступом может получить администраторские привилегии на дефолтной конфигурации Artifactory. По опубликованным данным JFrog, затронуты шесть веток релизов до 7.161 включительно, а исправления вышли в 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 и 7.161.20.
Масштаб интереса к этой дыре быстро стал заметен в сетевом шуме. CISA добавила CVE-2026-82329 в каталог известных эксплуатируемых уязвимостей 2 сентября и поставила федеральным агентствам США срок исправления до 5 сентября. Fastly писала, что публичный exploit появился 1 сентября, после чего началось сканирование; 2 сентября компания насчитала около 406 тысяч попыток эксплуатации в своем трафике. Это именно попытки, а не подтвержденные взломы, но для админов Artifactory разница скорее философская, если сервер смотрит в интернет и давно не обновлялся.
Для команд, которые держат Artifactory сами, главный список действий короткий, но неприятный. Нужно обновить сервер до исправленной версии своей ветки. Для JFrog Cloud, по заявлению компании, дополнительных действий не требуется. Тем, кто не может быстро закрыть CVE-2026-82329 обновлением, JFrog предлагает workaround: сгенерировать случайное значение и добавить его как дополнительный join key в system.yaml, чтобы при регистрации сервисов принимались только свои ключи. Для двух связанных уязвимостей JFrog Artifactory временного обходного пути в изученных advisories не указано.
Патч, впрочем, не стирает следы уже состоявшегося компромисса. Созданные атакующими админские учетные записи не исчезнут после обновления, а уже выпущенные токены не отзовутся сами. Fastly отдельно предупреждала: если сервер был доступен извне, его разумно рассматривать как потенциально скомпрометированный. Практический минимум — отозвать access tokens, выпущенные с 28 августа, проверить список администраторов, репозитории, плагины, изменения конфигурации и ротацию platform join key, если есть риск, что его читали.
Самые полезные сигналы для поиска — действия, которые не соответствуют правам аккаунта: internal anonymous user или низкопривилегированная учетная запись создает токены, перечисляет пользователей, читает или пишет плагины. Еще один маркер — новые админские аккаунты со странными именами. Wiz видела имена в стиле 0xTerror, svc_ и labadmin_ со случайными символами, но попадались и более маскировочные варианты: jfrog-distribution, jfrog-insight, repo-service. Это ровно тот случай, когда «похоже на сервисный аккаунт» не должно быть аргументом в пользу доверия.
Эта история снова показывает, почему инфраструктура сборки стала отдельной мишенью, а не скучной внутренней plumbing-зоной. Для разработчиков и платформенных команд уязвимости JFrog Artifactory означают простую вещь: репозиторий артефактов надо защищать как production-систему с секретами, аудитом, ротацией токенов и быстрым patch management. Следующий спор в компаниях будет не о том, надо ли обновлять такие узлы, а о том, кто имеет право держать их без инвентаризации, мониторинга и понятного владельца.