В форке почтового сервера qmail, поддерживаемом проектом Sagredo, обнаружена критическая уязвимость удалённого выполнения кода (CVE-2026-41113). Ошибка позволяет удалённому злоумышленнику запускать произвольные команды на уязвимом сервере с правами пользователя qmailr. Исполнение происходит в контексте системной оболочки и может использоваться как для разведки системы, так и для дальнейшего развития атаки.
Проблема связана с тем, как форк qmail обрабатывал имена почтовых серверов, возвращаемые DNS при определении MX-записей домена. Имя хоста, полученное из DNS‑ответа, не проходило должного экранирования специальных символов и фильтрации, после чего напрямую подставлялось в строку команды, передаваемую функции popen(). В результате появлялась классическая возможность инъекции команд через оболочку.
Уязвимость появилась после внесённого в октябре 2024 года изменения в утилиту qmail-remote. В неё добавили функцию notlshosts_auto, призванную повысить надёжность доставки почты. Эта функция автоматически запоминает хосты, с которыми не удаётся установить TLS-соединение из-за некорректной реализации протокола на их стороне. Идея заключалась в том, чтобы один раз зафиксировать проблемный хост и затем не пытаться снова отправлять ему почту по TLS, избегая зацикливания неудачных попыток.
Реализация механизма запоминания "плохих" хостов оказалась небезопасной. Для записи имени таких серверов использовался вызов системной оболочки через popen() с аргументом вида:
`"/bin/touch %s/control/notlshosts/'%s'"`
Во второй форматный спецификатор подставлялось значение MX-хоста, возвращённое DNS-сервером. Предполагалось, что имя домена будет безопасной строкой, но никаких гарантий или проверок на это не делалось. В случае, если в имени содержались специальные символы оболочки, они могли интерпретироваться как часть команды.
Злоумышленник мог развернуть или контролировать DNS-сервер, отвечающий на запросы MX для целевого домена, и вернуть заведомо злонамеренное имя, например:
`x'`id>/tmp/pwned`'y.evil.com`
Из-за некорректного экранирования и прямой подстановки этого имени в команду, оболочка интерпретировала фрагмент `` `id>/tmp/pwned` `` как подкоманду, подлежащую выполнению. В результате при срабатывании механизма notlshosts_auto на сервере выполнялся произвольный код, а вывод команды сохранялся в указанный файл. Таким образом, достаточно было создать условия, при которых qmail-remote сочтёт TLS-соединение с таким MX-хостом проблемным и попытается сохранить его имя.
Важный момент: команды выполняются с правами пользователя qmailr. Это не root, однако в типичных конфигурациях qmailr имеет доступ к части почтовой инфраструктуры, что уже создаёт серьёзный риск. В зависимости от окружения и настроек системы, такая точка входа может использоваться для дальнейшего повышения привилегий, чтения служебных файлов почтовой системы или организации плацдарма для последующих атак.
Разработчики форка Sagredo устранили уязвимость в выпуске с пометкой 2026.04.07. В обновлённой версии реализовано корректное обращение с данными, получаемыми из DNS: имя хоста больше не передаётся оболочке без фильтрации и разделения аргументов. Администраторам, использующим данный форк qmail, настоятельно рекомендуется оперативно обновиться до исправленного релиза и проверить, не были ли зафиксированы подозрительные записи в системных логах и в каталоге notlshosts.
Дополнительный фактор риска состоит в том, что в открытом доступе уже опубликован инструментарий для эксплуатации этой уязвимости. Это означает, что для атаки не требуется высокой квалификации: достаточно запустить готовый эксплойт, настроенный на нужный домен и DNS‑сценарий. В сочетании с тем, что уязвимость затрагивает инфраструктурный компонент - почтовый сервер - это значительно повышает практическую опасность CVE-2026-41113.
Интересная деталь: баг был найден с помощью AI-ассистента. В процессе анализа кода и обсуждения возможных проблем была использована нейросетевая модель, которая подсветила потенциальную точку уязвимости во взаимодействии с оболочкой. Это ещё раз демонстрирует, что инструменты искусственного интеллекта начинают играть заметную роль не только в автоматизации задач, но и в поиске уязвимостей, выступая в роли дополнительного "ревьюера" кода.
С точки зрения безопасности, данный инцидент - классический пример опасности использования оболочки для конструирования команд из недоверенных данных. Любая строка, которая формируется с участием внешнего ввода (в данном случае - DNS-ответ), не должна напрямую подставляться в командную строку без строгого экранирования, валидации и, по возможности, без участия shell вообще. При наличии функций наподобие execve с передачей аргументов массивом необходимость в оболочке часто отпадает, а вместе с ней исчезает целый класс инъекций.
Отдельно стоит отметить роль DNS в атаке. Многие администраторы по привычке считают имена хостов и DNS‑данные чем-то относительно доверенным, хотя на практике атакующий нередко может контролировать или подменять эти записи - особенно если речь идёт о доменах, владельцем которых он сам и является. Использовать DNS‑ответы как "безопасный" источник для формирования команд - фундаментальная ошибка моделирования угроз.
Для администраторов и разработчиков почтовых систем данный инцидент - повод пересмотреть свои подходы к обработке внешних данных. Важно не только обновиться до исправленной версии форка Sagredo, но и провести аудит других мест, где в коде используются popen и shell-команды с подстановкой строк, пришедших извне: из DNS, из заголовков писем, конфигурационных файлов, пользовательского ввода и т. д. Любой подобный фрагмент может таить в себе подобную же уязвимость.
Рекомендуется также внедрить дополнительные меры контроля: мониторинг необычных записей в каталогах служебных файлов (например, тех же notlshosts), отслеживание аномальных команд, запускаемых от имени системных пользователей вроде qmailr, и настройку механизмов обнаружения атак. Простая проверка на наличие неожиданных строк в файлах, куда записываются имена хостов, способна заметно упростить расследование.
Этот случай показывает, как даже небольшое "удобное" улучшение - автоматическое запоминание проблемных TLS‑хостов - может обернуться критической дырой в безопасности, если не учитывать модель угроз и не относиться к любым внешним данным как к потенциально враждебным. В экосистеме почтовых серверов, где пересекаются сеть, DNS, криптография и файловая система, подобные ошибки особенно чувствительны.
В итоге уязвимость в форке qmail от Sagredo - наглядный пример того, что безопасность нельзя "дописывать" поверх функциональности; она должна закладываться в архитектуру изначально. Использование нейросетевых ассистентов для анализа кода, регулярный аудит мест, где запускается shell, и внимательное отношение к данным из DNS и других внешних источников - те уроки, которые имеет смысл вынести из истории с CVE-2026-41113.
