Угрозы

В CUPS нашли опасную цепочку уязвимостей: при неудачной настройке сервера возможен удаленный захват системы

Маша Даровская
By Маша Даровская , IT-редактор и автор
В CUPS нашли опасную цепочку уязвимостей: при неудачной настройке сервера возможен удаленный захват системы
Обложка © Anonhaven

В OpenPrinting CUPS раскрыли цепочку уязвимостей, которую при определенной конфигурации можно довести до полной компрометации машины. Речь идет о двух уязвимостях — CVE-2026-34980 и CVE-2026-34990. Но важная деталь в том, что сценарий «удаленный root без пароля» работает не на любой системе с CUPS, а только при выполнении нескольких условий.

Первая уязвимость, CVE-2026-34980, затрагивает OpenPrinting CUPS 2.4.16 и более ранние версии. По описанию advisory, если cupsd опубликован в сети и у него есть общая целевая очередь печати, неавторизованный клиент может отправить задание Print-Job в общую PostScript-очередь без аутентификации. Именно этот шаг открывает путь к удалённому выполнению кода в контексте пользователя lp, то есть службы печати, а не сразу от имени root.

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

Вторая уязвимость, CVE-2026-34990, уже описывается как локальная. По данным NVD, локальный непривилегированный пользователь может заставить cupsd аутентифицироваться на контролируемом злоумышленником локальном IPP-сервисе и получить повторно используемый токен вида Authorization: Local .... Этого достаточно, чтобы отправлять административные запросы на localhost, а затем добиться произвольной перезаписи файлов от имени root. Демонстрационный пример использует этот примитив для подброса фрагмента sudoers и дальнейшего выполнения команд с повышенными привилегиями.

Именно комбинация этих двух багов и делает историю по-настоящему серьезной. Сначала атакующий получает код в контексте lp через сетевую общую очередь, а затем использует второй дефект, чтобы дойти до root. Но удаленный шаг требует уязвимой сетевой экспозиции cupsd, а повышение привилегий — уже локального примитива с утечкой административного токена.

Дополнительно вокруг CUPS всплыл еще один свежий дефект — GHSA-v987-m8hp-phj9, связанный с регистронезависимым сравнением имен пользователей в cupsd. GitHub Advisory объясняет проблему так: в Linux имена пользователей чувствительны к регистру, а CUPS в некоторых проверках авторизации — нет. Из-за этого пользователь с именем, отличающимся только регистром от уже привилегированного, может получить доступ к операциям, которые ему не должны быть доступны. Это не главный элемент цепочки, но важный сигнал: проблемы в CUPS сейчас не ограничиваются одним багом в очередях печати.

Еще одна важная деталь — патчи. На момент публикации исправленные версии публично не указаны. Для GHSA-v987-m8hp-phj9 advisory тоже сообщал, что публичного исправления на тот момент нет. Это означает, что администраторам пока приходится опираться прежде всего на временные меры снижения риска, а не просто ждать обновление из репозитория.

Если CUPS не нужна на сервере, безопаснее всего ее отключить. Если нужна — не публиковать cupsd наружу без необходимости, не держать общие legacy-очереди доступными из сети, требовать аутентификацию для отправки заданий печати и ограничить поведение службы через AppArmor или SELinux. Ведь даже если служба печати окажется скомпрометированной, мандатные политики могут уменьшить последствия и не дать процессу модифицировать критичные системные файлы.

*

CUPS — это стандартная подсистема печати для Linux и других Unix-подобных систем. Она отвечает не только за работу с принтерами, но и за сетевые очереди печати, IPP-взаимодействие и административные операции, поэтому уязвимости в ней могут затрагивать не только рабочие станции, но и серверы.

lp — это системный пользователь, от имени которого часто выполняются процессы печати. Если уязвимость дает код в этом контексте, это еще не root, но уже хороший старт для дальнейшего повышения привилегий. В данной цепочке именно так и происходит.

IPP — Internet Printing Protocol, сетевой протокол печати. В CVE-2026-34990 злоумышленник использует поддельный локальный IPP-сервис, чтобы заставить cupsd раскрыть повторно используемый локальный административный токен.

Root file overwrite — это примитив, при котором атакующий получает возможность перезаписать произвольный файл от имени root. На практике это часто уже почти готовый путь к полному захвату системы, потому что позволяет изменить конфигурацию доступа, сервисные файлы или правила sudo.

Есть новость? Станьте автором.

Мы сотрудничаем с независимыми исследователями и специалистами по кибербезопасности. Отправьте нам новость или предложите статью на рассмотрение редакции.

Вопросы по теме

Что произошло?
В CUPS раскрыли цепочку уязвимостей CVE-2026-34980 и CVE-2026-34990. Первая позволяет получить выполнение кода как lp через сетевую общую очередь печати, вторая — повысить привилегии до root через локальный административный токен.
Это правда удаленный root без пароля?
Не в общем случае. Удаленный шаг без аутентификации возможен только если cupsd опубликован в сети и есть общая PostScript-очередь. Повышение до root появляется уже во второй части цепочки.
Какие версии затронуты?
В описаниях CVE-2026-34980 и CVE-2026-34990 фигурируют CUPS 2.4.16 и более ранние версии. Для связанного advisory про обход авторизации по регистру указаны версии ниже 2.4.17.
Есть ли уже исправления?
На момент публикации доступных advisory публично указанных patched versions для этих багов не было. Поэтому пока основной упор — на ограничения экспозиции и снижение риска конфигурацией.
Что делать администраторам прямо сейчас?
Отключить CUPS там, где она не нужна, не публиковать cupsd наружу, убрать или ограничить общие очереди печати, включить обязательную аутентификацию и дополнительно ограничить службу через AppArmor или SELinux.