Уязвимость Exim с идентификатором CVE-2026-45185 позволяет удалённо выполнить код без аутентификации на ряде почтовых серверов. Под удар попали версии Exim 4.97-4.99.2 в сборках с GnuTLS, а для администраторов Linux-инфраструктуры это не очередная «теоретическая» проблема из базы CVE, а прямой повод срочно проверить конфигурации MTA и график обновлений.
О проблеме сообщает BleepingComputer: баг относится к классу use-after-free и срабатывает в момент завершения TLS-сессии при обработке chunked SMTP-трафика через BDAT. Проще говоря, Exim освобождает буфер TLS, а затем продолжает работать с уже недействительными callback-ссылками, которые могут записывать данные в освобождённую область памяти. Если такая цепочка звучит как плохая идея, то потому что это и есть плохая идея: результатом может стать удалённое выполнение произвольного кода на сервере без логина, пароля и прочих лишних церемоний.
Затронуты не все установки Exim подряд, а вполне конкретный набор условий. Уязвимыми названы версии с 4.97 по 4.99.2, собранные с библиотекой GnuTLS, если сервер объявляет STARTTLS и CHUNKING. Сборки на OpenSSL, по имеющимся данным, этой проблеме не подвержены. Это важная деталь для тех, кто привык смотреть только на номер версии пакета: одного совпадения по версии мало, нужно ещё понимать, как именно собран ваш Exim и какие SMTP-возможности он публикует наружу. В реальной эксплуатации это особенно неприятно для shared hosting, корпоративных почтовых систем и классических Linux-серверов, где Exim годами жил тихо и никому не мешал, пока не оказался удобной целью.
Риск здесь не сводится к абстрактному «возможен компромисс сервиса». По описанию исследователей, успешная эксплуатация даёт атакующему возможность выполнять команды на сервере, получать доступ к данным Exim и почтовому содержимому, а дальше уже двигаться по инфраструктуре настолько далеко, насколько позволят права процесса и общая конфигурация системы. Для бизнеса это означает не только простой или восстановление хоста, но и потенциальный доступ к переписке, служебным вложениям, паролям из писем, токенам восстановления и другой чувствительной информации, которая у почтового узла, как правило, есть в избытке. Для разработчиков и DevOps-команд вывод тоже неприятный, но понятный: почтовый сервер остаётся инфраструктурным активом первого класса, даже если про него вспоминают только в день, когда перестала ходить почта.
Уязвимость обнаружил и передал мейнтейнерам Exim исследователь XBOW Федерико Киршбаум. По таймлайну, опубликованному в материале, XBOW уведомила разработчиков 1 мая, подтверждение получила 5 мая, а ещё через три дня были оповещены затронутые Linux-дистрибутивы. Исправление уже выпущено в версии Exim 4.99.3. Для администраторов Debian- и Ubuntu-систем это, пожалуй, самая приземлённая часть истории: не нужно изобретать экзотический workaround, нужно поставить обновление через штатный пакетный менеджер и убедиться, что в репозитории приехал именно патченный пакет. Если обновление по каким-то причинам задерживается, стоит хотя бы проверить, используется ли GnuTLS и рекламируются ли STARTTLS с CHUNKING на внешнем интерфейсе.
Отдельный сюжет в этой истории связан не только с самой дырой, но и с тем, как для неё пытались собрать рабочий exploit. XBOW описывает это как семидневное соревнование между своим автономным AI-инструментом XBOW Native и человеком-исследователем, которому помогала большая языковая модель. Автоматизированная система смогла получить рабочий результат на упрощённой конфигурации Exim без ASLR и с non-PIE-бинарником. Во второй попытке LLM помогла добиться эксплуатации на машине с ASLR, но всё ещё без PIE. Исследователи отдельно отметили, что ИИ в какой-то момент пошёл не по стандартному пути атаки на allocator из glibc, а переключился на собственный allocator Exim. Звучит эффектно, но финал у истории отрезвляющий: победил всё же человек, а языковая модель оказалась сильным ускорителем рутинных и исследовательских задач, а не самостоятельным автором production-grade exploit для реальной цели.
Эта часть материала важна не меньше самого CVE, потому что хорошо описывает текущий баланс сил. Условный «AI уже сам ломает прод» пока остаётся скорее заголовком для конференции, чем повседневной операционной реальностью. Но и отмахиваться от инструмента как от игрушки уже поздно. Если модель помогает быстрее разбирать чужой код, собирать файлы, тестировать гипотезы и находить подозрительные участки, то скорость подготовки атаки объективно растёт даже там, где последний километр всё ещё делает человек. Для защитников это означает неприятную, но честную вещь: окно между публикацией бага и появлением практичных сценариев эксплуатации сжимается, а «успеем на следующем maintenance window» всё чаще переводится как «поиграем в рулетку».
Для русскоязычной IT-аудитории практический вывод довольно жёсткий. Если Exim у вас стоит «потому что так исторически сложилось» и никто давно не помнит, как он собран, это уже отдельная проблема управления инфраструктурой. Уязвимость Exim в очередной раз показывает, что почтовый слой нельзя держать в слепой зоне: нужны инвентаризация, понимание криптобиблиотек в сборке, быстрый процесс установки патчей и хотя бы минимальная проверка того, что сервер реально экспонирует наружу. И следующий тренд здесь очевиден: обсуждать будут не только саму уязвимость Exim, но и то, как быстро команды умеют закрывать такие баги до того, как исследовательский PoC превращается в массовый инструмент для атак.