PHP, GitLab, Node.js y NGINX: los 4 parches de seguridad que tienes que instalar ya

Esta semana se han juntado cuatro avisos de seguridad que conviene atender cuanto antes si tienes un servidor propio, una VPS o simplemente un proyecto en producción: PHP, GitLab, Node.js y NGINX. En los cuatro casos el atacante no necesita una cuenta: le basta con enviar peticiones o contenido manipulado. En el peor escenario, eso termina en ejecución remota de código (RCE): alguien de fuera ejecutando sus propios comandos en tu máquina.

La buena noticia: todos tienen ya versión corregida, y a fecha de hoy (22 de octubre de 2026) ninguno figura como explotado en el catálogo KEV de CISA. La mala: no hay que esperar a que eso cambie.

▲ En la imagen Los cuatro productos y su gravedad, tal como aparecen en el resumen animado. «Crítica» y «Alta» son las etiquetas oficiales de cada proyecto.

Resumen rápido

1. PHP — dos fallos críticos (CVSS 9.2, «PHP2Shell»). Actualiza a 8.5.12, 8.4.27, 8.3.36 u 8.2.35.
2. GitLab (instalaciones propias) — CVSS 10.0, afecta desde la versión 7.0. Actualiza a 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 u 18.11.13.
3. Node.js — fallo alto en el descompresor Brotli. Actualiza a 22.23.4, 24.22.1 o 26.12.1.
4. NGINX — tres fallos que solo afectan a ciertas configuraciones. Actualiza a 1.30.6 (estable) o 1.31.7 (mainline).

1. PHP: «PHP2Shell» (CVE-2026-109618 y CVE-2026-109619)

PHP publicó el 21 de octubre versiones corregidas para dos vulnerabilidades con nota 9.2 sobre 10 (CVSS v4.0). Circularon como un solo fallo y hasta con un «10», pero el dato oficial son dos CVE con 9.2 cada uno.

Qué hace

1. CVE-2026-109618: un atacante envía peticiones de subida (multipart) preparadas para que PHP se quede sin memoria. Al abortar, PHP deja estructuras internas a medio inicializar y la limpieza posterior las usa como si fueran válidas: corrupción de memoria que puede acabar en ejecución de código.
2. CVE-2026-109619: una petición deja «estado global» apuntando a memoria ya liberada, y la siguiente petición que atiende el mismo proceso la reutiliza (use-after-free). Uno de los caminos es el progreso de subida de sesiones, session.upload_progress, que viene activado por defecto.

Lo importante: no depende de tu aplicación. Da igual que tu WordPress, Drupal o Laravel estén al día; el fallo está en el propio intérprete. El escenario de más riesgo es Apache con mod_php, donde los investigadores demostraron una ejecución de código completa (sin publicar el exploit). PHP-FPM, FrankenPHP y LiteSpeed también se consideran susceptibles, en distinto grado.

▲ En la imagen Peticiones manipuladas agotan la memoria del proceso de PHP y, a partir de ahí, el atacante consigue ejecutar código. Es un esquema simplificado, no una captura de un ataque real.

Versiones

1. Corregidas: 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
2. PHP 8.1 y anteriores también están afectados y no tienen versión oficial corregida: solo hay parches en código fuente para 7.4, 8.0 y 8.1, o el soporte extendido de tu proveedor.

Qué hacer

Comprueba la versión que sirve la web (ojo: el php de la terminal puede ser otro binario distinto del de Apache o FPM) y actualiza desde tu distribución:

Si tu distribución aplica el parche sin cambiar el número de versión (backport), compruébalo en el changelog del paquete buscando los CVE. En Docker, reconstruye con docker build --pull o usa la etiqueta php:8.4.27-* equivalente: una imagen fijada a una versión anterior sigue vulnerable. Y reinicia todos los workers: el binario viejo sigue en memoria hasta entonces.

Si no puedes actualizar hoy, el aviso oficial propone mitigaciones temporales (no sustituyen al parche): session.upload_progress.enabled = 0 en php.ini o en el pool de FPM, en PHP 8.5 fatal_error_backtraces = 0, y limitar en el proxy el tamaño y el número de partes de las peticiones multipart. Bloquea multipart/form-data si tu aplicación no recibe subidas.

2. GitLab: nota máxima, 10 sobre 10 (CVE-2026-110264)

El 21 de octubre GitLab publicó un Critical Patch Release con 12 correcciones. La principal tiene CVSS 10.0: un desbordamiento de entero en el compilador de expresiones regulares que un atacante sin autenticar puede aprovechar para ejecutar código en el servidor «bajo ciertas condiciones». GitLab no ha dado más detalles técnicos todavía (suele publicarlos unos 90 días después); los indicadores de detección que publicó apuntan al motor de expresiones regulares de Ruby al renderizar contenido Org-mode.

Y sí, el dato que circula es correcto: afecta a todas las versiones desde la 7.0, que es de 2014.

▲ En la imagen Todas las versiones de GitLab instaladas por cuenta propia desde la 7.0 (2014) están afectadas. GitLab.com ya está corregido.

¿Me afecta?

1. GitLab.com y GitLab Dedicated: ya están parcheados, no tienes que hacer nada.
2. Instalación propia (CE o EE; Omnibus, Docker, Helm o código fuente): sí, tienes que actualizar, incluidas las réplicas de Geo.

Versiones corregidas

19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 y 18.11.13. Si estás en una versión anterior a la 18.11 no hay parche en tu rama: tienes que subir respetando las paradas obligatorias de actualización (la herramienta Upgrade Path de GitLab te dice cuáles). Atención: las versiones del parche del 12 de octubre (19.4.2, 19.3.5, 19.2.8) no corrigen este fallo.

Qué hacer

Guarda también /etc/gitlab/gitlab-secrets.json y /etc/gitlab/gitlab.rb. Las versiones 19.4.3 y 19.3.6 incluyen migraciones de base de datos, así que en una instalación de un solo nodo habrá un corte breve. GitLab no ofrece ninguna mitigación alternativa: la única solución es actualizar. Si tardas, al menos reduce la exposición (sin proyectos públicos ni acceso anónimo, detrás de VPN o SSO). Hay un supuesto exploit circulando en GitHub que no está verificado: no lo ejecutes.

3. Node.js: un archivo comprimido que corrompe la memoria (CVE-2026-111497)

Node.js publicó el 21 de octubre versiones para sus tres ramas con soporte. El fallo más serio está en Brotli, la librería de Google para descomprimir datos que Node.js lleva dentro: un flujo comprimido preparado a propósito provoca una escritura fuera de límites en memoria. Puede filtrar memoria del proceso, tumbarlo o, potencialmente, ejecutar código. Node.js lo califica como «Alta»; el registro del CVE, emitido por Google, le da 9.2 en CVSS v4.0.

No hace falta que tu código use Brotli a propósito: basta con que descomprima contenido que viene de fuera. fetch() descomprime las respuestas con Content-Encoding: br, igual que axios o got, y Express 5 con body-parser 2.x descomprime los cuerpos de las peticiones que recibe. También zlib.brotliDecompress() sobre datos externos.

▲ En la imagen Los datos descomprimidos se salen del búfer reservado (en rojo) y pisan memoria ajena. Esquema simplificado.

Versiones

1. Corregidas: v22.23.4 (LTS), v24.22.1 (LTS) y v26.12.1 (Current).
2. Node 20 y Node 25 están fuera de soporte y no recibirán corrección: toca migrar a 22, 24 o 26.
3. El mismo lote corrige otros tres fallos «Alta» (resolución DNS y validación del nombre de host en TLS), así que actualizar compensa aunque no uses Brotli.

Qué hacer

Comprueba la versión en el servidor o contenedor real (process.versions.node), no solo en tu equipo. Después reinicia los procesos y vuelve a construir imágenes, capas de Lambda y ejecutables SEA. Si no puedes actualizar ya, rechaza los cuerpos comprimidos con Brotli en tus APIs (por ejemplo body-parser con inflate: false) y no descomprimas Brotli de servidores que no controlas.

4. NGINX: tres fallos, pero solo con ciertas configuraciones

Aquí hay que matizar lo que circula. Los tres fallos (CVE-2026-15176, CVE-2026-97205 y CVE-2026-93479) son de corrupción de memoria en el proceso worker y los dispara un atacante remoto sin cuenta, pero solo con configuraciones concretas que no vienen por defecto. Además, el aviso no es de esta semana: nginx.org publicó las versiones corregidas el 14 de octubre.

El 9.2 que se ve en redes es la nota en CVSS v4.0 que les da F5; en CVSS v3.1 son 8.1 y nginx.org los califica como «medios». Lo normal es que el efecto sea la caída del worker; la ejecución de código solo es posible si la protección ASLR del sistema está desactivada o se puede sortear.

▲ En la imagen Las tres construcciones de configuración que activan los fallos. Si tu nginx.conf no usa ninguna, el riesgo baja mucho, pero actualizar sigue siendo lo recomendable.

Las configuraciones afectadas

1. CVE-2026-15176: un location con alias junto con rewrite y $request_filename (también si aparece en un log_format).
2. CVE-2026-97205: aio activado y páginas SSI con include virtual.
3. CVE-2026-93479: un map con expresión regular cuyas capturas sin nombre ($1…) se usan en root o en el formato del log.

Versiones y qué hacer

Corregidas: 1.30.6 (estable) y 1.31.7 (mainline). NGINX Plus: 37.0.5.1 o 37.1.0.1 (R33 a R36 no tienen corrección, hay que pasar a la serie 37).

Usa restart, no reload: recargar no carga el binario nuevo. Mientras actualizas, F5 propone evitar alias dentro de location y $request_filename, desactivar aio o ssi, y usar capturas con nombre en los map. Un caso aparte: ingress-nginx, el controlador comunitario de Kubernetes, se retiró en marzo de 2026 y no recibirá parches; si lo usas, revisa la configuración o migra.

Qué hacer hoy, en tres pasos

▲ En la imagen Comprueba tus versiones, actualiza y reinicia. Las versiones del ejemplo son las corregidas.

1. Comprueba qué versión corre de verdad: php -v, node -v, nginx -v y sudo gitlab-rake gitlab:env:info, en el servidor o contenedor, no en tu portátil.
2. Actualiza a la versión corregida de tu rama. Si usas paquetes de la distribución, confirma el CVE en el changelog: el número puede no cambiar.
3. Reinicia los servicios y reconstruye las imágenes Docker. Un parche instalado que no se ha reiniciado no protege.

Si tu hosting es compartido o gestionado (cPanel, Plesk, plataformas serverless), la actualización depende del proveedor: pregúntale si ya ha aplicado estos parches.

Míralo en un minuto

Lo hemos resumido en un video corto con animaciones que explican cada fallo. Está en el Instagram de Latimixo: ver el video en Instagram.

Fuentes

1. php.net — aviso de seguridad y versiones 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
2. GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
3. GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
4. GitLab — Critical Patch Release 19.5.1
5. Node.js — October 2026 Security Releases
6. Google Brotli — versiones 1.2.1 / 1.1.1 / 1.0.10
7. nginx.org — avisos de seguridad (1.30.6 / 1.31.7)
8. CISA — catálogo KEV (consultado el 22 oct 2026)

Datos verificados el 22 de octubre de 2026 en los avisos oficiales de cada proyecto y en el registro CVE. Las afirmaciones de explotación que circulan sobre PHP2Shell vienen de empresas de seguridad y no las confirman ni PHP ni CISA. Animaciones y música originales de Latimixo; narración del video con voz sintética.