PHP2Shell: la vulnerabilidad crítica de PHP que ha puesto en alerta a miles de servidores

¿Qué ha pasado?

Imagina que entras en una tienda online. Ves los productos, sus precios, el carrito de la compra y el botón para pagar. Pero detrás de esa página hay un servidor que se encarga de consultar los productos disponibles, comprobar tu cuenta, calcular el pedido y comunicarse con la base de datos.

PHP es uno de los lenguajes de programación que permiten realizar todo ese trabajo que no ves.

Y es mucho más común de lo que parece. Según W3Techs, aproximadamente el 70% de las páginas web cuyo lenguaje de servidor se conoce utilizan PHP, incluyendo muchas desarrolladas con WordPress: tiendas, periódicos digitales, blogs y webs corporativas.

Es decir, seguramente utilizas servicios basados en PHP todos los días sin saberlo.

¿Dónde empieza el problema?

Tenemos que viajar a 2024, cuando se detectaron indicios de un posible problema relacionado con la memoria de PHP. Los especialistas sospechaban que podía ser peligroso, pero todavía no habían demostrado cómo aprovecharlo para atacar un servidor.

En agosto de 2026, distintas investigaciones de seguridad, algunas apoyadas en herramientas de inteligencia artificial, consiguieron identificar formas de explotar vulnerabilidades de este tipo.

¿Y qué significa eso?

Imagina que tienes una tienda y todos los empleados necesitan una contraseña para entrar al almacén. Sin embargo, un atacante descubre un agujero en la pared que le permite entrar sin pasar por el control de acceso.

Algo parecido podría suceder con PHP: un atacante puede enviar una petición especialmente preparada y conseguir que el servidor ejecute instrucciones maliciosas sin necesidad de iniciar sesión.

Si el ataque tiene éxito, podría acceder a archivos, extraer información, modificar páginas web o instalar malware, dependiendo de los permisos y las protecciones del servidor.

Lo preocupante es que el fallo no está necesariamente en la página web de una empresa, sino en el propio PHP sobre el que funciona.

Octubre: comienzan los intentos de ataque

Mientras el equipo de PHP preparaba las soluciones, el 17 de octubre, los sistemas de vigilancia de Amazon detectaron intentos de aprovechar las vulnerabilidades en servidores trampa, diseñados precisamente para estudiar el comportamiento de los atacantes.

El 20 de octubre, PHP anunció una actualización de seguridad extraordinaria y, finalmente, el 21 de octubre publicó parches para dos vulnerabilidades críticas, CVE-2026-109618 y CVE-2026-109619, conocidas como PHP2Shell.

Ambas recibieron una puntuación de gravedad de 9,2 sobre 10.

Según el comunicado oficial de PHP, el problema afecta a diferentes tipos de servidores que utilizan este lenguaje, especialmente a determinadas configuraciones de Apache.

La publicación de los fallos disparó la actividad de los atacantes. Cloudflare registró decenas de miles de intentos de explotación en los primeros 45 minutos, que aumentaron hasta millones al día siguiente.

También se detectaron intentos de instalar una variante de la botnet Mirai, un tipo de malware utilizado para controlar dispositivos infectados.

Pero esto no significa que millones de páginas hayan sido hackeadas. Una cosa son los intentos de ataque y otra que hayan conseguido acceder a los servidores. Los investigadores citados por The Hacker News todavía no habían confirmado ejecuciones exitosas de código en ataques reales.

23 de octubre: aparece un tercer fallo, pero de menor riesgo

Dos días después de las actualizaciones de emergencia, PHP comunicó una tercera vulnerabilidad, CVE-2026-115560.

Esta vez la situación es diferente. El nuevo fallo solo puede aprovecharse cuando una aplicación utiliza una combinación muy poco habitual de configuraciones de sesión.

Además, los servidores que ya tienen desactivada la función session.upload_progress.enabled no están expuestos a esta nueva vía de ataque. Tampoco lo están, por esta vía, las aplicaciones que no realizan el cambio de configuración específico que origina el problema.

Por eso, PHP considera que su explotación es poco probable y no ha publicado un parche de emergencia. En su lugar, recomienda mantener desactivada esa función hasta la próxima actualización habitual.

Hasta el 23 de octubre no se habían comunicado ataques confirmados relacionados con esta tercera vulnerabilidad, según The Hacker News.

¿Y cuál es la solución?

Para los dos fallos críticos iniciales, PHP ya ha publicado las versiones corregidas: 8.2.35, 8.3.36, 8.4.27 y 8.5.12.

El equipo oficial de PHP insiste en que actualizar es la única solución completa. Las medidas temporales pueden reducir algunos riesgos, pero no sustituyen a los parches.

Y aquí está el verdadero reto: no basta con que PHP publique una actualización. Cada empresa, proveedor de alojamiento o administrador debe instalarla en sus servidores.

Por eso, este incidente recuerda la importancia de mantener los sistemas actualizados, revisar las configuraciones y monitorizar posibles amenazas.