Si instalaste Nginx siguiendo nuestra guía, revisa esto: una falla crítica (CVSS 9.2) ya tiene una herramienta de explotación pública

Hace unos días publicamos aquí la guía para instalar Nginx desde cero en un VPS. Si la seguiste, o si ya administras un servidor con Nginx desde antes, este es el tipo de aviso que vale la pena revisar de verdad, no solo leer por encima: existe una vulnerabilidad crítica en el propio Nginx, con parche disponible desde hace meses, y esta semana apareció públicamente en GitHub una herramienta que automatiza su explotación.

La falla, registrada como CVE-2026-42945 en la base de datos oficial de vulnerabilidades del NIST (NVD) el 13 de mayo de 2026, afecta tanto a NGINX Open Source como a NGINX Plus. El problema vive en el módulo ngx_http_rewrite_module, la parte de Nginx que se encarga de reescribir URLs — algo extremadamente común en configuraciones reales, desde redirecciones simples hasta reglas de enrutamiento más elaboradas. La causa técnica exacta es específica: cuando una directiva rewrite con un grupo de captura de expresión regular sin nombre (del tipo $1, $2) va seguida, en el mismo bloque, de otra directiva rewrite, if o set cuya cadena de reemplazo incluye un signo de interrogación, el módulo calcula mal el tamaño del buffer de memoria que necesita — el resultado es un desbordamiento de memoria (heap buffer overflow) que un atacante remoto, sin necesidad de autenticarse, puede usar para tumbar el proceso, y en ciertas condiciones, ejecutar código arbitrario en el servidor. El puntaje de severidad asignado es 9.2 sobre 10 — crítico, en la categoría más alta posible.

La buena noticia es que el parche ya existe: Nginx corrigió el problema en la versión 1.30.1, disponible desde antes de que la vulnerabilidad se hiciera pública. Si instalaste Nginx desde los repositorios oficiales de tu distribución en los últimos meses, es probable que ya tengas una versión corregida — pero "probable" no es lo mismo que "confirmado", y verificarlo toma diez segundos.

Lo que cambia el panorama esta semana no es la vulnerabilidad en sí —lleva meses siendo pública— sino que apareció en GitHub una herramienta llamada nGixShell: un framework que incluye una prueba de concepto funcional para explotar específicamente esta falla, junto con un escáner que cubre otras 52 vulnerabilidades conocidas de Nginx, con detección automática de configuración vulnerable y capacidad de evadir sistemas de protección web (WAF). No hace falta ser un atacante sofisticado para usarla — está escrita en Python puro, sin dependencias externas, lista para correr. Este es exactamente el tipo de evento que históricamente precede a oleadas de escaneo masivo contra servidores sin actualizar: cuando explotar una falla deja de requerir conocimiento experto y pasa a ser "ejecutar un script", el número de intentos de ataque sube de forma proporcional. Ya vimos ese mismo patrón con el ransomware Sorry contra cPanel/WHM hace unos meses — la falla llevaba semanas parchada cuando la ola de ataques masivos arrancó en serio.

Si administras un servidor con Nginx, hay dos pasos concretos que tomar hoy, no "cuando tengas tiempo". Primero, verifica tu versión con nginx -v y actualiza si estás por debajo de la 1.30.1. Segundo —y esto aplica incluso si ya estás en una versión parchada, porque nunca está de más—: revisa tu propia configuración buscando el patrón específico que activa el problema (una directiva rewrite con captura sin nombre seguida de otra rewrite, if o set con un signo de interrogación en el reemplazo) y, si la encuentras, cámbiala por grupos de captura con nombre — una mitigación que no depende de la versión que tengas instalada.

Ninguna de estas dos verificaciones toma más de unos minutos. La diferencia entre hacerlas hoy y hacerlas después de que algo falle es, como ya hemos visto varias veces este mes, la diferencia entre un aviso que leíste y un incidente que tuviste que explicar.