TL;DR: Столкнувшись с третьим обнаруженным за 2026 год переполнением буфера (и, по версии F5, RCE если нет ASLR) при работе с регэкспами и переменными, разработчик freenginx Максим Дунин решил, что пора это прекращать, и добавил в свой продукт проверку размера переменной перед тем как записывать в неё данные. Оттуда это нововведение утащили к себе и nginx, что даёт надежду на прекращение новых CVE на эту тему.
Теперь подробности.
19 июня был сделан коммит в freenginx, добавляющий в описатель переменной поле end, указывающее на конец буфера. Раньше там был только указатель на его начало (pos), нужная длина вычислялась (и сейчас вычисляется) заранее, и к моменту копирования в переменную данных предполагалось что правильно вычисленная ранее длина гарантирует, что данные в буфер влезут. К сожалению, уже два раза в мае 2026 года из-за различных недосмотров это оказывалось не так (1 (linux.org.ru), 2 (linux.org.ru)), что приводило к переполнениям буфера и плохим последствиям. Так вот, теперь при создании буфера переменной заполняется и указатель на её конец, а перед записью в переменную данных, если данные в неё не влезают, обработка запроса будет контролируемо завершаться с ошибкой. То есть ошибки вычисления длины могут находиться и дальше, но они будут теперь не бить память, а только фейлить конкретный http-запрос. Следующими коммитами (2 (freenginx.org), 3 (freenginx.org)) была добавлена аналогичная защита в другие места кода, включая код ведения access-лога. 7 июля была опубликована версия freenginx 1.31.3, включающая данное исправление.
15 июля данные коммиты были заимствованы nginx-ом (1 (github.com), 2 (github.com), 3 (github.com), почему-то поменяв местами второй и третий в цепочке), проблеме был назначен CVE-2026-42533, а F5 выпустило официальное SA (f5.com).
Касательно конкретной уязвимости на этот раз: она проявляется при использовании директивы map с регэкспами с выделяемыми параметрами. По поводу остальных необходимых для её срабатывания условий текст в описании коммита и текст в SA немного разнятся: в SA указано что в дальнейшем должно быть вычисление некоей строки, которое использует выделяемый параметр, оставшийся от map, раньше чем результат этого же map. В описании коммита в примере между этими шагами участвует ещё обнуление переменной, содержащей выделенный параметр. Как бы то ни было, в большинстве запущеных nginx-ов подобное скорее всего не встретится, и уязвимость таким образом мало кого затрагивала. Стоит так же отметить, что исправления расчёта длины конкретно в этом случае в закоммиченых правках кажется нет (или я плохо искал?), есть только защита, превращающая проблему в контролируемый фейл http-запроса. Хотя 19 июля в freenginx добавлены какие-то исправления (5bfb, 7622, b906) подсчёта длины для похожей ситуации, но точно сходу не понять, то это или нет.
Уязвимость появилась в версии nginx 0.9.6, исправления попали в версии freenginx 1.31.3, nginx 1.30.4, nginx 1.31.3.
В SA nginx указаны благодарности ряду лиц за независимые сообщения об уязвимости и соблюдение «стандартов скоординированного раскрытия информации»:
F5 acknowledges Ming Xuan, DKD (@pidifn), Ji'an Zhou, and Zhen Yan of AntAISecurityLab, Rafael Gacek, Sergii Negodiuk of EVO.company, Lam Jun Rong of Calif.io, Mufeed VH of Winfunc Research (winfunc.com), Vexera AI (https://vexera.ai), Tu Tran Dinh (@1w4y), Stan Shaw (cyberstan), qianshuidewajueji, zenneth (randomguy6407), Zhenpeng (Leo) Lin of depthfirst, Lukas Johannes Moeller, Melih Tolga Sahin of Vodafone Türkiye, Ayoub Nabil Boubagrat (GitHub: @ayoubnabil), and Milan Jovic (Kljunowsky) for independently bringing this issue to our attention and following the highest standards of coordinated disclosure.
В freenginx сопровождающая информация об исправлении фактически ограничивается сообщением при коммите. В changelog-е данное исправление даже не помечено ни подписью «безопасность» (security), ни «исправление» (bugfix), просто «добавление» (feature). Вероятно, автор не считал данную проблему критической. Как соотносятся сообщения о проблеме со стороны указанных лиц в F5 и заимствованный из freenginx коммит, сообщали ли они (или кто-то ещё) про проблему автору freenginx, выяснить не удалось.
>>> Коммит
