Разработчики открытого межсетевого экрана для веб-приложений (WAF) ModSecurity выпустили версию 3.0.16, закрывающую две уязвимости разной степени серьёзности. Первая из них, CVE-2026-52761, затрагивает функцию преобразования символов t:utf8toUnicode и позволяет обходить правила безопасности на 32-разрядных системах семейства i386. Вторая, CVE-2026-52747, получила высокий рейтинг опасности и связана с некорректной обработкой multipart-запросов - из‑за неё межсетевой экран может "не заметить" вредоносное содержимое, переданное в составе форм. Проблемы были выявлены участниками команды Core Rule Set (CRS) в ходе автоматизированного тестирования и раскрыты в соответствии с практикой ответственного разглашения.
Детали уязвимостей
Первая уязвимость вызвана ошибкой в коде, отвечающем за преобразование UTF‑8 в шестнадцатеричное представление Unicode. В функции используется оператор sizeof(), применённый к указателю, а не к самому буферу данных. На платформах i386 размер указателя составляет 4 байта, тогда как в реальности переменная имеет длину 8 байт. Из‑за этого результат преобразования обрезается, и правила, полагающиеся на корректную работу t:utf8toUnicode, могут неверно интерпретировать полезную нагрузку злоумышленника. На 64‑разрядных системах размер указателя случайно совпадает с размером буфера, поэтому там уязвимость не проявляется. Для эксплуатации атакующему не требуется аутентификация, а сложность атаки оценивается как низкая. Разработчики рекомендуют отказаться от использования i386, пока патч не развёрнут на всех затронутых узлах.
Вторая уязвимость связана с парсером multipart/form‑data в библиотеке libmodsecurity. В обычной конфигурации ModSecurity обрабатывает тело запроса и передаёт поля формы в переменные ARGS и ARGS_POST, которые затем анализируются правилами межсетевого экрана. Однако из-за ошибки в коде строки, содержащие символы перевода строки (\r\n или \n), теряют эти символы при разборе. Например, значение "A\r\nB" превращается в "AB" перед тем, как попасть к правилам. При этом серверное приложение может получить оригинальное значение с разрывами строк. Такое расхождение - классический пример "различия парсеров", когда WAF и бэкенд видят разные данные. Злоумышленник может воспользоваться этим, чтобы отправить многострочные инъекции или атаки, зависящие от разделителей, при этом правила безопасности их не обнаружат.
Исследователи привели доказательство концепции, в котором как CRLF-, так и LF-варианты многострочных payload обрабатывались как одна строка, а встроенные переменные строгости разбора multipart (MULTIPART_STRICT_ERROR, MULTIPART_LF_LINE, MULTIPART_CRLF_LF_LINES) оставались нулевыми, то есть ModSecurity не маркировал такой запрос как подозрительный. Это подтверждает, что уязвимость нарушает целостность проверки тела запроса и снижает способность межсетевого экрана навязывать политики безопасности.
Обе уязвимости получили оценки по шкале CVSS v3.1: CVE-2026-52761 - 5.3 (средняя), CVE-2026-52747 - 8.6 (высокая). Для обеих атака возможна удалённо без аутентификации и взаимодействия с пользователем. На данный момент нет сведений об активной эксплуатации в реальных условиях, однако вероятность их использования высока, особенно для второй уязвимости, учитывая, как часто ModSecurity развёртывается в качестве фронтальной защиты веб-приложений.
Команда проекта исправила обе проблемы в версии 3.0.16. Для закрытия первой уязвимости достаточно обновления и отказа от устаревшей архитектуры i386. Для второй уязвимости требуется не только установка патча, но и пересмотр наборов правил WAF. Разработчики также советуют добавить механизмы валидации на стороне бэкенда и провести регрессионное тестирование обработки multipart-данных, чтобы обеспечить единообразное восприятие входных данных на всех уровнях безопасности.
Ситуация с ModSecurity в очередной раз напоминает, что даже зрелые и широко распространённые системы защиты могут содержать скрытые расхождения в обработке данных. Парсерные дифференциалы становятся всё более популярным вектором для обхода средств обнаружения, и их поиск требует регулярного тестирования не только сигнатур, но и логики разбора протоколов. Организациям, использующим WAF, следует уделять особое внимание обновлениям встроенных парсеров и своевременно устанавливать патчи, особенно те, что затрагивают разбор HTTP-запросов.
Ссылки
- https://github.com/owasp-modsecurity/ModSecurity/security/advisories/GHSA-qjgm-7gp4-f8qq
- https://github.com/owasp-modsecurity/ModSecurity/security/advisories/GHSA-rcw9-2f5r-7p88
