Vulnerabilidades críticas en PHP: actualice ahora (CVE-2026-109618 y CVE-2026-109619)

El 20 de octubre el proyecto PHP anunció una versión de seguridad para dos vulnerabilidades críticas. El 21 de octubre a las 13:30 UTC se publicaron los parches. Ambas vulnerabilidades permiten ejecución remota de código sin autenticación con una puntuación CVSS de 9,2, y ya circula código proof-of-concept público.

No es una vulnerabilidad que se planifique para la próxima ventana de mantenimiento. Es una vulnerabilidad que se corrige hoy.

Lo esencial

• Actualice a PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35.
• Afecta a cualquier PHP que atienda tráfico web: PHP-FPM, mod_php, php-cgi, FrankenPHP y LiteSpeed.
• Puede bastar una sola petición sin autenticar, y puede actuar antes de que se ejecute el código de su aplicación.
• El código PoC es público. Cuente con escaneo masivo en horas, no en semanas.
• Si no puede parchear de inmediato: aísle los servicios expuestos a Internet hasta que el parche esté aplicado y verificado.

Qué ocurrió

El 20 de octubre el proyecto PHP comunicó que preparaba una versión de seguridad. Al día siguiente, el 21 de octubre a las 13:30 UTC, los parches se publicaron de forma simultánea en cuatro versiones: 8.5.12, 8.4.27, 8.3.36 y 8.2.35. CERT-EU emitió ese mismo día un aviso de seguridad y pidió a las organizaciones actualizar de inmediato.

Un parche rápido es algo bueno. Que la descripción técnica se hiciera pública al mismo tiempo significa que el plazo entre «existe el parche» y «los atacantes lo intentan» se mide en horas.

Qué hacen realmente estas vulnerabilidades

CVE-2026-109618: corrupción de memoria en el límite de memoria

PHP detiene una petición que supera memory_limit interrumpiéndola mediante longjmp(). La interrupción puede producirse por tanto en mitad de una operación interna, cuando los datos de la petición solo están parcialmente inicializados, por ejemplo durante el análisis de una subida de archivo en un formulario.

La limpieza de la petición puede entonces tratar datos no válidos como válidos y liberar memoria que nunca se inicializó. Esa memoria puede contener todavía datos de asignaciones anteriores controlados por el atacante. El resultado es una corrupción de memoria que puede llevar a ejecución de código.

CVE-2026-109619: estado global residual

Un estado interno perteneciente a una petición puede sobrevivir después de liberarse su memoria, por ejemplo tras un error fatal. Una petición posterior atendida por el mismo proceso de trabajo puede usar ese estado residual antes de que la inicialización normal llegue a restablecerlo.

Ninguna de las dos vulnerabilidades requiere un fallo en su aplicación. Están en el propio manejo de peticiones de PHP.

Un exploit demostrado muestra que una única petición sin autenticar puede desencadenar el ataque antes de que se ejecute cualquier código de la aplicación.

A quién afecta

A todas las instalaciones de PHP que sirven tráfico web. El equipo de PHP considera mod_php la configuración más expuesta.

• PHP 8.5 anterior a 8.5.12
• PHP 8.4 anterior a 8.4.27
• PHP 8.3 anterior a 8.3.36
• PHP 8.2 anterior a 8.2.35
• Las ramas al final de su vida útil (PHP 8.1 y anteriores), que ya no reciben actualizaciones periódicas

Además: muchos productos comerciales y de código abierto usan PHP por debajo. Pueden estar afectados aunque usted no gestione una instalación de PHP propia. NCSC-NL ha publicado una lista de software de terceros con PHP incorporado.

El error más frecuente que vemos: contar solo los servidores que usted instaló. No olvide contenedores, imágenes de CI, appliances, herramientas internas y servicios gestionados por proveedores.

Compruebe su exposición: cinco minutos por entorno

1. Ejecute php -v en cada host y en cada contenedor. No solo en uno.
2. Inventaríe los entornos de ejecución: pools de PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP, LiteSpeed.
3. Reconstruya las imágenes de contenedor: lo que cuenta es la imagen base, no la instancia en ejecución.
4. Pregunte a los proveedores que operan por usted productos dependientes de PHP: qué versión ejecutan y cuándo estarán parcheados.
5. Localice las ramas al final de su vida útil. PHP 8.1 y anteriores ya no reciben parches periódicos.

Remedie

Paquetes de la distribución. Las distribuciones de Linux y los proveedores LTS ya tenían los parches. Actualice mediante el gestor de paquetes y reinicie los procesos de trabajo.

Contenedores. Actualice la imagen base y reconstruya. Reiniciar una imagen antigua no resuelve nada.

Compilación propia. Actualice a 8.5.12, 8.4.27, 8.3.36 o 8.2.35.

Versiones al final de su vida útil. El equipo de PHP ha publicado backports mínimos para 7.4, 8.0 y 8.1 para quienes compilan desde el código fuente o no tienen proveedor LTS. Si tiene proveedor LTS, contacte primero con él.

rpms.remirepo.net: este repositorio mantenido por voluntarios no recibe actualizaciones el día de la publicación. El equipo de PHP anima a pasar a los paquetes de la distribución o a compilar desde el código fuente.

Reinicie PHP-FPM y los demás procesos de trabajo después de actualizar. Un binario nuevo sin reinicio sigue siendo el proceso antiguo.

Si no puede parchear hoy

Las medidas siguientes reducen la exposición a determinadas rutas de ataque. No hacen segura la instalación. Solo la actualización cierra la vulnerabilidad.

Contra CVE-2026-109618:

• Ajuste memory_limit=-1 de forma que la aplicación no pueda sobrescribirlo, por ejemplo php_admin_value en el pool de FPM o en la configuración de Apache. Compruebe que ningún pool, directorio o ajuste de la aplicación restablece el límite.
• Ajuste un post_max_size bajo: 8M para aplicaciones sin subida de archivos, 32M donde la subida sea necesaria. Mantenga upload_max_filesize por debajo de post_max_size.
• Ajuste en el servidor web o el proxy límites al tamaño de petición decodificado, número de campos, número de partes multipart, número de cabeceras y profundidad de anidamiento. Los límites deben cubrir también peticiones sin Content-Length útil.
• Use un límite de memoria de contenedor o cgroup como límite de disponibilidad, preferiblemente con una política que solo mate el proceso de trabajo afectado. No use RLIMIT_AS ni RLIMIT_DATA: pueden activar la ruta de asignación vulnerable.

Contra CVE-2026-109619:

• Ajuste session.upload_progress.enabled=0 y reinicie cada proceso de trabajo. Póngalo en php.ini, en el pool de FPM o en la configuración del servidor para que se aplique antes de analizar la petición. No confíe en ini_set() ni en el .user.ini de FPM.
• En PHP 8.5: ajuste fatal_error_backtraces=0 y reinicie cada proceso de trabajo.
• Elimine los ajustes por petición no válidos u obsoletos que emiten diagnósticos antes de la inicialización. Ocultar los diagnósticos con error_reporting, display_errors o @ no ayuda.
• Corrija los errores fatales y los límites de tiempo que un atacante pueda alcanzar, en callbacks, subidas, importaciones y limpieza.

Por qué no conviene esperar

Tres cosas distinguen este episodio de un parche corriente:

1. No se requiere autenticación. No hay un inicio de sesión tras el que esconderse.
2. El ataque ocurre antes de su código. La lógica de la aplicación, las reglas del WAF y el modelo de permisos no son aquí una barrera.
3. El PoC ya está fuera. Lo que normalmente lleva semanas, ya lo ha hecho otro.

El coste de parchear y reiniciar hoy es insignificante frente al coste de una intrusión. Esto vale especialmente si le afecta NIS2, donde un incidente importante debe notificarse en 24 horas.

Después del parche: tres cosas

1. Verifique en cada nodo. La versión, no solo que el gestor de paquetes diga OK.
2. Lea los registros hacia atrás. Peticiones POST multipart, respuestas 500 inesperadas, procesos de trabajo caídos y tráfico de orígenes desconocidos en los últimos días.
3. Ante la menor sospecha, active el procedimiento de incidentes. Aísle, asegure los registros y evalúe la obligación de notificación.

Fuentes

• CERT-EU, Security Advisory 2026-018: https://cert.europa.eu/publications/security-advisories/2026-018/
• PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35: https://www.php.net/
• GHSA-w8hw-w9fx-j79w: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
• GHSA-6wmf-4rv5-p3rp: https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
• NCSC-NL, lista de productos con PHP incorporado: https://github.com/NCSC-NL/php2shell

---

Este tipo de vulnerabilidad es en sí mismo el argumento a favor de la seguridad continua: parches, verificación y monitorización que funcionan todo el tiempo, no una revisión anual. Lea más sobre qué significa la seguridad continua en la práctica.