Корпоративный почтовый сервер аутентификации пользователей хранит личные переписки, доставляет ссылки для восстановления, управляет календарями и отправляет почту, которой доверяют сотрудники и другие системы. Компрометация такого сервера может привести к раскрытию не только электронной почты, но и учетных записей и рабочих процессов, построенных вокруг них.
В ходе комплексного аудита Zimbra Collaboration Suite (ZCS) компания Rapid7 обнаружила более 80 уязвимостей, затрагивающих аутентификацию, авторизацию почтовых ящиков, обработку календарей, веб-клиенты, документ-сервисы и операционную систему хоста. Затронутые компоненты исправляются по разным графикам, поэтому мы публикуем этот анализ поэтапно. Сопутствующий репозиторий на GitHub с полными описаниями (write-ups) и эксплойтами (PoC) служит актуальным техническим трекером и будет обновляться по мере публикации новых уязвимостей и исправлений.
Эта первая статья посвящена пяти уязвимостям, связанным с учетными записями:
CVE
Уязвимость
CVSS по версии Rapid7
Исправленный выпуск
Обход ограничения частоты запросов (rate-limit) при аутентификации в GraphQL
Публичное исправление отсутствует
Инъекция в фильтр LDAP
Публичное исправление отсутствует
Подделка электронной почты через SaveDraftRequest
ZCS 10.1.17
Межпользовательский доступ к почтовым ящикам через EWS
ZCS 10.1.20
Обход ограничений на пересылку уведомлений Sieve
ZCS 10.1.20
В Части 2 будут рассмотрены векторы неаутентифицированного сохраненного XSS в классическом и современном клиентах (Classic и Modern), а также возможности злоумышленников при получении контроля над сеансом получателя. Сценарий позволяет установить правило пересылки Sieve (CVE-2026-50055); другой путь сохраняет прямой доступ к почтовому ящику после истечения срока исходного сеанса или смены пароля жертвой. Уязвимость CVE-2026-73571 делает эти атаки более реалистичными, размещая сообщение в почтовом ящике от имени любого выбранного локального пользователя.
В Частях 3 и 4 мы пройдем путь через границу документ-сервиса от SSRF до выполнения кода с правами пользователя zimbra, а затем рассмотрим несколько независимых путей эскалации привилегий от zimbra до root. На презентации на конференции BruCON «Signed, Sealed, Compromised: Weaponizing Enterprise Mail Infrastructure» демонстрировались эти цепочки, включая вывод результатов выполнения корневых команд в браузер жертвы после выбора одного сообщения.
Описание продукта
Zimbra Collaboration Suite — это хостинговая платформа для электронной почты, календарей, контактов, задач и совместного использования файлов. Коммерческий сервер Zimbra называется Network Edition. В рамках одной инсталляции Network Edition клиенты могут приобретать лицензии для смеси пользователей Standard и Professional. Zimbra Desktop и Zimbra Connector for Outlook являются отдельными клиентскими приложениями, в то время как Exchange Web Services (EWS) — это отдельно лицензируемая серверная функция для обеспечения совместимости с Outlook.
ZCS включает в себя два веб-почтовых клиента с различными стеками запросов и рендеринга: Classic в основном опирается на SOAP, в то время как Modern использует GraphQL. Сервер также принимает входящий трафик SMTP и iCalendar, предоставляет службы совместимости, такие как EWS, и делегирует задачи локальным компонентам, работающим от имени нескольких учетных записей операционной системы.
Настройка для тестирования
Специалисты Rapid7 изначально оценивали ZCS 10.1.16_GA_4850 Network Edition на ОС Ubuntu 22.04. Для исправленных уязвимостей в каждом разделе описывается исправление от Zimbra, а в сопутствующем репозитории на Github сохранен полный дифф между уязвимой и исправленной версиями.
Влияние
Уязвимости предварительной аутентификации (pre-authentication) снижают барьеры для получения начального доступа. GraphQL скрывает неудачные попытки ввода пароля от счетчика исходных IP-адресов Zimbra. В случае конфигурации с внешним LDAP второй недостаток также может оставить дополнительную политику блокировки учетных записей без локального аккаунта для блокировки.
Каждая из оставшихся уязвимостей эксплуатируется независимо от обычного скомпрометированного аккаунта. Подделка электронной почты не требует дополнительных функций: злоумышленник подставляет другой локальный адрес в аутентифицированный запрос. Zimbra отправляет сообщение от имени этого аккаунта через доверенный исходящий конвейер и сохраняет копию в папке «Отправленные» выбранного пользователя.
Если для скомпрометированного аккаунта включен EWS, злоумышленник может читать личные переписки, вложения, черновики, отправленные письма, контакты и элементы календаря из почтовых ящиков других пользователей. Отдельный обход политики Sieve позволяет сохранять копии будущих писем у злоумышленника даже после истечения срока исходного сеанса или смены пароля.
Эти примеры не исчерпывают всех возможностей злоумышленника при наличии аутентифицированного доступа к Zimbra, равно как и всего набора уязвимостей, выявленных в ходе аудита.
Обход ограничения частоты запросов аутентификации в GraphQL (CVE-2026-93637)
Этот маршрут предварительной аутентификации требует лишь наличия доступа по HTTPS к Zimbra. Класс ZimbraInvalidLoginFilter обычно регистрирует неудачные попытки входа по исходному адресу для запросов к публичным конечным точкам служб. Classic отправляет попытки входа через путь SOAP AuthRequest, в то время как Modern предоставляет ту же проверку пароля через свою мутацию аутентификации в GraphQL.
Порог срабатывания этого ограничения по умолчанию составляет 10 попыток, и после того как источник превышает его в течение настроенного временного окна, последующие запросы, обрабатываемые фильтром, получают HTTP-ответ 503. Уязвимость CVE-2026-93637 позволяет попыткам входа через GraphQL оставаться незаметными для этого счетчика.
Технический анализ
Счетчик неудачных попыток опирается на атрибут запроса
Фильтр ZimbraInvalidLoginFilter оборачивает запросы к публичным конечным точкам служб и запускает нисходящий обработчик до логики своего счетчика:
В точке [0] обработка сбоев начинается только в том случае, если нисходящий путь добавил auth.failed к запросу. Соответствующий путь исключений SOAP:
В точке [1] метод SoapEngine.dispatchRequest() устанавливает этот атрибут перед возвратом ошибки аутентификации. Таким образом, неудачный вход через SOAP доходит до проверки в точке [0] и увеличивает счетчик для исходного IP-адреса.
GraphQL пропускает обработчик сбоев SOAP
Расширение GraphQL в современном Zimbra создает обычный AuthRequest, а затем обращается к своему обработчику через XMLDocumentUtilities.executeDocumentAsGuest():
В точке [2] вспомогательный метод вызывает обработчик аутентификации, минуя SoapEngine. Неправильный пароль по-прежнему приводит к ошибке GraphQL, но блок catch в точке [1] никогда не выполняется. Атрибут, считываемый в точке [0], отсутствует, поэтому фильтр не увеличивает счетчик исходного IP-адреса.
Эксплуатация
Пакетная аутентификация
Неаутентифицированный клиент отправляет JSON на адрес /service/extension/graphql. Псевдонимы (aliases) в GraphQL позволяют его полю query многократно вызывать authenticate с разными паролями:
Каждый псевдоним выполняет реальную операцию аутентификации. Ошибки появляются в массиве ошибок GraphQL, в то время как успешный псевдоним возвращает токен аутентификации под соответствующим именем. Механизм GraphQL не накладывает ограничений на уровне приложения на количество псевдонима в этом пути. Весь документ представляет собой один HTTP-запрос, поэтому механизм контроля количества запросов Jetty видит один запрос, а не количество операций входа внутри него.
Выполнение псевдонимов происходит последовательно и зависит от бэкенда, поэтому скорость зависит от развертывания. Используя 100 псевдонимов на запрос, 10 000 кандидатов были проверены менее чем за две минуты без блокировки источника счетчиком IP-адресов Zimbra или фильтром запросов Jetty. Уязвимость устраняет учет неудачных входов на уровне IP и снижает накладные расходы на запросы.
Инструмент CVE-2026-93637 PoC принимает обычный файл с паролями, генерирует пакетные документы GraphQL и сообщает о принятом кандидате.
Рисунок 1: Модуль Metasploit проверяет 1500 паролей за 15 запросов, успешно определяя правильный пароль в последнем пакете.
Блокировка учетной записи
Счетчик IP-адресов — не единственный механизм контроля в Zimbra. Отдельная политика блокировки для каждой учетной записи по умолчанию отключена, но при ее активации неудачные операции GraphQL все равно увеличивают счетчик целевой локальной учетной записи и прекращают дальнейшие попытки подбора, когда эта учетная запись блокируется.
CVE-2026-93635 и внешний LDAP
В доменах, настроенных на аутентификацию через внешний LDAP с использованием поискового фильтра и «ленивой» (lazy) автоподготовкой учетных записей, CVE-2026-93635 превращает поле логина в оракул паролей для пользователя внешнего каталога. Метод LdapUtil.computeDn() подставляет логин с подстановочным знаком, например jdoe*@example.test, в настроенный фильтр без экранирования. Если этот шаблон выбирает одну запись в каталоге, Zimbra проверяет пароль кандидата для этого пользователя. Неверный пароль возвращает account.AUTH_FAILED; верный пароль проходит привязку (bind) LDAP и доходит до этапа «ленивой» подготовки, выдавая другой ответ.
Логин с подстановочным знаком не является именем существующей локальной учетной записи Zimbra, поэтому опциональная блокировка по учетной записи не имеет объекта, для которого можно было бы зафиксировать неудачную попытку. Отправка той же операции через GraphQL также позволяет избежать срабатывания счетчика по исходному IP-адресу. При включенной блокировке по учетной записи и установленном пороге в пять попыток, повторные неверные варианты не увеличивали ни один из счетчиков, в то время как верный пароль оставался различимым. Эта комбинация из двух уязвимостей применима только к указанной конфигурации внешнего LDAP, а не к стандартному пути локальной аутентификации Zimbra.
В LDAP/GraphQL composition PoC и CVE-2026-93635 tracker entry подробно описан этот путь с использованием внешнего каталога. В CVE-2026-93637 tracker entry зафиксированы результаты независимого исследования и доказательства для затронутых версий.
Влияние
Любой, кто имеет доступ к публичной конечной точке GraphQL, может выполнять повторные попытки подбора пароля, не вызывая приостановку доступа по исходному IP-адресу в Zimbra. Пакетная отправка нескольких кандидатов также сокращает количество HTTP-запросов и связанные с этим накладные расходы сети. Это делает более практичным тестирование слабых, повторно используемых или ранее скомпрометированных паролей, однако не позволяет раскрыть сложный пароль или обойти отдельную проверку MFA.
Имперсонация электронной почты через SaveDraftRequest (CVE-2026-73571)
Запрос SaveDraftRequest имеет путь делегированной отправки, выбираемый параметром isDelegatedReq. На уязвимом сервере обычный пользователь может поместить другой локальный адрес в поле From запроса. Обработчик разрешает этот адрес в соответствующий почтовый ящик, принимает полномочия владельца ящика и вызывает стандартную процедуру отправки Zimbra, не проверяя, имеет ли вошедшая в систему учетная запись права на отправку от имени другого пользователя. Это ошибка авторизации приложения, а не поддельное отображаемое имя или написанный вручную SMTP-заголовок: Zimbra отправляет сообщение злоумышленника как выбранная учетная запись и добавляет соответствующий элемент в папку «Отправленные» этой учетной записи.
Цель должна находиться на том же сервере почтовых ящиков, но атака не требует использования опциональных функций Zimbra, существующего делегирования, прав администратора или каких-либо действий со стороны жертвы.
Технический анализ
Указанный отправитель становится владельцем почтового ящика
После того как парсер запроса извлекает адрес из поля From, делегированная ветка разрешает этот адрес в локальную учетную запись и считывает опциональный delegateeAccountId:
Между разрешением учетной записи в [0] и доставкой в [3] отсутствуют вызовы checkRight(), canAccessAccount() или canSendAs(). В продемонстрированном запросе параметр delegateeAccountId отсутствует. В [2] Zimbra формирует контекст операции из почтового ящика, указанного в поле From, что приводит к тому, что последующая отправка рассматривает выбранную учетную запись как инициатора. Затем в [3] сообщение отправляется через легитимный путь отправки Zimbra.
Существует второй способ вызвать эту уязвимость. Злоумышленник может предоставить UUID учетной записи указанного отправителя в параметре delegateeAccountId. В [1] Zimbra формирует контекст операции непосредственно из этой учетной записи и достигает того же результата имперсонации, не проверяя личность, которая фактически вошла в систему.
Эксплуатация
Отправка от имени локальной учетной записи
Соответствующее тело запроса SaveDraftRequest выглядит так:
Поскольку Zimbra отправляет сообщение через свою легитимную инфраструктуру, проблема выходит за рамки подделки отображаемого имени. В развертывании, где легитимная исходящая почта проходит проверки SPF, DKIM и DMARC, поддельное сообщение также проходит их: оно использует тот же исходный MTA, домен подписи, RFC-отправителя и конвертного отправителя, что и легитимная почта от выбранной учетной записи. Локальное тестирование подтвердило выравнивание отправителя и нормальный путь прохождения через MTA.
В CVE-2026-73571 PoC отправляется делегированный запрос с выбранными оператором отправителем, получателем, темой и телом сообщения. На затронутой сборке сообщение пришло с генеральным директором в качестве RFC-отправителя, и та же тема появилась в папке «Отправленные» генерального директора.
Рисунок 2: В папке «Входящие» жертвы поддельное сообщение отображается как обычное внутреннее письмо от генерального директора.
Влияние
Злоумышленник может выдать себя за любого локального пользователя, а не только за администратора или руководителя. Внутри организации это позволяет создавать правдоподобные запросы на оплату, изменения в данных учетных записей, вредоносные ссылки, ложные инструкции и мошеннические одобрения. Обычные предупреждения о подделке отображаемого имени и баннеры о внешнем отправителе не помогают, так как Zimbra отправляет сообщение как выбранный локальный пользователь.
Zimbra также помещает поддельное сообщение в папку «Отправленные» имперсонируемого пользователя. Это оставляет сфабрикованную запись об авторстве и может быть использовано для попытки подставить этого пользователя.
Рисунок 3: То же поддельное сообщение записано в папке «Отправленные» генерального директора.
Для внешних получателей злоумышленник может отправить письмо от имени финансового отдела с запросом новых реквизитов для оплаты, использовать учетную запись операционного отдела для отмены или изменения заказа, либо рассылать мошеннические и оскорбительные письма с адреса сотрудника. Последствия зависят от роли и отношений выбранного отправителя.
То же преимущество доверенной доставки применимо к письмам, содержащим эксплойты. В следующей статье будут рассмотрены результаты исследования на стороне браузера, которые злоумышленник может доставить от имени любой выбранной локальной учетной записи. Имперсонация не требуется для самой XSS, но может сделать сообщение выглядящим так, будто оно пришло от того, кому получатель доверяет.
Исправление
В patch в ZCS 10.1.17 сохраняется учетная запись, которая фактически вошла в систему, если только у нее нет явного права на отправку от имени (send-as) или отправку от лица другого пользователя (send-on-behalf-of). В результате неавторизованный делегированный запрос выполняется от имени инициатора, а не учетной записи, указанной в сообщении.
Межпользовательский доступ к почтовым ящикам через EWS (CVE-2026-10631)
Расширение EWS в Zimbra использует составные идентификаторы папок, предназначенные для операций с общими почтовыми ящиками. Метод FindItem доверяет UUID владельца внутри предоставленного злоумышленником идентификатора и формирует контекст авторизации на основе выбранного почтового ящика, а не учетной записи, которая вошла в систему. Эта небезопасная прямая ссылка на объект (IDOR) позволяет любой обычной учетной записи с поддержкой EWS читать полные элементы из почтовых ящиков других пользователей без предоставления прав общего доступа или делегирования.
Злоумышленнику необходимо наличие zimbraFeatureEwsEnabled=TRUE. Хотя эта функция отключена по умолчанию, в развертываниях, использующих интеграцию Zimbra с Outlook, EWS часто включается для всего класса обслуживания. Целевой учетной записи не требуется наличие включенного EWS, и никаких действий со стороны целевого пользователя не требуется.
Технический анализ
Составные идентификаторы выбирают почтовый ящик
Для обращения к общему элементу EWS должен идентифицировать как почтовый ящик, которому он принадлежит, так и элемент или папку внутри этого ящика. Zimbra кодирует это как {ownerUUID}_{numericId}. Например:
Когда FindItem получает составной ID, FolderUtil.parseItemId() отделяет владельца от числовой части. Затем значение владельца передается в ItemUtil.getGrantorMailbox():
В [0] EWS преобразует предоставленный UUID владельца в локальную учетную запись; [1] извлекает почтовый ящик этой учетной записи. Ни один из методов не получает идентификатор вызывающего объекта.
Почтовый ящик становится аутентифицированным идентификатором.
Затем аутентифицированная учетная запись и выбранный почтовый ящик передаются в ItemOperation:
[2] — это учетная запись злоумышленника. Предоставление UUID жертвы делает [3] почтовым ящиком жертвы, поэтому он не является null. Таким образом, [4] создает OperationContext из почтового ящика жертвы, а не из учетной записи злоумышленника.
[5] извлекает учетную запись жертвы из этого почтового ящика, а [6] сохраняет жертву в качестве аутентифицированного пользователя. Затем почтовый ящик сравнивает этот идентификатор со своим владельцем:
Идентификаторы совпадают, поэтому [7] меняет аутентифицированного пользователя на null, что последующие проверки интерпретируют как доступ владельца. В результате запрос злоумышленника авторизуется как запрос жертвы. EWS использовал ненадежный UUID владельца как для выбора почтового ящика, так и для принятия решения о том, кто прошел аутентификацию. Числовой ID папки впоследствии разрешается в контексте этого владельца, что позволяет FindItem получить доступ к любой папке в выбранном почтовом ящике.
Эксплуатация
Разрешение целевого почтового ящика
Целевой UUID доступен через обычные аутентифицированные поисковые запросы в каталоге. И GetAccountInfoRequest, и SearchGalRequest возвращают zimbraId для известного локального адреса. В PoC используется GetAccountInfoRequest:
Ответ содержит UUID цели:
Добавление _2 к UUID формирует идентификатор папки «Входящие» цели. Злоумышленник отправляет следующий запрос EWS на /service/extension/zimbraews или на /EWS/Exchange.asmx, когда EWS открыт через стандартный прокси-сервер Zimbra:
Сервер возвращает данные выбранного почтового ящика в ответе EWS:
CVE-2026-10631 PoC получает этот UUID и автоматически создает составной ID.
Чтение папок между учетными записями
Изменение числового компонента позволяет выбрать другую известную папку:
Папка
Сформированный ID
Несанкционированный результат
Входящие
{uuid}_2
Полученные сообщения и вложения
Отправленные
{uuid}_5
Сообщения, отправленные целью
Черновики
{uuid}_6
Незавершенные сообщения
Контакты
{uuid}_7
Записи адресной книги
Календарь
{uuid}_10
Встречи и данные календаря
Если целевой почтовый ящик находится на другом сервере в том же кластере Zimbra, первый сервер пересылает сформированный запрос. Принимающий сервер разрешает свой локальный почтовый ящик из того же UUID владельца и обращается к уязвимому конструктору FindItem.
CVE-2026-10631 tracker entry подробно описывает полный ответ, затронутые папки и путь между серверами.
Влияние
EWS раскрывает содержимое личных сообщений и вложения жертвы, а также черновики, отправленные письма, контакты и данные календаря. Злоумышленник может отслеживать переписку и использовать ее историю, чтобы сделать отдельную атаку с использованием подмены личности более правдоподобной.
Злоумышленник также может запросить сброс пароля для другого сервиса, отслеживать соответствующий почтовый ящик и использовать ссылку. EWS сам по себе не обходит стороннюю MFA, но он открывает канал электронной почты, который многие сервисы до сих пор считают достаточным доказательством. Поскольку UUID владельца выбирается злоумышленником, одна и та же обычная учетная запись EWS может повторять эти операции чтения для других локальных почтовых ящиков.
Обратите внимание, что в более ранней версии этого анализа, представленной на BruCON 2026, GetItem, отправка, перемещение и удаление были отнесены к той же уязвимости. Сравнение промежуточных выпусков Network Edition во время этого исследования потребовало восстановления нескольких виртуальных машин, поскольку EWS защищен лицензией, а обычное исправление обновляет всю систему; одна из машин сохранила отдельное состояние авторизации почтового ящика, которое скрывало границу, что поначалу сделало влияние более широким. Повторение каждой операции с явной авторизацией и контролем целевого состояния сузило CVE до FindItem, который все еще раскрывает полные MIME и вложения.
Исправление
в ZCS 10.1.20 создает контекст авторизации EWS из учетной записи, которая вошла в систему, а не из почтового ящика, выбранного составным ID. Zimbra применила это исправление как к локальным, так и к удаленным операциям с почтовыми ящиками.
Обход ограничения пересылки уведомлений Sieve (CVE-2026-50055)
zimbraFeatureMailForwardingInFiltersEnabled=FALSE предназначен для того, чтобы пользователи не могли создавать правила пересылки почты на стороне сервера. Zimbra обеспечивает это путем отклонения перенаправления Sieve, но принимает уведомления, несмотря на то, что это действие может отправить выбранные заголовки и полное тело текста на произвольный внешний адрес. Таким образом, аутентифицированный пользователь может установить постоянную эксфильтрацию почты вопреки ограничению администратора. Если пересылка обычно разрешена, то границы политики для обхода не существует.
Технический анализ
Перенаправление — единственное заблокированное действие
Обе команды SOAP, ModifyFilterRulesRequest и ModifyOutgoingFilterRulesRequest, вызывают checkForwardFilterAttr() перед сохранением правила. Проверка распознает только один тип действия:
В [0] политика классифицирует только RedirectAction как пересылку, что означает, что NotifyAction и RFCCompliantNotifyAction достигают [1], даже если они могут отправить выбранное злоумышленником содержимое сообщения на внешний адрес электронной почты.
Уведомление расширяет содержимое сообщения
Эти действия могут включать содержимое сообщения, а не просто общее оповещение, поскольку SoapToSieve.getSieveScript() включает переменные и расширения enotify. FilterUtil.getVarsMap() затем предоставляет значения, доступные для уведомления:
Когда правило выполняется, Notify.executeBasic() разворачивает эти переменные в теме и теле уведомления. [2] делает доступными декодированные заголовки, а [3] предоставляет текстовую часть, выбранную Mime.getTextBody(). Он не предоставляет необработанный MIME или вложения.
Эксплуатация
Установка постоянной эксфильтрации
Аутентифицированный пользователь может поместить следующий объект правила внутри ModifyFilterRulesRequest:
actionKeep оставляет исходное сообщение в папке «Входящие» пользователя, в то время как каждая соответствующая доставка отправляет выбранный текст сообщения и заголовки на внешний адрес.
CVE-2026-50055 PoC сохраняет существующие фильтры при установке правила уведомления. После того как обычное сообщение поступило для отфильтрованной учетной записи, другой почтовый ящик получил его тему, отправителя, получателей, дату и полное тело текста. CVE-2026-50055 tracker entry содержит полную информацию о затронутых версиях.
Рисунок 4: Уведомление, доставленное злоумышленнику, содержит тему, заголовки и полное тело текста сообщения жертвы.
Скрыто от Modern
Постоянство не очевидно в Modern. Во время тестирования сервер возвращал активное правило уведомления, в то время как представление «Фильтры» той же учетной записи оставалось пустым. Сервер продолжал выполнять правило в обычном режиме, но Modern не давал владельцу учетной записи возможности обнаружить или удалить его.
Рисунок 5: Представление «Фильтры» в Modern не отображает активное правило уведомления Sieve.
Classic действительно перечислял имя, выбранное злоумышленником, в разделе «Активные фильтры», но его обзор не раскрывал адрес уведомления или скопированные поля. Таким образом, правило не является невидимым для каждого клиента, и злоумышленник может выбрать менее заметное имя.
Рисунок 6: Classic отображает имя правила злоумышленника, но не внешнее назначение или скопированные поля.
Влияние
Уязвимость сводит на нет попытки администратора запретить пользователям пересылать почту с помощью серверных фильтров. Злоумышленник с аутентифицированной сессией может установить правило напрямую. Оно продолжает раскрывать текст и заголовки будущих сообщений после истечения срока действия сессии или смены пароля, при этом не отображаясь в представлении фильтров Modern. Оно не пересылает вложения или исходный код MIME.
Исправление
в ZCS 10.1.20 рассматривает notify и его соответствующий стандарту RFC вариант как действия по пересылке и отклоняет их в соответствии с той же политикой учетной записи, что и перенаправление.
Установите последний поддерживаемый выпуск Zimbra. В рекомендации по безопасности Zimbra указано, что CVE-2026-73571 исправлена в ZCS 10.1.17, а CVE-2026-10631 и CVE-2026-50055 исправлены в ZCS 10.1.20. Для CVE-2026-93635 или CVE-2026-93637 на момент публикации исправление в открытом доступе не указано, поэтому установите обновление безопасности, содержащее эти исправления, как только Zimbra выпустит его.
Обновление не удаляет правила фильтрации, уже сохраненные в учетных записях. Администраторы должны проверить сохраненные входящие и исходящие правила фильтрации на наличие внешних действий actionNotify и соответствующих RFC действий notify, которые нарушают политику пересылки; представления фильтров Modern недостаточно для этой проверки.
Обнаружение и реагирование на инциденты
Обратный прокси-сервер или брандмауэр веб-приложений, проверяющий тела запросов, может обнаружить несколько псевдонимов аутентификации в одном анонимном запросе GraphQL. Журналы EWS от Zimbra раскрывают операции между пользователями, затрагивающие два разных UUID учетных записей, как показано в индикаторах компрометации (IoC) EWS. Сохраненные правила уведомлений и исходящий трафик уведомлений предоставляют более прямые доказательства пути Sieve.
EWS не создает делегированные права для отзыва, правила Sieve остаются в виде сохраненного состояния учетной записи, а выдача себя за отправителя может генерировать обычные артефакты Sent и MTA. Восстановление должно охватывать эти изменения на стороне сервера и любые другие затронутые почтовые ящики, а не только пароль первой скомпрометированной учетной записи.
Благодарности
Оценка была проведена Джона Бёрджессом (CryptoCat), старшим исследователем безопасности в Rapid7, в соответствии с политикой раскрытия уязвимостей Rapid7.
Хронология раскрытия информации
- 17 апреля 2026 г.: компания Rapid7 представила первоначальный отчет, охватывающий 23 обнаруженные проблемы.
17 апреля 2026 г.: компания Rapid7 представила первоначальный отчет, охватывающий 23 обнаруженные проблемы.
- 24 апреля 2026 г.: компания Zimbra подтвердила получение отчета.
24 апреля 2026 г.: компания Zimbra подтвердила получение отчета.
- 21 мая 2026 г.: компания Zimbra подтвердила валидацию 10 из 23 найденных проблем, три из которых оказались дубликатами.
21 мая 2026 г.: компания Zimbra подтвердила валидацию 10 из 23 найденных проблем, три из которых оказались дубликатами.
- 28 мая 2026 г.: в ZCS 10.1.17 уязвимость CVE-2026-73571 была исправлена.
28 мая 2026 г.: в ZCS 10.1.17 уязвимость CVE-2026-73571 была исправлена.
- 1 июня 2026 г.: компания Zimbra запросила эмбарго на публикацию до запланированного релиза ZCS 10.1.18 в сентябре.
1 июня 2026 г.: компания Zimbra запросила эмбарго на публикацию до запланированного релиза ZCS 10.1.18 в сентябре.
- 16 июня и 7 июля 2026 г.: были выпущены версии ZCS 10.1.18 и 10.1.19 без дополнительных исправлений из первоначального отчета.
16 июня и 7 июля 2026 г.: были выпущены версии ZCS 10.1.18 и 10.1.19 без дополнительных исправлений из первоначального отчета.
- 15 июля 2026 г.: компании Zimbra и Rapid7 согласовали 24 сентября в качестве скоординированной даты раскрытия информации.
