Уязвимость в развиваемом проектом Sagredo почтовом сервере qmail позволяет выполнить произвольный код через подделку DNS-записей

В развиваемом сообществом форке классического почтового сервера qmail, известного своим изначально высоким уровнем безопасности, обнаружена критическая уязвимость удалённого выполнения кода (RCE). Проблема, получившая идентификатор CVE-2026-41113, затрагивает версии проекта с октября 2024 года по апрель 2026 года. Уязвимость позволяет злоумышленнику, способному контролировать DNS-записи домена, на который целевой сервер пытается отправить электронную почту, выполнить произвольные команды на почтовом сервере с правами пользователя qmailr. Разработчики устранили проблему в выпуске от 7 апреля 2026 года, однако в открытом доступе уже появился инструментарий для эксплуатации, что повышает актуальность немедленного обновления.

Уязвимость CVE-2026-41113

Инцидент является ярким примером того, как добавление новых функций в устоявшееся и считающееся безопасным программное обеспечение может непреднамеренно создать новые векторы атаки. В октябре 2024 года в проект была добавлена функция "notlshosts_auto", предназначенная для повышения надёжности работы. Её задача - предотвращать зацикливание попыток отправки почты на серверы с некорректной реализацией шифрования TLS. При неудачном TLS-рукопожатии система должна была запоминать проблемный хост, создавая файл с его именем в специальном каталоге, чтобы в будущем не тратить время на повторные попытки использовать шифрование.

Однако реализация этой логической защиты содержала фундаментальную ошибку. Имя хоста, полученное из DNS-записи MX (Mail Exchange), подставлялось в строку, которая затем выполнялась как команда операционной системы с помощью функции "popen()". Автор кода попытался экранировать имя хоста, заключив его в одинарные кавычки в команде вида "/bin/touch /путь/control/notlshosts/'ИМЯ_ХОСТА'". Этот подход оказался недостаточным и создал классическую уязвимость типа "инъекция команд оболочки" (shell injection).

Основное заблуждение при разработке заключалось в предположении, что имена хостов не могут содержать специальных символов. С точки зрения стандартов и удобства пользователя это верно: доменные имена обычно состоят из букв, цифр и дефисов. Однако на уровне сетевого протокола DNS (Domain Name System) метка (часть имени домена) представляет собой длину и последовательность байтов. Спецификация RFC 1035 допускает использование практически любых байтовых значений, включая символы, имеющие особое значение для командной оболочки, такие как обратная кавычка ("" " ""), одинарная кавычка ("'"), амперсанд ("&") и другие.

Когда qmail-сервер запрашивает MX-запись и получает ответ, стандартная библиотека C ("glibc") с помощью функции "dn_expand()" преобразует полученные байты в строковое представление. Критически важно, что эта функция не экранирует опасные символы. Следовательно, если злоумышленник управляет DNS-сервером и возвращает в MX-записи имя вида "x'"id>/tmp/hacked"'y.evil.com", после обработки "dn_expand()" строка "partner_fqdn" будет содержать именно эту последовательность.

При формировании команды для "popen()" строка будет вставлена внутрь одинарных кавычек. В результате командная оболочка увидит следующее: "/bin/touch /путь/control/notlshosts/'x'"id>/tmp/hacked"'y.evil.com'". С точки зрения синтаксиса shell, первые одинарные кавычки закрываются после "x", после чего идут обратные кавычки, которые интерпретируются как команда для выполнения. Команда "id>/tmp/hacked" выполняется, а оставшаяся часть строки игнорируется. Таким образом, атакующий получает возможность запустить на сервере произвольный код.

Данный случай интересен не только своей технической стороной, но и контекстом. Оригинальный qmail, написанный Дэниелом Дж. Бернстайном в 1995 году, долгое время считался эталоном безопасного проектирования. Его архитектура, основанная на принципе разделения привилегий между несколькими изолированными процессами, была предметом академических исследований. Со временем развитие интернета потребовало добавления в код поддержки современных протоколов, таких как TLS, SPF, DKIM, что привело к появлению множества патчей и форков, включая проект Sagredo.

Уязвимость CVE-2026-41113 находится не в оригинальном коде Бернстайна, а в одном из таких добавленных сообществом патчей. Это наглядно демонстрирует ключевой принцип безопасности: гарантии корректности и защищённости относятся к конкретной версии кода. Любые модификации, даже направленные на улучшение, требуют столь же тщательного анализа и аудита, как и исходная кодовая база. Более того, изменения могут нарушить изначальные предпосылки безопасности, заложенные автором.

Для эксплуатации уязвимости злоумышленнику необходимо, чтобы атакуемый сервер попытался отправить почту на контролируемый злоумышленником домен. Это может быть инициировано, например, через фишинг-письмо с запросом автоматического ответа, через подписку на рассылку или в результате обработки отскока (bounce). Учитывая, что публичный эксплойт уже доступен, риск целевых атак возрастает.

Основной и единственной рекомендуемой мерой защиты является немедленное обновление почтового сервера до версии sagredo-dev/qmail 2026.04.07 или новее, в которой проблема устранена. Исправление заменяет опасный вызов "popen()" на использование безопасных функций файлового ввода-вывода ("open()", "write()", "close()"), что полностью исключает возможность инъекции команд. Администраторам, использующим данный форк qmail, также следует проверить, активна ли у них опция "control/notlshosts_auto". Временным решением для тех, кто не может немедленно обновиться, может быть отключение этой функции, однако это лишит сервер механизма избегания проблемных TLS-хостов.

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

В конечном счёте, история с CVE-2026-41113 служит важным напоминанием для всего сообщества разработчиков и специалистов по безопасности. Даже наследие, имеющее репутацию "самого безопасного программного обеспечения", не защищено от рисков, возникающих при его адаптации к современным реалиям. Непрерывный аудит, включая анализ вновь добавляемого кода, и своевременное применение обновлений остаются краеугольными камнями поддержания защищённости любых, даже самых надёжных с исторической точки зрения, систем.

Уязвимость CVE-2026-41113

Ссылки