PHP: vulnerabilidad crítica CVE-2026-109618 ya explotada

Qué es y a quién afectaEl PHP Group mantiene PHP, el lenguaje de servidor que sostiene buena parte de las webs y aplicaciones que se ejecutan hoy en E...

Qué es y a quién afecta

El PHP Group mantiene PHP, el lenguaje de servidor que sostiene buena parte de las webs y aplicaciones que se ejecutan hoy en España: desde un WordPress de una tienda en Lleida hasta un PrestaShop, un Joomla o un desarrollo propio. La vulnerabilidad CVE-2026-109618, publicada en la NVD del NIST el 21 de octubre de 2026, es un fallo de corrupción de memoria que permite a un atacante no autenticado ejecutar código en remoto (RCE).

Según la descripción técnica, PHP utiliza longjmp() para salir de los errores de memoria agotada (OOM). En algunos contextos ese escenario no se gestiona bien y la memoria de la petición queda en un estado no inicializado antes de una reserva; la limpieza posterior puede leer o ramificar sobre esa memoria y, con determinadas estrategias de OOM, desembocar en ejecución remota de código. La gravedad es CVSS 4.0 de 9.2, CRITICAL, y el fallo se clasifica con los identificadores CWE-416, CWE-755, CWE-824 y CWE-1325.

Las versiones afectadas, según la NVD, son:

PHP desde 7.3.0 (incluida) hasta 8.2.35 (sin incluir).
PHP desde 8.3.0 (incluida) hasta 8.3.36 (sin incluir).
PHP desde 8.4.0 (incluida) hasta 8.4.27 (sin incluir).
PHP desde 8.5.0 (incluida) hasta 8.5.12 (sin incluir).

El aviso también alcanza a productos de terceros que incorporan PHP, como el firmware ruggedcom_ape1808_firmware de Siemens y distintas versiones de pan-os de Palo Alto Networks, entre otras configuraciones. Si tu empresa tiene servidores propios o un equipo de IT pequeño, conviene revisar tanto la web como los appliances de red que puedan llevar PHP embebido.

Por qué es urgente

No estamos ante un fallo teórico. CISA añadió CVE-2026-109618 a su catálogo KEV (Known Exploited Vulnerabilities) el 26 de octubre de 2026, lo que significa que ya se explota en ataques reales. A las agencias federales de EE. UU. les dio un plazo de corrección hasta el 29 de octubre de 2026, apenas tres días después. Esa premura da la medida de la exposición: un fallo de ejecución remota sin autenticación en un componente que está en primera línea de internet permite a un atacante tomar el control del servidor, leer datos, mover ficheros o plantar puertas traseras.

En el material consultado no consta uso conocido en campañas de ransomware, pero eso no rebaja la prioridad: la ejecución remota de código es el tipo de acceso inicial que muchas campañas aprovechan después. Para una pyme con comercio electrónico, la ventana entre la publicación del fallo y su explotación se mide en días, no en meses.

Qué hacer hoy

Comprueba si usas PHP y en qué versión. Revisa la versión del intérprete en cada servidor, contenedor o hosting. Si estás en cualquier versión de las ramas 7.3, 8.2, 8.3, 8.4 u 8.5 dentro de los rangos indicados, estás afectado.
Aplica la actualización o mitigación del aviso del fabricante. El PHP Group publicó un aviso de seguridad con la mitigación correspondiente; sigue exactamente lo que indique ese aviso para tu rama. No improvises versiones ni parches de terceros.
Revisa indicios de intrusión. Busca ficheros o procesos extraños, peticiones anómalas en los registros, cuentas o tareas programadas que no reconozcas y cambios recientes en el código de la web.
Reduce lo expuesto a internet. Cierra paneles de administración y servicios que no necesiten ser públicos, limita el acceso por IP o VPN y mantén al día el resto de la pila (sistema, servidor web, gestores de contenido).

Y no olvides el resto de la cadena: un PHP actualizado no sirve de mucho si el WordPress, el PrestaShop o el Joomla que corre encima arrastran plugins sin parchear. La actualización del intérprete y el mantenimiento del CMS son dos capas del mismo trabajo.

Cómo puede ayudar un equipo de ciberseguridad como el de ALMC

En ALMC trabajamos con pymes, comercios online y empresas de Cataluña que tienen webs en WordPress, PrestaShop o Joomla, servidores propios o un equipo de IT con pocas manos. Ante un fallo como este, lo primero es saber con certeza qué versión de PHP corre en cada entorno, algo que a menudo se pierde entre hostings, contenedores y entornos de staging. A partir de ahí, planteamos auditorías de seguridad y pentesting para detectar vulnerabilidades antes de que las exploten, hardening de servidores para reducir la superficie de ataque, monitorización y respuesta a incidentes para detectar actividad sospechosa a tiempo, y mantenimiento y actualización de los gestores de contenido. Si la web ya ha sido comprometida, nos encargamos también de su reparación. La idea es sencilla: cerrar las puertas antes de que alguien las empuje, y tener un plan claro si un día lo hacen.

Relacionado

¿Está tu empresa expuesta a fallos como este?

En ALMC revisamos qué versiones tienes publicadas, aplicamos los parches y endurecemos tus servidores y tu web. Descubre nuestros servicios de ciberseguridad o contáctanos para una revisión.

Resultados sin salir de la página.