El 21 de octubre de 2026, el ministerio alemán de transformación digital desconectó parte de sus sitios web. El Ministerio del Interior de Francia desactivó las webs de oficinas administrativas locales. Las autoridades de Bélgica, los Países Bajos, Finlandia y la República Checa hicieron lo mismo. La Agencia de Seguridad Nacional de Estados Unidos (NSA) también emitió una advertencia; según Al Jazeera, recomendó desconectar los sitios que no pudieran actualizarse de inmediato.
La causa fueron dos fallos en PHP, el lenguaje de programación con el que funciona la mayoría de los sitios web del mundo. Según los investigadores, el código vulnerable llevaba más de diez años en PHP. Investigadores que trabajaban con inteligencia artificial demostraron que permitía tomar el control de un servidor, aunque, como explicó después la PHP Foundation, uno de los problemas ya se había detectado en 2024.
Esta historia no trata solo de un parche urgente. Trata de cómo está cambiando la búsqueda de puntos débiles en el software y de por qué eso importa tanto a quienes defienden como a quienes atacan.
Qué es PHP y por qué nos afecta a casi todos
PHP es un lenguaje para la parte de servidor de los sitios web: lo que ocurre «entre bastidores» cuando abres una página, escribes una contraseña o envías un formulario. Sobre él están construidos gestores de contenido muy populares, como WordPress, Drupal o Joomla.
Según W3Techs, a 22 de octubre de 2026 PHP lo usa aproximadamente el 69 % de los sitios web cuyo lenguaje de servidor se puede identificar. De ahí sale la cifra del «70 % de internet» que llenó los titulares. Es aproximada: cuenta sitios, no tráfico ni datos, y no todos esos sitios estaban expuestos por igual.
Quien visita una web nunca ve PHP. Pero si un sitio que usa resulta comprometido, las consecuencias pueden alcanzarle también: datos filtrados, una página alterada, un enlace malicioso.
Qué se rompió exactamente
A los fallos se les asignaron los identificadores CVE-2026-109618 y CVE-2026-109619, y los investigadores los bautizaron PHP2Shell. Ambos recibieron una puntuación de gravedad de 9,2 sobre 10 en la escala CVSS 4.0.
Simplificando, el problema está en dos puntos de cómo PHP procesa una petición del navegador:
- cuando se agota la memoria mientras se procesa una petición, PHP deja «restos» con los que después tropieza su rutina de limpieza;
- un proceso de PHP puede reutilizar restos del estado de una petición anterior.
Imagina un camarero que a veces no recoge la mesa después del cliente anterior, de modo que el siguiente puede aprovechar lo que quedó. Por separado, cada descuido es menor. Pero los investigadores demostraron cómo encadenarlos: enviar al servidor una petición especialmente preparada y conseguir que ejecute las órdenes que uno quiera.
Hay dos cosas que lo hacen especialmente peligroso. Primero, no hace falta contraseña: PHP procesa la petición antes de que se activen las protecciones del propio sitio. Segundo, según Wiz, casi todas las versiones de PHP están afectadas por al menos uno de los fallos, hasta la 5.4, publicada en 2012. Las versiones hasta la 8.1 incluida ya no tienen soporte oficial: para ellas el equipo de PHP publicó solo parches mínimos de código fuente, y algunas distribuciones de Linux ofrecen sus propias correcciones.
Quién lo encontró y cómo
Según los investigadores de la empresa de seguridad Wiz, los hechos fueron así:
- 19 de agosto: encuentran el primer fallo;
- 20–21 de agosto: confirman que permite tomar el control de sitios con Drupal y WordPress;
- 24 de agosto: lo comunican al equipo de seguridad de PHP;
- 21 de septiembre: PHP reconoce el problema y empieza a preparar la corrección;
- 21 de octubre: salen las versiones corregidas y se publican los detalles.
Pero Wiz no fue la primera. La empresa Calif, que trabajaba con OpenAI, afirma que encontró antes uno de los fallos con GPT-5.6 Sol y lo comunicó el 11 de agosto. Wiz dice que los encontró de forma independiente.
Parte de la historia es anterior. Según la PHP Foundation, citada por The Record, la historia de CVE-2026-109618 se remonta a 2024, cuando PHP pasó su primera auditoría de seguridad externa en varios años: entonces no se conocía ninguna forma de aprovechar el problema y no se actuó. Además, los desarrolladores no se ponían de acuerdo en cómo corregirlo sin romper la compatibilidad, y el trabajo se estancó. Los informes de agosto dejaron claro su alcance real y, desde el 11 de agosto, corregirlo pasó a ser la máxima prioridad del equipo de seguridad de la fundación. La fundación añade que OpenAI, Wiz y Trail of Bits encontraron los mismos fallos de forma independiente en auditorías de PHP.
Wiz afirma que durante todo el trabajo utilizó su propia herramienta, Wiz Atlas, junto con los modelos de lenguaje Gemini 4 Argon, de Google, y GPT-5.6 Sol, de OpenAI. Según los investigadores, los modelos ayudaron a encontrar los fallos, a escribir y adaptar el exploit —el programa que aprovecha una vulnerabilidad— a distintas versiones de PHP, y a comprobar las correcciones. Aseguran que un solo especialista hizo en una semana lo que antes habría llevado meses a un equipo de primer nivel.
Aquí conviene distinguir. Que la IA ayudó a encontrar una cadena aprovechable y a construir el exploit es un hecho comprobado: lo dicen todos los implicados y la vulnerabilidad es real. «La IA encontró el fallo» es una simplificación: al menos parte del punto débil ya se había detectado antes; lo nuevo fue la prueba de que se podía aprovechar, y la rapidez. Cuánto hicieron los modelos y cuánto las personas, y cuánto se aceleró el trabajo, es una estimación de las propias empresas.
Wiz pertenece a Google, así que las dos compañías cuyos modelos se usaron tienen interés en una historia llamativa. Todavía no hay un análisis independiente de cómo se repartió el trabajo.
Por qué los gobiernos apagaron sus webs
Normalmente, las vulnerabilidades críticas se revelan de forma coordinada: primero la corrección y después los detalles. Esta vez el plan falló. Según SecurityWeek, los detalles se filtraron en internet antes de la publicación prevista de los parches.
El 20 de octubre, PHP avisó de que la corrección saldría al día siguiente y pidió a los administradores que se prepararan. Los expertos en seguridad pronosticaron intentos masivos de ataque a los pocos minutos de la publicación. Más tarde, varias empresas informaron de intentos de explotación, incluso antes de que salieran los parches.
Cloudflare contó decenas de miles de intentos en los 45 minutos posteriores a la divulgación y millones en la mañana del 22 de octubre. Algunos atacantes intentaron, sin éxito, usar los fallos para propagar Potassium, una variante del malware de botnet Mirai.
Para quien administra una web oficial, la decisión es sencilla: si el servidor no se puede actualizar enseguida, es más seguro desconectarlo unas horas que arriesgarse a una intrusión. De ahí los titulares sobre webs «apagadas».
El Reino Unido también se vio afectado. El 22 de octubre, una ministra informó a la Cámara de los Lores de que 32 servicios digitales del Gobierno no estaban disponibles y otros 4 lo estaban solo en parte, sobre todo por precaución. El Centro Nacional de Ciberseguridad (NCSC) envió avisos a más de 50 000 organizaciones británicas.
A 23 de octubre, las empresas de seguridad no informan de ninguna intrusión confirmada. Pero es pronto: las consecuencias reales suelen conocerse semanas después.
No es la primera vez que la IA busca fallos
En noviembre de 2024, el equipo Project Zero de Google informó de que su agente de IA, Big Sleep, había encontrado una vulnerabilidad desconocida en SQLite, una base de datos muy usada. El fallo se corrigió el mismo día, antes de llegar a una versión oficial. Entonces los autores escribieron, con prudencia, que «creían» que era el primer ejemplo público de ese tipo.
En dos años ha cambiado la escala. Entonces: un fallo, cerrado antes de que hiciera daño. Ahora: una cadena de fallos en los cimientos de la mayoría de los sitios web, junto con un ataque que funciona.
En la escala de madurez, esto ya no es una demostración de laboratorio: el uso de la IA para encontrar vulnerabilidades existe y funciona hoy. La pregunta abierta es hasta qué punto se extenderá y quién lo aprovechará primero.
Una herramienta para ambos bandos
Lo que sigue no son hechos, sino interpretación.
La misma capacidad que ayudó a Wiz y a Calif está al alcance de quienes buscan fallos para atacar. Los investigadores de Wiz lo dicen sin rodeos: la complejidad «puede dejar de ser una barrera significativa». Muchos fallos peligrosos pasaban desapercibidos simplemente porque eran muy difíciles de encontrar y de aprovechar. Si la IA baja esa barrera, el código antiguo de todo internet puede resultar menos seguro de lo que parecía.
Pero los dos bandos no están en igualdad. A quien ataca le basta con encontrar un servidor sin actualizar. Quien defiende tiene que actualizarlos todos. Por eso el cuello de botella se desplaza de encontrar fallos a corregirlos: alguien tiene que escribir el parche, probarlo e instalarlo en millones de servidores, algunos con versiones que ya no tienen soporte.
También hay una dimensión humana. Muchas tecnologías básicas de internet, como PHP, las mantienen equipos relativamente pequeños. Si la IA descubre cada vez más fallos graves, la carga sobre esas personas aumentará.
Lo que todavía no sabemos
- Cuántos sistemas siguen sin actualizar y cuántos fueron atacados con éxito. A 23 de octubre, Censys estima que más de 34 millones de servicios PHP (servicios web, no servidores físicos) siguen siendo vulnerables; todavía no hay intrusiones masivas confirmadas.
- Si otros encontraron estos fallos antes. El código vulnerable existía desde hacía más de diez años, y uno de los problemas se detectó en 2024. No se sabe si alguien los estaba usando en secreto. Amazon informa de que su red de señuelos registró un intento de explotación el 17 de octubre, cuatro días antes de la divulgación; no se sabe cómo obtuvo el atacante los detalles.
- Qué parte del trabajo fue de la IA. Solo lo han contado los participantes.
- Cuántos fallos parecidos quedan. Si la IA encontró esto en PHP, es razonable suponer que hay fallos similares en otras tecnologías antiguas. Pero es una suposición, no un hecho establecido.
Tres escenarios plausibles
Los defensores toman ventaja. Empresas y desarrolladores de código abierto revisan a gran escala el código antiguo con ayuda de la IA y corrigen los fallos antes de que los encuentren los atacantes. Condición: acceso a estas herramientas y personas capaces de publicar correcciones a tiempo.
Una carrera igualada. Los parches urgentes como PHP2Shell se vuelven algo habitual, y el tiempo entre la revelación de una vulnerabilidad y los primeros ataques se reduce a minutos.
El cuello de botella es actualizar. Los fallos se encuentran rápido, pero los servidores antiguos sin actualizar siguen siendo el punto más débil, y la habilidad más importante pasa a ser actualizar deprisa.
Estos escenarios no se excluyen entre sí. Lo más probable es que en distintas partes de internet se cumplan distintos.
Qué significa para ti
Si tienes un sitio web —por ejemplo, con WordPress—, pregunta a tu proveedor de alojamiento si ha actualizado PHP. Las versiones corregidas son 8.2.35, 8.3.36, 8.4.27 y 8.5.12, o posteriores. Si tu sitio funciona con PHP 8.1 o anterior, no habrá una versión oficial con la corrección —solo parches para quien compila PHP por su cuenta o correcciones de algunas distribuciones de Linux—, así que conviene planificar el paso a una versión con soporte. Los avisos oficiales para tu país los publica el equipo nacional de respuesta a incidentes: en España, INCIBE-CERT; en América Latina, el CSIRT de cada país.
Si simplemente usas internet, no tienes que hacer nada especial. Pero es un buen momento para activar las actualizaciones automáticas en el móvil y el ordenador, y para desconfiar de correos del tipo «actualiza urgentemente tu web»: a los estafadores les encantan las noticias sonadas.
La lección principal es sencilla: en seguridad no gana quien conoce todos los fallos, sino quien los corrige rápido.
Preguntas para el debate
- ¿Es correcto apagar webs oficiales durante unas horas por seguridad, si mientras tanto la gente no puede acceder a los servicios?
- ¿Quién debería responsabilizarse de la seguridad de tecnologías de las que depende todo internet, pero que mantienen equipos relativamente pequeños?
- ¿Cambia el papel de la IA tu forma de ver esta historia: es sobre todo una buena noticia para los defensores o una señal de alarma?
Log in or Sign up to join the discussion.