CVE-2026-109618 (PHP2Shell): Guía para Directivos y CTOs

La CVE-2026-109618 y su hermana, la CVE-2026-109619, forman el par apodado PHP2Shell: dos fallos en el núcleo de PHP que permiten ejecutar código en el servidor sin necesidad de autenticación. Si su empresa tiene un sitio web, tienda, Moodle o webhook en PHP, la pregunta es de negocio: ¿cuánto de su facturación depende de un intérprete que se volvió vulnerable la semana pasada? Esta guía traduce el incidente para quienes deciden.

TL;DR

• La CVE-2026-109618 (corrupción por falta de memoria) y la CVE-2026-109619 (estado global obsoleto entre peticiones) tienen una puntuación CVSS 4.0 de 9,2 y no requieren autenticación.
• Los identificadores se filtraron el 20/10/2026; la corrección se publicó el 21/10/2026 en las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
• PHP 7.4 a 8.1 solo tiene backports mínimos de código fuente. PHP 5.4 a 7.3 no tiene ninguna corrección.
• Los ajustes de configuración (memory_limit=-1, session.upload_progress.enabled=0) reducen el riesgo, pero no lo resuelven. Solo la actualización lo resuelve.
• El 23/10 se publicó una alerta adicional, la CVE-2026-115560, de vector improbable.

Qué es la CVE-2026-109618 y por qué se ha convertido en prioridad para la dirección

En lenguaje de gestión: la CVE-2026-109618 es una puerta trasera en el motor que ejecuta su sistema, y no en su sistema. No importa si el ERP es impecable o si WordPress y Moodle están actualizados. El fallo reside en el intérprete de PHP, la capa subyacente a todo.

Según el aviso oficial de PHP, la CVE-2026-109618 ocurre cuando el manejo de la falta de memoria (out-of-memory, u OOM) interrumpe PHP mientras los datos internos de la petición todavía están incompletos. Durante la limpieza, PHP trata esos datos residuales como si fueran válidos. Un atacante que provoque esto intencionadamente puede corromper la memoria y, a partir de ahí, ejecutar comandos.

La CVE-2026-109619 es otro camino hacia el mismo destino: un estado interno de la petición sobrevive después de que su memoria ha sido liberada (use-after-free), y la siguiente petición en el mismo proceso usa ese remanente. PHP también confirma una fuga de memoria.

Por qué el 9,2 importa más que el número

Las puntuaciones altas aparecen cada mes. Lo que sitúa a PHP2Shell en otro nivel son tres factores:

• Sin autenticación: basta una petición HTTP, sin contraseña ni sesión.
• Antes de que se ejecute su código: en Apache con mod_php, PHP afirma que existe un exploit demostrado en el que la petición desencadena el ataque antes de cualquier línea de la aplicación.
• Base instalada gigantesca: Tenable cita a W3Techs: PHP se ejecuta en el 69,3% de los sitios web cuya tecnología de servidor es conocida.

Para ser precisos: los identificadores que se filtraron tenían una puntuación de 10,0, luego corregida a 9,2 por la PHP Foundation, según Tenable. Un proveedor que todavía habla de "puntuación de 10" está consultando fuentes antiguas.

Cronología: de la filtración a la alerta adicional del 23/10

Las fechas de la CVE-2026-109618 definen desde cuándo su empresa está expuesta y lo que su proveedor debería haber hecho cada día.

Fecha	Qué sucedió	Fuente
17/10/2026	Amazon Threat Intelligence registra un intento de explotación en su red de honeypots MadPot, cuatro días antes de la divulgación	Tenable
20/10/2026	Los identificadores se filtran; PHP adelanta la publicación del 22 al 21/10 y emite un aviso previo	Tenable, watchTowr, Huntress
21/10/2026	Se publican las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35; CISA emite una alerta; watchTowr observa explotación en sus sensores	php.net, CISA, watchTowr
23/10/2026	Unit 42 actualiza el boletín; PHP publica una alerta informativa sobre la CVE-2026-115560	Unit 42, php.net

Unit 42, de Palo Alto Networks, informó que Cortex Xpanse identificó más de 22,6 millones de instancias expuestas potencialmente vulnerables. Es una estimación de la superficie expuesta, no de servidores comprometidos. Otras mediciones citadas por Tenable se situaron entre 1,3 y 1,9 millones de hosts. El orden de magnitud cambia; la conclusión, no.

Sobre ataques reales, las fuentes difieren. Huntress no había visto explotación en sus socios hasta el 20/10. watchTowr reporta explotación en sus honeypots desde el 21/10. Hasta el 23/10, los fallos aún no estaban en el catálogo KEV de CISA. Para quienes deciden: el exploit existe, ha sido demostrado y ya hay gente probándolo. Esperar un "ataque masivo confirmado" es esperar demasiado tarde.

Quién está afectado por la CVE-2026-109618 en PHP-FPM, mod_php, php-cgi, FrankenPHP y LiteSpeed

PHP fue directo: toda instalación que atiende peticiones web está en riesgo. La lista oficial cita cinco formas de ejecutar PHP, y saber cuál usa su empresa cambia la urgencia y el tipo de trabajo.

Mapa de riesgo por forma de ejecución

Forma de ejecución	Dónde suele aparecer	Lectura de riesgo
Apache + mod_php	Servidores antiguos, cPanel heredado, VPS montada "a mano"	Mayor riesgo según PHP: exploit demostrado antes del código de la aplicación
PHP-FPM	Nginx, hosting gestionado moderno, Moodle y Laravel en producción	Afectado; PHP confirmó la ejecución de comandos a través del procesamiento de subidas
php-cgi	Entornos heredados, algunos paneles Windows	Tratar como expuesto
FrankenPHP	Stacks modernas, workers persistentes, contenedores	Afectado; workers de larga duración exigen reinicio tras el parche
LiteSpeed (LSAPI)	Hostings compartidos y paneles comerciales	Afectado; depende de que el proveedor libere el paquete

Si no sabe cuál es su línea en esta tabla, este es el primer hallazgo del incidente. En más de 15 años operando servidores PHP, Moodle e integraciones con la API oficial de WhatsApp, veo el inventario como el eslabón más débil, no el parche.

Lo que casi nadie recuerda verificar

Datadog alerta que el PHP de línea de comandos y el que atiende a la web pueden tener versiones diferentes. El equipo ejecuta php -v, ve una versión nueva y concluye que todo está bien, mientras que el FPM sigue en el binario antiguo.

También se incluye el equipo que ni siquiera sabe que ejecuta PHP: los fabricantes de appliances de red publicaron sus propios avisos sobre PHP2Shell. El panel del firewall, el NAS y el sistema de cámaras entran en el inventario.

Versiones corregidas de la CVE-2026-109618 y el problema real: el PHP antiguo

La decisión más costosa reside aquí. Hay una corrección oficial para cuatro ramas:

Rama	Versión corregida	Situación
8.5	8.5.12	Soportado
8.4	8.4.27	Soportado
8.3	8.3.36	Soportado
8.2	8.2.35	Solo seguridad; fin de vida el 31/12/2026
7.4, 8.0, 8.1	Sin lanzamiento oficial	Solo backport mínimo de código fuente o paquete de distribución/proveedor LTS
5.4 a 7.3	Ninguna	Sin corrección del proyecto PHP

Fíjese en el 8.2: quien actualiza a 8.2.35 resuelve la CVE-2026-109618 hoy, pero la rama finaliza el 31/12/2026, según php.net. Es correcto como medida de emergencia, no como plan.

El dilema de PHP 7.x

Un sistema anclado en PHP 7.x es común: un ERP a medida de hace diez años, Moodle nunca migrado, una tienda con un plugin que "se rompe si se toca". El proyecto PHP publicó backports mínimos para 7.4, 8.0 y 8.1 en GitHub, para quienes compilan desde el código fuente. Las distribuciones Linux y los proveedores de soporte extendido también liberaron paquetes corregidos, a veces sin cambiar el número de versión, lo que confunde a escáneres y auditorías.

En la práctica, el directivo tiene tres caminos para PHP antiguo:

1. Paquete corregido de la distribución, cuando existe: el más rápido y seguro.
2. Compilar con el backport: exige a alguien que sepa compilar y mantener PHP. Es una nueva deuda técnica.
3. Migrar de versión: el camino correcto, que rara vez cabe en una semana.

Para PHP 5.4 a 7.3, no hay camino 1 ni 2. Solo queda aislar el sistema de internet o migrar.

Mitigaciones: lo que reduce el riesgo y lo que es una falsa sensación de seguridad

PHP publicó ajustes de configuración contra la CVE-2026-109618 y la CVE-2026-109619 para quienes no pueden actualizar inmediatamente, e hizo hincapié en que no sustituyen la actualización. Úselos como puente, nunca como destino.

Para la CVE-2026-109618

• memory_limit = -1 de modo que la aplicación no pueda sobrescribir. En PHP-FPM, esto se hace con php_admin_value[memory_limit] = -1 en el pool.
• post_max_size bajo: 8M sin subida, 32M con subida, con upload_max_filesize por debajo de él.
• Límites de tamaño, cantidad de campos, partes y profundidad en el servidor web o proxy.
• Límite de memoria por contenedor o cgroup que detenga solo el proceso afectado.

Para la CVE-2026-109619

• session.upload_progress.enabled = 0 en el php.ini o en el pool de FPM, y reiniciar todos los workers. PHP advierte: no confíe en ini_set() ni en .user.ini.
• En PHP 8.5, también fatal_error_backtraces = 0.
• Ocultar errores con @ no ayuda.

Errores que pueden tumbar servidores

memory_limit=-1 sin límite de contenedor cambia un riesgo por otro: un script mal escrito consume toda la RAM y tumba la base de datos. Y PHP desaconseja RLIMIT_AS y RLIMIT_DATA, que pueden provocar precisamente el fallo de asignación que utiliza el exploit.

Un WAF ayuda, pero tiene límites. Cloudflare publicó reglas para los vectores conocidos y las calificó de paliativo, y solo protegen el tráfico que pasa por ella: la IP directa del servidor sigue abierta si el firewall no la cierra. Por último, desactivar session.upload_progress rompe las barras de progreso de subida. Avise al equipo de producto antes.

CVE-2026-115560: la alerta del 23/10 y por qué no cambia la prioridad

Dos días después del parche, PHP publicó un aviso informativo sobre la CVE-2026-115560, otro fallo relacionado con la sesión y el progreso de subida, que afecta incluso a las versiones ya corregidas. La buena noticia: el vector es improbable. Según php.net, solo se aplica si la aplicación configura session.serialize_handler como php_binary o php_serialize, cambia a php en tiempo de ejecución con ini_set() antes de session_start() y mantiene el progreso de subida activado.

La corrección vendrá en la próxima versión regular. Hasta entonces, la misma mitigación es válida: session.upload_progress.enabled=0. The Hacker News cubrió la alerta.

La CVE-2026-115560 no es motivo para posponer el parche de la CVE-2026-109618, y quien ya desactivó el progreso de subida como mitigación obtuvo protección para ambas.

Decisiones de negocio: qué preguntar a su equipo o proveedor esta semana

El papel del directivo no es compilar PHP, es hacer las preguntas correctas y exigir plazos. Esta es la lista que yo llevaría a la reunión.

Las siete preguntas

1. Inventario: ¿Qué servidores, contenedores y appliances ejecutan PHP? ¿Incluye el sitio web institucional que la agencia hizo en 2019?
2. Versión real de la web: ¿Qué versión de PHP atiende las peticiones, no la del terminal?
3. Estado del parche: ¿Ya estamos en 8.5.12, 8.4.27, 8.3.36 o 8.2.35? ¿Los workers han sido reiniciados?
4. Imágenes Docker: ¿Las imágenes han sido reconstruidas y reimplantadas, o el contenedor antiguo sigue en el aire?
5. Legado: ¿Qué está en PHP 8.1 o inferior, y cuál de los tres caminos vamos a seguir para cada sistema?
6. Indicios: ¿Alguien ha revisado los logs de error con "Unknown on line 0", fallos de segmentación en Apache y shells disparados por el proceso web desde el 17/10?
7. Responsable y plazo: ¿Quién firma cada elemento y hasta cuándo?

Cuándo actualizar ya y cuándo no salir actualizando

Actualice el mismo día todo lo que esté en 8.2 a 8.5 y expuesto a internet: es una versión de corrección, con bajo riesgo de regresión.

No salte de PHP 7.4 a 8.4 un viernes por la noche por pánico: un cambio de rama rompe plugins y código antiguo. Aísle primero (VPN o lista de IPs), aplique el paquete corregido del proveedor si existe y planifique la migración con pruebas.

No confíe en "mi hosting ya corrigió la CVE-2026-109618" sin pruebas. Pida la versión y la fecha del reinicio por escrito.

Dónde puede estar escondido el incidente

Los webhooks son un punto ciego clásico: el endpoint que recibe eventos de la API oficial de WhatsApp o de la pasarela de pago es público por definición. Si se ejecuta en PHP, va a la parte superior de la lista.

La homologación también: muchas empresas protegen la producción y olvidan el staging con la misma base copiada y PHP antiguo. Para cerrar las puertas, la checklist de hardening de servidor Linux cubre lo que viene después del parche.

Costes: cuánto cuesta actuar ahora versus después

No voy a inventar un valor medio de incidente; varía demasiado por tamaño y sector. Pero se pueden comparar los tipos de coste de la CVE-2026-109618, que es lo que importa para priorizar.

Actuar ahora cuesta horas de equipo técnico: inventario, actualización, reinicio, revisión de logs. En 8.2+, suele ser trabajo de días. En 7.x, se suma el aislamiento y el proyecto de migración.

Actuar después cuesta lo que cuesta cualquier ejecución remota de código: servidor comprometido con los privilegios del proceso web, base de datos y credenciales expuestas, posible ransomware y, si hay datos personales, obligaciones por la RGPD. El post sobre plan de respuesta a fugas de datos muestra quién avisa a quién y en qué plazo.

También hay un coste oculto: deuda técnica de versión. Una empresa en PHP 8.3 resuelve la CVE-2026-109618 en una ventana de mantenimiento. Una empresa en PHP 7.2 descubre que no tiene parche y necesita un proyecto. Para pequeñas empresas sin equipo de seguridad, la priorización sigue la lógica de ransomware en pequeñas empresas: qué cerrar primero.

Si su equipo no tiene capacidad para separar lo urgente de lo importante, es ahí donde una consultoría técnica independiente se amortiza: alguien externo mapea, prioriza y entrega un plan de ataque.

Cómo Agathas Web resuelve esto

Agathas Web opera servidores PHP desde 2008: hosting gestionado, Moodle en producción, sistemas en PHP y Laravel y la API oficial de WhatsApp. A través de la consultoría de Agathas Web, el trabajo comienza por lo que los boletines no hacen: mirar su entorno.

Qué está incluido

• Inventario de exposición: servidores, contenedores, homologación, webhooks y appliances con PHP, y la versión real que atiende a la web.
• Matriz de decisión por sistema: actualizar ya, aplicar paquete corregido del proveedor, compilar backport, aislar o migrar, con coste y riesgo de cada opción.
• Mitigación segura mientras el parche no sale, sin tumbar el servidor por falta de RAM.
• Búsqueda de indicios en los logs y procesos desde el 17/10.
• Plan de migración para lo que está en PHP 8.2 o inferior, antes del fin de vida del 31/12/2026.

Cómo funciona en la práctica

Quien lo dirige es el socio/CTO, no un júnior. Para la CVE-2026-109618 el alcance es corto: diagnóstico, prioridades y ejecución de lo urgente. Si tiene sentido ir más allá, se convierte en un diagnóstico técnico completo de 4 a 6 semanas, con informe ejecutivo y plan de acción, o liderazgo técnico fraccionado (CTO bajo demanda).

Cómo contratar

A través de la página de consultoría en tecnología y seguridad, cuente el escenario (cuántos sistemas, qué hosting, qué PHP) y le responderemos con un camino y alcance. La recomendación viene del diagnóstico, no de un paquete predefinido.

Conclusión: la CVE-2026-109618 es una prueba de gobernanza, no solo de parcheo

La CVE-2026-109618 será corregida en la mayoría de los servidores en las próximas semanas. Queda la pregunta: ¿cuánto tiempo tardó su empresa en saber dónde se ejecuta PHP, en qué versión y quién es responsable de ello?

Resumen para llevar a la dirección:

• Actualice hoy todo lo que esté en 8.2 a 8.5 y reinicie los workers.
• Trate las mitigaciones como un puente, nunca como una solución.
• Para PHP 8.1 o anterior, aísle primero y decida el camino sistema por sistema.
• Planifique salir del 8.2 antes del 31/12/2026.
• Revise los logs desde el 17/10 en busca de indicios.

Si desea una mirada externa para realizar este inventario y establecer el plan de ataque, la consultoría de Agathas Web atiende exactamente este escenario.