Las primeras señales del fallo de PHP que obligó a gobiernos de todo el mundo a desconectar webs el 21 de octubre de 2026 aparecieron en 2024, durante una auditoría de seguridad que pagó Alemania, según el análisis de la propia PHP Foundation. El arreglo se atascó durante más de un año por falta de consenso y de recursos, y cuando por fin se publicó, el país que había financiado aquella auditoría tuvo que retirar de internet webs de su policía y de varios gobiernos regionales. La PHP Foundation lo ha calificado como un fallo estructural.
Las claves del origen de PHP2Shell y la respuesta alemana en 30 segundos
- Un desarrollador de la PHP Foundation vio el problema en 2024 al corregir hallazgos de una auditoría de Quarkslab financiada por la Sovereign Tech Agency alemana.
- El arreglo se retrasó hasta que la firma Calif reportó el fallo explotable el 11 de agosto de 2026.
- Chainguard publicó sus versiones corregidas más de seis horas antes del parche oficial, rompiendo el embargo.
- El BSI alemán elevó la alerta a naranja y recomendó desconectar los servidores sin parchear, y varias administraciones lo hicieron.
Los dos fallos, conocidos como PHP2Shell y registrados como CVE-2026-109618 y CVE-2026-109619, permiten ejecutar código en un servidor web con PHP sin iniciar sesión. Opensecurity ya explicó cómo se filtraron antes del parche del 21 de octubre. Este artículo, basado en la reconstrucción publicada en FOSS Pub y en el análisis de la PHP Foundation, repasa por qué tardó tanto en llegar el arreglo y qué ocurrió ese día en Alemania.
Una auditoría alemana y un arreglo atascado
En 2024, la empresa francesa Quarkslab hizo la primera auditoría de seguridad externa de PHP en años, financiada por la Sovereign Tech Agency, el organismo alemán que invierte en software de código abierto crítico. Según FOSS Pub, la agencia contabiliza 205.000 euros de inversión en PHP entre 2023 y 2024. Mientras corregía uno de los problemas detectados, un desarrollador pagado por la PHP Foundation vio las primeras señales del fallo de gestión de memoria que acabaría siendo PHP2Shell.
El arreglo no salió. Según el análisis de la Foundation que recoge Socket, el equipo de seguridad tenía varias soluciones posibles, cada una con sus inconvenientes de compatibilidad, decidía por consenso y no tenía personas suficientes para desbloquearlo, así que el trabajo se paró y se retomó durante meses. El 11 de agosto de 2026, investigadores de la firma Calif reportaron un ataque de ejecución remota sin autenticación, y el arreglo pasó a ser prioridad absoluta. La Foundation atribuyó el retraso tanto al proceso de decisión de su equipo de seguridad como a su falta de recursos, y ha anunciado que pasará a decidir por mayoría y a escalar antes los casos difíciles.
Filtraciones, embargo roto y 22 horas de carrera
La recta final fue caótica. El 20 de octubre, un usuario de Hacker News avisó de que llegaban dos fallos críticos, con una puntuación de gravedad y una fecha equivocadas, y los identificadores de las CVE se filtraron ese mismo día. Calif publicó por error un vídeo de su ataque funcionando contra webs reales; lo retiró, pero circuló en X, y según la Foundation aceleró el trabajo de quienes intentaban construir un exploit. PHP adelantó su publicación un día, al 21 de octubre a las 14:00 UTC.
Chainguard, que vende compilaciones listas para usar de software de código abierto, publicó sus versiones corregidas de PHP a las 07:41 UTC, más de seis horas antes, según la PHP Foundation. Desde ese momento, cualquiera podía comparar el código nuevo con el antiguo y localizar el fallo, mientras Debian, Ubuntu o Red Hat seguían esperando. Su consejero delegado, Dan Lorenc, defendió en Hacker News que adelantó la publicación porque ya había exploits circulando, según le habían confirmado varios proveedores de seguridad que no nombró. La Foundation sostiene que no había identificado ningún exploit público funcional al publicar el parche. Amazon, por su parte, registró en sus servidores señuelo un intento de explotación el 17 de octubre, según FOSS Pub.
Alemania desconecta sus webs
El 21 de octubre, el BSI, la oficina federal alemana de seguridad de la información, elevó su alerta al nivel 3, naranja, en una escala de cuatro, y recomendó separar temporalmente de internet los servidores web que no pudieran parchearse, según recogió Der Tagesspiegel. Muchas administraciones siguieron el consejo. Según FOSS Pub, la oficina federal de policía criminal (BKA) desconectó su web, desaparecieron las comisarías online de Berlín y Brandeburgo, y las webs de ministerios y policía de Baviera mostraron un aviso de no disponibilidad por motivos de seguridad. El diario berlinés cita además las webs de la Charité, los bomberos de Berlín, la Universidad de Potsdam y el ayuntamiento de Maguncia.
PHP publicó el parche a las 13:33 UTC y Debian distribuyó el suyo doce minutos después, a partir del trabajo de Ondřej Surý, el voluntario que empaqueta PHP para Debian y Ubuntu. Las versiones sin soporte quedaron peor paradas: Debian 11 solo recibió el arreglo a través del soporte extendido de pago de Freexian, las versiones antiguas de Ubuntu a través de Ubuntu Pro, y PHP 8.1 y anteriores solo recibieron parches de código fuente.
La lección que extrae FOSS Pub es económica. Según su recuento, la PHP Foundation ingresó 730.534 dólares en patrocinios y donaciones en 2025, mientras Alemania invierte 108 millones de euros en migrar sus webs federales a un sistema escrito en PHP. Surý contó a The Atlantic que en 24 horas recibió en donaciones lo mismo que en un año. Para las empresas, la recomendación práctica es la de siempre, pero con más urgencia: saber qué versión de PHP corre en cada servidor, quién la empaqueta y si sigue teniendo soporte.
Preguntas frecuentes
¿Qué es PHP2Shell?
El nombre de dos vulnerabilidades críticas de PHP, CVE-2026-109618 y CVE-2026-109619, que permiten ejecutar código en un servidor web sin iniciar sesión. Se corrigieron el 21 de octubre de 2026.
¿Desde cuándo se conocía el fallo?
Según la PHP Foundation, un desarrollador vio las primeras señales en 2024, al corregir hallazgos de una auditoría de Quarkslab financiada por la Sovereign Tech Agency alemana.
¿Por qué se desconectaron webs en Alemania?
El BSI elevó la alerta a naranja y recomendó separar de internet los servidores que no pudieran parchearse. Administraciones como la BKA y varios gobiernos regionales lo hicieron de forma preventiva.
¿Qué versiones de PHP quedaron sin parche oficial?
PHP 8.1 y anteriores solo recibieron parches de código fuente. En distribuciones sin soporte, como Debian 11, el arreglo llegó a través de servicios de pago.
Fuentes:
- FOSS Pub: Germany Paid for the Audit That Spotted PHP’s Bug, Then Took Its Police Websites Offline
- PHP Foundation: Today’s PHP security release and how we’re strengthening PHP security
- Socket: PHP Foundation Says Chainguard Broke Security Embargo Ahead of Emergency Patches
- Der Tagesspiegel: Sicherheitslücke in PHP, Bundesamt warnt
- BSI: PHP, kritische Schwachstellen bedrohen Webanwendungen weltweit
