Roundcube выпустил 11 патчей безопасности — но ни одного CVE. Разбираемся, что происходит

Обычно выход патча безопасности — это четкая история. Уязвимость получает номер CVE, сканеры начинают её детектировать, админы ставят галочку в отчёте. Всё понятно.

Но недавно Roundcube обновился иначе.

Что случилось

Вышли версии 1.7.3 и 1.6.18. Внутри — исправления для одиннадцати различных проблем с безопасностью. Цифра серьёзная.

Самая интересная из известных уязвимостей — IMAP command injection. Если кратко: теоретически атакующий может влиять на команды, которые Roundcube отправляет почтовому серверу. Не самая приятная перспектива.

Остальные десять проблем подробно не раскрыты. По опыту, там наверняка спектр от XSS до утечек данных — типичный набор для крупного релиза. Но без деталей остаётся только гадать.

Почему отсутствие CVE — это проблема

Давайте объясню, зачем вообще нужны эти номера.

CVE — это общий язык безопасности. Сканер нашёл уязвимость? Смотрит в базу CVE. Пришёл аудитор? Ему нужны CVE-номера. Заполняете отчёт для compliance? Без CVE никуда.

Без них начинается бардак.

Возьмём типичную ситуацию. Вы обновили Roundcube. Приходит аудит. «Покажите, что все уязвимости закрыты». А у вас нет номеров CVE, только версия 1.7.3 в логе. Теоретически достаточно, но попробуйте объяснить это проверяющим, которые привыкли к конкретным идентификаторам.

Автоматические системы мониторинга тоже страдают. Если сканер ориентируется на CVE-базу, он просто не узнает, что патч вышел. Вендор сканера должен отдельно добавить детекцию по релизу Roundcube — а это время и ресурсы.

Такое бывает?

Бывает. Особенно в мире открытого софта.

Иногда у проекта нет связей с MITRE или CNA для быстрого назначения номеров. Иногда вендор хочет скрытую уязвимость — и просит обойтись без публичного CVE. Иногда это просто процесс.

Неважно, какая причина. Результат один: ты обновляешься вслепую.

Что делать прямо сейчас

Если у вас работает Roundcube — действуйте:

Обновитесь. Берём нужную ветку (1.7.3 или 1.6.18) и ставим. Это первое.

Записывайте обновление вручную. Дата, версия, откуда скачали. Пусть будет в changelog вашей системы.

Подпишитесь на каналы Roundcube. Почтовые рассылки проекта, GitHub-релизы. Не надейтесь, что сканер всё поймает сам.

Проверьте свой сканер. Убедитесь, что он вообще умеет определять версию Roundcube. Если нет — патч может пройти незамеченным.

Что это значит для индустрии

Вот в чём реальный урок.

Мы привыкли полагаться на стандарты. CVE, CVSS, NIST — всё это упрощает жизнь. Но стандарты — это не замена головному мозгу.

Когда проект выпускает патчи без CVE, это напоминание: инструменты — не замена практикам. Регулярные обновления, внимание к релизным заметкам, поддержание актуальной документации — базовые вещи, которые не отменяются наличием или отсутствием красивого номера в базе.

В нашем деле (да и в любом, где есть серверы) это особенно актуально. Серверный парк не обновляется сам по себе. Кто-то должен за этим следить.

Вопросы по обновлению инфраструктуры? Пишите — разберёмся.