Imagínate. Casi el 70 % de los sitios web funcionan con un único lenguaje de programación, y el 21 de octubre sus desarrolladores publicaron un parche de emergencia para dos vulnerabilidades críticas que lo afectaban. La vulnerabilidad «php2shell» (en realidad, dos fallos relacionados) es el tema de actualidad en materia de seguridad esta semana. ¿La sorpresa? Ha sido un modelo de IA el que ha permitido detectarla.
Si gestionas una página web, la administras o pagas a alguien para que lo haga, dedica cinco minutos a leer este artículo. A continuación te explicamos qué ha ocurrido, cómo interviene la IA en este asunto y qué medidas concretas deberías tomar para solucionarlo.
Entonces, ¿qué ha sido realmente el problema?
PHP es el lenguaje en el que se basa gran parte de la web. Cloudflare, citando datos de W3Techs, indica que casi el 70 % de los sitios web lo utilizan. WordPress funciona con este lenguaje. Al igual que este blog.
Estas dos vulnerabilidades llevan los identificadores CVE-2026-109618 y CVE-2026-109619, y cada una de ellas obtiene una puntuación de 9,2 sobre 10 según la escala CVSS. Se trata del estándar utilizado por el sector para evaluar la gravedad de un fallo, y una puntuación de 9,2 se sitúa claramente en la categoría de «prioridad absoluta».
Lo preocupante es lo siguiente: estas vulnerabilidades se encuentran en el núcleo mismo del motor de ejecución de PHP, es decir, el motor que ejecuta el código. Esto significa que un pirata informático no necesita ninguna cuenta, y da igual el cuidado con el que hayas diseñado tu sitio web. Según The Hacker News, estas vulnerabilidades afectan prácticamente a todas las versiones de PHP desde la 5.4. En las instalaciones que utilizan el módulo mod_php de Apache, se ha demostrado que para explotarlas basta con una sola solicitud no autenticada.
Una de estas vulnerabilidades también puede provocar una fuga de memoria desde el servidor. Esta memoria podría contener contraseñas, tokens, claves API y certificados procedentes de las solicitudes de otros usuarios. No es nada tranquilizador.
¿Qué papel desempeña la IA en todo esto?
Esta es la parte de la que todo el mundo habla. OpenAI señala que la empresa de seguridad Calif «ha identificado una vulnerabilidad crítica utilizando GPT-5.6 Sol en el marco de nuestra iniciativa Patch the Planet». En otras palabras, el equipo de Calif utilizó un modelo de IA para detectar una de las dos vulnerabilidades.
Pero seamos sinceros. Wiz Research también descubrió y notificó estas dos vulnerabilidades por su cuenta, y el equipo Codex Security de OpenAI también trabajó en ellas, según The Hacker News. OpenAI afirma además que «por lo que sabemos, la IA de vanguardia detectó estas vulnerabilidades antes que los atacantes». Se trata de una afirmación audaz y, tal y como señala PPC Land, el relato de OpenAI no se basa en ninguna verificación externa.
La IA también ha contribuido en la otra vertiente del trabajo. Los investigadores afirman que los modelos de IA han permitido convertir estas vulnerabilidades en exploits funcionales. Al parecer, un investigador logró en una semana lo que, de otro modo, habría llevado meses a un equipo. Sin embargo, Calif aporta una matización. La empresa sostiene que los modelos actuales aún no son capaces de crear de forma fiable exploits de este tipo a partir de un código antiguo y oscuro sin ayuda humana.
¿Y el propio fallo? Es antiguo. El código vulnerable llevaba más de diez años presente en PHP, y Calif ha rastreado sus orígenes hasta unas investigaciones sobre PHP que datan de 2004.
¿Por qué la vulnerabilidad php2shell se convirtió en un desastre?
La divulgación no salió según lo previsto. El 20 de octubre, un mensaje publicado en el foro Hacker News reveló que las dos vulnerabilidades se harían públicas el 22 de octubre. Por lo tanto, PHP adelantó su publicación un día. Esa misma noche, Calif publicó accidentalmente un vídeo en el que se mostraba una prueba de concepto funcional.
Cloudflare activó las reglas de cortafuegos predeterminadas para sus clientes a las 03:02 UTC del 21 de octubre, incluso antes de que existiera el parche oficial. Posteriormente, PHP publicó las versiones corregidas por la tarde. Aproximadamente 20 minutos más tarde, la empresa de seguridad watchTowr informó de intentos activos de explotación dirigidos a estas dos vulnerabilidades. Dane Knecht, director técnico de Cloudflare, lo expresó sin rodeos: «Estamos observando la aparición de los primeros ataques y actualizando nuestras medidas de protección a medida que surgen nuevos vectores».
Algunas organizaciones no esperaron. BambooHR desconectó su servicio en Estados Unidos, Canadá e Irlanda como medida de precaución. En los Países Bajos, también se han desconectado servicios gubernamentales como DigiD y MijnOverheid, al igual que el centro nacional de ciberseguridad. Sin embargo, ninguna fuente ha confirmado aún que se haya producido una intrusión en un servidor concreto.
Bueno, ¿qué hay que hacer en la práctica?
Ahí es donde muchos se equivocan. Actualizar WordPress, Laravel o tus plugins no resolverá el problema, ya que las vulnerabilidades se encuentran en el entorno de ejecución de PHP. Tal y como indica el artículo de Cloudflare: «Estas vulnerabilidades se encuentran en el entorno de ejecución de PHP; por lo tanto, la simple actualización del código del sitio web o de uno o varios plugins no basta para corregirlas».
Las primeras versiones corregidas son:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
Si utilizas PHP 8.1 o una versión anterior, el proyecto PHP ya no ofrece actualizaciones para estas versiones; por lo tanto, es hora de pasar a una versión más reciente. Tras la actualización, reinicia Apache, PHP-FPM y todos los trabajadores PHP en ejecución de larga duración. Y si tu servidor está gestionado por un proveedor de alojamiento, pregúntale directamente si ha aplicado el parche. No des nada por sentado.
Una última cosa. El 23 de octubre, PHP informó de una tercera vulnerabilidad, CVE-2026-115560, que afecta incluso a versiones totalmente parcheadas, como la 8.5.12. Según Cloudflare, se espera que haya un parche disponible en la próxima versión regular de PHP. Así que mantente al tanto, porque esta historia aún no ha terminado.
Por qué probablemente no será la última
Sinceramente, el enfoque de la IA es a la vez una buena noticia y una advertencia. Es una buena noticia porque fueron los defensores quienes descubrieron estas vulnerabilidades primero, al menos según OpenAI. Pero también es una advertencia, ya que las mismas herramientas funcionan para los atacantes. Ya hemos mencionado que el hackeo mediante agentes de IA se ha abaratado, y php2shell muestra la otra cara de la moneda.
OpenAI indica que espera que «los descubrimientos de este tipo aumenten considerablemente en los próximos meses». Por otra parte, la Fundación PHP ha admitido que un desarrollador principal detectó indicios de esta vulnerabilidad de memoria durante una auditoría externa en 2024. Posteriormente, los trabajos quedaron paralizados durante meses. La Fundación ha calificado este retraso de «fallo estructural» y afirma haber modificado su forma de tomar decisiones en materia de seguridad.
Por lo tanto, el cuello de botella se ha desplazado. La detección de errores no deja de acelerarse, mientras que su corrección sigue siendo la parte más lenta. Esto supone un quebradero de cabeza para todos los equipos pequeños que utilizan código obsoleto, y apostaríamos a que muchas pequeñas empresas de nuestra región encajan en esta descripción. Si los grandes modelos lingüísticos ya realizan un trabajo real, la caza de errores forma claramente parte de esas tareas.
¿Supone, pues, la vulnerabilidad php2shell una victoria para la IA?
En cierto modo. La vulnerabilidad php2shell demuestra que la IA puede ayudar a desenterrar errores graves, con décadas de antigüedad, ocultos en el código del que depende la mayor parte de la web. Pero también pone de manifiesto hasta qué punto puede agravarse la situación en cuanto se hace pública una falla de este tipo, con fugas de información, ataques tempranos y servicios fuera de servicio.
Nuestra opinión: la caza de errores mediante la IA es una realidad, y no hará más que acelerarse. Los ganadores serán los equipos capaces de implementar parches en cuestión de horas, en lugar de varias semanas. Antes, la rapidez en la aplicación de los parches era un pequeño extra apreciable. Hoy en día, es una medida de seguridad básica, igual que cerrar con llave la puerta de entrada por la noche. Así pues, aquí tienes una pregunta que debes plantearle hoy mismo a tu desarrollador o a tu proveedor de alojamiento: si el mes que viene se revelara una nueva vulnerabilidad del tipo «php2shell», ¿en cuánto tiempo podrías realizar la actualización?