php2shell: dos fallos en el núcleo de PHP obligan a parchear a toda prisa y apagan webs públicas en media Europa

En 30 segundos

Dos vulnerabilidades críticas en el propio PHP, no en ninguna aplicación concreta, permiten a un atacante sin credenciales ejecutar código o leer la memoria del servidor web; la única solución completa es actualizar el intérprete y reiniciar todos los procesos.

• Qué ha pasado: PHP corrigió el 21 de octubre CVE-2026-109618 y CVE-2026-109619 (CVSS 9.2 las dos) en las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, un día antes de lo previsto porque los detalles se filtraron.
• A quién afecta: a toda instalación de PHP que atienda peticiones web (Apache con mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed), incluidas WordPress, Drupal, Joomla, Magento o Laravel y el PHP embebido en paneles, appliances y contenedores. Las ramas 8.1 y anteriores no tienen versión oficial.
• Qué hacer ahora: inventariar todo PHP, actualizar al paquete corregido de la distribución, reiniciar los trabajadores o reconstruir las imágenes y, si no se puede hoy, aislar el sistema de Internet. Revisar los registros desde el 17 de octubre.

Qué ha pasado

El 21 de octubre, a las 13:30 UTC, el equipo de seguridad de PHP publicó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 para corregir dos vulnerabilidades críticas del intérprete, conocidas ya como php2shell. Según los avisos de PHP, ambas permiten ejecución remota de código sin autenticación con los privilegios del proceso web, y el caso de mayor riesgo es Apache con mod_php: PHP ha demostrado un exploit en el que una sola petición ejecuta código antes de que se cargue ninguna línea de la aplicación.

CVE-2026-109618 está en la gestión del agotamiento de memoria. Cuando una petición supera el límite de memoria, PHP la aborta con un salto brusco; si eso ocurre con los datos de la petición a medio inicializar, el cierre trata memoria inválida como válida. Una petición multipart manipulada basta para provocarlo sin salirse de los límites aparentes. CVE-2026-109619 es un estado global obsoleto: tras un error fatal, un proceso trabajador conserva punteros a la memoria de la petición anterior ya liberada, y una petición posterior puede usarlos antes de que se reinicialicen. Las rutas confirmadas pasan por el progreso de subida de sesión, activado por defecto aunque la aplicación no use sesiones, y en PHP 8.5 por las trazas de errores fatales.

La ruta de lectura de memoria es la que más preocupa a los analistas. Según Wiz Research, permite extraer memoria viva del trabajador, con contraseñas, tokens, claves de API y certificados de otras peticiones, sin llegar a ejecutar nada. Wiz y la firma Calif demostraron ejecución de código sin autenticar contra las imágenes oficiales más recientes de WordPress, Drupal y Joomla; Calif añade Magento y MediaWiki. El código vulnerable más antiguo data de PHP 5.4.0, de 2012.

Dos equipos llegaron al fallo de forma independiente: Calif, dentro del programa Patch the Planet de OpenAI, y Wiz Research, que informó a PHP el 24 de agosto. Ambos afirman que usaron modelos de IA para encontrar los fallos y adaptar los exploits a distintas versiones y disposiciones de memoria. Según la PHP Foundation, los primeros indicios de CVE-2026-109618 se vieron en 2024 durante una auditoría externa, pero la corrección se quedó parada durante meses, algo que la propia Fundación describe como un fallo estructural de decisión y recursos.

• 2024: una auditoría externa detecta indicios del primer fallo; la corrección no avanza (PHP Foundation).
• 24 de agosto de 2026: Wiz Research informa a PHP; Calif había hecho su primer hallazgo a principios de agosto.
• 17 de octubre: la red de señuelos de Amazon registra un intento de explotación, cuatro días antes de la divulgación.
• 20 de octubre: una publicación anónima en Hacker News filtra que vienen dos fallos críticos; los identificadores circulan con un CVSS 10.0 que PHP califica de incorrecto. PHP adelanta la publicación un día.
• 21 de octubre, 03:02 UTC: Cloudflare activa reglas en su cortafuegos de aplicaciones para todos sus planes.
• 21 de octubre, 13:30 UTC: PHP publica los parches y los avisos; CISA, CERT-EU e INCIBE-CERT emiten alertas el mismo día.
• 21 y 22 de octubre: administraciones de Países Bajos, Alemania, Francia, Bélgica, Finlandia y República Checa apagan portales por precaución.

Lo que está confirmado y lo que no

Los datos disponibles apuntan a intentos de explotación, algunos anteriores a la divulgación, pero a día de hoy ninguna fuente ha confirmado una intrusión con éxito.

• Confirmado: los dos fallos permiten ejecución remota de código sin autenticación; PHP lo validó contra mod_php con la configuración por defecto (avisos de PHP).
• Confirmado: el 17 de octubre hubo un intento contra los señuelos de Amazon desde una red de anonimización comercial; el 21, varios exploits de prueba distintos desde las 02:00 UTC. Amazon recomienda investigar desde el 17 y reconoce no saber si alguno habría funcionado contra un sistema real.
• Confirmado: Cloudflare ve tráfico de ataque y atacantes cambiando las cargas para esquivar sus reglas; no publica cifras ni clientes comprometidos.
• Confirmado: VulnCheck documentó en sus señuelos cinco direcciones origen el 21 de octubre, con un escáner identificado en su agente de usuario, y un intento de plantar una shell web a través del progreso de subida de sesión que falló.
• Confirmado: Arctic Wolf observa intentos que descargan binarios de malware común; watchTowr reproduce ambos fallos y ve intentos contra los dos.
• No confirmado: ninguna intrusión con éxito. Huntress no había visto explotación en su base de clientes a las 20:30 UTC del 21; CISA tampoco la había observado al publicar su alerta.
• No confirmado: ninguno de los dos CVE figura en el catálogo KEV de CISA a 22 de octubre.
• No confirmado: la fiabilidad del código de exploit público. PHP afirma que no identificó exploits funcionales en el momento de la publicación y Tenable advierte de que parte del código que circula puede llevar malware.
• Contradicción: el aviso de INCIBE-CERT habla de ataques anteriores a los parches, pero su tabla marca «No» en explotación para ambos CVE.

Por qué importa

El fallo está en la capa que casi toda la web dinámica comparte. Wiz y Cloudflare recuerdan que PHP sostiene cerca del 70 % de las webs con lenguaje de servidor conocido. VulnCheck detecta PHP en 2,6 millones de direcciones IP expuestas a Internet y considera vulnerables o probablemente vulnerables a casi todas; alrededor del 42 %, más de 1,1 millones, corre ramas sin soporte, de 3.x a 8.1, para las que no hay versión oficial, y solo unas 403.000 están en las ramas 8.2 a 8.5 con parche. Otras estimaciones van de 1,3 a 5,1 millones de servidores según la metodología.

La reacción ha sido inusual: en vez de esperar el parche, decenas de organizaciones apagaron sus webs. Según Reuters, el proveedor federal alemán ITZBund desconectó varias webs en una medida «puramente preventiva», el Ministerio del Interior francés apagó las webs de las prefecturas, el Ministerio de Exteriores belga hizo lo mismo aunque el centro nacional de ciberseguridad belga no registró ataques, el centro estatal finlandés Valtori cerró los servicios web públicos del Gobierno, el Gobierno checo apagó su web y la Fundación Wikimedia desconectó varios sistemas. En Países Bajos, tras el aviso del NCSC, cayeron Overheid.nl, el Puerto de Róterdam, la federación de fútbol KNVB, las webs de los cinco mayores partidos y numerosos hospitales. En Alemania, el hospital Charité retiró toda su presencia web; el BSI recomendó esa medida y CISA la respalda: quien no pueda actualizar, o siga en PHP 8.1 o anterior, debe desconectar sus sistemas PHP hasta parchear.

En España, INCIBE-CERT publicó el 21 de octubre el aviso INCIBE-2026-762 con la importancia máxima de su escala. No consta ninguna desconexión preventiva de webs españolas ni, al cierre de este reportaje, un aviso del CCN-CERT. WordPress, PrestaShop, Drupal, Joomla y Moodle sostienen buena parte de las webs de pymes, ayuntamientos y comercios electrónicos españoles, a menudo en hosting compartido donde es el proveedor quien actualiza PHP.

El precedente pesa: CVE-2024-4577 (php-cgi) y CVE-2019-11043 (PHP-FPM) entraron en el catálogo KEV y se usaron en campañas de ransomware. Y la corrección de ahora cierra las rutas conocidas, no el patrón de fondo: Datadog y la propia PHP advierten de que pueden aparecer variantes, también en ramas que quedarán sin parche.

Cómo saber si está afectado y qué hacer

Han aparecido decenas de comprobadores gratuitos por URL, incluido uno publicado por OpenAI. Casi todos leen solo la versión que el servidor anuncia en sus cabeceras, así que no ven nada si está oculta y marcan como vulnerable un servidor cuya distribución ha retroportado el parche sin cambiar el número de versión, como hace Ubuntu 22.04. OpenAI lo reconoce en el suyo: un resultado «desconocido» no significa seguro. Además, enviar los dominios de la empresa a un servicio de terceros es entregar un inventario de objetivos.

El escáner activo de Assetnote sí comprueba el comportamiento provocando el agotamiento de memoria, pero mueve unos 29 MiB por ruta y puede tumbar trabajadores: solo contra sistemas propios y fuera de horas de servicio. La comprobación fiable es local: consultar la versión del paquete instalado y compararla con la corregida por la distribución (Debian 13: php8.4 8.4.27-1~deb13u1; Debian 12: php8.2 8.2.35-1~deb12u1; Ubuntu: avisos USN-8948-1 y USN-8948-2 del 21 de octubre para todas las LTS, incluidas las de soporte ampliado hasta PHP 5.5) o buscar los dos CVE en el registro de cambios del paquete; verificar que la versión que sirve la web (mod_php, FPM o contenedor) es la misma que la de la línea de comandos; y confirmar que los trabajadores se han reiniciado o la imagen se ha reconstruido. Un paquete nuevo con el proceso antiguo en memoria sigue siendo vulnerable.

• Inventariar todo PHP, también el embebido en paneles de hosting, appliances, contenedores e imágenes de CI; CISA insiste en que su presencia no siempre es evidente. Para flotas grandes, Rapid7 publica un artefacto de inventario para Velociraptor y el NCSC neerlandés mantiene listas de productos que llevan PHP embebido.
• Actualizar a 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o al paquete de la distribución, y reiniciar todos los trabajadores; reconstruir las imágenes de contenedor. Actualizar WordPress o los plugins no sirve: el fallo está en el intérprete.
• Ramas sin soporte: PHP publicó parches mínimos en código fuente para 7.4, 8.0 y 8.1; para 5.x a 7.3 no hay nada. Migrar o aislar.
• Si no se puede parchear hoy: aislar de Internet, o al menos desactivar el progreso de subida de sesión (y las trazas de errores fatales en 8.5), fijar el límite de memoria en ilimitado desde la configuración del administrador, bajar el tamaño máximo de las peticiones y la profundidad de anidamiento, reducir el número de peticiones por trabajador, limitar el tamaño y las partes multipart en el proxy y aplicar perfiles SELinux o AppArmor que impidan al proceso web lanzar shells. PHP avisa de que nada de esto hace seguro el sistema y de que los límites RLIMIT_AS y RLIMIT_DATA pueden provocar justo el fallo vulnerable.
• Después de parchear: la corrección añade un tope duro de memoria que mata el proceso sin ejecutar los manejadores de cierre, así que conviene revisar los límites de memoria y vigilar errores nuevos en los registros. Wiz recomienda además dejar de anunciar la versión de PHP en las cabeceras.
• Si hay compromiso: aislar, conservar los registros, buscar shells web y persistencia, rotar las credenciales del servidor y notificar a INCIBE-CERT (empresas) o CCN-CERT (administraciones); si hay datos personales afectados, el RGPD da 72 horas para avisar a la AEPD.

Qué vigilar ahora

Las señales útiles están por debajo de la aplicación, así que los registros de WordPress o Drupal dirán poco. Según Datadog y Wiz, conviene correlacionar peticiones multipart inusualmente grandes con errores de memoria agotada en «Unknown on line 0» o respuestas HTTP 500 repetidas, cookies PHPSESSID anormalmente largas o malformadas en las respuestas, caídas de trabajadores y, sobre todo, procesos PHP que lanzan shells o herramientas de descarga. La ausencia de estas señales no demuestra que el sistema esté limpio.

• Si CISA añade los CVE al catálogo KEV: confirmaría explotación real y fijaría plazos a las agencias federales de EE. UU.
• La primera intrusión confirmada: hasta ahora solo hay intentos; con exploits públicos y 1,1 millones de servidores sin parche posible, es cuestión de tiempo según watchTowr.
• Variantes nuevas: PHP y Datadog avisan de que la corrección cierra las rutas conocidas, no el patrón de fondo.
• La respuesta de los proveedores de hosting compartido, que son quienes actualizan PHP para la mayoría de pymes y ayuntamientos.
• Los cambios de proceso anunciados por la PHP Foundation tras reconocer que el fallo se conocía desde 2024.

Fuentes

• Aviso de seguridad de PHP GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• Aviso de seguridad de PHP GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching
• INCIBE-CERT: Múltiples vulnerabilidades en PHP (INCIBE-2026-762)
• php2shell.com: página de divulgación de Wiz, Calif y OpenAI
• VulnCheck: PHP2Shell Vulnerabilities
• Cloudflare: protections against php2shell
• Reuters: Websites taken offline over PHP risks
• NCSC-NL: repositorio php2shell (productos con PHP embebido)
• Assetnote: php2shell-scanner

Vulnerabilidades (4)