Уязвимости Artifactory уже используют в реальных атаках: злоумышленники обходят аутентификацию, получают права администратора и ставят Rust-бэкдор на self-hosted серверы. Для русскоязычных команд это не абстрактная история про чужую инфраструктуру, а прямой риск для CI/CD, внутренних репозиториев и цепочки поставки ПО.
По данным BleepingComputer, атаки затрагивают критические и высокоопасные ошибки в JFrog Artifactory. Исследователи Wiz подтвердили эксплуатацию в нескольких средах и описали цепочку из CVE-2026-42018 и CVE-2026-42016. Отдельно фигурирует CVE-2026-82329 — критический обход аутентификации, который компания watchTowr ранее наблюдала в атаках с выпуском администраторских токенов.
Схема выглядит неприятно просто. Сначала атакующие используют CVE-2026-42018, чтобы получить JWT внутреннего анонимного пользователя Artifactory. Это срабатывает даже там, где анонимный доступ отключен, хотя начальные права у такого токена низкие. Затем через CVE-2026-42016, связанную с недостаточной проверкой токенов, права поднимаются до уровня администратора. По наблюдениям Wiz, с 15 августа по 8 сентября 2026 года несколько групп применяли эту связку против доступных из интернета self-hosted инсталляций.
В отдельных случаях путь от первичного доступа до создания учетной записи администратора занимал меньше пяти минут. После этого злоумышленники выпускали долгоживущие access-токены, ставили вредоносные Groovy-плагины для выполнения команд и закреплялись в системе через кастомный бэкдор на Rust с возможностями управления через C2. Rust здесь не магия, а практичный выбор: компактный бинарник, меньше бытовых зависимостей, сложнее быстрый разбор на коленке.
Дальше атака превращалась в привычную инвентаризацию всего ценного. Злоумышленники загружали дополнительные payload-файлы в /dev/shm, /tmp и /var/tmp, добавляли webshell, вытаскивали конфигурацию Artifactory и cluster join keys, просматривали репозитории, токены и пользователей. В новых учетных записях они также прописывали свои SSH-ключи. Для бизнеса это уже не просто компрометация одного сервера, а потенциальный доступ к артефактам сборки, зависимостям и внутренним пакетам.
Самая тревожная цифра в отчете Wiz — от 49% до 62% доступных из интернета инстансов Artifactory могут быть уязвимы хотя бы к одной из трех ошибок. Даже если оценка плавает из-за методологии сканирования, порядок величины неприятный. Artifactory часто стоит рядом с самыми чувствительными процессами разработки: там живут библиотеки, Docker-образы, пакеты, сборочные артефакты и иногда слишком щедро выданные токены. Компрометация такого узла может тихо отравить пайплайн, а не просто положить сервис.
Администраторам рекомендуют срочно обновиться до одной из версий Artifactory или более новых: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 или 7.161.20. После обновления работа не заканчивается. Нужно проверить доступные из интернета инстансы на неожиданные токены, неизвестные администраторские аккаунты, подозрительную активность плагинов и массовые запросы на перечисление пользователей, токенов и репозиториев. Если Artifactory торчит наружу без жесткой необходимости, это хороший момент закрыть доступ только для доверенных систем.
Для разработчиков и платформенных команд главный вывод простой: репозиторий артефактов давно перестал быть скучным складом бинарников. Это часть production-контура, где компрометация может ударить по релизам, контейнерам, зависимостям и доверию к сборкам. Следующий практичный шаг — не ждать постмортема, а проверить версии, токены, плагины и сетевую экспозицию Artifactory до того, как чужой админ-аккаунт появится быстрее, чем успеет открыться утренний стендап.