Veeam закрыла брешь 9,4 балла — версия 13 не затронута

Согласно бюллетеню Veeam от 6 октября 2026 года, уязвимость CVE-2025-64393 с оценкой 9,4 балла по CVSS 4.0 закрыта в Veeam Backup & Replication 12.3.2 P4 (сборка 12.3.2.4934); версия 13 не затронута. Уязвимы сборка 12.3.2.4854 и более ранние сборки ветки 12. Пользователю с ограниченной ролью Backup Viewer достаточно доступа к затронутому серверу, чтобы получить возможность удалённого выполнения кода.

Опубликованное 8 октября 2026 года предупреждение K-iS относит эту брешь к критическим и рекомендует установить сборку 12.3.2.4934. Для администратора ключевой вопрос — какой полный номер сборки сейчас работает на каждом сервере резервного копирования. Название ветки без последних цифр не позволяет отличить исправленную установку от уязвимой.

Какая сборка Veeam требует обновления

Граница проходит внутри версии 12, поэтому оценивать состояние установки нужно по номеру работающей сборки Backup & Replication. Номер загруженного установщика или запись о запланированном обновлении не говорят о текущем состоянии сервера. Если серверов несколько, для каждого потребуется собственная запись о версии: одинаковое название продукта не означает одинакового уровня исправлений.

• Версия 13. Эта уязвимость её не затрагивает. Пакет 12.3.2 P4 для устранения именно CVE-2025-64393 такой установке не нужен.
• Версия 12, сборка 12.3.2.4934 или более новая в этой ветке. Исправление входит начиная с 12.3.2 P4. После обновления сравнивайте полный номер работающей сборки с этой границей.
• Версия 12, сборка 12.3.2.4854 или более ранняя. Установка затронута. При сохранении ветки 12 целевая исправленная сборка — 12.3.2.4934.

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

Для веток, предшествующих версии 12, этот бюллетень не даёт отдельной оценки: он описывает затронутые сборки версии 12 и прямо исключает версию 13. Владельцу более старой установки понадобится сверить её с документацией своей ветки и доступным путём обновления. Приписывать ей статус версии 12 по одному номеру CVE было бы некорректно.

Почему достаточно роли Backup Viewer

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

Причина бреши — небезопасная десериализация недоверенных данных, поступающих через Mount Service. При десериализации программа превращает полученные данные во внутренние объекты; в данном случае обработка специально подготовленного содержимого может привести к выполнению кода на сервере резервного копирования. Предупреждение киберведомства Сингапура указывает, что успешная атака позволяет выполнить произвольный код с правами SYSTEM.

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

Администратору важно разделить два вопроса: есть ли на сервере уязвимая сборка и есть ли основания разбирать возможный инцидент. Ответ на первый даёт номер версии. Для второго нужны данные о действиях учётных записей и состоянии самого сервера. Установка исправления закрывает известный путь атаки, но сама по себе не устанавливает, что происходило до обновления.

Что проверить после установки исправления

После обновления первой проверкой становится фактически установленная сборка на каждом затронутом сервере. Статус завершённой процедуры и номер скачанного пакета полезны для учёта работ, но не заменяют номер работающего экземпляра Backup & Replication. Если обновление не довело сервер до исправленной границы, его статус по этой уязвимости остаётся прежним.

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

Для завершения работ нужно убедиться, что задания резервного копирования продолжают выполняться, а предусмотренная эксплуатационным регламентом проверка восстановления проходит штатно. Эти проверки относятся к работоспособности после обновления, а не к доказательству отсутствия прежней атаки. Если до установки исправления появились конкретные признаки злоупотребления учётной записью или изменений на сервере, журналы и связанные данные следует сохранить для отдельного расследования.

Читайте также:

• Zimbra взламывают письмом без входа — обновление 10.1.20 закрывает брешь
• 10 онлайн-тестов на внимательность — почему одного балла недостаточно
• Windows закрыла 398 уязвимостей — одну уже использует Lazarus