La IA encontró dos fallos críticos en PHP, el lenguaje de casi siete de cada diez sitios web. La misma capacidad sirve para atacar

PHP no es un nombre que la mayoría de la gente conozca, pero está detrás de buena parte de lo que lee en internet. Es el lenguaje con el que funcionan WordPress, Drupal o Joomla, los gestores de contenido de miles de medios, universidades, comercios y entidades públicas. Según el servicio de medición W3Techs, el 69,2 % de los sitios web cuyo lenguaje de servidor se conoce usan PHP.

El 21 de octubre de 2026 se publicaron parches para dos fallos críticos en el núcleo del lenguaje, identificados como CVE-2026-109618 y CVE-2026-109619 y conocidos en conjunto como «php2shell». Lo que hace relevante el caso, además de su alcance, es cómo se encontraron: con ayuda de modelos de inteligencia artificial.

Este análisis amplía el reel «El elefante que mueve la web tenía dos grietas» (abre en una pestaña nueva), publicado por EPOCH en Instagram.

#Qué permitían los fallos

Según la alerta de la CISA, la agencia de ciberseguridad de Estados Unidos, ambos fallos permiten la ejecución remota de código sin autenticación: un atacante puede hacer que el servidor ejecute sus instrucciones sin necesidad de usuario ni contraseña.

La agencia considera afectada cualquier instalación de PHP que atienda solicitudes web, en sus configuraciones más comunes (Apache con mod_php, PHP-FPM, php-cgi, FrankenPHP y LiteSpeed). Wiz, la firma de seguridad que documentó técnicamente el problema, sostiene que todas las versiones de PHP de la última década tienen al menos uno de los errores, que se remontan hasta PHP 5.4, y les asigna una severidad de hasta 9,2 sobre 10 en la escala CVSS.

Se trata de errores de manejo de memoria vinculados a la forma en que PHP gestiona los errores fatales, en especial cuando un proceso se queda sin memoria. Según Fortune, el código vulnerable llevaba alrededor de 14 años en el lenguaje.

#Cómo los encontró la IA

La cronología que reconstruyen Fortune y Wiz muestra que al menos dos equipos llegaron al problema por separado, y ambos usaban modelos de IA:

• 1 de agosto de 2026. La firma californiana Calif, dedicada a pruebas de seguridad de sistemas de IA, encontró el primer fallo con GPT-5.6 Sol, de OpenAI, dentro de una iniciativa de esa empresa para buscar vulnerabilidades en software de alto impacto. Según Fortune, OpenAI encontró después elementos adicionales que mostraron que el problema era más grave.
• 19 de agosto. Wiz, propiedad de Google, halló el primer error con su herramienta Wiz Atlas y los modelos Gemini 4 Argon y GPT-5.6 Sol. Al día siguiente confirmó que podía tomar el control de un sitio Drupal y, al otro, uno en WordPress.
• 24 de agosto. Wiz reportó los fallos al equipo de seguridad de PHP, que el 21 de septiembre inició una corrección coordinada.
• 21 de octubre. Salieron las versiones corregidas y la divulgación pública.

Wiz describe el episodio como un punto de inflexión: la IA no solo ayudó a detectar las debilidades, sino a convertirlas en un ataque funcional.

#Horas, no semanas

La otra cara llegó de inmediato. Según Fortune, los primeros reportes sobre los fallos circularon la noche del 20 de octubre, antes del parche oficial. Cloudflare registró decenas de miles de intentos de explotación en los 45 minutos siguientes a la noticia, cientos de miles en dos horas y millones esa misma noche. Amazon Web Services afirmó el 21 de octubre que el fallo ya se estaba explotando de forma amplia.

El 26 de octubre, la CISA incorporó ambos fallos a su catálogo de vulnerabilidades explotadas activamente, la lista que obliga a las agencias federales estadounidenses a corregirlas.

OpenAI resumió el dilema en una frase citada por Fortune: las mismas capacidades que descubren fallos a escala de internet «también pueden ayudar a los atacantes» a desarrollar herramientas ofensivas con rapidez.

#Por qué importa

El caso muestra que la IA ya no es solo un tema de política tecnológica, sino una herramienta de trabajo diario en seguridad informática, en ambos lados. Si encontrar un fallo en un componente que sostiene media web cuesta menos, la ventaja pasa a quien actúa primero, y el margen para corregir se reduce de semanas a horas.

Eso pesa más donde los equipos técnicos son pequeños y las actualizaciones se aplazan, una situación habitual en sitios de entidades públicas, medios y pequeñas empresas. La corrección existe y es gratuita; el problema es aplicarla a tiempo.

#Qué recomiendan las autoridades

La CISA pide a las organizaciones:

1. Hacer inventario de todos los sistemas que ejecutan PHP, incluido el que viene integrado en otros programas.
2. Actualizar de inmediato, empezando por los sistemas expuestos a internet. Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
3. Si no es posible actualizar, o si se usa PHP 8.1 o anterior (ya sin soporte), desconectar esos sistemas hasta corregirlos.
4. Usar un cortafuegos de aplicaciones web como protección temporal y vigilar actividad sospechosa en los servidores.

Wiz recuerda que la actualización es la única solución completa.