El equipo de PHP publicó el 21 de octubre versiones de seguridad de emergencia para corregir dos vulnerabilidades críticas en el núcleo del lenguaje, bautizadas como «PHP2Shell». Los fallos, CVE-2026-109618 y CVE-2026-109619, permiten ejecutar código en el servidor con una petición web sin autenticar y afectan a todas las versiones de PHP desde la 5.4 hasta la 8.5.11. Los detalles se filtraron un día antes del parche y ya existen pruebas de concepto públicas.
A diferencia de la mayoría de avisos de seguridad en el ecosistema PHP, que afectan a un plugin o a una aplicación concreta, aquí el problema está en el propio intérprete. Eso significa que da igual si el servidor ejecuta WordPress, Drupal, Laravel o una aplicación hecha a mano: si sirve peticiones web con una versión vulnerable, está expuesto.
Qué ha pasado
- 20 de octubre, por la mañana: una publicación en Hacker News anuncia dos vulnerabilidades críticas de PHP antes de su divulgación. Se retira, pero las capturas ya circulan y watchTowr confirma la filtración.
- 20 de octubre: PHP adelanta su calendario y anuncia una versión de seguridad fuera de ciclo para el día siguiente a las 14:00 UTC. El embargo original era el jueves.
- 21 de octubre: salen PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Esa misma tarde, Calif y Wiz Research publican los detalles técnicos.
Los dos fallos
- CVE-2026-109618 (falta de memoria): si PHP se queda sin memoria mientras prepara los datos de una petición, el proceso se interrumpe y esos datos quedan solo a medio inicializar. La limpieza posterior los trata como válidos, y eso abre una vía para ejecutar código.
- CVE-2026-109619 (estado que sobrevive): parte del estado interno de una petición sigue existiendo después de liberar su memoria. La siguiente petición que atiende el mismo proceso de PHP puede usar ese estado obsoleto antes de que se reinicie, un clásico use-after-free que permite filtrar memoria o ejecutar código con los permisos del servidor web.
El proyecto PHP les asigna una puntuación CVSS 4.0 de 9,2 sobre 10: ataque por red, sin autenticación ni interacción del usuario, aunque de complejidad alta. Las primeras filtraciones hablaban de un 10. Los detalles filtrados apuntan a la función session.upload_progress, que viene activada por defecto.
A quién afecta
Según PHP, está en riesgo cualquier instalación que sirva peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. PHP ha confirmado además que existe un exploit para mod_php en el que la petición maliciosa actúa antes de que llegue a ejecutarse el código de la aplicación, así que ni el mejor WordPress actualizado protege por sí solo.
Wiz demostró la ejecución remota de código contra WordPress, Drupal y Joomla, y una vía separada de fuga de memoria con la que se podrían leer contraseñas, tokens, claves de API o certificados que estén en la memoria del proceso.
El problema de las versiones antiguas
Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. PHP 8.1 y anteriores están fuera de soporte y no tendrán versión nueva; el proyecto solo ha publicado parches mínimos de código fuente para 7.4, 8.0 y 8.1, pensados para quien compila PHP por su cuenta.
Las cifras de VirusTotal dan una idea del tamaño del problema. De los servidores PHP que muestran su versión en las cabeceras, unos 272.000 usan ramas con soporte, frente a unos 758.000 que siguen en versiones entre la 5.4 y la 8.1; solo PHP 7.4 suma unos 187.000. Y como cuatro de cada cinco servidores ocultan su versión, la cifra real es bastante mayor.
Hay un matiz importante: muchas distribuciones Linux (Debian, Ubuntu, Red Hat) aplican los parches a sus propios paquetes sin cambiar el número de versión. Un PHP que dice ser 8.2.x de Debian puede estar corregido aunque no ponga 8.2.35; hay que mirar el aviso de seguridad de la distribución.
Explotación
Hay pruebas de concepto públicas desde antes del parche. A la tarde del 21 de octubre, Huntress todavía no había visto ataques reales en los equipos que vigila, aunque otras fuentes ya hablan de intentos. Cloudflare ha añadido reglas de emergencia a sus conjuntos gestionados, incluidos los del plan gratuito.
Qué hacer ya
- Actualizar PHP a 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o al paquete corregido de la distribución, y reiniciar PHP-FPM o el servidor web. Empezar por todo lo que esté expuesto a Internet.
- Revisar las imágenes Docker: un contenedor con una etiqueta fija de PHP no se corrige solo. Hay que reconstruir o descargar la imagen nueva y recrear el contenedor. Para ver la versión:
docker exec <contenedor> php -v. - Hacer inventario: PHP aparece en sitios inesperados, como paneles de hosting (cPanel, Plesk), phpMyAdmin, Nextcloud, Roundcube o software de terceros.
- Si no se puede actualizar todavía: poner
session.upload_progress.enabled = Offenphp.iniy reiniciar. Es un paliativo y puede no cubrir todos los vectores, pero reduce mucho el riesgo. - Sacar de Internet lo que no tenga arreglo: las instalaciones en PHP 8.1 o anteriores deberían quedar detrás de una VPN o un WAF mientras se migran.
- Vigilar señales de compromiso: procesos de PHP que lanzan
sh,bash,curl,wgetonc, archivos nuevos en la raíz web, tareas cron desconocidas o usuarios nuevos. Y, por la fuga de memoria, plantearse rotar las claves y contraseñas de los servidores expuestos.
Qué vigilar a continuación
- Si aparecen campañas de explotación masiva, algo habitual pocos días después de un parche con exploit público.
- Los avisos de las distribuciones Linux y de los proveedores de hosting compartido, que concentran miles de webs en versiones antiguas.
- Parches de terceros para versiones sin soporte, cuya eficacia aún no se ha evaluado.
No es el primer susto reciente en el ecosistema PHP: repasa el ataque a la cadena de suministro que comprometió más de 700 versiones de Laravel-Lang.
Conclusión: PHP2Shell es de los fallos que justifican dejar lo que se esté haciendo para actualizar. Afecta al intérprete, no a una aplicación, funciona sin contraseña y los detalles ya son públicos. Quien siga en PHP 7.4 o anterior tiene, además, la excusa definitiva para migrar.
Fuentes y documentación
- PHP — Aviso de seguridad GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
- PHP — Aviso de seguridad GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
- Huntress — Rapid Response: php2shell, Leaked Critical PHP Vulnerabilities
- Google Cloud — Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619
- VirusTotal — Sizing the PHP exposure window for CVE-2026-109618 and CVE-2026-109619
- Sophos — Proof-of-concept exploit released for PHP vulnerabilities
- elhacker.NET — PHP alerta sobre dos fallos críticos y lanzará parches de emergencia