Los sitios PHP están siendo hackeados: así puedes protegerte

Empecemos por el nombre, porque ayuda a entender el alcance del problema. PHP2Shell no es el fallo de un plugin o de una plantilla: es un defecto en el propio motor de PHP, es decir, en el programa que en el servidor interpreta y ejecuta el código de los sitios. Cuando el defecto está ahí, da igual lo bien escrito que esté el sitio que corre encima: está expuesto de todos modos. Y PHP hace funcionar cerca del 69% de los sitios web del mundo, WordPress incluido.

Técnicamente son dos vulnerabilidades distintas, CVE-2026-109618 y CVE-2026-109619. La primera aprovecha un agotamiento de memoria: si el servidor se queda sin memoria en el momento equivocado, las estructuras internas de una petición quedan inicializadas solo a medias, pero la limpieza al final de la petición las trata como completas y acaba escribiendo donde no debe. La segunda tiene que ver con el estado global: datos de una petición sobreviven a la memoria que los alojaba y la petición siguiente en el mismo proceso los encuentra y los usa. En ambos casos un atacante que envía peticiones construidas a propósito llega a ejecutar código en el servidor, sin contraseña, sin cuenta y sin pasar por ningún formulario.

El fallo llevaba años ahí, desde la versión 5.4 hasta la 8.5. Una pista ya había aparecido en 2024, pero sin un exploit conocido nadie lo consideró urgente. Lo encontraron en agosto de 2026 dos grupos independientes, los investigadores de Wiz y el proyecto Patch the Planet de OpenAI, ambos usando modelos de inteligencia artificial para leer el código fuente en busca de errores. Es un detalle que nos llamó la atención: la misma tecnología que encuentra los fallos es la que luego los explota.

Los parches salieron el 21 de octubre: PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Quien esté en 8.1 o versiones anteriores, ya sin soporte, no tiene ninguna versión que instalar y debe migrar. No hay mitigaciones parciales que valgan: lo dicen los mantenedores de PHP y lo confirmamos nosotros, que hemos seguido el asunto desde los primeros avisos. Amazon interceptó un intento de explotación ya el 17 de octubre, cuatro días antes de que el fallo fuera público, y varios gobiernos europeos prefirieron apagar sus sitios antes que arriesgarse.

La segunda noticia nos hizo reflexionar todavía más. Reuters contó una investigación de la empresa de seguridad NorForge: un grupo de habla china puso a trabajar agentes de inteligencia artificial contra más de 1.200 sitios entre Estados Unidos, Canadá, Australia y Japón, y vulneró más de cien. No había nadie tecleando comandos: el agente exploraba el sitio, probaba los caminos posibles y seguía solo, de media 23 horas por objetivo.

Las herramientas no tenían nada de exótico: DeepSeek, GLM, Grok y Claude Code. Este último es un programa, no un modelo, y en las configuraciones encontradas estaba a menudo conectado a modelos distintos de los de Anthropic. En una de las intrusiones documentadas la puerta de entrada volvió a ser PHP, pero en otro punto: la deserialización insegura de objetos y componentes antiguos del framework Zend. Código legítimo, escrito hace años, nunca actualizado y que seguía a la escucha en internet.

Juntas, las dos historias dicen una sola cosa. El tiempo entre el descubrimiento de un fallo y su explotación se mide ya en días, y al otro lado ya no hay una persona que elige el objetivo sino un software que lo prueba todo, en todas partes, hasta que algo cede.