Почтовый сервер Exim содержит уязвимость, связанную с передачей имени очереди через аргументы командной строки. Ошибка позволяет файловый обход за пределы спула, что при локальном доступе может привести к повышению привилегий. Разработчики выпустили версию 4.99.5, которая устраняет проблему.
Детали уязвиости
Согласно бюллетеню EXIM-Security-2026-06-22.1, уязвимость затрагивает все версии Exim начиная с 4.88 (выпущена в 2017 году) до 4.99.4 включительно. Проблема классифицирована как локальная уязвимость типа directory traversal (обход каталогов) с высоким уровнем угрозы. Для эксплуатации злоумышленнику необходим доступ к командной строке системы.
При обработке командной строки Exim использует аргументы для указания имени очереди сообщений. Уязвимый код допускает обращение к файлам за пределами стандартной директории спула - при определённых символах в имени очереди можно прочитать или изменить произвольные файлы на сервере. Это открывает сценарий повышения привилегий: даже непривилегированный пользователь, имеющий возможность запускать Exim с определёнными аргументами, может получить контроль над системой.
Исправление в версии 4.99.5 вводит два ключевых ограничения. Во-первых, использование проблемных опций командной строки разрешено только уже привилегированным пользователям. Во-вторых, введён строгий фильтр допустимых символов для имён очередей: теперь разрешены только буквы, цифры и знак подчёркивания, что исключает подстановку путей и спецсимволов.
Временных мер защиты в бюллетене не указано. Разработчики рекомендуют немедленно обновить Exim до версии 4.99.5, доступной на официальном FTP-сервере и в репозитории кода. Дистрибутивы Linux, входящие в список рассылки distros@vs.openwall.org, получили уведомление за неделю до публичного релиза, поэтому для популярных ОС обновление может быть уже доступно через штатные менеджеры пакетов.
Хотя уязвимость имеет высокую степень опасности, её эксплуатация требует локального доступа. Это означает, что для большинства систем, где Exim работает под выделенным пользователем и не допускает выполнения произвольных команд посторонними, риск остаётся ограниченным. Однако в многопользовательских средах, на общих хостингах или при компрометации низкопривилегированной учётной записи угрозу нельзя игнорировать: она может стать ступенью для полного захвата сервера.
Уязвимость выявлена внешними исследователями; авторы находки не раскрыты. Тем не менее полный тайминг публикации известен: отчёт поступил 22 июня 2026 года, патч был подготовлен на следующий день, а 13 июля уведомление получили ключевые вендоры Linux-дистрибутивов. Публичный релиз состоялся 22 июля - ровно через месяц после сообщения об уязвимости.
Exim остаётся одним из самых распространённых почтовых серверов в интернете, особенно в связке с cPanel и на выделенных серверах. Каждое подобное исправление - напоминание о необходимости своевременного управления обновлениями. Пропуск патча версии 4.99.5 может оставить сервер уязвимым для локальной эскалации привилегий, что на практике часто используется в многошаговых атаках для закрепления в системе и бокового перемещения.
Администраторам следует сверить версию Exim командой "exim -bV" и, при обнаружении версии в диапазоне 4.88-4.99.4, выполнить обновление. В системах, где непосредственная установка из репозитория невозможна, рекомендуется собрать версию 4.99.5 из исходных кодов, доступных по адресу "ftp.exim.org/pub/exim/exim4/". Разработчики также подписали релиз ключом GPG, что позволяет проверить подлинность дистрибутива.
Уязвимость затрагивает и ветку разработки (master), поэтому даже пользователи пререлизных сборок не застрахованы. Флагманский патч, добавленный в исходный код, уже интегрирован в основную ветку.
В целом инцидент не уникален: ошибки в обработке аргументов командной строки - классический вектор, который неоднократно приводил к повышению привилегий в почтовых серверах, системных утилитах и демонах. Хотя локальный характер снижает поверхность атаки, пренебрегать такими уязвимостями не следует: часто именно они становятся ключом к полной компрометации инфраструктуры после первичного проникновения. Регулярный мониторинг бюллетеней безопасности и оперативное обновление критического ПО остаются единственным надёжным способом предотвращения подобных сценариев.
Ссылки
