CVE-2026-42945 - Анализ уязвимости NGINX Rift и воспроизведение

Обзор

CVE-2026-42945 (с кодовым названием "NGINX Rift") — это переполнение кучи (heap buffer overflow) в модуле ngx_http_rewrite_module NGINX. Оценка CVSS v4: 9.2 (Critical).

Уязвимость была обнаружена исследовательской группой depthfirst в апреле 2026 года и скрывалась в NGINX 18 лет, начиная с версии 0.6.27 (введена в 2008 году).

Затронутые версии

• NGINX Open Source 0.6.27 ~ 1.30.0
• NGINX Plus R32 ~ R36
• NGINX Instance Manager 2.16.0 ~ 2.21.1
• F5 WAF for NGINX 5.9.0 ~ 5.12.1
• NGINX App Protect WAF 4.9.0 ~ 4.16.0 и 5.1.0 ~ 5.8.0
• NGINX Gateway Fabric 1.3.0 ~ 1.6.2 и 2.0.0 ~ 2.5.1
• NGINX Ingress Controller 3.5.0 ~ 3.7.2, 4.0.0 ~ 4.0.1, 5.0.0 ~ 5.4.1

Исправленная версия

• NGINX 1.31.0 (выпущен 13 мая 2026 года)

Условия срабатывания

Для возникновения уязвимости необходима следующая конфигурация NGINX:

location ~ ^/api/(.*)$ {
    rewrite ^/api/(.*)$ /internal?migrated=true;
    set $original_endpoint $1;
}

Ключевые условия:

1. Строка замены в директиве rewrite содержит ? (вопросительный знак)
2. Последующая директива set ссылается на группу захвата регулярного выражения (например, $1)
3. URI запроса содержит символы, подлежащие экранированию (например, +, &, % и т.д.)

Анализ первопричины

Двухфазная обработка скриптового движка

Скриптовый движок NGINX использует двухфазную обработку для выполнения директив rewrite/set:

1. Первая фаза (вычисление длины): вычисляет размер памяти, необходимой для итоговой строки
2. Вторая фаза (копирование данных): записывает реальные данные в выделенный буфер

Переполнение из-за несоответствия состояния

Ключевая проблема — несоответствие состояния движка между двумя фазами:

Фаза 1: rewrite устанавливает флаг is_args

Когда строка замены директивы rewrite содержит ?, функция ngx_http_script_start_args_code устанавливает:

void ngx_http_script_start_args_code(ngx_http_script_engine_t *e)
{
    e->is_args = 1;  // Устанавливается навсегда, никогда не сбрасывается!
    e->args = e->pos;
    e->ip += sizeof(uintptr_t);
}

Фаза 2: Вычисление длины для директивы set использует новый поддвижок

Когда последующая директива set ссылается на группу захвата, ngx_http_script_complex_value_code создаёт обнулённый поддвижок:

void ngx_http_script_complex_value_code(ngx_http_script_engine_t *e)
{
    ngx_http_script_engine_t le;
    // ...
    ngx_memzero(&le, sizeof(ngx_http_script_engine_t)); // le.is_args = 0
    le.ip = code->lengths->elts;

Фаза 3: Расхождение между вычислением длины и реальным копированием

Вычисление длины (использует поддвижок le, is_args=0):

// ngx_http_script_copy_capture_len_code
if ((e->is_args || e->quote) && (e->request->quoted_uri || e->request->plus_in_uri))
{
    // is_args=0, условие ложно, выполняется ветка else
    return cap[n + 1] - cap[n];  // Возвращается исходная длина (неэкранированная)
}

Реальное копирование (использует основной движок e, is_args=1):

// ngx_http_script_copy_capture_code
if ((e->is_args || e->quote) && (e->request->quoted_uri || e->request->plus_in_uri))
{
    // is_args=1, условие истинно, выполняется ветка if
    e->pos = (u_char *) ngx_escape_uri(pos, &p[cap[n]],
                                        cap[n + 1] - cap[n],
                                        NGX_ESCAPE_ARGS);
    // Каждый экранируемый символ расширяется с 1 байта до 3 байт!
}

Размер переполнения

• Размер выделенного буфера: raw_size (исходная длина захвата)
• Фактический размер записанных данных: raw_size + 2 * N (N = количество экранируемых символов)
• Переполнение: 2 * N байт

Например, если URI содержит 100 символов +, переполнение составит 200 байт.

Способы эксплуатации

1. DoS (отказ в обслуживании)

Самый простой способ — отправить запрос с большим количеством экранируемых символов, что приводит к аварийному завершению рабочего процесса:

GET /api/+++++++++++++++++++++++++++++++++++ HTTP/1.1
Host: target.com

2. RCE (удалённое выполнение кода)

Полная цепочка RCE (требуется отключённый или обойдённый ASLR):

1. Контроль компоновки кучи: управление компоновкой ngx_pool_t через порядок соединений
2. Переполнение для перезаписи указателя cleanup: переполнение до соседней структуры пула памяти
3. Внедрение поддельной структуры cleanup: через тело POST-запроса внедряется поддельная структура, содержащая адрес system()
4. Запуск выполнения: закрытие уязвимого соединения, что запускает ngx_destroy_pool, обходящий цепочку cleanup

Многопроцессная архитектура NGINX делает эксплуатацию более надёжной — после аварийного завершения рабочего процесса мастер порождает новый рабочий процесс с идентичной компоновкой памяти.

Описание файлов

• README.md — данный файл, документ с анализом уязвимости
• Dockerfile — создание уязвимого окружения NGINX
• nginx.conf — конфигурация NGINX для активации уязвимости
• poc_crash.py — PoC DoS (вызов аварийного завершения рабочего процесса)
• docker-compose.yml — запуск тестового окружения одной командой

Быстрое воспроизведение

# 1. Сборка и запуск уязвимого NGINX
docker-compose up -d

# 2. Запуск DoS PoC
python3 poc_crash.py

# 3. Просмотр журнала ошибок NGINX для подтверждения аварийного завершения
docker-compose logs nginx

Ссылки

• Официальный CHANGES NGINX — объявление об исправлении
• Исследовательский отчёт depthfirst — технический анализ первооткрывателей уязвимости
• Уведомление безопасности F5 K000160932 — официальное уведомление безопасности

Отказ от ответственности

Данный материал предназначен только для исследовательских и образовательных целей. Не используйте эту информацию для несанкционированных атак.