Vulnerabilidades críticas en PHP (CVE-2026-109618 y CVE-2026-109619): qué ha ocurrido y qué hacer

El 21 de octubre de 2026 el proyecto PHP publicó las correcciones de dos fallos críticos, y ese mismo día CERT-EU difundió el aviso 2026-018. Ambos están valorados con 9,2 y ambos se describen como ejecución remota de código sin autenticación. Si usted gestiona un sitio WordPress, una tienda en línea o cualquier otra aplicación PHP, esto le afecta, y la solución es una actualización, no un ajuste de configuración. Este artículo explica qué se sabe, cómo entra el ataque y qué debe hacer. Situación a 22 de octubre de 2026, según la versión 1.1 del aviso de CERT-EU.

Qué ha ocurrido

PHP anunció una versión de seguridad el 20 de octubre y publicó las correcciones el 21 de octubre a las 13:30 UTC. CERT-EU tituló su aviso «Critical Vulnerabilities in PHP» y enumera dos CVE: CVE-2026-109618 y CVE-2026-109619, cada uno con una puntuación de 9,2. CERT-EU añade que los detalles técnicos ya se debaten en público y que ha empezado a circular un primer código de prueba de concepto. El aviso no confirma ataques en curso, pero indica que esto hace más probable que los atacantes ya estén explotando los fallos. Trátelo como urgente.

Quién está afectado

Las versiones afectadas son todas las de PHP anteriores a la corregida en una rama con soporte, y todas las ramas que han llegado al final de su vida útil.

CERT-EU menciona PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. Según el equipo de PHP, mod_php conlleva el mayor riesgo. También pueden verse afectados los productos que incorporan PHP; CERT-EU remite a una lista del NCSC neerlandés al final de este artículo. Cuenta cualquier instalación que atienda peticiones web, tenga o no un formulario de subida de archivos.

Cómo llega un atacante al primer fallo

Nadie tiene que iniciar sesión. Según CERT-EU, una explotación demostrada prueba que una única petición sin autenticar puede desencadenar el ataque antes de que se ejecute código alguno de la aplicación. Ese es el punto que la mayoría pasa por alto: da igual que su WordPress esté al día, que sus plugins estén parcheados o que su formulario de contacto esté protegido. La petición llega primero al motor de PHP.

El primer fallo, CVE-2026-109618, funciona así:

1. Llega una petición a una dirección que PHP atiende. Sin inicio de sesión, sin cuenta.
2. PHP empieza a leer el cuerpo de la petición. CERT-EU cita como ejemplo el análisis de las subidas de archivos mediante formularios.
3. PHP aplica su memory_limit con longjmp(). Cuando se supera el límite, abandona de golpe lo que estaba haciendo y termina la petición.
4. Si eso ocurre en mitad de la preparación de los datos internos de la petición, esos datos quedan a medio construir.
5. La limpieza posterior trata los datos no válidos como válidos y libera memoria que nunca se inicializó. Esa memoria puede conservar todavía datos de asignaciones anteriores que controlaba el atacante.
6. A partir de ahí, el aviso describe la ejecución remota de código en el servidor.

No describimos deliberadamente cómo dirige el atacante el último paso. Basta con saber que el punto de entrada no es su aplicación, y por eso nada dentro de su aplicación puede detenerlo.

El segundo fallo: un estado que sobrevive a su memoria

CVE-2026-109619 es un mecanismo distinto con el mismo resultado. PHP mantiene un estado interno para cada petición. Tras ciertos errores, como un error fatal, ese estado puede permanecer aunque la memoria que lo sustentaba ya se haya liberado. La siguiente petición atendida por el mismo proceso de trabajo puede entonces usar este estado obsoleto antes de que se restablezca de la manera habitual. El atacante necesita dos peticiones que lleguen al mismo proceso de trabajo; CERT-EU valora el resultado igual que el del primer fallo: ejecución remota de código.

Qué hacer hoy

1. Averigüe qué versión de PHP sirve realmente su sitio. php -v en la línea de comandos muestra la versión de la línea de comandos, que puede diferir de la que usa su servidor web. Compruebe php-fpm -v, su panel de alojamiento o una página que llame a phpinfo(). En un alojamiento compartido, consulte a su proveedor.
2. Actualice a una versión corregida: 8.5.12, 8.4.27, 8.3.36 o 8.2.35. Las distribuciones suelen incorporar las correcciones sin cambiar el número de versión, así que busque los números CVE en el aviso de seguridad de su proveedor. En contenedores, vuelva a construir la imagen a partir de una base actualizada. El equipo de PHP señala que rpms.remirepo.net no tenía actualizaciones el día de la publicación y recomienda los paquetes de la distribución o una compilación desde el código fuente.
3. Reinicie todos los procesos de trabajo de PHP. Una actualización en disco no modifica los procesos que ya están en marcha. Reinicie PHP-FPM o el servidor web y vuelva a comprobar la versión en ejecución.
4. Si hoy no puede actualizar, aísle el servidor de las redes públicas hasta que la corrección esté instalada y verificada. CERT-EU es claro: solo una actualización corrige por completo estos fallos.
5. Si utiliza PHP 8.1 o anterior, pida a su proveedor el backport o pase a una rama con soporte. Estas versiones no reciben actualizaciones regulares.

Medidas paliativas que reducen el riesgo pero no lo eliminan

CERT-EU enumera medidas que dificultan un ataque. Afirma sin ambigüedad que no hacen segura una instalación. Utilícelas mientras prepara la actualización, no en lugar de ella.

• Frente a CVE-2026-109618: establezca memory_limit=-1 de forma que las aplicaciones no puedan modificarlo, por ejemplo con php_admin_value en el pool de FPM, y compruebe que ningún pool, directorio ni aplicación vuelve a fijar un límite finito. Fije un post_max_size bajo (8M sin subidas, 32M con ellas) y mantenga upload_max_filesize por debajo. Limite el tamaño de la petición, el número de campos, las partes multiparte, el número de cabeceras y la profundidad de anidamiento en el servidor web o en el proxy. Utilice un límite de memoria de contenedor o de cgroup como frontera de disponibilidad, pero no RLIMIT_AS ni RLIMIT_DATA, que pueden provocar el fallo de asignación vulnerable.
• Frente a CVE-2026-109619: establezca session.upload_progress.enabled=0 en php.ini, en el pool de FPM o en una configuración del servidor que se aplique antes de analizar la petición (no con ini_set() ni con .user.ini), y reinicie todos los procesos de trabajo. En PHP 8.5 establezca además fatal_error_backtraces=0. Elimine los ajustes por petición no válidos u obsoletos que imprimen diagnósticos antes de la inicialización, y corrija los errores fatales y los tiempos de espera de ejecución que un atacante pueda provocar.

Qué puede y qué no puede hacer SilentShield aquí

Esto no es un problema de bots, y preferimos decirlo antes que dejar que una página de producto insinúe lo contrario. El ataque alcanza el motor de PHP antes de que la petición llegue a nada nuestro, o a cualquier CAPTCHA, plugin o regla de cortafuegos dentro de su aplicación. Una protección contra bots en un formulario no lo detiene, y nadie debería decirle que sí. La única solución completa es la actualización de PHP.

La API y el panel de SilentShield no están escritos en PHP. El plugin de WordPress y el SDK de PHP se ejecutan dentro de su propio PHP, de modo que para ellos la actualización debe hacerse en su servidor. Una vez actualizado, la protección habitual contra bots y spam en formularios es tan útil como antes; simplemente nunca fue la respuesta a esto.

Fuentes

• CERT-EU Security Advisory 2026-018: Critical Vulnerabilities in PHP
• Anuncio de PHP del 20 de octubre de 2026
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• NCSC-NL php2shell: productos que incorporan PHP