--- title: "Vulnerabilidades NGINX: causas, soluciones y verificación de producción" description: "Revise cinco vulnerabilidades NGINX de octubre de 2026, sus requisitos previos de configuración, correcciones específicas de cada rama, backports de distribución y verificación de producción." language: "es" url: "https://keendigit.com/es/insights/nginx-remediation-guide" author: "KeenDigit" published: "2026-10-14" updated: "2026-10-27" --- # Vulnerabilidades NGINX: causas, soluciones y verificación de producción Revise cinco vulnerabilidades NGINX de octubre de 2026, sus requisitos previos de configuración, correcciones específicas de cada rama, backports de distribución y verificación de producción. Fecha histórica del artículo: 2026-10-14 (fecha de divulgación y publicación de seguridad). Fuentes verificadas e información complementada a través de 2026-10-27. Este artículo está archivado por fecha del evento; A continuación se incluyen las actualizaciones de versión y lanzamiento publicadas después del 14 de octubre. Público: sitio web NGINX Open Source / NGINX Plus y personal de operación y mantenimiento de proxy inverso, personal de respuesta de seguridad, mantenedores de distribución, así como ingenieros que autocompilan NGINX y mantienen módulos de terceros. Este artículo se centra en las cinco vulnerabilidades principales de NGINX que se divulgaron y corrigieron intensivamente el 14 de octubre de 2026, y también analiza las vulnerabilidades representativas de seguridad de la memoria e integridad de solicitudes de mayo a septiembre de 2026. El contenido cubre condiciones de activación, causas a nivel de código, alcance del impacto, flujo de trabajo de remediación, medidas de mitigación a corto plazo, implementación de parches oficiales, backports a ramas más antiguas y verificación de producción. Referencias como [S1](https://keendigit.com/es/insights/nginx-remediation-guide#source-1) enlazan al apéndice fuente. Las configuraciones de ejemplo solo se utilizan para ilustrar las ideas de implementación y auditoría, y deben verificarse en función de la versión real, la herencia de configuración, las dependencias y la capacidad comercial antes de la implementación. ## TL;DR: Acciones prioritarias 1. Priorice las actualizaciones de seguridad. Para paquetes de código abierto nginx.org, actualice la rama Stable 1.30 al menos a 1.30.6 y la rama Mainline 1.31 a al menos 1.31.7.. En la fecha de verificación, 1.31.8 es el último Mainline. liberación. Estas son líneas de base de sucursales separadas; no compare sus números entre sucursales. [S1](https://keendigit.com/es/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/es/insights/nginx-remediation-guide#source-2) 2. Verifique las instalaciones de distribución por versión del paquete completo. Ubuntu 22.04 / 24.04 / 26.04 / 26.10 tienen backports de proveedores; Debian 13 (trixie) requiere al menos `1.26.3-3+deb13u10`. En la verificación, el paquete Debian 12 (bookworm) `1.22.1-9+deb12u10` todavía está marcado como afectado. Verifique cada CVE; el aviso Debian 13 no establece que Debian 12 esté solucionado. [S13](https://keendigit.com/es/insights/nginx-remediation-guide#source-13)[S14](https://keendigit.com/es/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/es/insights/nginx-remediation-guide#source-15) 3. Audite cinco combinaciones de configuración: `alias + rewrite + $request_filename`, `map` + expresión regular + evaluación de variables, `aio + ssi + include virtual`, HTTP/3 con `proxy_request_buffering on` y `ssl_session_cache shared:...` con rotación automática de claves de ticket de sesión TLS. La presencia de una directiva por sí sola no establece la explotabilidad; evaluar la ruta de la solicitud y el alcance de la configuración. [S1](https://keendigit.com/es/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/es/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/es/insights/nginx-remediation-guide#source-4) 4. Reemplace todos los procesos y contenedores antiguos. Ejecute `nginx -t`, luego reinicie el servicio o realice una implementación continua de alta disponibilidad. Confirme que los procesos antiguos master/worker hayan salido; `nginx -s reload` por sí solo no prueba que el binario en ejecución haya cambiado. 5. Verifique los puntos finales reales: HTTP/1.1, HTTP/2, HTTP/3 si están habilitados, cargas proxy y cuerpos de solicitud API, autenticación de certificados mTLS, páginas SSI y registros de acceso. Registre la procedencia del paquete, la versión, el resumen de imágenes, los procesos en ejecución y los resultados para cada punto final. 6. Si una actualización inmediata es imposible, elimine las condiciones de activación aplicables: deshabilite SSI/AIO o HTTP/3 innecesarios, revise las referencias variables vulnerables de `alias`/`rewrite`/`map` y evalúe el `ssl_session_tickets off;` temporal para los servicios mTLS afectados. WAF, ASLR, los límites de velocidad y los cambios de configuración cubren solo algunas condiciones y no pueden reemplazar los parches oficiales. [S3](https://keendigit.com/es/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/es/insights/nginx-remediation-guide#source-4)[S8](https://keendigit.com/es/insights/nginx-remediation-guide#source-8)[S12](https://keendigit.com/es/insights/nginx-remediation-guide#source-12) ## 1. Descripción general de la vulnerabilidad y juicio de riesgo NGINX lanzó 1.30.6 (Stable) y 1.31.7 (Mainline) el 14 de octubre de 2026, solucionando cinco problemas de seguridad. Tres implican desbordamientos de montón o uso después de la liberación y recibieron puntuaciones F5 CVSS v4.0 de 9.2/Crítico. Los otros dos afectan la integridad de la solicitud HTTP/3 y la autenticación del certificado de cliente TLS. [S1](https://keendigit.com/es/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/es/insights/nginx-remediation-guide#source-2)[S3](https://keendigit.com/es/insights/nginx-remediation-guide#source-3) Distinga los sistemas de clasificación: nginx.org enumera los cinco problemas como `medium`, mientras que F5 CVSS v4.0 y algunas agencias de seguridad nacional clasifican los tres problemas de memoria como críticos. Esto no significa que los cinco permitan la ejecución remota incondicional de código. La configuración, la accesibilidad del tráfico y las condiciones fuera del control del atacante son importantes. La corrupción de la memoria y el RCE confiable son diferentes niveles de evidencia. [S1](https://keendigit.com/es/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/es/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/es/insights/nginx-remediation-guide#source-4) | CVE | Problemas técnicos y condiciones de activación típicas | impacto central | Evaluación y eliminación | | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | CVE-2026-15176 | Mapeo de ruta `alias` + cambio `rewrite` URI + evaluación `$request_filename` | Desbordamiento del búfer del montón, bloqueo de Worker; potencial RCE bajo ciertas condiciones | F5 CVSS v4.0 9.2; priorizar la resolución de problemas | | CVE-2026-93479 | Evaluación de script HTTP/Stream, especialmente captura de expresiones regulares `map` y directorio root, referencia cruzada de variables de registro | El búfer reservado se sobrescribe y el montón se desborda; potencial RCE bajo ciertas condiciones | F5 CVSS v4.0 9.2; Existe un riesgo de regresión después de reparaciones anteriores. | | CVE-2026-97205 | SSI virtual incluye y AIO/operación asíncrona; desbordamiento del recuento de operaciones pendientes | Use-After-Free, bloqueo de Worker, corrupción de memoria; potencial RCE | F5 CVSS v4.0 9.2; requiere una configuración no predeterminada | | CVE-2026-95101 | HTTP/3 El marco desconocido está fragmentado en búferes, el almacenamiento en búfer del cuerpo de la solicitud de proxy está habilitado | Inyectar incorrectamente bytes que no sean DATA en el cuerpo de la solicitud ascendente, posiblemente omitiendo el límite de tamaño del cuerpo de la solicitud | Esta vulnerabilidad afecta la integridad de la solicitud. Por sí solo no proporciona ejecución remota de código (RCE). | | CVE-2026-97629 | Caché de sesión compartida TLS, rotación automática de claves y duplicación de claves Worker | Falsificación de entradas de sesión; Puede ocurrir una omisión de autenticación del certificado de cliente para el servicio mTLS afectado | Es necesario prestar especial atención al impacto empresarial del tipo de autenticación de certificado API. | La puntuación CVSS anterior la proporciona F5 utilizando v4.0; la misma vulnerabilidad puede mostrar diferente gravedad en CVSS 3.1, nginx.org grados propios y clasificaciones de gravedad de distribución. [S1](https://keendigit.com/es/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/es/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/es/insights/nginx-remediation-guide#source-4) ### 1.1 Priorizar la exposición de la implementación en lugar de las puntuaciones CVE únicamente | Formulario de implementación | Puntos clave de investigación | Recomendaciones de prioridad de eliminación | | -------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | | Proxy inverso de red pública, incluidos `rewrite`, `alias` personalizados y `map` complejos | CVE-2026-15176, CVE-2026-93479 y vulnerabilidades de reescritura/mapeo de mayo a julio | P0: Auditar y actualizar inmediatamente | | API / Plano de gestión utilizando certificado de cliente como autenticación de entrada única o principal | Ticket de sesión y configuración de caché compartida de CVE-2026-97629 | P0: Confirme inmediatamente el límite de autenticación y actualice | | Proporciona carga externa HTTP/3, interfaz de cambio de estado, clase de transacción API | CVE-2026-95101, especialmente el cuerpo de la solicitud se envía mediante proxy al backend | P0/P1: Organizar según la importancia empresarial | | SSI Página dinámica o E/S de archivos asíncronos | CVE-2026-97205 | P1: Confirme las condiciones de combinación y repare lo antes posible. | | Sólo páginas estáticas + proxy inverso simple HTTP/1.1/2 | Aún es necesario auditar la configuración y la versión, pero es posible que falten algunas condiciones CVE | P1: Incluido en la ventana de actualización de seguridad de emergencia | | Utilice la comunidad Kubernetes retirada ingress-nginx | El proyecto detiene el mantenimiento de la seguridad y los riesgos no se limitan a estos cinco CVE | Haga un plan de migración de controlador individual | P0/P1 son las sugerencias de eliminación de operación y mantenimiento que se dan en este artículo para la exposición de la red pública y la sensibilidad de la certificación. No es una clasificación oficial CVSS, ni debe reemplazar la evaluación de riesgos de cambios y activos internos de la empresa. ### 1.2 Límites de impacto y permisos de ataque Las principales vulnerabilidades de este lote se encuentran principalmente en el plano de datos NGINX: el punto de entrada del ataque es la conexión y solicitud del cliente, y el impacto real generalmente ocurre en el proceso Worker. Si se cumplen las condiciones explotables para la corrupción de la memoria, el permiso de ejecución del código generalmente está restringido por el usuario que lo ejecuta, las restricciones del contenedor, la capacidad de Linux, el montaje y los permisos de red del Worker; El potencial RCE no implica automáticamente privilegios de root ni compromiso del host. [S4](https://keendigit.com/es/insights/nginx-remediation-guide#source-4) Pero incluso si el proceso no tiene privilegios, aún puede tener acceso a credenciales de proxy, archivos legibles que contienen claves privadas de certificados, tokens de servicio ascendentes, archivos temporales, API interno y redes accesibles. Para mTLS, la omisión de autenticación en sí misma puede ser una consecuencia comercial grave y no necesariamente tiene que ir acompañada de la ejecución de código. ## 2. Análisis de causa ### 2.1 Comprenda los tres límites propensos a errores en NGINX Un NGINX worker es un proceso de larga duración impulsado por eventos que mantiene el estado de la solicitud, las operaciones asincrónicas y los analizadores de protocolos. Esta vulnerabilidad incorpora restricciones en tres niveles de ingeniería: 1. la evaluación de variables y el tamaño de la memoria deben ser consistentes: `rewrite` Después de cambiar la solicitud URI, la asignación de ruta debe ser consistente con el `location` actualmente vigente; Cuando el intérprete de script calcula la longitud variable, el espacio de escritura debe cubrir la salida real y las áreas reservadas. 2. Las operaciones asincrónicas deben extender el ciclo de vida de la memoria solicitada: cuando hay lecturas y escrituras de archivos sin terminar, espera de caché o tareas de subprocesos, el grupo de memoria de solicitud relevante no se puede liberar por adelantado. 3. el estado del protocolo y el estado de seguridad no se pueden mezclar ni omitir: HTTP/3 La longitud del salto de trama desconocido no se puede considerar como la longitud del cuerpo de la solicitud DATA; TLS Todas las ranuras de claves que participan en la verificación de firmas deben inicializarse y sincronizarse correctamente durante la rotación del ticket de sesión. El siguiente contenido se basa en la confirmación de corrección ascendente NGINX y el anuncio del proveedor para explicar el mecanismo de falla que se puede desencadenar; El fragmento de ejemplo es para análisis, no es el código completo que pueda usarse directamente para reparar el entorno de producción. [S5](https://keendigit.com/es/insights/nginx-remediation-guide#source-5)[S6](https://keendigit.com/es/insights/nginx-remediation-guide#source-6)[S7](https://keendigit.com/es/insights/nginx-remediation-guide#source-7)[S8](https://keendigit.com/es/insights/nginx-remediation-guide#source-8)[S9](https://keendigit.com/es/insights/nginx-remediation-guide#source-9) ### 2.2 CVE-2026-15176: La asignación de ruta entre `alias` y URI reescrito no es válida. En NGINX, el `location` coincidente y su `alias` determinan la ruta del archivo; `rewrite` puede cambiar la solicitud actual URI. Después de reescribir, es posible que las suposiciones utilizadas por el mapeo `location` original ya no sean válidas. La ruta de procesamiento afectada no verificó adecuadamente si la solicitud se había reescrito al verificar el estado `alias` en `ngx_http_map_uri_to_path()`. Cuando la configuración continúa evaluando `$request_filename` después de la reescritura, la ruta puede construirse con suposiciones que no se ajustan al estado actual de URI, lo que eventualmente desencadena una escritura fuera de límites en la memoria del montón. [S5](https://keendigit.com/es/insights/nginx-remediation-guide#source-5) Combinación típica (solo se usa como contraejemplo para la auditoría de configuración, no se recomienda la implementación): ```nginx # 仅用于识别风险模式：不是修复配置 location /foo/ { alias /srv/alias-root/; rewrite ^/foo/.*$ /new-path; return 200 $request_filename; } ``` El peligro no se limita a `return`: `set`, `if`, `add_header`, `log_format`, etc. también deben auditarse si la evaluación de `$request_filename` se activa en el mismo proceso de solicitud. `return` en el ejemplo solo hace que esta ruta de estado sea fácil de ver; no se puede usar para inferir que todas las configuraciones de producción producirán desbordamientos. [S5](https://keendigit.com/es/insights/nginx-remediation-guide#source-5)[S10](https://keendigit.com/es/insights/nginx-remediation-guide#source-10) Consecuencias del ataque: la creación de una solicitud puede provocar que Worker se reinicie o se interrumpa el servicio; en condiciones como que ASLR esté cerrado o pueda ser anulado, existe un potencial RCE. El núcleo del parche ascendente es negarse a completar el mapeo de ruta URI reescrito en el contexto `alias` que ya no es válido, en lugar de simplemente expandir un determinado búfer. [S5](https://keendigit.com/es/insights/nginx-remediation-guide#source-5)[S10](https://keendigit.com/es/insights/nginx-remediation-guide#source-10) ### 2.3 CVE-2026-93479: Falta de coincidencia entre el "espacio reservado" y la longitud real de la variable en la evaluación del script Los módulos HTTP y Stream de NGINX tienen evaluadores de secuencias de comandos que concatenan cadenas literales y valores variables en la cadena de resultado. Los ejemplos de aplicaciones incluyen rutas del documento HTTP root, rutas de registro de acceso y expresiones variables en Stream. Ciertas configuraciones de expresiones regulares `map` + permiten que otras expresiones lean los valores capturados antes de que se evalúe la variable de resultado `map`. Combinado con el método de ejecución de script con longitud reservada, la implementación anterior contará el espacio reservado `len` en el acumulador de longitud evaluada por adelantado, de modo que los cálculos posteriores del puntero de escritura ya no sean consistentes con el límite del búfer. En una secuencia de evaluación de variables específica, las escrituras de cadenas posteriores pueden sobrescribir el área reservada, provocando un desbordamiento del montón. [S6](https://keendigit.com/es/insights/nginx-remediation-guide#source-6) | elementos participativos | ¿Por qué vale la pena prestarle atención? | | --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | expresión regular en `map` | La evaluación de la variable de captura puede tener un ciclo de vida independiente y un comportamiento de almacenamiento en caché | | Capturas anónimas como `$1`, `$2`, etc. | Se sobrescribe fácilmente con otras expresiones o expresiones regulares, lo que dificulta el seguimiento de la propiedad. | | Variables en `root` | Ejecución de script y reserva de búfer al activar la creación de rutas | | `log_format`/Ruta de registro dinámica | El mismo tipo de evaluación puede activarse más adelante en la solicitud. | | Expresiones de script en `stream` | La solución ascendente también modifica `ngx_stream_script_run()`. No solo puede revisar el módulo HTTP. | Relación de regresión importante: el código relacionado con esta vulnerabilidad está relacionado con los cambios anteriores que solucionaron CVE-2026-42533. El DSA oficial para Debian 13 establece claramente que el código afectado se introdujo en el paquete trixie a través de un puerto de seguridad anterior. Por lo tanto, "se ha instalado el parche de vulnerabilidad `map` de julio" no significa que se haya cubierto el CVE-2026-93479 de octubre; Se debe verificar toda la cadena de correcciones de seguridad. [S6](https://keendigit.com/es/insights/nginx-remediation-guide#source-6)[S14](https://keendigit.com/es/insights/nginx-remediation-guide#source-14)[S17](https://keendigit.com/es/insights/nginx-remediation-guide#source-17) El riesgo potencial de RCE aquí está relacionado con el entorno de protección de la memoria, y no se debe afirmar que la expresión regular `map` por sí sola podrá ser explotada por atacantes anónimos. [S11](https://keendigit.com/es/insights/nginx-remediation-guide#source-11) ### 2.4 CVE-2026-97205: AIO El ajuste del recuento de operaciones no finalizadas provoca el uso después de la liberación Esta vulnerabilidad no es simplemente "activar SSI y obtendrá UAF". La clave radica en el recuento de referencias de operaciones asincrónicas que mantiene la solicitud principal. NGINX Utilice `r->main->blocked` para realizar un seguimiento del procesamiento asincrónico que aún no se ha completado; en la implementación anterior era un recuento de 8 bits; algunas rutas no realizaron una verificación del límite superior antes de incrementar el recuento. Cuando la misma solicitud principal acumula 256 operaciones pendientes, el recuento puede pasar de 255 a 0. Los procesos posteriores creerán erróneamente que no hay ninguna operación asincrónica que impida que la solicitud se libere, liberando así el grupo de memoria de solicitudes al que todavía hace referencia la tarea. [S7](https://keendigit.com/es/insights/nginx-remediation-guide#source-7) El proceso de fracaso se puede dividir en: 1. Con la ruta de subproceso/E/S asincrónica asociada habilitada, la página SSI introduce múltiples solicitudes secundarias u operaciones de lectura a través de `include virtual`. 2. Las operaciones pendientes de una determinada solicitud principal se acumulan hasta el límite superior representado por el campo de recuento. 3. El recuento de 8 bits regresa, expresado incorrectamente como "no hay operaciones pendientes". 4. El grupo de memoria de solicitudes se libera, mientras que las lecturas de archivos, las esperas de caché o las devoluciones de llamadas de tareas de subprocesos aún conservan referencias a él. 5. Las devoluciones de llamadas de finalización asincrónica posteriores acceden a la memoria liberada, lo que provoca fallas en UAF, Worker o una posible corrupción de la memoria. La solución oficial agrega `NGX_HTTP_MAX_BLOCKED 250` al archivo de encabezado de solicitud y agrega restricciones al filtro de salida, lectura de caché y ruta de subproceso ascendente; cuando se alcanza el umbral, las operaciones con rutas sincronizadas se completan sincrónicamente y, si no se pueden procesar de forma segura, se rechazará la adición de tareas pendientes. [S7](https://keendigit.com/es/insights/nginx-remediation-guide#source-7) Juicio de aplicabilidad: se debe evaluar si SSI, AIO, inclusión virtual, subsolicitudes y operaciones asincrónicas relacionadas pueden ocurrir en combinación en la misma cadena de solicitudes. Por lo general, estas no son las configuraciones de proxy estático simples predeterminadas. `aio off;` o `ssi off;` pueden eliminar elementos desencadenantes específicos, pero primero se deben confirmar las dependencias de las funciones comerciales. [S4](https://keendigit.com/es/insights/nginx-remediation-guide#source-4)[S7](https://keendigit.com/es/insights/nginx-remediation-guide#source-7)[S25](https://keendigit.com/es/insights/nginx-remediation-guide#source-25) ### 2.5 CVE-2026-95101: El marco desconocido HTTP/3 se confunde con el estado del cuerpo de solicitud DATA El analizador de tramas HTTP/3 debe distinguir entre tramas `DATA` (que deben pasarse al procesamiento del cuerpo de la solicitud HTTP) y tramas desconocidas que deben omitirse. La longitud de las tramas desconocidas también debe preservarse con precisión al fragmentar entre búferes de red. La implementación anterior de `ngx_http_v3_parse_data()` usaba el campo `st->length` para guardar el "número restante de bytes a omitir" al omitir tramas desconocidas, mientras que el filtro del cuerpo de la solicitud interpretaba el mismo campo como la "longitud de carga útil restante de DATA". Si la trama desconocida abarca varias llamadas de análisis, el siguiente lote de bytes después de interrumpir el análisis puede confundirse con parte del cuerpo de la solicitud. [S8](https://keendigit.com/es/insights/nginx-remediation-guide#source-8) Surgen dos tipos de riesgos: - Inyección del cuerpo de la solicitud: la carga útil de la trama que no es DATA enviada por el cliente puede transmitirse a la aplicación ascendente, cambiando los datos realmente recibidos por el backend. - omisiones de límite de tamaño: `client_max_body_size` y otras restricciones. Las comprobaciones esperadas se concentran en la ruta DATA y el contenido convertido incorrectamente puede pasar por alto la verificación correspondiente. El escenario de activación típico descrito por el funcionario es cuando `ngx_http_v3_module` recibe la solicitud HTTP/3 y reenvía `proxy_request_buffering on`. El almacenamiento en búfer del cuerpo de la solicitud de proxy está habilitado de forma predeterminada en `ngx_http_proxy_module`. Por lo tanto, primero se debe verificar el proxy inverso que activa HTTP/3. No es apropiado suponer que no existe una condición de activación simplemente porque `proxy_request_buffering on;` no esté escrito explícitamente. [S8](https://keendigit.com/es/insights/nginx-remediation-guide#source-8)[S18](https://keendigit.com/es/insights/nginx-remediation-guide#source-18) La consecuencia directa de esta vulnerabilidad pertenece a la integridad de la solicitud de backend y al cambio de límites de seguridad, que no es la expresión equivalente de RCE completada directamente en el núcleo NGINX. El impacto final en el negocio depende de cómo se analizan y se confía en estos bytes en sentido ascendente. [S24](https://keendigit.com/es/insights/nginx-remediation-guide#source-24) ### 2.6 CVE-2026-97629: TLS La rotación de boletos pierde la tercera ranura de clave En las configuraciones afectadas, NGINX puede generar y rotar automáticamente claves de ticket de sesión TLS a través de la memoria caché compartida, lo que permite que varios Worker procesen el mismo lote de tickets. La lógica de sincronización relevante asigna 3 ranuras de clave para cada Worker, y la devolución de llamada de descifrado también atravesará estas ranuras; pero la implementación anterior solo copia 2 ranuras de clave de la memoria compartida cada vez, lo que da como resultado el nombre de la clave, la clave HMAC y AES de la tercera ranura. La clave puede permanecer sin inicializar. Si el identificador de clave de un ticket coincide con este estado, se puede utilizar material de clave no inicializado para la verificación y descifrado de la firma, formando así una ruta para falsificar la sesión TLS. [S9](https://keendigit.com/es/insights/nginx-remediation-guide#source-9) Las combinaciones de implementación de alto riesgo suelen ser: ```nginx # 仅为排查触发条件所示：共享缓存本身不是恶意配置 ssl_session_cache shared:SSL:10m; # 未显式配置 ssl_session_ticket_key 文件，使用自动轮换机制 ``` La consecuencia empresarial más grave de esta vulnerabilidad es que en los servicios que utilizan autenticación de certificado de cliente (mTLS) en `ssl_verify_client on;` y otras formas, las sesiones de recuperación falsificadas pueden omitir la verificación de certificado de cliente. El éxito del ataque también está sujeto a condiciones incontrolables; un sitio que sólo utiliza un certificado HTTPS normal del lado del servidor y ninguna autenticación de certificado de cliente no debe ser caracterizado erróneamente como "el atacante puede omitir todo el inicio de sesión del sitio web". [S9](https://keendigit.com/es/insights/nginx-remediation-guide#source-9)[S12](https://keendigit.com/es/insights/nginx-remediation-guide#source-12) Este es un problema de estado de autenticación de sesión TLS y no tiene nada que ver con si la clave privada TLS del servidor está descifrada o si el certificado público CA root está afectado. [S24](https://keendigit.com/es/insights/nginx-remediation-guide#source-24) ### 2.7 Cómo entender DoS, RCE, omisión de autenticación y exploits conocidos - DoS: El error de memoria hace que Worker falle o se reinicie masivamente. Si causa indisponibilidad general está relacionado con la presión del tráfico, la capacidad de reinicio del proceso, el tiempo de mantenimiento de la conexión y la arquitectura de alta disponibilidad. - potencial RCE: Algunos anuncios indican que existe la posibilidad de ejecución de código cuando se cierra o se omite ASLR. Esto no significa que se haya revelado una cadena de ataque pública que pueda ejecutar comandos de manera estable y universal. [S4](https://keendigit.com/es/insights/nginx-remediation-guide#source-4) - Solicitud de inyección/omisión de autenticación: puede cambiar directamente el estado empresarial protegido o el contenido de la solicitud, y no se puede ignorar simplemente porque no obtiene directamente el shell. - ha descubierto intentos de ataque: CVE-2026-42945 en mayo de 2026 tiene informes de actividades de explotación en estado salvaje; No deberíamos inferir directamente que este hecho histórico significa que los cinco CVE de octubre han sido explotados con éxito a gran escala. [S23](https://keendigit.com/es/insights/nginx-remediation-guide#source-23) ## 3. Versión de reparación y selección de parches ### Línea base del parche oficial 3.1 NGINX Open Source | rama aguas arriba | La primera versión oficial que cubre cinco vulnerabilidades en octubre | Recomendaciones a partir de 2026-10-27 | | ---------------------------------- | ----------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | Stable 1.30.x | 1.30.6（2026-10-14） | Instale al menos 1.30.6 y realice un seguimiento con versiones de seguridad posteriores. | | Mainline 1.31.x | 1.31.7（2026-10-14） | 1.31.8（2026-10-21） | | La rama NGINX Open Source anterior | No se puede juzgar únicamente basándose en "se han aplicado parches de vulnerabilidad antiguos" | Primero migre a la rama mantenida; de lo contrario, el proveedor debe proporcionar evidencia formal de respaldo sobre la base de CVE-by-CVE. | Estas son las conclusiones de la versión del código fuente ascendente/rama oficial nginx.org, y no deben usarse para negar directamente el paquete de seguridad con correcciones respaldadas proporcionadas por el proveedor de distribución. Incluso si el valor de `1.31.6` es mayor que `1.30.6`, sigue siendo inferior a la línea base del parche de la rama principal. [S1](https://keendigit.com/es/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/es/insights/nginx-remediation-guide#source-2) ### 3.2 El alcance del impacto ascendente de cinco CVE Los siguientes rangos se enumeran según el texto original del boletín de seguridad nginx.org y deben entenderse junto con la "rama en ejecución actual" y la "ruta de configuración real": | CVE | Versiones afectadas de etiquetas ascendentes | Versión fija oficialmente etiquetada | | -------------- | -------------------------------------------- | ----------------------------------------------------------- | | CVE-2026-15176 | `0.1.29–1.31.6` | `1.30.6+` o `1.31.7+`, dentro de sus respectivas sucursales | | CVE-2026-93479 | `1.30.0–1.30.5`，`1.31.2–1.31.6` | Igual que arriba | | CVE-2026-97205 | `0.8.11–1.31.6` | Igual que arriba | | CVE-2026-95101 | `1.25.0–1.31.6` | Igual que arriba | | CVE-2026-97629 | `1.23.2–1.31.6` | Igual que arriba | CVE-2026-93479 tiene límites específicos de versión de introducción; No todas las versiones antiguas de NGINX se ven afectadas por esta regresión. Las versiones anteriores fuera de esos rangos aún pueden verse afectadas por la vulnerabilidad de expresión regular `map` anterior CVE-2026-42533. [S1](https://keendigit.com/es/insights/nginx-remediation-guide#source-1) ### 3.3 Ubuntu: backports de distribución (USN-8955-1) Canonical USN-8955-1 del 26 de octubre de 2026 proporciona una actualización de seguridad para cuatro compilaciones de Ubuntu: [S13](https://keendigit.com/es/insights/nginx-remediation-guide#source-13) | Versión Ubuntu | `nginx` y la misma versión fija del paquete fuente | Descripción | | -------------- | -------------------------------------------------- | ----------------------------------------------------------------------------------- | | 22.04 LTS | `1.18.0-6ubuntu14.22` | Es un backport de proveedor; el número de versión ascendente todavía muestra 1.18.0 | | 24.04 LTS | `1.24.0-2ubuntu7.19` | Igual que arriba | | 26.04 LTS | `1.28.3-2ubuntu1.12` | Igual que arriba | | 26.10 | `1.30.4-7ubuntu1.1` | Igual que arriba | El anuncio contiene las correspondientes versiones fijas de paquetes homólogos como `nginx-core`, `nginx-extras`, `nginx-full` y `nginx-light`. No saque conclusiones sobre si es necesario solucionarlo desde la parte ascendente que solo se muestra en `nginx -v`. como Ubuntu 24.04 y `1.24.0-2ubuntu7.19` han sido parcheados por este proveedor, pero `1.24.0` de cualquier fuente no es inherentemente seguro. Ubuntu oficialmente también marcado claramente que CVE-2026-95101 solo afecta Ubuntu 26.04 / 26.10 , y CVE-2026-97629 solo afecta Ubuntu 24.04 / 26.04 / 26.10. Aquí está Ubuntu Su propio empaque y alcance funcional, que no pueden promocionarse directamente a otras distribuciones. [S13](https://keendigit.com/es/insights/nginx-remediation-guide#source-13) ### 3.4 Debian: Las diferencias entre versiones deben comprobarse por separado El aviso Debian DSA-6575-1 (2026-10-21) cubre estos cinco CVE e identifica el paquete `nginx` fijo para Debian 13/trixie como: ```text 1.26.3-3+deb13u10 ``` Sin embargo, en el momento de la verificación de este informe, `1.22.1-9+deb12u10` para Debian 12 / bookworm todavía está marcado como vulnerable por el rastreador de seguridad Debian. Por lo tanto: - Debian 13 Simplemente actualice y acepte según DSA-6575-1. - Debian 12 debe verificar las correcciones de seguridad proporcionadas por el Security Tracker actual o el proveedor de ELTS una por una; Antes de que se confirme la solución en el anuncio, no declare que los cinco elementos se han solucionado según el éxito de `apt upgrade`. - El paquete fuente Debian puede incluir un conjunto de parches independiente del número de versión nginx.org. Para compilaciones personalizadas, debe verificar el conjunto de correcciones del paquete de código fuente completo y no puede simplemente copiar una única confirmación ascendente y considerarla completa. La distinción anterior se basa en los registros de seguimiento de DSA y CVE. [S14](https://keendigit.com/es/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/es/insights/nginx-remediation-guide#source-15)[S16](https://keendigit.com/es/insights/nginx-remediation-guide#source-16) ### 3.5 NGINX Plus, njs y controlador de ingreso | Productos/Componentes | Puntos clave de selección y verificación de seguridad | | -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | NGINX Plus (versión comercial) | Consulte el anuncio y las instrucciones de actualización de la sucursal Plus correspondiente a F5. El CR más reciente en el momento de la verificación es `PLS.37.2.0.1` y la versión de seguridad de LTS es `PLS.37.0.7.1`; la versión Plus y el backport incluido no se pueden reemplazar directamente por el umbral 1.30/1.31 de código abierto. [S19](https://keendigit.com/es/insights/nginx-remediation-guide#source-19) | | njs/ngx\_http\_js\_module | 2026-10-14 lanza `njs 1.0.2` y corrige CVE-2026-101019 y CVE-2026-101025; Si está utilizando njs, también debe verificar la compatibilidad del módulo con NGINX. [S20](https://keendigit.com/es/insights/nginx-remediation-guide#source-20) | | F5 NGINX Controlador de ingreso/tela de puerta de enlace | El núcleo NGINX es una cadena de distribución de software relacionada pero independiente. Corrija las vulnerabilidades relevantes con sus respectivos controladores, imágenes y notas de la versión. No puedes simplemente reemplazar un binario NGINX en el Pod. | | Comunidad Kubernetes `kubernetes/ingress-nginx` | El proyecto quedará fuera de servicio en marzo de 2026 y ya no proporcionará nuevo mantenimiento de seguridad. Debe planear migrar a un controlador mantenido o Gateway API en lugar de confundir su número de versión con el controlador de ingreso F5 NGINX. [S21](https://keendigit.com/es/insights/nginx-remediation-guide#source-21) | ### 3.6 ¿Qué parche debería elegir? | Formulario de implementación | Prácticas recomendadas | Prueba de reparación | | --------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | | Paquete DEB/RPM oficial nginx.org | Actualice a la versión fija de la rama ascendente | `nginx -v/-V`, fuente del paquete, anuncio oficial de seguridad | | Repositorio oficial Ubuntu/Debian | Instalar paquetes de seguridad del proveedor | Versión del paquete completo + proveedor USN/DSA + estado CVE | | RHEL/Alma/Rocky/SUSE/Otras distribuciones | Actualice según boletines de seguridad de distribución específicos y versiones de paquetes | CSAF/anuncio del proveedor correspondiente, la versión Ubuntu/Debian no se puede aplicar | | Imágenes de contenedores oficiales o personalizados. | Reconstruya o extraiga la imagen de reparación verificada y reemplácela de forma continua | Resumen de imágenes, compilación de SBOM, identificación de imagen de pod/contenedor en ejecución | | NGINX, OpenResty, Tengine autocompilados o versiones parcheadas con módulos de terceros | Priorizar el uso de la versión de seguridad completa del mantenedor; realizar backports de parches revisados para el árbol de origen de destino cuando sea necesario | Cinco correcciones de vulnerabilidades, compatibilidad de módulos/ABI, regresión de unidades y negocios | OpenResty y Tengine son sistemas de liberación diferentes; Esta tabla solo describe el método de verificación. No significa que todas sus versiones se vean afectadas al mismo tiempo que el estándar NGINX, ni que el parche de código ascendente se pueda aplicar incondicionalmente. ## 4. Proceso de reparación formal ### 4.1 Inventario de instancias reales de recepción de tráfico externo Coteje para cada entrada al menos: - Nombre de dominio, equilibrio de carga/CDN/enlace proxy de borde, método de exposición del sitio de origen y protocolo de red utilizado. - Productos NGINX (Open Source, Plus, Ingress, etc.), versión completa, fuente del repositorio de paquetes, resumen de imágenes. - `nginx -V` muestra los módulos de construcción y los parámetros de compilación; si hay njs, Lua, OpenResty y módulos dinámicos de terceros. - PID master/worker en ejecución real, unidad de servicio/contenedor/pod, réplica y nodo Worker. - Las configuraciones efectivas reales de `http`/`stream`, `server`, `location`, `include`. - Ya sea para habilitar HTTP/3, mTLS, SSI/AIO, ruta de registro dinámica, `map` complejo y captura de expresiones regulares. No se limite a comprobar el `/etc/nginx/nginx.conf` predeterminado. El entorno de producción a menudo carga varios sitios, TLS y configuraciones de módulos a través de `include`. También puede haber varias rutas de instalación de NGINX o varias capas de proxy. ### 4.2 Verificar versión e información de compilación ```bash # NGINX 版本及构建选项 nginx -v nginx -V 2>&1 # Linux：查看实际运行的 NGINX 进程 ps -eo pid,ppid,user,comm,args | grep '[n]ginx' # Debian / Ubuntu：查看完整已安装包版本、来源 apt-cache policy nginx # 兼顾 nginx-core / nginx-full / nginx-extras 等实际已安装包 dpkg-query -W 'nginx*' 2>/dev/null # RPM 系：以实际安装包及仓库公告为准 rpm -qa | grep '^nginx' ``` `nginx -V` informa la compilación del binario encontrado en la ruta de la línea de comandos; no prueba que el worker en ejecución lo haya cargado. `nginx -v` puede omitir el sufijo del paquete completo de la distribución, así que verifique también el administrador de paquetes o los registros de la cadena de suministro. ### 4.3 Exporte la configuración efectiva y realice la primera ronda de detección estática `nginx -T` probará la configuración y volcará la configuración fusionada. La salida puede contener información confidencial como credenciales de autenticación, rutas de claves, nombres de host internos, etc. Se recomienda guardar el terminal controlado con permisos root y permisos de archivos privados, y no publicar los archivos originales en órdenes de trabajo públicas: ```bash sudo sh -c 'umask 077; nginx -T > /root/nginx-effective.conf 2> /root/nginx-config-check.log' sudo grep -nE \ 'alias|rewrite|map[[:space:]]|request_filename|aio[[:space:]]|ssi[[:space:]]|quic|http3|proxy_request_buffering|ssl_session_cache|ssl_session_ticket_key|ssl_session_tickets|ssl_verify_client|log_format|root[[:space:]]' \ /root/nginx-effective.conf ``` Este es solo el localizador de rutas candidatas, no una herramienta confiable de determinación automática de CVE: 1. `grep` no puede determinar si las variables están ubicadas en el mismo `location` o en la misma cadena de evaluación de solicitudes, ni puede deducir la relación de herencia de configuración. 2. `proxy_request_buffering on`, algunas configuraciones de caché y tickets tienen valores predeterminados, y no escribir las instrucciones correspondientes no significa que el riesgo desaparezca. 3. Las configuraciones generadas por servidores proxy inversos, CDN, sidecars de contenedores o controladores pueden diferir de los archivos inspeccionados manualmente. 4. Es posible que sea necesario confirmar las características de `NGINX Plus` y los módulos dinámicos utilizando sus respectivas herramientas de gestión oficiales. ### 4.4 Implementar solución a través de canales confiables Debian/Ubuntu (repositorio de distribución oficial): ```bash sudo apt-get update apt-cache policy nginx # 升级发行版仓库中已经安装的 NGINX 及相关包； # 先确认 Candidate 属于修复版本，再执行升级。 sudo apt-get install --only-upgrade nginx # 对实际安装的 nginx-core / nginx-full / nginx-extras 等包 # 确认它们的版本和依赖一同达到厂商修复要求。 dpkg-query -W 'nginx*' 2>/dev/null ``` Este conjunto de comandos no puede generar correcciones de seguridad de la nada que aún no estén disponibles. Especialmente para Debian 12, si el sistema de seguimiento de seguridad aún considera vulnerable el paquete actualizado, se requieren medidas adicionales de reparación, aislamiento o migración del proveedor. [S13](https://keendigit.com/es/insights/nginx-remediation-guide#source-13)[S14](https://keendigit.com/es/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/es/insights/nginx-remediation-guide#source-15) Paquete oficial nginx.org: ```bash # 先确认仓库来自 nginx.org、目标分支和候选版本 apt-cache policy nginx # 经变更审批后再执行对应仓库的升级命令 sudo apt-get install --only-upgrade nginx ``` Si utiliza OpenResty, Tengine o NGINX Plus autocompilados, utilice la versión de reparación admitida por el mantenedor correspondiente y no mezcle nginx.org, paquetes de distribución y de repositorio de terceros. Se deben conservar los archivos binarios/imágenes, las configuraciones, las firmas y los manifiestos de implementación de reversión originales. Contenedores/Kubernetes: actualice la imagen inmutable, registre su resumen y reemplace todas las réplicas antiguas con una implementación por etapas. `kubectl rollout status` solo confirma que el controlador de implementación finalizó; También verifique los resúmenes de imágenes, el enrutamiento de ingreso y las réplicas en mal estado. ### 4.5 Verifique la configuración y reemplace el antiguo Worker ```bash sudo nginx -t # 按服务实际名称、主机高可用和变更窗口执行重启 sudo systemctl restart nginx sudo systemctl status nginx --no-pager # 核查真正存在的 master / worker ps -eo pid,ppid,user,comm,args | grep '[n]ginx' ``` No trate a `nginx -s reload` como prueba de que se está ejecutando un nuevo binario: las recargas de configuración ordinarias permiten que el antiguo master inicie nuevos trabajadores sin reemplazar su ejecutable. NGINX admite un procedimiento de actualización binaria en línea dedicado, pero requiere pasos y verificación adicionales. Sin un procedimiento establecido, utilice un cambio de tráfico de alta disponibilidad seguido de un reinicio del servicio o implemente contenedores de reemplazo. [S22](https://keendigit.com/es/insights/nginx-remediation-guide#source-22) Si administra NGINX a través del socket `systemd`, el script de entrada del contenedor o varias instalaciones, debe verificar el objetivo de lanzamiento real y la ruta del proceso en lugar de asumir directamente que `systemctl restart nginx` cubre todas las instancias. ### 4.6 Aceptar y hacer regresión comercial desde la entrada externa real Se recomienda realizar al menos: - ¿Son correctos HTTPS normales, rutas reescritas, recursos estáticos y páginas de mapeo `alias`? - ¿Son correctas la distribución normal `map`, la ruta variable root, la ruta del registro de acceso, el enrutamiento de certificado/SNI y el proxy Stream? - ¿Las cargas normales, las cargas fragmentadas, las solicitudes de API y los límites de volumen ascendente para HTTP/3 (cuando están habilitados) siguen siendo los esperados? - mTLS: Las solicitudes de certificados legítimos deberían realizarse correctamente; Los certificados faltantes, vencidos o no autorizados aún deben rechazarse, y la reanudación/reconexión de TLS no debe cambiar los permisos accidentalmente. - Si la página SSI y el acceso asincrónico a archivos son normales; el registro de errores no muestra solicitudes anormales de referencias de memoria ni fallas repetidas de Worker. - Después del cambio de tráfico, el proceso de la versión anterior y la réplica de la imagen anterior deberían haber salido. Las pruebas deben realizarse en un entorno propio o autorizado. La prueba de humo de solicitud normal no puede probar por sí sola que se haya solucionado la vulnerabilidad de la memoria; En última instancia, la versión fija del proveedor, el parche del código fuente y la prueba de tiempo de ejecución deben aceptarse conjuntamente para su aceptación. ## 5. Medidas de mitigación cuando no es posible una actualización inmediata Esta sección es una opción de reducción de riesgos, no un reemplazo de parche. Se debe realizar una copia de seguridad de todos los cambios de configuración temporales, ejecutar `nginx -t`, publicarlos en lotes y revertirlos rápidamente si es necesario. [S3](https://keendigit.com/es/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/es/insights/nginx-remediation-guide#source-4) ### 5.1 Controlar la prioridad del tráfico según la exposición externa Priorice la reducción de la superficie de ataque de los servicios que no se pueden actualizar a tiempo: en la superficie de administración e interna API Agregue control de acceso a fuentes confiables, aislamiento de red ascendente o fuera de línea a corto plazo; agregar límites de conexión, cuerpo de solicitud y tarifas a las entradas de alto riesgo; asegúrese de que la autenticación de origen se produzca en el NGINX relacionado con la entrada antes de la cadena de procesamiento de solicitudes. Cabe señalar que la mayoría de las vulnerabilidades se encuentran en NGINX. Dentro del plano de datos, es posible que las reglas tradicionales WAF no determinen con precisión las condiciones de activación de la configuración personalizada. ### 5.2 `alias` / `rewrite`: evite evaluar `$request_filename` después de reescribir Se recomienda comprobar y ajustar: - Intente no realizar `rewrite` que cambiará URI al mismo tiempo que `location` usando `alias`. - Evite utilizar `$request_filename` cuando se haya reescrito URI pero aún no se haya completado la coincidencia de posición correcta. - Busque referencias de variables indirectas en `return`, `set`, `if`, `add_header`, acceda al formato de registro e incluya archivos. - Utilice `root`/`try_files`/`location` independiente cuando el negocio lo permita, pero solo cambie `alias` a `root`. También puede cambiar la semántica de la ruta del archivo, que debe verificarse una por una. No copie directamente la "plantilla de reescritura segura" común en Internet para sobrescribir la configuración existente. Los diferentes prefijos `location` y los objetivos de reescritura dan como resultado un empalme de rutas con significados completamente diferentes. [S5](https://keendigit.com/es/insights/nginx-remediation-guide#source-5) ### 5.3 `map`/Regex: Reducir la mezcla de estados variables de captura Se recomienda priorizar las capturas con nombre y limitar su alcance de propagación, en lugar de permitir que capturas anónimas como `$1` se reutilicen en diferentes rutas de evaluación de expresiones regulares a lo largo del tiempo. Por ejemplo: ```nginx # 演示具名捕获的结构，实际变量名和匹配表达式须按业务调整 map $host $tenant_root { default /srv/www/default; ~^(?[a-z0-9-]+)\.example\.net$ /srv/www/$tenant; } ``` Este fragmento solo demuestra una estructura de propiedad variable más fácil de auditar; no significa que se haya demostrado que elimina de forma independiente todas las rutas de activación del CVE-2026-93479. En particular, revise si otras `root` o `log_format` hacen referencia a las variables de captura con anticipación, y si hay `volatile`, rutas dinámicas y cadenas de evaluación interdependientes. F5/CERT recomienda utilizar la captura con nombre y limitar el alcance de uso a la configuración de coincidencia regular correspondiente como alivio a corto plazo. [S3](https://keendigit.com/es/insights/nginx-remediation-guide#source-3)[S6](https://keendigit.com/es/insights/nginx-remediation-guide#source-6) ### 5.4 AIO + SSI: Cerrar combinaciones de funciones innecesarias Para servidores/rutas que no requieren SSI o E/S de archivos asíncronos, utilice: ```nginx # 在适当的 http/server/location 上下文中配置 ssi off; aio off; ``` Desde la perspectiva de las condiciones desencadenantes de la vulnerabilidad, cerrar una de las dos suele ser suficiente para eliminar la cadena específica descrita; cerrar al mismo tiempo solo es aplicable a escenarios en los que la empresa no depende de esta capacidad. Verifique `include virtual`, subsolicitudes, caché y comportamiento del grupo de subprocesos; cuando la carga del proxy inverso es alta, apagar AIO puede cambiar la latencia y el rendimiento de E/S. [S7](https://keendigit.com/es/insights/nginx-remediation-guide#source-7) ### 5.5 HTTP/3 Solicitar inyección corporal: cerrar temporalmente la entrada si es necesario Deshabilite el escucha `quic` que involucra a HTTP/3, cancele el encabezado de respuesta `Alt-Svc` que anuncia HTTP/3 y verifique si la capa perimetral/equilibrador de carga aún envía solicitudes QUIC directamente al NGINX no reparado: ```nginx # 示意：保留 HTTPS/TCP；暂时移除此前的 QUIC/UDP listen server { listen 443 ssl; # 保留 HTTPS/TCP 入口 # 对支持新版语法的构建，可在此使用 http2 on; # 删除原有的 listen 443 quic reuseport; # 删除原有的 add_header Alt-Svc ...;（仅限宣传 h3 的那项） # 其余证书、server_name、location 等配置保持不变 } ``` Lo anterior es solo una descripción de la diferencia de cambio, no una configuración completa del servidor que se pueda habilitar individualmente. La sintaxis de configuración de HTTP/2 está relacionada con la versión NGINX; si necesita conservar HTTP/2, debe usar `http2 on;` o la sintaxis válida existente según la versión correspondiente y verificar con `nginx -t`. debe fusionarse con la configuración del servidor existente antes de la implementación, en lugar de reemplazar toda la sección con esta sección. También verifica el firewall UDP 443, la ubicación de terminación HTTP/3 y la ruta alternativa del cliente de CDN/proxy frontal. Otro tipo de mitigación a corto plazo es utilizar `proxy_request_buffering off;` en la ruta del proxy afectada, pero esto cambiará el comportamiento de la transmisión del cuerpo de la solicitud ascendente, los reintentos fallidos y algunos flujos de trabajo de carga; solo se puede utilizar después de pruebas suficientes y confirmación de que la directiva llega a la ruta del proxy HTTP/3 afectada. [S8](https://keendigit.com/es/insights/nginx-remediation-guide#source-8)[S18](https://keendigit.com/es/insights/nginx-remediation-guide#source-18) ### 5.6 TLS Ticket de sesión: Protección de prioridad mTLS Límite de autenticación Si la actualización no es posible y la instancia depende de la caché de sesión compartida + rotación automática de claves de ticket, evalúe: ```nginx # 在 nginx http/server 适当作用域进行配置 ssl_session_tickets off; ``` Esto puede desactivar el mecanismo de ticket de sesión TLS, eliminando así la ruta de falsificación de ticket descrita en esta vulnerabilidad; sin embargo, puede afectar el rendimiento de la reanudación de la sesión. No puede simplemente desactivar la verificación del certificado del cliente mTLS para "evitar vulnerabilidades", ya que eso eliminará directamente el límite de autenticación original. [S9](https://keendigit.com/es/insights/nginx-remediation-guide#source-9)[S12](https://keendigit.com/es/insights/nginx-remediation-guide#source-12) Los procesos de gestión profesionales TLS también pueden utilizar los archivos `ssl_session_ticket_key` explícitos y la rotación segura para evitar las condiciones generadas automáticamente, pero la custodia de claves, la distribución completa de los nodos, la rotación y los ciclos de vida de los tickets antiguos deben auditarse cuidadosamente. No se recomienda codificar una clave reutilizable a largo plazo en la configuración web normal o en scripts para emergencias temporales. Los servicios críticos que utilizan mTLS también deben monitorearse para detectar el comportamiento de reanudación de la sesión de TLS y el rechazo de solicitudes sin un certificado de cliente válido. [S12](https://keendigit.com/es/insights/nginx-remediation-guide#source-12) ### 5.7 El papel del sistema operativo y la protección de fronteras ```bash # Linux：常见值 2 表示进程地址空间随机化处于完整启用状态 sysctl kernel.randomize_va_space ``` Los trabajadores ASLR, no root, los sistemas de archivos contenedores de solo lectura, los permisos mínimos de archivos y el aislamiento de la red pueden reducir el impacto de un potencial RCE. ASLR no soluciona los desbordamientos del montón ni UAF y no puede garantizar que los trabajadores no fallen. WAF, los límites de tarifa y los límites de tamaño corporal de solicitud no solucionan la sincronización de claves del ticket TLS. [S4](https://keendigit.com/es/insights/nginx-remediation-guide#source-4) ### 5.8 Malentendido común: estas operaciones no son suficientes para completar la reparación | Operaciones comunes | ¿Por qué es insuficiente? | | ----------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | "nginx -v parece relativamente nuevo" | No se verifican la rama a la que pertenece, la versión completa del paquete respaldado de la versión de lanzamiento y el proceso en línea. | | “Solo se actualizó una de las intranets” | La antigua instancia de origen Worker/antiguo contenedor/antiguo CDN todavía recibe solicitudes | | "El sitio no utiliza PHP/etiquetas dinámicas" | El defecto se produce en la ruta principal NGINX o en el análisis del protocolo y no depende de la ejecución de PHP. | | "Abrir WAF/Cloudflare es suficiente" | No se puede demostrar que WAF bloquee todas las fallas de memoria dependientes de la configuración de NGINX o las fallas de reanudación de TLS | | "Ya abierto ASLR" | Simplemente aprovechando la mitigación de dificultades; DoS con inyección de solicitud aún es posible | | "HTTP/3 no está expuesto a la red pública, por lo que no es necesario realizar ninguna actualización" | Los otros cuatro CVE todavía requieren una evaluación independiente; y puede haber conexiones directas con orígenes ocultos | | "Se ha solucionado la vulnerabilidad `map` de julio" | Octubre CVE-2026-93479 implica problemas de regresión de evaluación de script posteriores | | "Deshabilitar el almacenamiento en caché resuelve todos los problemas" | Solo afecta a algunos escenarios de caché TLS o AIO y no cubre alias, script, HTTP/3. | ## 6. Ideas de implementación del parche oficial y puntos de revisión Esta sección sigue las correcciones ascendentes de NGINX de octubre de 2026. Los fragmentos ilustran cambios representativos para la revisión de parches; no son correcciones completas y compilables de forma independiente. Para compilaciones personalizadas, revise las confirmaciones completas, el código circundante y las pruebas, y prefiera una versión completamente compatible. [S5](https://keendigit.com/es/insights/nginx-remediation-guide#source-5)[S6](https://keendigit.com/es/insights/nginx-remediation-guide#source-6)[S7](https://keendigit.com/es/insights/nginx-remediation-guide#source-7)[S8](https://keendigit.com/es/insights/nginx-remediation-guide#source-8)[S9](https://keendigit.com/es/insights/nginx-remediation-guide#source-9) ### 6.1 CVE-2026-15176: URI se ha reescrito para incluir condiciones de rechazo de asignación de ruta `alias` La confirmación ascendente modificó `ngx_http_map_uri_to_path()` en `src/http/ngx_http_core_module.c`: ```diff - if (alias && !r->valid_location) { + if (alias && (!r->valid_location || r->uri_changed)) { ``` Enfoque de revisión: La ruta del sistema de archivos no se puede seguir calculando cuando URI ha cambiado pero la semántica de ubicación correspondiente de `alias` ya no es confiable. Se trata de una mejora de la restricción preestatal. No es una simple comprobación si la solicitud URI contiene caracteres ilegales. [S5](https://keendigit.com/es/insights/nginx-remediation-guide#source-5) ### 6.2 CVE-2026-93479: Distinguir correctamente entre longitud de datos de salida y longitud reservada La confirmación ascendente actualiza `src/http/ngx_http_script.c` y `src/stream/ngx_stream_script.c` al mismo tiempo. La intención central se puede resumir en: ```diff - n = len; + n = 0; /* ...计算实际脚本输出长度... */ - value->len = n; - value->data = ngx_pnalloc(pool, n); + value->len = n + len; + value->data = ngx_pnalloc(pool, n + len); ``` Aquí, `pool` es un nombre de parámetro ilustrativo: las expresiones de asignación HTTP reales y Stream difieren. El cambio calcula primero la longitud de salida del script y luego agrega la longitud reservada a la asignación final para que la salida no sobrescriba el espacio reservado. [S6](https://keendigit.com/es/insights/nginx-remediation-guide#source-6) Al realizar auditorías y backporting, también se debe cubrir el evaluador correspondiente de HTTP/Stream; Sólo comprobar el archivo de sintaxis de configuración de `map` no puede probar que el defecto se haya solucionado. ### 6.3 CVE-2026-97205: Establecer umbral de seguridad para el recuento de operaciones asíncronas de 8 bits Upstream agregado en `src/http/ngx_http_request.h`: ```c #define NGX_HTTP_MAX_BLOCKED 250 ``` Y agregue entradas similares a la lectura asincrónica de archivos, espera de caché, filtrado de salida y operación de subprocesos: ```c if (r->main->blocked >= NGX_HTTP_MAX_BLOCKED) { /* 使用同步路径，或者拒绝新的异步操作 */ } ``` Enfoque de revisión: Se deben cubrir todas las rutas de código reales que agregarán `r->main->blocked`. No puede simplemente escribir la constante de umbral en el archivo de encabezado. Backport también necesita verificar la coordinación completa del respaldo sincrónico, el retorno de llamada asincrónico y el retorno de error para garantizar que el bloqueo directo o la fuga de referencia no sean causados ​​por el rechazo directo de tareas. [S7](https://keendigit.com/es/insights/nginx-remediation-guide#source-7) ### 6.4 CVE-2026-95101: Mantener el estado de `skip` por separado para tramas desconocidas El nivel ascendente agrega el campo `skip` en la estructura de estado del analizador HTTP/3 y realiza la separación de estados: ```c if (st->type != NGX_HTTP_V3_FRAME_DATA && st->length > 0) { st->skip = st->length; st->length = 0; st->state = sw_skip; } /* ... */ rc = ngx_http_v3_parse_skip(b, &st->skip); ``` La clave no es "deshabilitar tramas HTTP/3 desconocidas", sino garantizar que en múltiples lecturas, el recuento de bytes omitidos y la longitud de la carga útil DATA siempre sean administrados por estados independientes. Las revisiones deben centrarse en la fragmentación entre búfer de fotogramas desconocidos y en la coherencia final de `client_max_body_size`. [S8](https://keendigit.com/es/insights/nginx-remediation-guide#source-8) ### 6.5 CVE-2026-97629: Sincronice el conjunto completo de ranuras para claves TLS Los cambios ascendentes se encuentran en `src/event/ngx_event_openssl.c`: ```diff ngx_memcpy(keys->elts, cache->ticket_keys, - 2 * sizeof(ngx_ssl_ticket_key_t)); + keys->nelts * sizeof(ngx_ssl_ticket_key_t)); ``` La imagen original contenía tres ranuras para llaves, pero sólo se copiaron las dos primeras. En su lugar, sincronice según la cantidad real de elementos de la matriz para garantizar que el conjunto de claves de votación de Worker sea coherente con la memoria compartida. Al revisar, también confirme que la asignación de matriz, la inicialización, el bloqueo compartido y la lógica de rotación sean consistentes, en lugar de simplemente verificar la modificación de longitud `memcpy` una vez. [S9](https://keendigit.com/es/insights/nginx-remediation-guide#source-9) ### 6.6 ¿Por qué no se recomienda aplicar sólo fragmentos de parche dispersos? Estas cinco modificaciones abarcan `src/http`, `src/stream`, `src/http/v3` y `src/event` respectivamente, y las versiones anteriores pueden tener backports de seguridad y extensiones no oficiales. El backporting debe formar la siguiente matriz de verificación: | comprobar objeto | que hay que confirmar | | ------------------------------ | ------------------------------------------------------------------------------------------------------- | | fuente del parche | Envío oficial, versión de destino coincidente, parche completo y verificación de firma. | | Conjunto de parches originales | No entra en conflicto con modificaciones históricas como CVE-2026-42533, backport de distribución, etc. | | ruta del código | El script HTTP + Stream, AIO/thread, HTTP/3, OpenSSL Ticket están todos cubiertos | | Compilado compatible | OpenSSL, PCRE, módulo ABI, módulo dinámico y dependencias de enlace son consistentes | | regresión funcional | Reescritura de `alias`, registro dinámico, SSI/AIO, carga de HTTP/3, reanudación de sesión de mTLS | | tiempo de ejecución | Todos los Worker/Pods ejecutan nuevas compilaciones verificadas, no quedan imágenes heredadas | Para los equipos que mantienen sus propias versiones, se recomienda mantener ID de parches, versiones de paquetes, registros de compilación e informes de regresión auditables para cada CVE; para operación y mantenimiento ordinarios, la solución más segura es instalar las actualizaciones de seguridad completas del proveedor. ## 7. Retroceso de vulnerabilidad histórica, sucursales antiguas y otros productos. ### Vulnerabilidad central 7.1 NGINX digna de confirmación simultánea de mayo a septiembre de 2026 Muchas instancias NGINX que no se han actualizado durante mucho tiempo no solo se ven afectadas por el nuevo problema de octubre. Los siguientes son los nodos de reparación representativos en un futuro próximo: [S1](https://keendigit.com/es/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/es/insights/nginx-remediation-guide#source-2) | CVE | Primera versión de corrección | Riesgos y condiciones clave que requieren auditoría | | -------------- | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | CVE-2026-42945 | Stable 1.30.1 / Mainline 1.31.0, 13 de mayo | `rewrite` La captura anónima de expresiones regulares y la lógica de reemplazo desencadenan un desbordamiento del montón, potencial RCE; Hay informes públicos de intentos de ataque en estado salvaje. | | CVE-2026-9256 | Stable 1.30.2 / Mainline 1.31.1, 22 de mayo | La superposición de captura de expresiones regulares y estimación de longitud en `rewrite` provoca un desbordamiento | | CVE-2026-42055 | Stable 1.30.3 / Mainline 1.31.2, 17 de junio | HTTP/2 Configuración específica para upstream o gRPC, la condición de encabezado de solicitud grande desencadena un desbordamiento del búfer | | CVE-2026-42530 | Mainline 1.31.2, 17 de junio | HTTP/3 Uso después de la liberación; Marca oficial gama afectada `1.31.0–1.31.1` | | CVE-2026-42533 | Stable 1.30.4 / Mainline 1.31.3, 15 de julio | La evaluación de la variable de captura de expresiones regulares `map` + provoca un desbordamiento del montón y los parches posteriores tienen correlación de regresión con CVE-2026-93479 en octubre | | CVE-2026-60005 | Stable 1.30.4 / Mainline 1.31.3, 15 de julio | `ngx_http_slice_module` El contenido de la memoria se filtró bajo condiciones específicas de actualización de caché y variables | | CVE-2026-56434 | Stable 1.30.4 / Mainline 1.31.3, 15 de julio | SSI está relacionado con UAF; no es la misma causa root que la vulnerabilidad de conteo AIO de octubre | | CVE-2026-90439 | Stable 1.30.5 / Mainline 1.31.6, 15 de septiembre | Desbordamiento de montón limitado de la combinación de versión HTTP/3 + OpenSSL específica, que se manifiesta principalmente como falla/corrupción de memoria limitada | Otras vulnerabilidades como NGINX Core, HTTP/2, charset y SMTP anunciadas en 2026 también deberían ser investigadas según los boletines de seguridad oficiales; Esta tabla se centra intencionalmente en eventos típicos que son más relevantes para las implementaciones actuales de proxy inverso de cara al público NGINX y que tienen implicaciones para la seguridad de la memoria o la integridad de las solicitudes. No son todos los CVE en 2026. Lista. [S1](https://keendigit.com/es/insights/nginx-remediation-guide#source-1) #### Por qué prestar especial atención a CVE-2026-42945 Hay boletines de seguridad de agencias gubernamentales que registran actividades de explotación en estado salvaje e información pública del código de explotación para esta vulnerabilidad `rewrite` en mayo. Por lo tanto, para los casos que no han sido parcheados durante mucho tiempo desde mayo hasta el presente y tienen abiertas reescrituras complejas de expresiones regulares en la red pública, además de completar la reparación, se deben revisar adicionalmente el bloqueo anormal de Worker, los registros de acceso y los cambios sospechosos en ese momento. [S23](https://keendigit.com/es/insights/nginx-remediation-guide#source-23) "Se produjo un intento de ataque" no prueba automáticamente que el atacante haya ejecutado comandos de manera confiable en cada objetivo; Cuando se trata de respuesta a incidentes, los indicadores de compromiso y las fallas de los procesos deben investigarse por separado de la evidencia real de escalada o persistencia de privilegios. ### 7.2 Corrección para versiones anteriores y backports de distribución NGINX Las diferentes ramas tienen sus propios ciclos de soporte y diferentes tiempos de introducción de vulnerabilidades. Los cinco nuevos parches no se pueden implementar en todos los árboles fuente iniciales sin una revisión. | escena | Estrategia recomendada | | ----------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | La versión de lanzamiento ha anunciado parches de seguridad completos. | Utilice paquetes de proveedores y documente versiones completas de los paquetes; evite reemplazar con archivos binarios desnudos ascendentes incompatibles | | Debian 12 y otras versiones afectadas que aún no están cubiertas por todos los CVE de este lote | Enviar órdenes de trabajo de riesgo, limitar la exposición externa y verificar el estado del proveedor/ELTS; migrar o utilizar una cadena de versiones de mantenimiento verificable cuando sea necesario | | Ramas históricas que han finalizado el soporte upstream | Priorizar la migración a versiones compatibles; Si es necesario realizar un backport a corto plazo, los mantenedores evaluarán las dependencias y la compatibilidad de los parches y escribirán pruebas completas. | | Viene con horquilla NGINX (OpenResty, Tengine, puerta de enlace personalizada) | Primero determine si se incluye la ruta del código correspondiente y luego use la declaración de seguridad del mantenedor de la bifurcación. No puede ser directamente equivalente a la versión ascendente. | | Los parches de seguridad provocan cambios en la funcionalidad empresarial | Adoptar implementaciones por etapas, cambio de tráfico entre versiones y adaptación de la configuración; no es apropiado restaurar la versión no reparada de la red pública sin aislamiento. | ### 7.3 Corrección separada para njs, Ingress y NGINX Core - njs: además del programa principal NGINX, también debe verificar la versión del módulo JavaScript NGINX. `njs 1.0.2` soluciona un problema de agotamiento de la memoria de análisis XML y de inconsistencia de validación XML de octubre de 2026 con atributos de referencia de entidad. Para implementaciones asociadas con la verificación de firma XML usando `nginx-saml`, debe leer más las instrucciones oficiales njs para escenarios de complementos. [S20](https://keendigit.com/es/insights/nginx-remediation-guide#source-20) - Controlador de ingreso F5 NGINX Plus / NGINX: Además, el controlador y Gateway Fabric pueden tener boletines de seguridad adicionales, diferentes versiones de empaquetado y vulnerabilidades de políticas únicas. Actualizar una capa no significa actualizar automáticamente otra capa. [S19](https://keendigit.com/es/insights/nginx-remediation-guide#source-19) - Comunidad Kubernetes ingress-nginx: Los funcionarios de Kubernetes ya han anunciado que el controlador dejó de recibir mantenimiento en marzo de 2026 y su almacén no se puede confundir con el controlador F5. Las empresas afectadas deben planificar una migración fluida y verificar las anotaciones de Ingress y las diferencias semánticas de Gateway API en lugar de esperar una nueva versión de seguridad. [S21](https://keendigit.com/es/insights/nginx-remediation-guide#source-21) ## 8. Criterios de aceptación e inspecciones de seguimiento Se recomienda utilizar la siguiente lista como condiciones de aceptación para las órdenes de trabajo de cambio: | Proyecto | Estándares de calificación | Pruebas que pueden conservarse | | --------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | | Cobertura de activos y portales | Se han inventariado todas las instancias externas y conectadas directamente que pueden omitir CDN. | Nombre de dominio, LB, IP, lista de pods/contenedores | | Fuente del paquete y alcance de la reparación | Utilice versiones confirmadas para cubrir todos los CVE aplicables | Aviso de seguridad ascendente, USN/DSA, versión del paquete, resumen de imágenes | | salidas de procesos antiguos | Se han reemplazado todos los contenedores antiguos master/worker/ | PID/hora de inicio, estado de implementación continua, imagen en ejecución | | Auditoría de configuración | Se han eliminado o cubierto mediante parches las combinaciones de alto riesgo y se han verificado las relaciones de herencia. | resumen redactado y registro de auditoría de `nginx -T` | | TLS/mTLS | Pasan los certificados confiables; se rechazan los certificados inválidos o faltantes; La reanudación de la sesión no pasa por alto la autenticación. | Prueba de autorización negativa/positiva, resultados controlados de la prueba TLS | | Cuerpo de solicitud HTTP/3 | Habilitar ruta fija; El cuerpo de la solicitud ascendente y la limitación se comportan correctamente. | HTTP/3, carga de proxy, prueba de regresión de límite de volumen | | SSI/AIO | La función cumple con los requisitos, Worker no tiene abortos anormales | Monitoreo de regresión empresarial, fallas y tasa de error | | Monitoreo de operación y mantenimiento. | Sin excepción obvia 5xx, SIGSEGV, el proceso sale repetidamente | Indicadores y registros de servicio antes y después de los cambios. | | estrategia de reversión | Si es necesaria una reversión, primero limite la exposición y preserve los límites de seguridad. | Órdenes de cambio, flujos de emergencia y planes de cuarentena | | ciclo de vida posterior | Determinar las suscripciones a boletines de seguridad, la frecuencia de actualización de contenedores y los planes de migración de sucursales. | Libro mayor de actualización, persona responsable y próxima fecha de auditoría | ### 8.1 ¿En qué debería centrarse en los registros y el estado de ejecución? Solucionar anomalías en servidores que han estado expuestos durante mucho tiempo `worker process exited on signal` 、 `SIGSEGV` , picos de fallas de solicitudes, agregación anormal de acceso a fuentes, TLS Reanudación de sesión/éxito de autenticación inesperados y comportamiento anormal del cuerpo de solicitud de backend. Estos indicadores sólo pueden utilizarse como pistas de investigación y no son evidencia suficiente para demostrar directamente que se ha explotado un determinado CVE. ;La falta de registros relevantes no prueba que no haya habido un ataque. ### 8.2 Redacción final recomendada de la conclusión sobre riesgos El informe de aceptación para el entorno de producción debe utilizar la siguiente expresión precisa: > Se han identificado la entrada de servicio externo NGINX y la fuente del paquete de software. Todas las instancias aplicables se han actualizado a la versión de seguridad oficial ascendente o se ha completado el backport confirmado por el proveedor de la versión; Se han sustituido el antiguo Worker y los contenedores antiguos. Las configuraciones relacionadas con el alias/reescritura/mapa, AIO/SSI, HTTP/3 y el ticket de sesión TLS/mTLS han sido auditadas y pasaron pruebas de regresión funcional, de autenticación y de integridad de la solicitud. Para los casos que aún no han completado la actualización, registre adicionalmente las áreas de exposición, las medidas de compensación, las personas responsables y los plazos de finalización. Si el parche para Debian 12 u otras versiones aún está incompleto, no es apropiado juzgar todo el formulario de aceptación como "completado"; Se debe registrar claramente el CVE no resuelto, si existe una configuración de activación correspondiente, el estado de aislamiento y la ruta de actualización final. *** ## Apéndice: fuentes citadas y enlaces Descripción: Los números `[Sx]` en el texto corresponden uniformemente a esta sección. A continuación se da prioridad a los anuncios de seguridad del proyecto, las confirmaciones de código, los anuncios de lanzamiento de proveedores y la información de la agencia de seguridad nacional. La gravedad de las vulnerabilidades citadas se describe según los criterios de calificación de cada organismo emisor; la fecha de verificación de datos es el 27 de octubre de 2026. ### T1 — Boletín oficial de seguridad NGINX Open Source - Contiene las versiones afectadas, ramas de corrección y niveles de gravedad oficiales de cinco CVE de octubre, y también cubre vulnerabilidades históricas hasta 2026. ### T2 — Registro de lanzamiento de la versión oficial NGINX - - Confirme 1.30.6 / 1.31.7 de 2026-10-14, 1.31.8 de 2026-10-21 y los hitos críticos de la versión de seguridad de mayo a septiembre. ### S3 - Agencia de Seguridad Cibernética de Singapur: F5 NGINX Tres vulnerabilidades críticas - Descripción de las puntuaciones de CVSS v4.0 9.2, condiciones de configuración requeridas y recomendaciones de mitigación provisionales para CVE-2026-15176, CVE-2026-93479 y CVE-2026-97205. ### S4 - NHS Inglaterra: F5 NGINX Aviso de alto riesgo - Describe el impacto potencial de DoS/RCE de los problemas de seguridad de la memoria y restricciones como la desactivación o la omisión de ASLR. ### T5 - Confirmación de fuente oficial: CVE-2026-15176 - Corresponde a la verificación de estado de `alias` y `r->uri_changed` en `ngx_http_map_uri_to_path()`. ### T6 - Confirmación de fuente oficial: CVE-2026-93479 - Correspondiente a la longitud del script HTTP/Stream y la lógica de asignación del búfer reservado. ### S7 - Confirmación de fuente oficial: CVE-2026-97205 - Corresponde al umbral de recuento `r->main->blocked` `NGX_HTTP_MAX_BLOCKED 250` y al respaldo de ruta asincrónica. ### T8 - Confirmación de fuente oficial: CVE-2026-95101 - La separación de estados correspondiente a la longitud restante del marco desconocido HTTP/3 y la longitud del cuerpo de la solicitud DATA. ### T9 - Confirmación de fuente oficial: CVE-2026-97629 - Corresponde a todas las ranuras de claves durante la sincronización TLS Rotación de tickets de sesión. ### T10 - F5: Anuncio del proveedor de CVE-2026-15176 - Enumere los factores desencadenantes como `alias`, `rewrite`, `$request_filename` y registros de acceso. ### T11 - F5: Anuncio del proveedor CVE-2026-93479 - Enumere la captura de expresiones regulares del mapa, la ruta root y las condiciones de evaluación de variables de registro. ### S12 — Documentación oficial del módulo NGINX TLS/SSL - Descripción `ssl_session_cache`, `ssl_session_tickets`, `ssl_session_ticket_key` y autenticación de certificado de cliente y otras instrucciones. ### S13 — Aviso de seguridad: Ubuntu USN-8955-1 (2026-10-26) - Proporciona la versión fija del paquete de software completo y el alcance de distribución de Ubuntu 22.04 / 24.04 / 26.04 / 26.10. ### S14 — Aviso de seguridad: Debian DSA-6575-1 (2026-10-21) - Confirme el paquete de corrección de seguridad `1.26.3-3+deb13u10` para Debian 13/trixie y registre la asociación de backport para CVE-2026-93479. ### S15 — Seguimiento de vulnerabilidades: Debian Security Tracker: CVE-2026-15176 - Se utiliza para verificar el estado de corrección de distribución de Debian 12/bookworm y Debian 13/trixie. Este estado puede cambiar con futuras actualizaciones de seguridad. ### S16 — Seguimiento de vulnerabilidades: Debian Security Tracker: CVE-2026-95101 - Confirmación complementaria del estado de seguridad de la vulnerabilidad HTTP/3 en diferentes ramas de Debian. ### T17 - Sombrero rojo: CVE-2026-93479 - Comprensión complementaria de la correlación entre la vulnerabilidad de regresión de octubre y la solución de julio CVE-2026-42533. ### S18 — Documento oficial del módulo de proxy inverso NGINX - - Consulta la semántica y los valores predeterminados de configuraciones como `proxy_request_buffering`, `client_max_body_size`, `alias`, `aio`, etc. ### T19 - Notas de la versión oficial de NGINX Plus - List Plus CR/LTS ramas, versiones, parches y recordatorios de compatibilidad de actualizaciones. ### S20 — NGINX JavaScript / njs Boletín de seguridad oficial - - Contiene octubre de 2026 njs 1.0.2 y validación XML relacionada, problemas de agotamiento de la memoria. ### T21 — Kubernetes: Instrucciones oficiales de retiro de la comunidad ingress-nginx - - Tenga en cuenta que el proyecto detuvo nuevas versiones y correcciones de seguridad en marzo de 2026, y se recomienda migrar el controlador mantenido o Gateway API. ### S22: control de servicio oficial NGINX e instrucciones de actualización binaria en línea - Distinga los métodos de recarga de configuración, reinicio y actualización de archivos ejecutables en línea para la aceptación del cambio de proceso. ### S23: Aviso de seguridad del gobierno: vulnerabilidad de reescritura NGINX de mayo de 2026 - - Proporcionar antecedentes históricos de riesgos y sugerencias de actualizaciones de seguridad para CVE-2026-42945; Los juicios relacionados con la explotación en la naturaleza deben basarse en el anuncio de la agencia en ese momento y en evidencia adicional del incidente. ### S24 — F5: Anuncios de proveedores de CVE-2026-95101 y CVE-2026-97629 - - Cubre los riesgos de inyección del cuerpo de solicitud HTTP/3 y rotación automática de clave de Ticket TLS respectivamente. ### T25 - F5: Anuncio del proveedor de CVE-2026-97205 - Descripción SSI/AIO condiciones de activación y posibles riesgos de corrupción de memoria. [Actualización de seguridad NGINX: comprobaciones de configuración, actualizaciones y verificación](https://keendigit.com/es/news/nginx-security-update) ## Consulta de mantenimiento de seguridad. ¿No está seguro de cómo los cambios de confianza de los certificados afectan sus sistemas? Podemos ayudar a evaluar a los clientes afectados y planificar actualizaciones de seguridad. [Discutir actualizaciones de seguridad]() [pagina original]() · [índice de contenido]() KeenDigit LLC · Identificación de presentación de Wyoming: 2026-002106155 [Verificar con el Secretario de Estado de Wyoming]() © 2026 KeenDigit LLC · Sheridan, Wyoming, EE.UU. · Todos los derechos reservados.