PHP2Shell: la falla que hizo a gobiernos apagar sus webs
El 21 de octubre, medio Europa desconectó sus propias webs a propósito por dos fallas de PHP, el lenguaje que mueve cerca del 70% de internet. Llevaban 14 años ahí y las encontró una IA. Qué pasó, por qué apagar fue la decisión correcta y qué revisar si tu negocio tiene una web.
Tipo: Análisis/noticia | Fuentes principales: CISA (21 de octubre de 2026), The Record, UptimeRobot
El miércoles 21 de octubre, en Países Bajos, DigiD dejó de funcionar. Es el sistema con el que los holandeses entran a casi cualquier trámite del Estado. Nadie lo había hackeado. Lo apagaron sus propios administradores, igual que el sitio de su agencia nacional de ciberseguridad, el portal MijnOverheid, el del Parlamento y el del Puerto de Róterdam.
Ese mismo día hicieron lo mismo los servicios web públicos del gobierno de Finlandia, las prefecturas de Francia, la cancillería de Bélgica, el gobierno checo y cyber.gov.au, el sitio de ciberseguridad del gobierno de Australia. Y no solo gobiernos: Nintendo, el hospital Charité de Berlín, el proyecto OBS y varios sistemas de la Fundación Wikimedia también desconectaron servicios.
La razón tiene nombre: PHP2Shell. Y lo que más me llamó la atención no fue el apagón, sino cómo se encontró la falla.
Qué es PHP2Shell, sin tecnicismos
PHP es el lenguaje en el que está escrita la parte "de atrás" de una enorme cantidad de páginas web. Si tu web es un WordPress, una tienda WooCommerce, un Drupal o un Joomla, corre sobre PHP aunque nunca hayas visto una línea de código. Según W3Techs, citado por iTWire, es cerca del 70% de las webs cuyo lenguaje se puede identificar.
PHP2Shell son dos fallas en el propio PHP, no en un plugin ni en una plantilla. Tienen nombres de catálogo, CVE-2026-109618 y CVE-2026-109619, y el equipo de PHP les puso 9.2 sobre 10 de gravedad. La firma watchTowr les puso directamente 10. Las dos permiten lo peor que le puede pasar a un servidor: que alguien, sin usuario ni contraseña, ejecute sus propias órdenes adentro.
Rapid7, una empresa de seguridad, explicó cómo funciona cada una. Las traduzco con dos analogías, sabiendo que simplifican.
La primera (109618) aparece cuando PHP se queda sin memoria a mitad de un pedido, por ejemplo al recibir un formulario o un archivo subido con una forma especial. Se detiene de golpe y deja datos a medio preparar, que después el proceso de limpieza usa como si estuvieran bien. Piensa en un mesero que tropieza a mitad de camino, y luego alguien recoge la mesa con una lista que ya no corresponde.
La segunda (109619) tiene que ver con que PHP reutiliza el mismo "trabajador" para atender varios pedidos seguidos. A veces, de un pedido anterior queda una referencia a un espacio de memoria que ya se liberó, y el siguiente pedido la lee como si siguiera siendo válida. Es una habitación de hotel donde quedó la nota del huésped anterior señalando un cajón que ya se vació y se le dio a otra persona.
Lo grave es el alcance. Las fallas afectan a casi todas las versiones de PHP desde la 5.4, que salió en 2012. El presidente de OpenAI, Greg Brockman, dijo que el bug llevaba 14 años en PHP. Unit 42, el equipo de investigación de Palo Alto Networks, contó más de 22 millones de instalaciones de PHP expuestas a internet.
Lo encontró una IA, y se filtró antes de tiempo
Aquí la historia se conecta con algo que escribí esta misma semana. La falla la encontró la firma de seguridad Calif en agosto, usando GPT-5.6 Sol, un modelo de OpenAI, dentro de un programa de OpenAI llamado "Patch the Planet". En septiembre, el propio equipo de OpenAI encontró una versión más completa del problema. La empresa Wiz, por su lado, encontró las dos fallas de forma independiente.
Durante dos meses, OpenAI, los mantenedores de PHP, Wiz, Cloudflare y agencias de Estados Unidos prepararon los arreglos en secreto. La fecha de publicación era el 22 de octubre. No llegó: el 20 empezaron a filtrarse detalles, y PHP adelantó todo un día. Las versiones corregidas (8.5.12, 8.4.27, 8.3.36 y 8.2.35) salieron el 21 a las 14:00 UTC. Para colmo, Chainguard, una empresa que distribuye software, publicó sus versiones corregidas más de seis horas antes de lo acordado, y eso permitía a cualquiera comparar el código y ver qué se había arreglado.
Hay un detalle que me parece la parte más humana de la historia. Según la Fundación PHP, el problema de memoria ya se había detectado en una auditoría de Quarkslab en 2024. No se arregló porque cada solución que se probaba rompía otra cosa. El bug estaba visto, y aun así siguió ahí dos años más.
¿Se usó para atacar? Las fuentes no coinciden, y prefiero decirlo así. Amazon registró un intento de explotación el 17 de octubre, cuatro días antes de que se hiciera público. watchTowr dijo que vio intentos reales usando herramientas armadas con ayuda de IA, y su jefe de inteligencia, Jake Knott, lo resumió así a The Record: "Whilst nobody has been successful to date, we don't expect that will last long." Hasta ahora nadie lo ha logrado, pero no esperamos que dure. La CISA, la agencia de ciberseguridad de Estados Unidos, dijo ese mismo día que no había visto explotación. Y Rapid7 comprobó que los exploits públicos funcionan solo con combinaciones muy específicas de sistema operativo, versión de PHP y servidor.
El día que media Europa desenchufó sus webs
Apagar tu propia web parece una exageración hasta que entiendes el razonamiento. Cuando sale un arreglo, los atacantes lo comparan con la versión vieja y descubren exactamente dónde estaba el hueco. Kristian Razum, de UptimeRobot, lo explica así: "it can be reverse engineered into a working exploit in minutes". Se puede convertir en un ataque funcional en minutos, y después empieza el escaneo masivo.
Si no puedes actualizar ese mismo día, la cuenta es simple. La NSA de Estados Unidos recomendó desconectar cualquier sistema que no se pudiera actualizar de inmediato. La CISA pidió lo mismo para quienes usan PHP 8.1 o anterior, versiones que ya no reciben arreglos oficiales.
UptimeRobot, un servicio que vigila si las webs están en línea, midió el efecto. En el pico del 21 de octubre registró unas 37,000 alertas de caída por minuto, contra unas 3,300 del día anterior. En Europa el salto fue de unas 20 veces. Y los dominios inalcanzables se dispararon:
Dominios web inalcanzables, 20 vs 21 de octubre
Una parte de esas caídas fueron apagones voluntarios y otra, actualizaciones que salieron mal. Incluso actualizar costó: php.net devolvía errores minutos antes del lanzamiento y el repositorio de PHP para Ubuntu también se cayó un rato.
La parte incómoda
Ahora, las tres cosas que no me dejan tranquilo.
La primera: muchísimas webs no pueden simplemente actualizar. Joviane Jardim, de Detectify, calcula que cerca de la mitad de las webs con PHP usan versiones viejas, y SC Media habla de alrededor del 80% en versiones sin soporte. Las cifras no coinciden, pero en los dos casos son millones de sitios que no van a recibir un arreglo oficial y dependen de parches de terceros o de una migración.
La segunda: quién sostiene esto. La Fundación PHP, que financia el desarrollo del lenguaje que mueve la mayor parte de la web, según su último reporte de transparencia, tenía en 2024 a 10 desarrolladores pagados, a tiempo parcial o completo, y recibió 683,550 dólares en donaciones e inversiones. Esa es la base sobre la que corre buena parte del comercio en internet.
La tercera es la que conecta con el blog anterior. Esta misma semana, Anthropic contó cómo usó a Claude para encontrar cientos de bugs escondidos en librerías de código abierto. OpenAI encontró PHP2Shell con su modelo. La IA está encontrando fallas viejas a una velocidad que antes no existía, y eso es bueno. Pero la misma OpenAI reconoció que la IA "can also help attackers exploit them", también puede ayudar a los atacantes a explotarlas, y watchTowr ya vio ataques armados con IA. Brockman lo dijo sin rodeos: "We expect to find many more such issues over upcoming months." Esperan encontrar muchos más problemas así en los próximos meses.
Traducido: el tiempo entre "se descubre una falla" y "alguien la usa" se está acortando. Y eso le pega más fuerte a quien no tiene a nadie mirando.
Qué significa para un negocio sin equipo técnico
Si tienes una web con WordPress, una tienda en línea o un sistema de reservas en un hosting compartido, lo más probable es que corra sobre PHP. Tú no elegiste PHP. Lo eligió la plantilla, el plugin o el hosting. Y ahí está la lección que más me importa: tu web no es solo lo que se ve. Es todo lo que tiene debajo, y lo de abajo también envejece.
Los gobiernos que apagaron sus webs tenían algo que la mayoría de los negocios chicos no tiene: alguien que supiera, el mismo día, qué versión de PHP corría en cada servidor y que pudiera decidir apagarlo. Si tu web la armó un freelancer hace tres años y no has vuelto a hablar con él, esa persona no existe en tu negocio.
No hace falta que aprendas a actualizar un servidor. Hace falta que sepas quién lo hace, qué tan rápido y qué pasa mientras tanto. Para eso es este checklist.
Checklist: 5 pasos para la web de tu negocio
- Averigua si tu web usa PHP y qué versión. Si usas WordPress, está en Herramientas → Salud del sitio → Información → Servidor. Si no, pregúntale a tu hosting. Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
- Si estás en PHP 8.1 o anterior, tienes un problema más grande. Esas versiones ya no reciben arreglos oficiales. Pregúntale a tu hosting si aplicó un parche de terceros y pon fecha para migrar a una versión con soporte.
- Ten escrito quién actualiza y en cuánto tiempo. El nombre de la persona o del hosting, cómo contactarla un miércoles a las 3 de la tarde y cuántas horas tarda en reaccionar. Si la respuesta es "no sé", ese es el primer arreglo.
- Decide antes cuándo apagarías. Razum lo dice claro: "a few hours of planned downtime is a much smaller risk than leaving the site up and hoping". Unas horas de caída planificada son un riesgo mucho menor que dejar la web arriba y esperar que no pase nada. Ten listo un aviso de "volvemos pronto" y una forma alternativa de atender a tus clientes (WhatsApp, teléfono).
- Después de actualizar, revisa. Pide que miren los registros del servidor desde el 17 de octubre y, si hay señales raras, que cambien las contraseñas del hosting y de la base de datos. Actualizar no borra lo que alguien pudo haber dejado adentro antes.
Ninguno de estos pasos requiere saber programar. Requieren saber a quién llamar.
Fuentes
- CISA — Critical Vulnerabilities in PHP Require Immediate Patching (21 de octubre de 2026)
- Rapid7 — CVE-2026-109618 and CVE-2026-109619: Critical Unauthenticated Remote Code Execution in PHP
- The Record — Hundreds of websites taken offline as concern grows over two PHP vulnerabilities
- UptimeRobot — Inside PHP2Shell: Why Websites Took Themselves Offline
- iTWire — PHP2Shell: the 14-year-old bugs that pulled cyber.gov.au and government sites worldwide offline
- Decrypt — Who Found the PHP Bug That Made Governments Unplug Their Websites? ChatGPT, Of Course
- The PHP Foundation y su reporte de transparencia 2024
¿Quieres automatizar esto en tu negocio?