Los administradores de webs tienen deberes urgentes esta semana. El proyecto PHP publicó el 21 de octubre versiones de emergencia para corregir dos vulnerabilidades críticas, bautizadas como PHP2Shell, que permiten ejecutar código en un servidor sin necesidad de iniciar sesión. Según Wiz Research, el equipo que las ha investigado, los fallos afectan a casi todas las versiones de PHP desde la 5.4 y se pudieron explotar en instalaciones por defecto de WordPress, Drupal y Joomla. La única solución completa es actualizar.
Qué es PHP2Shell y por qué es tan grave
Los dos fallos están registrados como CVE-2026-109618 y CVE-2026-109619 y tienen una puntuación de gravedad de 9,2 sobre 10 en la escala CVSS v4.0. El primero se aprovecha de la forma en que PHP gestiona los errores por falta de memoria, que pueden dejar datos internos a medio inicializar. El segundo permite que un estado interno ya liberado sobreviva y lo reutilice una petición posterior atendida por el mismo proceso.
Lo delicado es que el problema está en el núcleo del lenguaje, no en el código de cada web. Según Wiz, incluso una aplicación tan simple como un «Hello World» podría quedar expuesta en una versión vulnerable. El aviso oficial de PHP señala que el riesgo afecta a cualquier instalación que atienda peticiones web, y que es máximo con Apache y mod_php, donde el ataque puede lanzarse antes de que se ejecute el código de la aplicación.
Wiz asegura además que logró leer la memoria de los procesos de PHP sin autenticación, lo que podría dejar al descubierto contraseñas, tokens, claves de API y certificados procedentes de otras peticiones o del propio servidor.
Una investigación hecha con IA y un parche con prisas
La cronología publicada por Wiz arranca el 19 de agosto de 2026, cuando detectó el primer fallo. Al día siguiente confirmó la ejecución remota de código contra Drupal y el 21 de agosto, contra WordPress. El 24 de agosto envió los informes al equipo de seguridad de PHP, que empezó a coordinar la corrección el 21 de septiembre. Wiz explica que usó modelos de IA como Gemini 4 Argon y GPT-5.6 Sol para descubrir los fallos, desarrollar los exploits y validar el parche.
El lanzamiento no fue tranquilo. PHP avisó el 20 de octubre de que publicaría el parche al día siguiente, y según Cybernews y Hostinger los detalles se filtraron antes de tiempo y circulaba código de explotación horas antes de que llegara la corrección. CERT-EU llegó a recomendar aislar o desconectar las aplicaciones expuestas que no pudieran parchearse, y Reuters informó de que algunas webs de administraciones, colegios y hospitales europeos se desconectaron por precaución.
Qué versiones hay que instalar y qué hacer si no se puede actualizar
Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. PHP 8.1 y anteriores ya no reciben actualizaciones oficiales, aunque el proyecto ha publicado parches de código para 7.4, 8.0 y 8.1 y recuerda que las distribuciones de Linux recibieron las correcciones por adelantado. Además, PHP 8.2 deja de tener soporte el 31 de diciembre de 2026, así que conviene planificar ya el salto.
Para quien no pueda actualizar de inmediato, PHP propone medidas que reducen la exposición pero que no hacen segura la instalación: desactivar session.upload_progress.enabled en php.ini y reiniciar los procesos, limitar el tamaño de las peticiones y, en PHP 8.5, desactivar fatal_error_backtraces. Proveedores como Cloudflare, Fastly, Google o Vercel han activado protecciones para sus clientes, y Hostinger asegura que ha bloqueado patrones de ataque y actualizado PHP en sus planes, salvo en los VPS.
Qué significa para quienes gestionan webs con WordPress
La primera tarea es saber qué versión de PHP usa cada web, algo que se puede consultar en la pantalla de Salud del sitio de WordPress o en el panel del hosting. En un hosting gestionado, lo normal es que el proveedor aplique el parche, pero conviene confirmarlo por escrito. En un VPS o un servidor propio, la actualización es responsabilidad de quien lo administra.
Wiz recomienda vigilar señales como errores 500 repetidos, peticiones multipart extrañas seguidas de errores de memoria o cookies PHPSESSID anormalmente grandes, porque los registros de la aplicación pueden mostrar muy poco. Y no hay que olvidar los subdominios de pruebas, las instalaciones abandonadas o las imágenes de Docker antiguas, que suelen quedarse sin actualizar.
Si hace falta desconectar una web para parchearla, John Mueller, de Google, recomendó servir un código HTTP 503 en lugar de dejar que las peticiones caduquen o devuelvan errores 404 o 500, para que el apagón temporal no afecte al posicionamiento en buscadores.