Критическая уязвимость Collabora CVE-2026-110447 позволяла без авторизации выполнять команды на сервере и уже использовалась для установки веб-шеллов на Nextcloud. Проблема касается встроенного приложения Collabora Online — Built-in CODE Server, а не всех инсталляций офисного пакета; для российских команд это ещё один повод проверить, какие «удобные встроенные» компоненты живут рядом с корпоративным облаком.
Атаки начались не позднее 10 сентября, хотя публичный бюллетень и идентификатор CVE появились лишь 14 октября, сообщает BleepingComputer. За это время злоумышленники успели получить почти месяц форы: исправление попало в код 9 сентября, версия приложения 26.4.303 вышла 11 сентября, а формальное описание риска появилось более чем через четыре недели.
Проблема находится в приложении richdocumentscode, которое запускает встроенный сервер Collabora CODE для редактирования офисных документов в Nextcloud. Через запрос к endpoint proxy.php атакующий может внедрить команду операционной системы. Логин, пароль и действия пользователя не требуются — достаточно, чтобы приложение было доступно из сети и выполнялись условия для эксплуатации.
Важная деталь: встроенный CODE-сервер должен быть остановлен. Это возможно после перезапуска хоста, обновления Nextcloud или приложения, аварийного завершения процесса. Иными словами, привычное обслуживание системы может создать окно для атаки именно в момент, когда администратор ожидает, что сервер становится безопаснее. После выполнения команды злоумышленники, по сообщениям администраторов, размещали PHP-веб-шеллы и искали базы с паролями, артефакты менеджеров паролей и криптокошельки.
Отдельные пользователи также сообщили о возможном использовании бага операторами вымогательского ПО. Независимого подтверждения этой части истории у BleepingComputer нет, поэтому называть CVE-2026-110447 «ransomware-уязвимостью» преждевременно. Но сам сценарий с веб-шеллом достаточно плох: он превращает сервис совместной работы в точку закрепления внутри инфраструктуры и даёт атакующему время на дальнейшую разведку.
Кого затрагивает и что делать администраторам
Под риском находятся версии richdocumentscode до 26.4.303. При этом уязвимость Collabora не относится к отдельным серверам Collabora Online, развёрнутым самостоятельно, в Docker либо через RPM/DEB-пакеты. По данным Collabora, не затронут и Nextcloud All-in-One. Это не повод автоматически вычёркивать свою установку из списка проверки: ключевой вопрос — используется ли именно опциональное встроенное приложение Built-in CODE Server.
Приоритетный шаг — обновить richdocumentscode до версии 26.4.303 или новее. Если встроенный сервер не нужен, его следует удалить. Простого отключения недостаточно: вендор отдельно предупредил, что деактивация приложения не устраняет риск. Для администраторов это повод проверить не только версию пакета, но и фактическое состояние приложения, доступность proxy.php извне, журналы запросов с 10 сентября и неожиданные PHP-файлы в каталогах Nextcloud.
Командам ИБ стоит рассматривать сервер как потенциально скомпрометированный, если он оставался уязвимым в указанный период и был доступен из интернета. Минимальная реакция — поиск веб-шеллов и аномальных процессов, проверка изменений в файлах, ревизия учётных данных и токенов, а также анализ сетевой активности. Обновление закрывает вход, но не удаляет уже установленный бэкдор. Особенно внимательно стоит отнестись к хранилищам секретов и резервным копиям: именно их, судя по сообщениям, искали атакующие.
Месяц между патчем и CVE
Эта история заметна не только техническими деталями. Исследование компании Second Security показывает, что разрыв между появлением публичного исправления и публикацией CVE растёт: медианный интервал в августе достиг 39 дней против 5,1 дня в январе. Исследователи также фиксировали случаи, когда рабочий код эксплуатации появлялся через часы после патча — раньше, чем запись в базе CVE.
Collabora связывает задержку с перегрузкой обработки CVE на GitHub на фоне роста числа отчётов, подготовленных с помощью ИИ. Nextcloud объяснил паузу тем, что обновление уже было доступно в магазине приложений и компания не видела массовой эксплуатации. Логика понятна: дать пользователям время на патч. Но на практике отсутствие CVE усложняет работу тем, кто строит автоматические алерты, ищет индикаторы компрометации и приоритизирует обновления по стандартным идентификаторам.
Для разработчиков и владельцев self-hosted-сервисов вывод неприятный, но полезный: следить нужно не только за CVE-лентой, но и за changelog, security advisory и обновлениями критичных расширений. Патч в публичном репозитории уже подсказывает атакующим, куда смотреть; бюрократическая задержка не делает баг менее эксплуатируемым. Разбор инцидента и данные о временном разрыве между фиксом и публикацией CVE собраны в материале .