Хранилище артефактов, как правило, находится в критическом месте инфраструктуры компании: между сборкой продукта и внешним миром. Через него команды получают зависимости, публикуют собственные пакеты и передают артефакты дальше по цепочке поставки. Если такой сервис недоступен или его содержимое нельзя считать доверенным, то проблема быстро выходит за пределы одной лишь команды DevOps. Останавливаются сборки и поставки программного обеспечения, а вредоносный или уязвимый пакет может попасть во множество проектов.

На этом фоне компаниям особенно неприятно быть зависимыми от версии инструмента, которую сложно обновлять. Именно в таком положении оказалась часть пользователей бесплатной версии Nexus Repository после изменения модели выпуска в начале 2025 года. В этой статье мы разберемся, почему некоторые установки остались на старых ветках и какие критические уязвимости раскрылись в инструменте после этого.

Почему часть установок осталась на старых версиях

Начиная с версии 3.77.0 Sonatype переименовали Nexus Repository OSS в Community Edition и ввели для бесплатной редакции жесткие ограничения. Сначала речь шла о 100 тысячах компонентов и 200 тысячах запросов за сутки. Позже эти пороги снизили до 40 тысяч компонентов и 100 тысяч запросов. При превышении одного из них Nexus перестает принимать новые компоненты, пока показатели снова не опустятся ниже обоих лимитов.

Для небольшой компании это может быть и не особо релевантно. Сами разработчики Sonatype писали, что первоначальные ограничения затрагивали около 5% самых крупных инсталляций. Но у более нагруженных команд появилась развилка: можно сократить использование, перейти на Pro или вовсе не обновлять старую OSS-версию. В обсуждении на форуме Sonatype один из пользователей прямо писал, что остается на 3.76.1, потому что после обновления лимиты станут обязательными.

Есть и другой путь. Открытое ядро Nexus Repository Core по-прежнему можно собирать самостоятельно. Однако в него не входят некоторые форматы, доступные в готовой Community Edition, включая npm, Docker, NuGet и PyPI. Если команда добавляет недостающую функциональность или поддерживает собственную сборку, то вместе с контролем над продуктом она получает и обязанность самостоятельно переносить исправления безопасности.

Данных о том, сколько пользователей выбрали каждый вариант, нет. Поэтому нельзя достоверно сказать, что ограничения оставили на старой версии большинство установок. Однако и тем, кто остался на старой версии, и тем, кто поддерживает собственную сборку, приходится самим следить за исправлениями и переносить их в свою установку.

Критические уязвимости Nexus Repository 3

В официальном разделе бюллетеней Sonatype с момента появления Community Edition опубликованы 27 CVE для Nexus Repository 3. По оценке CVSS 4.0, критическими среди них являются две:

CVE-2026-3199: выполнение кода через создание задач (CVSS 9,4)

Пользователь, которому разрешено создавать задачи, может обойти запрет на административные скрипты и выполнить произвольный код на сервере Nexus. После этого он способен остановить сервис или вмешаться в содержимое репозитория, откуда артефакты расходятся по проектам компании.

Случайная атака без авторизации здесь не сработает. Для эксплуатации нужна учетная запись с правом создавать задачи, но такие разрешения могут быть и у обычного пользователя. Уязвимы версии с 3.22.1 по 3.90.x, а закрыли проблему Sonatype только в 3.91.0.

В бюллетене Sonatype нет сведений об эксплуатации в реальных атаках. Однако для пользователей, которые после появления лимитов остались на 3.76.1, это особенно неприятная комбинация. Их версия входит в уязвимый диапазон, а исправление требует перехода на новую ветку или самостоятельного переноса патча.

CVE-2026-5189: жестко заданные учетные данные OrientDB (CVSS 9,2)

В случае этой уязвимости атакующему уже не нужна учетная запись Nexus. Если внутренний бинарный интерфейс OrientDB доступен по сети, то к базе можно подключиться с жестко заданными учетными данными. Это открывает доступ к содержимому хранилища и позволяет выполнять команды от имени процесса Nexus.

Важно уточнить, что уязвима не каждая старая установка. В обычной одиночной конфигурации бинарный интерфейс OrientDB выключен. Он использовался конкретно в старом режиме кластеризации HA-C (либо его могли включить вручную). 

Установке на H2 или PostgreSQL без сетевого интерфейса OrientDB потенциальная атака не угрожает. Но в старом кластере с доступной OrientDB последствия будут тяжелыми, поскольку злоумышленник сможет менять данные хранилища и выполнять команды без входа в Nexus.

Одного лишь критического рейтинга недостаточно для понимания угрозы

За тот же период Sonatype опубликовала еще 25 CVE для Nexus Repository 3. Некоторые из них позволяют выполнять код, хотя из-за необходимых прав или особенностей конфигурации получили высокий, а не критический рейтинг.

Например, CVE-2026-10748 с оценкой 8,6 по CVSS позволяет пользователю, имеющему право установки лицензии загрузить подготовленный файл и выполнить команды на сервере. В CVE-2026-17603 с оценкой 8,7 код выполняется на установках с H2 через параметр инициализации соединения с базой.

Эксплуатация обеих уязвимостей требует дополнительных условий. Но если нужные права уже выданы или Nexus работает в подходящей конфигурации, то десятые доли CVSS не делают захват сервера менее серьезным.

Приоритет обновления в такой ситуации лучше определять последовательно. Сначала нужно сопоставить установленную версию с уязвимым диапазоном, затем проверить условия атаки в своей конфигурации и права у пользователей, сервисных учетных записей и скомпрометированных агентов. Такой разбор точнее показывает срочность обновления, нежели один цвет метки в бюллетене.

Известные уязвимости остаются основной практической задачей

Недавняя история с JFrog Artifactory хорошо показывает, насколько далеко может зайти автоматизированная атака. Во время внутренней проверки возможностей модели OpenAI нашли и использовали ранее неизвестную уязвимость Artifactory, чтобы выйти из изолированной среды в интернет. OpenAI сообщила JFrog и о других найденных проблемах, а JFrog выпустила исправления для нескольких уязвимостей, которые в цепочке могли привести к критическому сценарию.

Но zero-day были и остаются редким и сложным случаем. Для владельца Nexus повседневная задача проще. Нужно знать текущую версию и тип базы, изучать бюллетени Sonatype, проверять условия эксплуатации и сохранять рабочий путь обновления. Если используется собственная сборка Core, тот же процесс должен включать перенос исправлений и проверку получившегося пакета.

Уязвимость с опубликованным идентификатором, описанием и исправленной версией уже не является неожиданностью. Если после этого Nexus остается без патча, то сбой сборок, подмена артефактов или захват сервера происходят не из-за недостатка информации. Значит, процесс управления уязвимостями в компании просто не сработал.

Подписывайтесь на Codescoring в Telegram, VK, YouTube и Макс.