Nextcloud: уязвимость во встроенном Collabora, ставят бэкдоры

Во встроенном сервере Collabora Online для Nextcloud нашли уязвимость CVE-2026-110447. Через неё злоумышленники ставили на серверы веб-шеллы — небольшие скрипты для удалённого управления. Первую атаку зафиксировали 10 сентября 2026 года, запись CVE прямо указывает на использование в сентябре и октябре. Исправление — в версии 26.4.303. Если вы держите Nextcloud со встроенным редактором документов, проверьте сервер.
Что произошло
Collabora Online — редактор документов, который встраивается в Nextcloud. Приложение называется «Collabora Online - Built-in CODE Server». По разбору, уязвимость в обработке пути запроса позволяла выполнить команду на сервере, когда локальный сервер документов был недоступен — например, во время перезапуска или обновления. Злоумышленники использовали это, чтобы оставить на сервере веб-шелл.
| Параметр | Значение |
|---|---|
| Приложение | richdocumentscode (встроенный сервер Collabora в Nextcloud) |
| Уязвимые версии | все до 26.4.303 |
| Исправлено | 26.4.303 (выпуск 11 сентября) |
| Не затронуты | отдельный сервер Collabora, приложение richdocuments без встроенного |
| Атаки | с 10 сентября 2026 года |
Важная деталь: более новая версия 26.4.402 на части конфигураций не запускалась, и администраторы возвращались к 26.4.303. Исправленные версии требуют Nextcloud 30 или новее; на Nextcloud 29 и старше установить их нельзя.
Кого касается
Тех, кто держит Nextcloud и использует именно встроенный сервер Collabora. Отдельно установленный Collabora и приложение Nextcloud Office без встроенного сервера не затронуты.
Nextcloud популярен как замена зарубежным облакам для хранения документов. Если вы ставили его сами или с подрядчиком и включали редактор документов, проверка обязательна.

Что делать
- Обновите приложение richdocumentscode до 26.4.303 или новее, либо удалите его. Простое отключение уязвимость не закрывает.
- На Nextcloud 29 и старше сначала обновите сам Nextcloud до 30 или удалите приложение.
- Проверьте каталог приложения на посторонние PHP-файлы. По данным разбора, веб-шеллы имели имена вида `shx*.php` в папке `apps/richdocumentscode`.
- Просмотрите журналы доступа минимум с 10 сентября на обращения к `proxy.php?status` с подозрительными символами в пути.
- Если нашли посторонние файлы или следы — считайте сервер скомпрометированным: лечите по плану восстановления, меняйте пароли и ключи.
Наше мнение
Nextcloud — хороший способ держать документы на своём сервере, но у него тот же недостаток, что у любого самостоятельного решения: за обновлениями нужно следить. Эта история показывает типичную ловушку: исправление вышло 11 сентября, а первая атака — 10 сентября, и в заметках к выпуску оно не было отмечено как исправление безопасности. То есть даже внимательный администратор мог его пропустить.
Мы советуем для Nextcloud и подобных систем подписаться на бюллетени безопасности и обновлять не только ядро, но и приложения. Отдельно проверьте, какие приложения включены: часто их ставят «на пробу» и забывают, а каждое — это дополнительный код с доступом к серверу.
Как заметить веб-шелл
Веб-шелл — это скрипт, который даёт удалённый доступ к серверу через обычный веб-запрос. Признаки: незнакомые PHP-файлы в папках приложения и загрузок, особенно со случайными именами; обращения к таким файлам в журналах; исходящие соединения с незнакомыми адресами. Регулярная проверка целостности файлов и мониторинг изменений помогают заметить такое раньше, чем злоумышленник успеет закрепиться.
Почему self-hosted требует дисциплины
Эта история — хороший пример того, чем свой сервер отличается от облачного сервиса. В облаке провайдер сам закрывает уязвимости, и вы можете не узнать о них вовсе. На своём Nextcloud ответственность на вас: вышло исправление — нужно его заметить и поставить, причём не только для ядра, но и для каждого приложения.
Мы не отговариваем от self-hosted: контроль над данными того стоит, особенно с учётом требований хранить персональные данные в России. Но за этот контроль нужно платить вниманием. Минимальный набор: подписка на бюллетени безопасности, регулярные обновления ядра и приложений, резервные копии с запасом по времени и мониторинг изменений файлов.
Резервные копии здесь особенно важны. Если сервер скомпрометировали через веб-шелл, восстановление имеет смысл только из копии, сделанной до атаки. Поэтому копии должны храниться несколько поколений, а не перезаписываться каждый день поверх предыдущей. Если своими силами это тянуть некому, разумно вынести сопровождение сервера на внешнюю поддержку — это дешевле, чем восстановление после взлома.
Что делать прямо сегодня
Если у вас есть Nextcloud со встроенным редактором, не откладывайте: откройте список приложений, посмотрите версию richdocumentscode и обновите её или удалите. Затем бегло проверьте папку приложения на незнакомые файлы и журналы за сентябрь. Эти действия занимают полчаса и закрывают конкретную, уже используемую в атаках уязвимость.
Материалы для проверки
Если нужна реализация
Состав работ зависит от текущего проекта и подтверждённой причины. Можно обсудить диагностику или разработку подходящего решения.
Вопросы и ответы
У меня Nextcloud, но без редактора документов. Я в опасности?
Нет, если не установлен встроенный сервер Collabora (richdocumentscode). Отдельный Collabora и приложение Nextcloud Office без встроенного сервера не затронуты.
Можно ли просто отключить приложение?
Нет. Отключение не закрывает уязвимость. Нужно обновить richdocumentscode до 26.4.303 или удалить его полностью.
У меня старый Nextcloud. Как обновиться?
Исправленные версии требуют Nextcloud 30 или новее. Сначала обновите ядро Nextcloud, затем приложение. На версиях 29 и старше встроенный сервер лучше удалить.
Как понять, что сервер уже взломали?
Ищите посторонние PHP-файлы со случайными именами в папках приложения, обращения к ним в журналах и исходящие соединения с незнакомыми адресами. При сомнениях проведите аудит.
Что делать при подтверждённом взломе?
Лечите по плану восстановления после взлома: изолируйте сервер, удалите веб-шеллы, смените все пароли и ключи, проверьте другие сервисы на сервере и при необходимости восстановите из чистой копии.
Почему исправление не было помечено как обновление безопасности?
По разбору, заплатку внесли в код 9 сентября, но в заметках к выпуску 26.4.303 не описали как исправление безопасности. Это частая ситуация, поэтому для таких систем важно подписаться на бюллетени, а не полагаться только на заметки к выпускам.