PHP en la diana: dos vulnerabilidades críticas que tu pipeline debería haber detectado ayer

El 21 de octubre de 2026, INCIBE-CERT publicó un aviso de importancia crítica (nivel 5) por múltiples vulnerabilidades en el núcleo de PHP que permiten a un atacante remoto sin autenticar ejecutar código con los privilegios del proceso web. Ambas tienen una puntuación CVSS v4.0 de 9,2 y, lo que es peor: ya se han comunicado ataques activos contra servidores PHP antes incluso de que se publicaran las actualizaciones.

¿Qué ha pasado exactamente?

PHP ha corregido dos vulnerabilidades críticas:

CVE-2026-109618 — Ejecución remota de código (RCE) por corrupción de memoria durante un agotamiento de memoria (OOM). Un vector destacado son las peticiones multipart por POST: un número elevado de cabeceras en las partes, controles de archivo vacíos o nombres de campos anidados pueden disparar el uso de memoria aunque la petición parezca respetar los límites. Se ha validado un exploit sin autenticación contra Apache mod_php, antes de que se ejecute código de tu aplicación.
CVE-2026-109619 — RCE por uso de estado global obsoleto: parte del estado interno de una petición puede sobrevivir en un proceso worker tras liberarse, y una petición posterior sobre el mismo worker puede provocar un use-after-free con posible divulgación de memoria y ejecución de código.

¿Estás afectado?

Las versiones corregidas de las ramas mantenidas son:

Rama	Versión corregida
PHP 8.5.x	8.5.12
PHP 8.4.x	8.4.27
PHP 8.3.x	8.3.36
PHP 8.2.x	8.2.35

PHP 8.1 y anteriores ya no reciben mantenimiento regular; para 7.4, 8.0 y 8.1 existen parches retroportados de código fuente, o actualizaciones del proveedor de tu distribución.

PHP considera en riesgo todas las instalaciones que procesan peticiones web — PHP-FPM, Apache mod_php, php-cgi, Frankenphp y LiteSpeed — con un riesgo especialmente alto en Apache mod_php.

El problema real: tu stack cambió y nadie se enteró

Aquí está la parte incómoda. Cuando sale un aviso así, la pregunta no es solo "¿qué versión de PHP tengo en producción?". Es:

¿Qué versión de PHP tiene cada uno de mis despliegues, hoy?
¿Alguien hizo un deploy esta semana que subió la imagen de Docker base a una rama vulnerable?
¿Ese servidor "temporal" de hace dos años sigue corriendo PHP 8.1 en mod_php?

En la mayoría de equipos, contestar esas preguntas exige abrir una hoja de cálculo desactualizada y rezar.

En AiSecBox no: monitorizamos tus proyectos en tiempo real y realizamos comprobaciones periódicas del stack tecnológico de cada proyecto. Eso significa que detectamos cuándo un despliegue introduce una versión vulnerable — de PHP, de tu framework, de tus dependencias — en el momento en que ocurre, no cuando ya es noticia. Con un aviso como el de hoy, saber al instante qué despliegues exponen una rama afectada (y si usan mod_php, el escenario más explotable) es la diferencia entre parchear en una hora o enterarte por el postmortem.

Y vamos un paso más allá: estamos trabajando en herramientas para mantener el SBOM (Software Bill of Materials) de tus contenedores — el inventario de todo lo que viaja dentro de cada imagen: sistema operativo, runtime, librerías del sistema y paquetes de tu aplicación. Con ese inventario cruzado contra las fuentes de vulnerabilidades, el panel de control podrá decirte de un vistazo qué proyectos se ven afectados por cualquier aviso, no solo por el de PHP de hoy: sin grep en Dockerfiles, sin abrir imágenes a mano y sin esperar a que alguien pregunte. Un CVE nuevo deja de ser una búsqueda contrarreloj y pasa a ser una lista concreta de proyectos, imágenes y versiones que tocar.

Qué hacer ahora mismo

Actualiza PHP de inmediato a la versión corregida de tu rama: 8.5.12, 8.4.27, 8.3.36 o 8.2.35. Si usas paquetes de una distribución o soporte LTS, verifica que incluyan las correcciones.
Si estás en 8.1, 8.0 o 7.4 y tu proveedor no tiene parche, migra a una rama mantenida.
Si no puedes actualizar todavía, INCIBE recoge mitigaciones temporales: memory_limit=-1 aplicado administrativamente (CVE-2026-109618), desactivar session.upload_progress.enabled y fatal_error_backtraces (CVE-2026-109619), mantener post_max_size bajo (8–32 MB), limitar tamaño de peticiones decodificadas y bloquear multipart si no las necesitas. Ojo: ocultar avisos con error_reporting, display_errors o @ no mitiga nada.
Si un sistema expuesto no puede actualizarse, aíslalo de las redes públicas hasta parchearlo.

La mitigación reduce exposición; la actualización es la única solución completa.

📚 Fuente

Aviso original de INCIBE-CERT (Actualización 21/10/2026, identificador INCIBE-2026-762, importancia 5 – Crítica): https://www.incibe.es/incibe-cert/alerta-temprana/avisos/multiples-vulnerabilidades-en-php

📌 ¿Quieres saber qué versiones de tu stack están expuestas con este y futuros avisos, sin hojas de cálculo? Prueba AiSecBox y automatiza la seguridad de tu código, impulsada por IA.

¿Qué ha pasado exactamente?

PHP ha corregido dos vulnerabilidades críticas:

CVE-2026-109618 — Ejecución remota de código (RCE) por corrupción de memoria durante un agotamiento de memoria (OOM). Un vector destacado son las peticiones multipart por POST: un número elevado de cabeceras en las partes, controles de archivo vacíos o nombres de campos anidados pueden disparar el uso de memoria aunque la petición parezca respetar los límites. Se ha validado un exploit sin autenticación contra Apache mod_php, antes de que se ejecute código de tu aplicación.
CVE-2026-109619 — RCE por uso de estado global obsoleto: parte del estado interno de una petición puede sobrevivir en un proceso worker tras liberarse, y una petición posterior sobre el mismo worker puede provocar un use-after-free con posible divulgación de memoria y ejecución de código.

¿Estás afectado?

Las versiones corregidas de las ramas mantenidas son:

Rama	Versión corregida
PHP 8.5.x	8.5.12
PHP 8.4.x	8.4.27
PHP 8.3.x	8.3.36
PHP 8.2.x	8.2.35

PHP 8.1 y anteriores ya no reciben mantenimiento regular; para 7.4, 8.0 y 8.1 existen parches retroportados de código fuente, o actualizaciones del proveedor de tu distribución.

El problema real: tu stack cambió y nadie se enteró

Aquí está la parte incómoda. Cuando sale un aviso así, la pregunta no es solo "¿qué versión de PHP tengo en producción?". Es:

¿Qué versión de PHP tiene cada uno de mis despliegues, hoy?
¿Alguien hizo un deploy esta semana que subió la imagen de Docker base a una rama vulnerable?
¿Ese servidor "temporal" de hace dos años sigue corriendo PHP 8.1 en mod_php?

En la mayoría de equipos, contestar esas preguntas exige abrir una hoja de cálculo desactualizada y rezar.

Qué hacer ahora mismo

Actualiza PHP de inmediato a la versión corregida de tu rama: 8.5.12, 8.4.27, 8.3.36 o 8.2.35. Si usas paquetes de una distribución o soporte LTS, verifica que incluyan las correcciones.
Si estás en 8.1, 8.0 o 7.4 y tu proveedor no tiene parche, migra a una rama mantenida.
Si no puedes actualizar todavía, INCIBE recoge mitigaciones temporales: memory_limit=-1 aplicado administrativamente (CVE-2026-109618), desactivar session.upload_progress.enabled y fatal_error_backtraces (CVE-2026-109619), mantener post_max_size bajo (8–32 MB), limitar tamaño de peticiones decodificadas y bloquear multipart si no las necesitas. Ojo: ocultar avisos con error_reporting, display_errors o @ no mitiga nada.
Si un sistema expuesto no puede actualizarse, aíslalo de las redes públicas hasta parchearlo.

La mitigación reduce exposición; la actualización es la única solución completa.

📚 Fuente

📌 ¿Quieres saber qué versiones de tu stack están expuestas con este y futuros avisos, sin hojas de cálculo? Prueba AiSecBox y automatiza la seguridad de tu código, impulsada por IA.