{"id":314,"date":"2026-05-15T08:10:36","date_gmt":"2026-05-15T12:10:36","guid":{"rendered":"https:\/\/juredev.com\/blog\/?p=314"},"modified":"2026-05-15T21:13:41","modified_gmt":"2026-05-16T01:13:41","slug":"como-parchear-la-vulnerabilidad-critica-de-nginx-en-debian-13-y-alpine-linux","status":"publish","type":"post","link":"https:\/\/juredev.com\/blog\/2026\/05\/como-parchear-la-vulnerabilidad-critica-de-nginx-en-debian-13-y-alpine-linux\/","title":{"rendered":"C\u00f3mo parchear la vulnerabilidad cr\u00edtica de NGINX en Debian 13 y Alpine Linux"},"content":{"rendered":"\n

Gu\u00eda paso a paso con errores reales del proceso de actualizaci\u00f3n, cambios de sintaxis en HTTP\/2 y diferencias entre gestores de paquetes.<\/p>\n\n\n\n

En mayo de 2026 se public\u00f3 una vulnerabilidad cr\u00edtica en NGINX<\/a> que afecta a millones de servidores. Esta gu\u00eda documenta el proceso real de actualizaci\u00f3n en dos entornos distintos, Debian 13 y Alpine Linux, incluyendo los problemas encontrados y c\u00f3mo resolverlos.<\/p>\n\n\n\n

La vulnerabilidad: CVE-2026-42945 (NGINX Rift)<\/h2>\n\n\n\n

El detonante de esta actualizaci\u00f3n fue NGINX Rift<\/strong>, un heap buffer overflow cr\u00edtico que llevaba 18 a\u00f1os sin detectarse en el c\u00f3digo de NGINX. El fallo vive en ngx_http_rewrite_module<\/code>, incluido en toda instalaci\u00f3n est\u00e1ndar de NGINX, y se activa cuando una directiva rewrite<\/code> combina capturas PCRE sin nombre (la sintaxis $1<\/code>, $2<\/code>) con un string de reemplazo que contiene un signo de pregunta, seguido de otro rewrite<\/code>, if<\/code> o set<\/code>. NGINX calcula el tama\u00f1o del buffer con un m\u00e9todo de escape pero escribe el resultado usando otro, lo que permite que los bytes escritos fuera del buffer sean controlados por el atacante.<\/p>\n\n\n\n

F5 lo califica con CVSS v4 9.2<\/strong> (Cr\u00edtico<\/strong>). Si oper\u00e1s una instancia NGINX expuesta a internet con reglas de rewrite no triviales, configuraciones PHP, WordPress permalinks, API gateways, esto es relevante hoy. La correcci\u00f3n est\u00e1 disponible a partir de la versi\u00f3n 1.30.1.<\/p>\n\n\n\n

Actualizaci\u00f3n de NGINX en Debian 13<\/h2>\n\n\n\n
Estado<\/th>Versi\u00f3n<\/th><\/tr><\/thead>
Vulnerable<\/td>1.26.3<\/td><\/tr>
Corregida<\/td>1.30.1<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

1. Verificar la versi\u00f3n instalada<\/h3>\n\n\n\n

Antes de comenzar, conviene revisar qu\u00e9 versi\u00f3n de NGINX est\u00e1 ejecut\u00e1ndose y desde qu\u00e9 repositorio proviene.<\/p>\n\n\n\n

nginx -v\napt policy nginx<\/code><\/pre>\n\n\n\n
2. Instalar dependencias y agregar el repositorio oficial<\/h3>\n\n\n\n
Aunque Debian incluye NGINX en sus repositorios oficiales, las versiones suelen ser m\u00e1s conservadoras. Para obtener r\u00e1pidamente una versi\u00f3n corregida, se utiliza el repositorio oficial de NGINX.<\/p>\n\n\n\n
Instalar dependencias necesarias<\/strong><\/p>\n\n\n\n
sudo apt update\nsudo apt install curl gnupg2 ca-certificates lsb-release debian-archive-keyring -y<\/code><\/pre>\n\n\n\n
Importar la clave GPG oficial<\/strong><\/p>\n\n\n\n
curl -fsSL https:\/\/nginx.org\/keys\/nginx_signing.key | \\\nsudo gpg --dearmor -o \/usr\/share\/keyrings\/nginx-archive-keyring.gpg<\/code><\/pre>\n\n\n\n
Agregar el repositorio estable<\/strong><\/p>\n\n\n\n
echo \"deb [signed-by=\/usr\/share\/keyrings\/nginx-archive-keyring.gpg] \\\nhttps:\/\/nginx.org\/packages\/debian `lsb_release -cs` nginx\" | \\\nsudo tee \/etc\/apt\/sources.list.d\/nginx.list<\/code><\/pre>\n\n\n\n
Actualizar \u00edndices de paquetes<\/strong><\/p>\n\n\n\n
sudo apt update<\/code><\/pre>\n\n\n\n
3. Instalar la versi\u00f3n corregida<\/h3>\n\n\n\n
sudo apt install nginx<\/code><\/pre>\n\n\n\n
\n
Recomendaci\u00f3n<\/strong>: Si ya tienes virtual hosts, certificados SSL o configuraciones personalizadas, selecciona mantener la versi\u00f3n local instalada cuando Debian pregunte sobre archivos de configuraci\u00f3n existentes. De lo contrario podr\u00edas sobrescribir configuraciones productivas.<\/p>\n<\/blockquote>\n\n\n\n
4. Iniciar y habilitar el servicio<\/h3>\n\n\n\n
\n
Problema encontrado<\/strong>: Despu\u00e9s de instalar desde el repositorio oficial, el servicio no qued\u00f3 iniciado autom\u00e1ticamente. Es necesario levantarlo manualmente.<\/p>\n<\/blockquote>\n\n\n\n
sudo systemctl start nginx\nsudo systemctl enable nginx\nsudo systemctl status nginx<\/code><\/pre>\n\n\n\n
5. Validar configuraci\u00f3n y versi\u00f3n<\/h3>\n\n\n\n
sudo nginx -t\nnginx -v<\/code><\/pre>\n\n\n\n
La salida esperada de nginx -t<\/code>:<\/p>\n\n\n\n
syntax is ok\ntest is successful<\/code><\/pre>\n\n\n\n
Advertencia HTTP\/2 en versiones recientes<\/h3>\n\n\n\n
A partir de NGINX 1.25.1, el soporte HTTP\/2 se desacopl\u00f3 de la directiva listen<\/code> para permitir mayor flexibilidad en la configuraci\u00f3n. La sintaxis antigua sigue funcionando pero genera advertencias.<\/p>\n\n\n\n
Para localizar configuraciones con la sintaxis antigua:<\/p>\n\n\n\n
sudo grep -E \"listen.*http2\" -R \/etc\/nginx\/<\/code><\/pre>\n\n\n\n
<\/th>Sintaxis<\/th><\/tr><\/thead>
Antigua<\/strong><\/td>listen 443 ssl http2;<\/code><\/td><\/tr>
Nueva (recomendada)<\/strong><\/td>listen 443 ssl;<\/code> + http2 on;<\/code> (dentro del bloque server<\/code>)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
# Nueva sintaxis\nlisten 443 ssl;\nhttp2 on;<\/code><\/pre>\n\n\n\n
Resumen r\u00e1pido – Debian 13<\/h3>\n\n\n\n
sudo apt update\nsudo apt install curl gnupg2 ca-certificates lsb-release debian-archive-keyring -y\n\ncurl -fsSL https:\/\/nginx.org\/keys\/nginx_signing.key | \\\nsudo gpg --dearmor -o \/usr\/share\/keyrings\/nginx-archive-keyring.gpg\n\necho \"deb [signed-by=\/usr\/share\/keyrings\/nginx-archive-keyring.gpg] \\\nhttps:\/\/nginx.org\/packages\/debian `lsb_release -cs` nginx\" | \\\nsudo tee \/etc\/apt\/sources.list.d\/nginx.list\n\nsudo apt update && sudo apt install nginx\n\nsudo systemctl start nginx\nsudo systemctl enable nginx\nsudo nginx -t && nginx -v<\/code><\/pre>\n\n\n\n
Actualizaci\u00f3n de NGINX en Alpine Linux<\/h2>\n\n\n\n
Estado<\/th>Versi\u00f3n<\/th><\/tr><\/thead>
Vulnerable (rama estable)<\/td>1.28.3-r1<\/td><\/tr>
Corregida (rama edge)<\/td>1.30.1-r0<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
En Alpine la rama estable a\u00fan ofrec\u00eda una versi\u00f3n 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\u00e9 paquetes se instalan desde ah\u00ed, sin desestabilizar el resto del sistema.<\/p>\n\n\n\n
1. Agregar el repositorio Edge con etiqueta restringida<\/h3>\n\n\n\n
vi \/etc\/apk\/repositories<\/code><\/pre>\n\n\n\n
Agregar al final del archivo:<\/p>\n\n\n\n
@edge https:\/\/dl-cdn.alpinelinux.org\/alpine\/edge\/main<\/code><\/pre>\n\n\n\n
Guardar y salir: ESC<\/code> –> :wq<\/code> –> ENTER<\/code><\/p>\n\n\n\n
\n
\u00bfPor qu\u00e9 usar la etiqueta <\/strong>@edge<\/code>?<\/strong> Sin ella, Alpine podr\u00eda actualizar otros paquetes del sistema desde la rama edge<\/code>, lo cual puede introducir inestabilidad. La etiqueta restringe su uso \u00fanicamente a los paquetes que la especifiquen expl\u00edcitamente.<\/p>\n<\/blockquote>\n\n\n\n
2. Actualizar \u00edndices e instalar desde Edge<\/h3>\n\n\n\n
sudo apk update\nsudo apk add nginx@edge<\/code><\/pre>\n\n\n\n
\n
Problema encontrado:<\/strong> Si el repositorio no fue agregado correctamente con @edge<\/code>, Alpine devuelve:<\/p>\n\n\n\n
WARNING: The repository tag for world dependency 'nginx@edge' does not exist<\/code><\/pre>\n\n\n\n
Verificar con cat \/etc\/apk\/repositories<\/code> que la l\u00ednea tiene exactamente el prefijo @edge<\/code> y que el comando usa nginx@edge<\/code>. Ambos deben coincidir.<\/p>\n<\/blockquote>\n\n\n\n
3. Reiniciar y validar<\/h3>\n\n\n\n
sudo rc-service nginx restart\nsudo nginx -v\nsudo nginx -t<\/code><\/pre>\n\n\n\n
Archivo .apk-new<\/code> generado autom\u00e1ticamente<\/h3>\n\n\n\n
Durante la instalaci\u00f3n, Alpine puede generar \/etc\/nginx\/nginx.conf.apk-new<\/code>. Esto es normal: el gestor crea ese archivo como respaldo cuando detecta una configuraci\u00f3n modificada localmente. Si nginx -t<\/code> devuelve validaci\u00f3n exitosa, el archivo puede ignorarse o compararse manualmente m\u00e1s adelante.<\/p>\n\n\n\n
Recomendaciones finales<\/h2>\n\n\n\n
Despu\u00e9s de aplicar actualizaciones cr\u00edticas en NGINX:<\/p>\n\n\n\n
    \n
  • Verifica siempre la versi\u00f3n activa con nginx -v<\/code><\/li>\n\n\n\n
  • Ejecuta nginx -t<\/code> antes de reiniciar servicios productivos<\/li>\n\n\n\n
  • Revisa cambios de sintaxis entre versiones mayores (especialmente HTTP\/2)<\/li>\n\n\n\n
  • Comprueba que el servicio realmente qued\u00f3 iniciado y habilitado<\/li>\n\n\n\n
  • En Alpine, evita habilitar repositorios edge<\/code> globalmente sin etiquetas restrictivas<\/li>\n<\/ul>\n\n\n\n
    Parchear es solo el primer paso<\/h2>\n\n\n\n
    Actualizar NGINX parece una tarea simple, pero en escenarios reales aparecen detalles operativos que no siempre est\u00e1n en la documentaci\u00f3n oficial: repositorios sin el parche, servicios que no reinician autom\u00e1ticamente, cambios de sintaxis silenciosos y diferencias entre gestores de paquetes.<\/p>\n\n\n\n
    Documentar estos hallazgos facilita repetir el procedimiento en m\u00faltiples servidores o automatizarlo mediante Ansible, Terraform o pipelines de CI\/CD.<\/p>\n","protected":false},"excerpt":{"rendered":"
    Gu\u00eda paso a paso con errores reales del proceso de actualizaci\u00f3n, cambios de sintaxis en HTTP\/2 y diferencias entre gestores de paquetes. En mayo de 2026 se public\u00f3 una vulnerabilidad cr\u00edtica en NGINX que afecta a millones de servidores. Esta gu\u00eda documenta el proceso real de actualizaci\u00f3n en dos entornos distintos, Debian 13 y Alpine […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[18],"tags":[24,28],"class_list":["post-314","post","type-post","status-publish","format-standard","hentry","category-guia","tag-linux","tag-seguridad"],"_links":{"self":[{"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/posts\/314","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/comments?post=314"}],"version-history":[{"count":0,"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/posts\/314\/revisions"}],"wp:attachment":[{"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/media?parent=314"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/categories?post=314"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/tags?post=314"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}