Skip to content
KitploitKITPLOIT
HerramientasBlog
Enviar
HerramientasBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
nginx-rift-check — Detecta el patrón de rewrite de CVE-2026-42945 en configuraciones de nginx: rewrite con `?` en el reemplazo más una captura sin nombre consumida en la misma location | Kitploit
Herramientas/GitHubGitHub/cynepmyx/nginx-rift-check
Análisis EstáticoEscáneres de VulnerabilidadesAnálisis de VulnerabilidadesAuditoría de ConfiguraciónSeguridad Web
GitHubcynepmyx/nginx-rift-check

nginx-rift-check

Detecta el patrón de rewrite de CVE-2026-42945 en configuraciones de nginx: rewrite con `?` en el reemplazo más una captura sin nombre consumida en la misma location

Ver Repositorio
hace 7 díasAún no revisado

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir

nginx-rift-check

Encuentra configuraciones vulnerables a CVE-2026-42945, el desbordamiento de búfer en el heap del ngx_http_rewrite_module de nginx.

Ejecutar una versión afectada de nginx (de 0.6.27 a 1.30.0) no es suficiente para ser explotable. La configuración debe contener un par específico de directivas, y ese par es raro: dos escaneos independientes de configuraciones reales encontraron cero explotables de 1465 y uno de 35633. Este script te dice en qué lado de esa línea estás.

Qué busca

Un rewrite cuyo reemplazo contiene un ? con argumentos después, seguido de una captura sin nombre ($1 a $9) leída en el mismo location:

root@kitploit:~
location / {
    rewrite ^(.*) /new?c=1;   # the ? here raises the internal is_args flag
    set $myvar $1;            # ...which was never cleared, and leaks into this
    return 200 $myvar;
}

Una pasada dimensiona el búfer para la cadena cruda; la siguiente copia una versión escapada en él. Ambas mitades parecen correctas por sí solas.

Las reglas provienen de un banco de pruebas, no del aviso

Cada regla a continuación fue medida en nginx 1.30.0 en lugar de inferida, porque las descripciones publicadas se equivocan en dos de ellas.

Dos consecuencias que vale la pena explicitar:

Un ? final no es peligroso. /new/$1? es la forma de eliminar la cadena de consulta heredada, y aparece en una gran parte de las configuraciones de migración. Marcar todos los ? le gritaría a media internet.

“Las capturas con nombre son seguras” está mal planteado. Lo que importa es cómo se lee la captura, no cómo se declaró. Un grupo con nombre leído como $1 falla exactamente igual que uno sin nombre.

También se ignoran, por las mismas razones medidas: un ? dentro de la propia regex (un cuantificador), y redirect / permanent / break, que terminan el procesamiento antes de que se ejecute el consumidor.

Uso

root@kitploit:~
nginx -T | python3 check_rewrite.py
python3 check_rewrite.py /path/to/dump.txt
python3 check_rewrite.py --json /path/to/dump.txt

Python 3, solo biblioteca estándar.

Códigos de salida: 0 limpio, 1 se encontró un par, 2 no se pudo leer o analizar la configuración. El tercero es el punto clave: una comilla sin cerrar o llaves desbalanceadas truncan el análisis, y un comprobador que responda "nada encontrado" para un archivo que no pudo leer es peor que uno que falle. Cuando eso ocurre, lo dice y devuelve 2.

Pásale nginx -T, no archivos individuales: los includes pueden estar en cualquier lugar, y una configuración generada solo es real en el servidor en ejecución. Los hallazgos se notifican contra el archivo y la línea donde vive realmente la directiva, no el desplazamiento en el volcado.

Ejemplo

root@kitploit:~
$ python3 check_rewrite.py samples/vuln-nginx-T.txt
[HIGH] находка #1
  location:  location /  (/etc/nginx/nginx.conf:14)
  rewrite:   rewrite ^(.*) /new?c=1  (/etc/nginx/nginx.conf:15)
  захват $N: set -> set $myvar $1  (/etc/nginx/nginx.conf:16)
  почему:    обработка продолжается в этом же location без редиректа

Итого находок: 1

Límites que vale la pena conocer

También se imprimen al final de cada informe, para que nadie confunda la herramienta con una garantía:

  • solo se notifica el primer par por location;
  • rewrite y set que están directamente en server en lugar de dentro de un location no se rastrean;
  • las cadenas transitivas (set $tmp $1; y luego usar $tmp) no se siguen;
  • los saltos a través de try_files, error_page y ubicaciones con nombre no se siguen;
  • no se evalúa la alcanzabilidad: un par dentro de un if que nunca se activa se notifica igualmente.

Actualizar es más fiable que cualquier comprobación de configuración. Toma la versión estable o mainline actual de nginx.org.

Pruebas

root@kitploit:~
python3 -m unittest test_check_rewrite -v

29 pruebas. La mayoría son casos negativos, ya que el riesgo en una herramienta así es gritarle a configuraciones que están bien. También se ha ejecutado contra una configuración de producción de 250 líneas repartidas en once archivos incluidos, con una regex en map y una cabecera CSP llena de punto y coma dentro de comillas: cero hallazgos, cero quejas de análisis, y exactamente un hallazgo una vez que se inyectó un par real en ella.

Licencia

MIT

Descargar herramienta
Config dentro de un location¿Falla?
rewrite ^(.*) /new?c=1; + set $x $1;sí
rewrite ^/old/(.*)$ /new?x=1; + set $x $1;sí
rewrite ^/old/(.*)$ /new/$1?; + set $x $1;no
rewrite ... /mid?c=1; then rewrite ... /new; then set $x $1;no
rewrite ^(.*) /new?c=1 break; + set $x $1;no
rewrite ^(?<tail>.*) /new?c=1; + set $x $1;sí
rewrite ^(?<tail>.*) /new?c=1; + set $x $tail;no