Cómo parchear la vulnerabilidad crítica de NGINX en Debian 13 y Alpine Linux

Guía paso a paso con errores reales del proceso de actualización, cambios de sintaxis en HTTP/2 y diferencias entre gestores de paquetes.

En mayo de 2026 se publicó una vulnerabilidad crítica en NGINX que afecta a millones de servidores. Esta guía documenta el proceso real de actualización en dos entornos distintos, Debian 13 y Alpine Linux, incluyendo los problemas encontrados y cómo resolverlos.

La vulnerabilidad: CVE-2026-42945 (NGINX Rift)

El detonante de esta actualización fue NGINX Rift, un heap buffer overflow crítico que llevaba 18 años sin detectarse en el código de NGINX. El fallo vive en ngx_http_rewrite_module, incluido en toda instalación estándar de NGINX, y se activa cuando una directiva rewrite combina capturas PCRE sin nombre (la sintaxis $1, $2) con un string de reemplazo que contiene un signo de pregunta, seguido de otro rewrite, if o set. NGINX calcula el tamaño del buffer con un método de escape pero escribe el resultado usando otro, lo que permite que los bytes escritos fuera del buffer sean controlados por el atacante.

F5 lo califica con CVSS v4 9.2 (Crítico). Si operás una instancia NGINX expuesta a internet con reglas de rewrite no triviales, configuraciones PHP, WordPress permalinks, API gateways, esto es relevante hoy. La corrección está disponible a partir de la versión 1.30.1.

Actualización de NGINX en Debian 13

Estado	Versión
Vulnerable	1.26.3
Corregida	1.30.1

1. Verificar la versión instalada

Antes de comenzar, conviene revisar qué versión de NGINX está ejecutándose y desde qué repositorio proviene.

nginx -v
apt policy nginx

2. Instalar dependencias y agregar el repositorio oficial

Aunque Debian incluye NGINX en sus repositorios oficiales, las versiones suelen ser más conservadoras. Para obtener rápidamente una versión corregida, se utiliza el repositorio oficial de NGINX.

Instalar dependencias necesarias

sudo apt update
sudo apt install curl gnupg2 ca-certificates lsb-release debian-archive-keyring -y

Importar la clave GPG oficial

curl -fsSL https://nginx.org/keys/nginx_signing.key | \
sudo gpg --dearmor -o /usr/share/keyrings/nginx-archive-keyring.gpg

Agregar el repositorio estable

echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] \
https://nginx.org/packages/debian `lsb_release -cs` nginx" | \
sudo tee /etc/apt/sources.list.d/nginx.list

Actualizar índices de paquetes

sudo apt update

3. Instalar la versión corregida

sudo apt install nginx

Recomendación: Si ya tienes virtual hosts, certificados SSL o configuraciones personalizadas, selecciona mantener la versión local instalada cuando Debian pregunte sobre archivos de configuración existentes. De lo contrario podrías sobrescribir configuraciones productivas.

4. Iniciar y habilitar el servicio

Problema encontrado: Después de instalar desde el repositorio oficial, el servicio no quedó iniciado automáticamente. Es necesario levantarlo manualmente.

sudo systemctl start nginx
sudo systemctl enable nginx
sudo systemctl status nginx

5. Validar configuración y versión

sudo nginx -t
nginx -v

La salida esperada de nginx -t:

syntax is ok
test is successful

Advertencia HTTP/2 en versiones recientes

A partir de NGINX 1.25.1, el soporte HTTP/2 se desacopló de la directiva listen para permitir mayor flexibilidad en la configuración. La sintaxis antigua sigue funcionando pero genera advertencias.

Para localizar configuraciones con la sintaxis antigua:

sudo grep -E "listen.*http2" -R /etc/nginx/

	Sintaxis
Antigua	`listen 443 ssl http2;`
Nueva (recomendada)	`listen 443 ssl;` + `http2 on;` (dentro del bloque `server`)

# Nueva sintaxis
listen 443 ssl;
http2 on;

Resumen rápido – Debian 13

sudo apt update
sudo apt install curl gnupg2 ca-certificates lsb-release debian-archive-keyring -y

curl -fsSL https://nginx.org/keys/nginx_signing.key | \
sudo gpg --dearmor -o /usr/share/keyrings/nginx-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] \
https://nginx.org/packages/debian `lsb_release -cs` nginx" | \
sudo tee /etc/apt/sources.list.d/nginx.list

sudo apt update && sudo apt install nginx

sudo systemctl start nginx
sudo systemctl enable nginx
sudo nginx -t && nginx -v

Actualización de NGINX en Alpine Linux

Estado	Versión
Vulnerable (rama estable)	1.28.3-r1
Corregida (rama edge)	1.30.1-r0

En Alpine la rama estable aún ofrecía una versión vulnerable, por lo que fue necesario recurrir temporalmente a la rama edge. La clave es hacerlo de forma controlada usando una etiqueta (@edge) para limitar exclusivamente qué paquetes se instalan desde ahí, sin desestabilizar el resto del sistema.

1. Agregar el repositorio Edge con etiqueta restringida

vi /etc/apk/repositories

Agregar al final del archivo:

@edge https://dl-cdn.alpinelinux.org/alpine/edge/main

Guardar y salir: ESC –> :wq –> ENTER

¿Por qué usar la etiqueta @edge? Sin ella, Alpine podría actualizar otros paquetes del sistema desde la rama edge, lo cual puede introducir inestabilidad. La etiqueta restringe su uso únicamente a los paquetes que la especifiquen explícitamente.

2. Actualizar índices e instalar desde Edge

sudo apk update
sudo apk add nginx@edge

Problema encontrado: Si el repositorio no fue agregado correctamente con @edge, Alpine devuelve:
WARNING: The repository tag for world dependency 'nginx@edge' does not exist
Verificar con cat /etc/apk/repositories que la línea tiene exactamente el prefijo @edge y que el comando usa nginx@edge. Ambos deben coincidir.

3. Reiniciar y validar

sudo rc-service nginx restart
sudo nginx -v
sudo nginx -t

Archivo `.apk-new` generado automáticamente

Durante la instalación, Alpine puede generar /etc/nginx/nginx.conf.apk-new. Esto es normal: el gestor crea ese archivo como respaldo cuando detecta una configuración modificada localmente. Si nginx -t devuelve validación exitosa, el archivo puede ignorarse o compararse manualmente más adelante.

Recomendaciones finales

Después de aplicar actualizaciones críticas en NGINX:

Verifica siempre la versión activa con nginx -v
Ejecuta nginx -t antes de reiniciar servicios productivos
Revisa cambios de sintaxis entre versiones mayores (especialmente HTTP/2)
Comprueba que el servicio realmente quedó iniciado y habilitado
En Alpine, evita habilitar repositorios edge globalmente sin etiquetas restrictivas

Parchear es solo el primer paso

Actualizar NGINX parece una tarea simple, pero en escenarios reales aparecen detalles operativos que no siempre están en la documentación oficial: repositorios sin el parche, servicios que no reinician automáticamente, cambios de sintaxis silenciosos y diferencias entre gestores de paquetes.

Documentar estos hallazgos facilita repetir el procedimiento en múltiples servidores o automatizarlo mediante Ansible, Terraform o pipelines de CI/CD.

Tema Relacionado: Infraestructura Linux/VPS