Roundcube и CVE-2025-49113: как закрыть дыру в веб-почте

CVE-2025-49113 позволяет выполнить код на сервере через уязвимый Roundcube после входа в веб-почту. Первые исправления вышли в 1.5.10 и 1.6.11, но сегодня я выбираю актуальную поддерживаемую версию. Ниже — как проверить установку, подготовить резервную копию, обновить приложение и отдельно оценить признаки уже случившегося взлома.

Что позволяет CVE-2025-49113 и какие версии затронуты

Я начинаю с условий атаки. CVE-2025-49113 — выполнение кода после аутентификации из-за десериализации объектов PHP. NVD связывает проблему с непроверенным параметром _from в program/actions/settings/upload.php. Атакующему нужен действующий доступ к уязвимому веб-клиенту; администраторская учётная запись для этого не требуется. Чужой украденный пароль — возможный способ получить такой доступ, но не обязательная часть определения уязвимости. В защите корпоративной почты я рассматриваю и обновления приложения, и защиту учётных записей: одно не заменяет другое.

При успешной эксплуатации код выполняется с правами процесса, обслуживающего приложение. Это серьёзно: под угрозой оказываются доступные ему файлы, секреты и подключения. Но автоматические права системного администратора из определения RCE не следуют. Итог зависит от изоляции и разрешений. Roundcube получает письма по IMAP и отправляет по SMTP; это веб-клиент, а не вся почтовая система. Поэтому я отдельно проверяю его, почтовые службы и доступы между ними. Формула «один ящик гарантирует полный захват сервера» эффектная, только технически негодная.

В описании NVD указаны Roundcube до 1.5.10 и ветка 1.6.x до 1.6.11. Значит, старую установку 1.4 нельзя объявить защищённой только потому, что в короткой новости названы две более новые ветки. Разработчики выпустили первые исправления 1 июня 2025 года. Версии 1.5.9 и 1.6.10 без исправления относятся к уязвимым исходным релизам. Для пакетов дистрибутива я проверяю полный номер сборки и бюллетень поставщика: исправление могут перенести в пакет с прежним основным номером. Сравнивать только первые цифры здесь недостаточно.

Я не выдаю условие входа за защиту от автоматизированных атак. Если доступ уже получен, дальнейшие запросы тоже можно автоматизировать. При этом само наличие старого приложения ещё не доказывает успешную эксплуатацию на конкретном сервере. Мой вывод практический: подтверждённо уязвимую установку нужно обновить, а при признаках постороннего доступа — дополнительно расследовать инцидент. Патч и расследование отвечают на разные вопросы. Первый закрывает известную ошибку; второе выясняет, что успели сделать до её устранения.

• Условие: доступ к учётной записи в уязвимом Roundcube.
• Последствие: выполнение кода в пределах прав процесса приложения.
• Первые исправления: 1.5.10 и 1.6.11; это исторические пороги для данной CVE.
• Для пакета поставщика нужен его бюллетень, а не только номер исходного релиза.

Как узнать версию работающего Roundcube

Сначала я нахожу установку, на которую направлен запрос веб-сервера. На диске может лежать несколько каталогов: действующий, старый после переноса и тестовый. Проверить самый знакомый путь и закрыть заявку — удобный способ обновить музейный экспонат. Я сопоставляю настройки сайта с каталогом приложения, а в контейнерной схеме — с запущенным контейнером и подключёнными томами. Доступ к файлам нужен соответствующий задаче; запускать всё от системного администратора ради чтения одной строки бессмысленно.

В стандартной структуре Roundcube константа RCMAIL_VERSION объявлена в program/include/iniset.php. Из найденного корня установки я читаю именно её:

grep -n RCMAIL_VERSION program/include/iniset.php

Команда только показывает строку и ничего не меняет. У исходной сборки значение может содержать суффикс разработки — тогда я дополнительно устанавливаю происхождение сборки. Файл config/config.inc.php содержит настройки, поэтому искать в нём достоверную версию ядра не стоит. Универсальную команду приложения для получения версии я здесь не придумываю.

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

В Docker я проверяю работающий контейнер, его образ и файлы приложения с учётом томов. Список локальных образов показывает, что скачано, а не что обслуживает почту. Тег latest тоже не доказывает, что запущенный экземпляр обновлён: получение нового образа и замена контейнера — отдельные действия. При планировании обновления я записываю выбранный тег и идентификатор образа. Это помогает воспроизвести установку и подготовить откат. Само слово latest пока никого не обновило; у него даже нет такой должности.

• Найти фактический каталог сайта или работающий контейнер.
• Прочитать RCMAIL_VERSION в файлах действующей установки.
• Для пакета проверить полный номер сборки и бюллетень поставщика.
• Зафиксировать источник установки, плагины и подключённые тома.

До какой версии обновлять Roundcube сейчас

Я разделяю дату появления исправления и выбор версии для сегодняшнего обслуживания. В экспертной базе правильно названы 1.5.10 и 1.6.11: они устранили CVE-2025-49113. Но формулировка «обновитесь до них и получите безопасный сервер» устарела. После этих релизов выходили другие исправления безопасности. Установка старого патча закрывает конкретную известную ошибку, а не все проблемы приложения за последующие месяцы. Перед работой я смотрю официальный список релизов, а не копирую номер из прошлогодней памятки.

На дату проверки, 25 октября 2026 года, разработчики уже выпустили 1.6.20 и 1.7.5; объявление датировано 19 октября. После выхода 1.7.0 10 мая 2026 года ветка 1.6 перешла в режим LTS, а поддержка 1.5 прекращена. Для самостоятельной установки я рассматриваю актуальную 1.6 LTS либо 1.7 с учётом совместимости. Для пакета или панели проверяю поддерживаемый ими путь. При чтении статьи позже эти номера нужно снова сверить: календарь исправлений не обязан останавливаться вместе с публикацией.

Для существующей ветки 1.6 я сначала оцениваю обновление внутри неё: так проще ограничить число одновременно меняющихся условий. Переход на 1.7 требует отдельной проверки окружения и настроек веб-сервера. В этой ветке обязательным корнем сайта становится public_html, поэтому заменить файлы и оставить прежнюю конфигурацию недостаточно. Если PHP, плагины или интеграции не подходят, я готовлю переход на копии. Совместимость нельзя установить по одному удачному входу: нужны проверки тех действий, ради которых сотрудники используют веб-почту.

Для старой 1.4 я не назначаю обязательную остановку на 1.5.10 как универсальный закон. Маршрут определяют инструкция выбранного релиза, требования окружения и результат репетиции. Пакет поставщика может иметь собственную последовательность действий. Если уязвимый экземпляр приходится временно ограничить в доступе, я описываю это как временную меру до обновления. Смена пароля, фильтр запросов или закрытие публичной страницы сами по себе не исправляют код. У каждой меры должна быть своя понятная цель, иначе вместо плана получается коллекция успокоительных.

Как обновить файлы, базу и права доступа

Перед изменениями я сохраняю согласованный комплект: базу Roundcube, конфигурацию, файлы приложения и собственные плагины. Для контейнера отдельно выясняю, где находятся постоянные данные и настройки. Резервная копия самого веб-клиента не заменяет копию почтового хранилища. Я проверяю восстановление на отдельной площадке и заранее определяю условия возврата. Если после изменения схемы базы понадобится откат, возвращать придётся совместимые файлы и базу вместе. Старый каталог рядом с новой базой ещё не составляет рабочий план восстановления.

Для установки из архива я беру официальный выпуск и его инструкцию. Архив распаковываю в отдельный временный каталог. В UPGRADING ветки 1.6 предусмотрен bin/installto.sh: из каталога нового выпуска он обновляет указанную существующую установку, включая проверку конфигурации и схемы базы. Например, если фактический целевой путь — /srv/roundcube, запуск выглядит так:

./bin/installto.sh /srv/roundcube

Здесь путь условный: перед выполнением его заменяют своим. Этот способ относится к архивной установке и не подменяет обновление пакета или контейнера.

При ручном обновлении инструкция предусматривает ./bin/update.sh из каталога установки. Для отдельного изменения схемы есть bin/updatedb.sh; в документации приведён запуск ./bin/updatedb.sh --package=roundcube --dir=SQL. Я не запускаю оба средства подряд на всякий случай: выбираю процедуру для конкретного способа установки и проверяю её сообщения. Ожидание, что первый вход пользователя сам выполнит необходимые миграции, — плохая замена инструкции. При ошибке обновления я останавливаю дальнейшие действия, выясняю причину и использую подготовленный вариант восстановления.

Зависимости и плагины я проверяю отдельно от номера ядра. В базе знаний есть полезное напоминание: в интеграции с mailcow зависимости Roundcube обслуживаются через Composer. Его подтверждает документация проекта, где также описана проверка установленных пакетов на известные проблемы. Я сначала повторяю обновление на копии, фиксирую получившийся набор зависимостей и проверяю нужные функции. Совет, что репозиторий плагинов якобы всегда обновляется быстрее ядра, не имеет смысла: у каждого расширения свой разработчик и свой график исправлений.

Права я назначаю по роли каталога. В официальной инструкции интеграции с mailcow владельцем config указан root с группой www-data, а записываемых logs и temp — www-data. Это пример конкретной схемы, а не команда для любого сервера. Для своей установки я проверяю пользователя процесса, чтение конфигурации и запись рабочих файлов. Делать весь код доступным веб-процессу на запись опасно. Конфигурацию, журналы и временные данные также нужно закрыть от прямого получения через HTTP. Если используется SQLite, её файлу и каталогу нужны отдельные подходящие разрешения.

На время замены файлов и изменения базы я исключаю пользовательские запросы к обновляемому экземпляру. Для этого выбираю способ обслуживания конкретного сайта; останавливать весь веб-сервер вместе с соседними приложениями не обязательно. Перезапуск нужных процессов или обновление кеша выполняю по схеме установки. Затем проверяю вход, чтение, отправку, вложения, контакты и журналы. Обещать восстановление за минуты до репетиции я не стану. Бэкап без проверки восстановления — архив хороших намерений, иногда очень аккуратно подписанный.

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

Условный сценарий для «Вертикаль-М»: что считать результатом

Покажу порядок на условном примере: обслуживание лифтов «Вертикаль-М», Москва, 48 рабочих мест. Для разбора принимаю исходную установку Roundcube 1.5.9 из архива и проверку в октябре 2026 года. Все дальнейшие действия — план для этого учебного сценария. Количество рабочих мест не сообщает количество ящиков, поэтому я не подставляю эти числа друг вместо друга. В задаче есть уязвимый веб-клиент и неподдерживаемая ветка; способ доставки почты и фактическое размещение данных нужно установить до выбора обновления.

Я начинаю с действующего каталога, конфигурации подключения и списка расширений. Затем делаю копию приложения и базы, проверяю восстановление и совместимость выбранного релиза. Для этого сценария рассматриваю актуальную 1.6 LTS, если окружение проходит её требования. Если нужна 1.7, отдельно проверяю её требования и корень сайта. Заодно выясняю, какие интеграции обязательны: отключать несовместимое расширение можно лишь после оценки того, какую функцию потеряют сотрудники. Пустой список ошибок в консоли не заменяет работающий бизнес-процесс.

Продолжительность окна я определяю после репетиции: учитываю копирование, обновление базы, проверки и резерв на возврат. Утверждение «всегда сорок минут» здесь ничем не подтверждено. Если меняется только веб-клиент, я отдельно проверяю доступность IMAP и SMTP для остальных почтовых программ. Ограничение веб-почты не обязано останавливать доставку писем, но зависит от устройства системы. Порядок проверки учётных записей и настроек после работ перекликается со сверкой после переноса почты: сначала составить список, потом отмечать результат.

Приёмку я привязываю к наблюдаемым действиям. Тестовый пользователь входит, открывает письмо, отправляет сообщение с вложением, видит контакты и сохраняет настройки. Я подтверждаю версию действующей установки и смотрю журналы за период испытаний. Если проверка не проходит, доступ остаётся ограниченным до исправления причины или согласованного возврата. Ожидаемый итог сценария — поддерживаемая веб-почта с закрытой CVE и записанной процедурой обслуживания. Заявлять успешное обновление до выполнения этих шагов было бы выдумкой. Галочка в плане не умеет отправлять письма.

Что проверить после патча и как не пропустить следующий

После обновления я отдельно решаю, есть ли основания подозревать компрометацию. Если замечены посторонние входы, неизвестные файлы или изменения настроек, сохраняю доступные журналы и ограничиваю доступ к затронутому экземпляру. Удалять всё подозрительное до фиксации следов — значит мешать собственному расследованию. Сам факт появления исправленной версии не объясняет старые события. При подтверждённом выполнении чужого кода я планирую восстановление из доверенного состояния и проверку доступных приложению секретов. Замена файлов ядра сама по себе не удаляет всё, что мог оставить атакующий.

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

Чтобы история не повторялась, я включаю веб-почту в реестр приложений. Для неё записываю ответственного, источник установки, версию, статус поддержки, состав плагинов и способ резервного копирования. Рядом держу ссылку на официальный канал выпусков и дату последней проверки восстановления. Новость об исправлении безопасности запускает оценку и работы по риску, а не ждёт удобного дня для переписи таблицы. Старый неподдерживаемый компонент не становится надёжнее от того, что его давно никто не менял. Возраст здесь даёт только стаж, а не иммунитет.

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

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

Частые вопросы