Vulnerabilidad crítica en PHP (php2shell): qué ha pasado y cómo actuar

El 21 de octubre de 2026 el equipo de seguridad de PHP publicó un parche para dos vulnerabilidades críticas que permiten ejecutar código en el servidor sin autenticación. Se identifican como CVE-2026-109618 y CVE-2026-109619, tienen una puntuación de 9,2 sobre 10 en CVSS v4.0 y la comunidad de seguridad ya las conoce como php2shell.

PHP está detrás de buena parte de la web. Según W3Techs, es el lenguaje de servidor del 69,3 % de los sitios cuyo lenguaje se conoce, y ahí entran WordPress, Drupal, Joomla o Magento, además de muchas aplicaciones internas y paneles de gestión.

Te contamos qué ha pasado, a quién afecta, qué recomiendan las autoridades de ciberseguridad y qué hacer hoy mismo en tus servidores.

Qué ha pasado

La publicación del parche estaba prevista para el 22 de octubre, pero los identificadores de las vulnerabilidades se filtraron el día 20. Ese mismo día el equipo de PHP adelantó el aviso y publicó las versiones corregidas el 21 de octubre a las 14:00 UTC.

Los dos fallos están en el núcleo de PHP, antes incluso de que se ejecute el código de la aplicación.

• CVE-2026-109618. Cuando PHP se queda sin memoria mientras prepara los datos de una petición, esos datos quedan a medio inicializar y la limpieza posterior los trata como válidos.
• CVE-2026-109619. Parte del estado interno de una petición sobrevive después de liberar su memoria, y una petición posterior atendida por el mismo proceso puede usarlo antes de que se reinicie.

En los dos casos, una petición manipulada puede acabar ejecutando código con los permisos del servidor web. Investigadores de Wiz han documentado además una vía de fuga de memoria que podría exponer contraseñas, tokens, claves de API o certificados.

Ataques e intentos de explotación

Amazon Threat Intelligence detectó un primer intento de explotación en su red de señuelos el 17 de octubre, cuatro días antes del aviso público, y afirma que la vulnerabilidad ya se explota de forma amplia. Cloudflare y watchTowr también han informado de intentos de ataque.

Por eso Amazon recomienda que, si investigas un posible incidente, revises la actividad desde el 17 de octubre y no solo desde la fecha del parche. Conviene tener en cuenta también que circula código de explotación sin verificar, que puede contener malware.

Qué dicen las autoridades de ciberseguridad

Los organismos públicos de España, Europa y Estados Unidos reaccionaron el mismo 21 de octubre, y todos coinciden en lo esencial, que es actualizar cuanto antes y empezar por los sistemas expuestos a internet.

• INCIBE-CERT: El equipo de respuesta del Instituto Nacional de Ciberseguridad publicó un aviso de gravedad crítica y lo actualizó esa misma tarde con las versiones corregidas.
• Unión Europea: La Comisión Europea, ENISA, CERT-EU, el centro de cibercrimen de Europol y la red de CSIRT nacionales firmaron una declaración conjunta. Piden identificar las aplicaciones con PHP, coordinarse con los proveedores de alojamiento y servicios, aplicar el parche dando prioridad a lo que está expuesto a internet y, si no se puede parchear de inmediato, plantearse aislar esas aplicaciones de las redes públicas.
• CERT-EU: En su aviso de seguridad recomienda actualizar todas las instalaciones afectadas lo antes posible y recuerda que las mitigaciones no dejan una instalación segura. Señala además que ya circulan pruebas de concepto y que eso aumenta la probabilidad de que haya atacantes explotando el fallo.
• CISA: La agencia de ciberseguridad de Estados Unidos pide parchear de inmediato y va un paso más allá. Las organizaciones que no puedan actualizar enseguida, o que sigan en PHP 8.1 o anterior, deberían desconectar esos sistemas hasta poder corregirlos. En el momento de su alerta, CISA no había observado explotación, pero insiste en que el riesgo es alto si no se parchea.

A quién afecta

PHP indica que cualquier instalación que atienda peticiones web está en riesgo, sea con PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP o LiteSpeed. El riesgo es mayor con mod_php, donde ya se ha demostrado un ataque que no necesita credenciales.

Estas son las versiones con parche oficial:

Las ramas 8.1, 8.0 y 7.4 ya no tienen soporte y no recibirán una versión oficial. El equipo de PHP ha publicado unos parches mínimos de código fuente para ellas, pero la salida recomendada es migrar. Las versiones anteriores a 7.4 tampoco tienen corrección.

El alcance llega a cualquier software que incluya PHP, desde gestores de contenidos y tiendas online hasta paneles como cPanel o Plesk y aplicaciones de terceros que lo llevan integrado.

Cómo actuar hoy

Si tienes cualquier proyecto, servidor, contenedor o servicio con PHP, estos son los pasos que recomendamos.

1. Haz inventario. Localiza todo lo que ejecuta PHP, incluidas las copias integradas en aplicaciones de terceros, y comprueba la versión con php -v.
2. Actualiza. Instala 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o el paquete corregido de tu distribución de Linux. Las distribuciones recibieron el parche por adelantado. PHP insiste en que actualizar es la única corrección completa.
3. Migra las versiones sin soporte. Si usas 8.1 o anterior, planifica el salto a 8.3 o 8.4. Mejor evitar 8.2, que deja de tener soporte el 31 de diciembre de 2026.
4. Reconstruye los contenedores. Si usas imágenes Docker con PHP, reconstrúyelas con la imagen base actualizada y vuelve a desplegarlas.
5. Reinicia los procesos. Tras actualizar o cambiar la configuración, recarga php-fpm o el servidor web para que todos los procesos tomen la versión nueva.

Si no puedes actualizar de inmediato, hay mitigaciones parciales que reducen la exposición mientras preparas la migración. Fijar session.upload_progress.enabled = Off en el php.ini o en el pool de FPM bloquea las vías confirmadas del segundo fallo, y fijar memory_limit=-1 de forma que las aplicaciones no puedan cambiarlo reduce la exposición al primero. En PHP 8.5, PHP recomienda además fatal_error_backtraces=0. Ninguna de estas medidas cierra el problema, así que el parche sigue siendo imprescindible.

Para los servidores que no se puedan actualizar a corto plazo, CERT-EU recomienda aislarlos de internet y CISA va más allá y pide desconectarlos hasta corregirlos. Un WAF puede dar algo de protección en el ínterin, pero solo como medida temporal.

Qué revisar si sospechas de un ataque

Además de parchear, merece la pena comprobar si alguien ha entrado antes. Estas son las señales que proponen los equipos de respuesta.

• Procesos sospechosos: Procesos de PHP que lanzan consolas, intérpretes o herramientas de descarga.
• Archivos nuevos: Webshells o ficheros desconocidos en la raíz web.
• Persistencia: Tareas programadas o cuentas de usuario que nadie ha creado.

Si encuentras algo, aísla el servidor, conserva los registros del servidor web y de PHP y cambia las credenciales que pudieran estar expuestas.

Si necesitas ayuda, contáctanos

Una vulnerabilidad así recuerda la importancia de saber en todo momento qué versiones corren en tus sistemas y de tener un procedimiento para actualizar rápido. Si gestionas aplicaciones con PHP y quieres revisar tu exposición o planificar la migración desde versiones sin soporte, cuéntanos tu caso.