La filtración anticipada de los detalles técnicos desencadenó intentos de explotación antes de que existieran parches públicos y llevó a gobiernos, universidades y plataformas digitales a desconectar sus servicios. Las actualizaciones ya están disponibles, pero millones de instalaciones podrían seguir expuestas.
El 21 de octubre de 2026, numerosos sitios web comenzaron a desaparecer de Internet. Organismos gubernamentales europeos, universidades, medios de comunicación y plataformas digitales suspendieron temporalmente sus servicios ante una amenaza que todavía no podían resolver mediante una actualización de seguridad.
El origen estaba en PHP, uno de los lenguajes de programación más utilizados para desarrollar aplicaciones web.
Dos vulnerabilidades críticas, identificadas como CVE-2026-109618 y CVE-2026-109619, permitían ejecutar código de forma remota y sin autenticación bajo determinadas condiciones. Ambas recibieron una puntuación de 9,2 sobre 10 en CVSS 4.0 y terminaron siendo conocidas conjuntamente como PHP2Shell.
La gravedad del incidente no se limitaba a las vulnerabilidades. Los detalles técnicos comenzaron a circular antes de la publicación de los parches, aparecieron pruebas de concepto y empresas de seguridad reportaron intentos de explotación mientras los administradores de sistemas todavía esperaban una solución oficial.
Lo que debía ser una divulgación coordinada terminó convirtiéndose en una carrera contra el tiempo.
Una filtración que comenzó con un mensaje difícil de creer
La historia pública comenzó el 20 de octubre, cuando el equipo de seguridad de PHP anunció una actualización extraordinaria para el día siguiente, a las 14:00 UTC.
El proyecto anticipó que corregiría dos vulnerabilidades críticas, pero inicialmente mantuvo bajo reserva los detalles técnicos para reducir el riesgo de explotación antes de que estuvieran disponibles las soluciones.
Sin embargo, información sobre las fallas comenzó a circular en comunidades técnicas.
Una publicación en Hacker News mencionó los identificadores CVE y la existencia de vulnerabilidades de ejecución remota de código. Su autor admitió no disponer de pruebas verificables y recurrió a la expresión informal «source: trust me, bro».
En otras circunstancias, una afirmación semejante podría haber pasado inadvertida.
Pero el investigador de seguridad Kevin Beaumont llamó la atención sobre la publicación. Poco después, investigadores de watchTowr confirmaron que las vulnerabilidades eran reales y que existían posibilidades concretas de explotación.
El escenario cambió radicalmente.
Ya no se trataba simplemente de rumores sobre dos vulnerabilidades futuras. La información circulaba públicamente y terceros comenzaban a investigar cómo aprovecharlas.
Según el análisis posterior de Recorded Future, un archivo con información filtrada sobre las vulnerabilidades ya había sido enviado a VirusTotal a las 02:29 UTC del 21 de octubre.
La ventana de divulgación coordinada se había roto.
¿Qué hace tan peligrosas a estas vulnerabilidades?
PHP es un lenguaje de programación del lado del servidor. Creado por Rasmus Lerdorf en 1994, originalmente como un conjunto de herramientas denominado Personal Home Page, terminó convirtiéndose en una pieza fundamental del desarrollo web.
WordPress, Drupal, Joomla y numerosas aplicaciones empresariales utilizan PHP para generar contenido dinámico, procesar formularios, administrar sesiones y comunicarse con bases de datos.
Precisamente por eso, un problema de seguridad en el propio intérprete puede tener consecuencias mucho más amplias que una vulnerabilidad en una aplicación determinada.
En PHP2Shell, el problema no está necesariamente en el código del sitio web, sino en el software que lo ejecuta.
Esto significa que incluso una aplicación correctamente desarrollada puede quedar expuesta si funciona sobre una versión vulnerable de PHP y se cumplen las condiciones necesarias para explotar alguna de las fallas.
Las dos vulnerabilidades afectan mecanismos internos relacionados con la administración de memoria y el procesamiento de solicitudes HTTP.
CVE-2026-109618: corrupción de memoria ante errores de asignación
La primera vulnerabilidad está relacionada con el tratamiento de situaciones en las que PHP agota la memoria disponible durante determinadas operaciones.
En condiciones normales, cuando un proceso encuentra un error de este tipo, el intérprete debería interrumpir la operación y liberar sus recursos de manera segura.
Sin embargo, la vulnerabilidad puede provocar que determinadas estructuras internas queden parcialmente inicializadas.
Cuando PHP intenta limpiar esos recursos, puede interpretar información inválida como si fuera válida.
El resultado es una condición de corrupción de memoria que, bajo circunstancias específicas, puede aprovecharse para ejecutar código.
CVE-2026-109619: información de una solicitud que sobrevive a la siguiente
La segunda vulnerabilidad involucra referencias a memoria que deberían dejar de utilizarse cuando termina una operación.
En determinados escenarios, el estado interno asociado con una solicitud permanece disponible después de que la memoria correspondiente fue liberada.
Si posteriormente otra solicitud es procesada por el mismo trabajador de PHP, puede intentar utilizar esa información obsoleta.
Este tipo de problema se conoce como use-after-free: el programa continúa utilizando una región de memoria después de haberla liberado.
Dependiendo de las condiciones, estos errores pueden permitir leer información sensible, alterar estructuras internas o llegar a ejecutar código.
Los investigadores demostraron que el riesgo no era meramente teórico.
El ataque puede comenzar antes de que se ejecute la aplicación
Uno de los aspectos más preocupantes del caso es que determinadas cadenas de explotación pueden activarse durante el procesamiento inicial de una solicitud HTTP.
Es decir, antes de que PHP comience a ejecutar el código de la aplicación.
Esto representa un problema especialmente importante para las organizaciones que concentran su estrategia defensiva en proteger aplicaciones web.
Un sitio puede contar con validaciones de entrada, controles de autenticación, consultas parametrizadas y otras buenas prácticas de desarrollo seguro, pero esas medidas no necesariamente impiden explotar una vulnerabilidad situada en una capa inferior.
El equipo de PHP identificó las instalaciones de Apache que utilizan mod_php como particularmente expuestas.
En esa configuración se demostró una cadena de explotación capaz de activarse sin autenticación y antes de que se ejecute el código de la aplicación.
Sin embargo, el riesgo no se limita a Apache.
También pueden verse afectados entornos que utilizan PHP-FPM, php-cgi, FrankenPHP y LiteSpeed, aunque la posibilidad de explotación depende de su configuración y de los mecanismos disponibles.
En el caso de PHP-FPM, los investigadores validaron escenarios de ejecución remota asociados con el ciclo de vida de las sesiones bajo determinadas condiciones.
La consecuencia es clara: no alcanza con actualizar WordPress, Drupal o Joomla. Es necesario corregir el propio intérprete PHP.
La función de carga de archivos que apareció en los exploits
Durante las primeras horas, buena parte de la investigación pública se concentró en un mecanismo denominado session.upload_progress.
Esta funcionalidad permite que PHP registre el progreso de las cargas de archivos realizadas mediante formularios HTTP.
Su propósito es legítimo: facilitar que una aplicación muestre al usuario cuánto falta para completar una transferencia.
Pero su implementación interactúa con componentes internos del sistema de sesiones y del procesamiento de solicitudes.
Los investigadores encontraron que determinadas secuencias podían activar condiciones anómalas relacionadas con la memoria.
Esto abrió la posibilidad de construir cadenas de explotación que combinaran el procesamiento de solicitudes especialmente preparadas con errores de administración de memoria.
La funcionalidad está disponible desde PHP 5.4 y, en numerosas configuraciones, se encuentra habilitada de manera predeterminada.
Sin embargo, no todos los mecanismos de explotación dependen exclusivamente de ella.
Por esa razón, desactivarla puede reducir determinadas superficies de ataque, pero no constituye una corrección completa.
De los rumores a las pruebas de concepto
A medida que avanzaba la emergencia comenzaron a aparecer herramientas que afirmaban explotar las dos vulnerabilidades.
Uno de los repositorios difundidos fue ikow/php2shell-poc, publicado en GitHub, que incluía supuestas cadenas de explotación y reglas de detección para tecnologías como Suricata, Sigma y ModSecurity.
También circuló una investigación publicada bajo el nombre PHP-UP-2026, que exploraba posibles errores de memoria asociados con el procesamiento de sesiones.
La proliferación de estas herramientas aumentó la presión sobre los equipos defensivos.
Pero también introdujo un problema adicional: no todas las pruebas de concepto eran funcionales.
En el caso de PHP-UP-2026, su propio autor corrigió posteriormente sus conclusiones y reconoció que una de las cadenas de explotación inicialmente propuestas era inválida.
La investigación identificó otra condición de uso de memoria liberada, pero no logró demostrar que ese mecanismo específico permitiera ejecutar código.
Recorded Future advirtió que la publicación de un repositorio que afirma explotar una vulnerabilidad no constituye, por sí sola, evidencia de que el ataque funcione.
Mientras tanto, investigadores vinculados con Calif difundieron demostraciones de ejecución de comandos en aplicaciones construidas sobre PHP, lo que reforzó las preocupaciones sobre la gravedad de las vulnerabilidades.
La distinción es importante: las fallas son reales y existen explotaciones demostradas, pero eso no implica que cualquier herramienta publicada durante la emergencia sea confiable.
Los ataques comenzaron antes de que existieran parches públicos
La situación se volvió especialmente delicada cuando comenzaron a aparecer reportes de actividad maliciosa.
El 21 de octubre, antes de la publicación de los parches, proveedores de seguridad ya estaban recibiendo información sobre posibles intentos de explotación.
Patchstack informó haber recibido reportes de incidentes activos de socios del sector de alojamiento web a las 07:34 UTC.
El director de tecnología de Cloudflare, Dane Knecht, también confirmó que la empresa observaba actividad temprana dirigida contra las vulnerabilidades.
Cloudflare desplegó reglas de protección para su firewall de aplicaciones web, disponibles incluso para clientes de planes gratuitos.
Sin embargo, estas medidas solamente cubrían los mecanismos de ataque conocidos.
La propia compañía advirtió que no debían interpretarse como una solución definitiva.
El problema es que un firewall de aplicaciones web puede identificar y bloquear determinadas solicitudes sospechosas, pero no elimina la vulnerabilidad presente en el intérprete.
Además, algunos mecanismos de explotación dependen de estados internos, errores de memoria y secuencias de procesamiento que no necesariamente pueden detectarse examinando una solicitud HTTP de manera aislada.
Por otra parte, observar tráfico de explotación no equivale automáticamente a demostrar que un servidor fue comprometido.
Hasta el momento, la información pública disponible no permite establecer cuántos ataques consiguieron ejecutar código exitosamente ni cuántas organizaciones resultaron comprometidas.
Lo que sí está documentado es que los intentos comenzaron antes de que las actualizaciones estuvieran disponibles.
Gobiernos y universidades optaron por desconectarse
Con los detalles técnicos circulando públicamente y sin parches disponibles durante varias horas, numerosas organizaciones tomaron una decisión extraordinaria: apagar preventivamente sus servicios.
En los Países Bajos, la situación afectó a organismos gubernamentales y servicios vinculados con administraciones locales.
Entre los sitios reportados temporalmente fuera de servicio estuvieron los del Parlamento neerlandés, el Centro Nacional de Ciberseguridad y la autoridad de protección de datos.
También se vieron afectados servicios asociados con NotuBiz, una plataforma utilizada por más de cien gobiernos locales para publicar información institucional.
Ciudades como Eindhoven, Breda y Den Bosch estuvieron entre las administraciones cuyos servicios experimentaron interrupciones.
En Finlandia, el proveedor estatal de servicios tecnológicos Valtori anunció la suspensión preventiva de servicios web de la administración central.
La decisión alcanzó también a otros organismos públicos del país.
Valtori aclaró que se trataba de una medida preventiva y no de una respuesta a un ataque confirmado.
Instituciones académicas adoptaron decisiones similares.
La Universidad de Viena suspendió temporalmente distintos servicios, incluyendo sitios web, correo electrónico y Moodle. También se reportaron interrupciones en la Universidad de Friburgo y en la institución finlandesa Haaga-Helia.
La emergencia alcanzó además a plataformas privadas.
4chan pasó temporalmente a modo de solo lectura mientras esperaba la actualización de seguridad. Something Awful suspendió sus foros y otros servicios, como Pinboard, Fur Affinity y explain xkcd, también registraron interrupciones preventivas.
La agencia Reuters documentó medidas semejantes en organismos e instituciones de Alemania, Francia, Bélgica, Países Bajos y otros países.
Se trató de una respuesta poco habitual por su escala.
En lugar de mantener los servicios disponibles mientras evaluaban posibles ataques, numerosas organizaciones decidieron interrumpirlos para evitar que una vulnerabilidad crítica pudiera convertirse en un incidente real.
PHP publica los parches de emergencia
Finalmente, el 21 de octubre de 2026, el equipo de PHP publicó las actualizaciones que corrigen ambas vulnerabilidades.
Las versiones oficiales que incorporan las correcciones son:
Rama de PHPVersión corregidaPHP 8.58.5.12PHP 8.48.4.27PHP 8.38.3.36PHP 8.28.2.35
Las versiones anteriores dentro de estas ramas deben actualizarse.
El proyecto también confirmó que PHP 8.1 y las ramas más antiguas ya no reciben mantenimiento regular.
Debido a la gravedad del incidente, el equipo publicó correcciones mínimas del código fuente para PHP 7.4, 8.0 y 8.1, destinadas a facilitar su aplicación en entornos que todavía dependen de esas versiones.
Esto no significa que esas ramas hayan recuperado soporte oficial.
Las organizaciones que utilizan versiones antiguas deben recurrir a proveedores que mantengan paquetes corregidos o planificar la migración hacia versiones compatibles.
También es importante considerar que algunas distribuciones Linux incorporan correcciones de seguridad mediante backports, sin modificar necesariamente el número principal de versión que muestra el intérprete.
Por eso, determinar si una instalación está protegida requiere consultar la información del proveedor y no solamente comprobar el número de versión.
Millones de instalaciones expuestas
La dimensión potencial de PHP2Shell se comprende mejor al observar la presencia de PHP en Internet.
Un análisis de VirusTotal identificó aproximadamente 5,1 millones de direcciones IP asociadas con servidores que utilizan PHP.
De ellas, solamente alrededor de 1,1 millones revelaban información suficiente para identificar la versión instalada.
Entre los servidores cuya versión podía determinarse, una proporción considerable utilizaba ramas que ya habían alcanzado el fin de su vida útil.
Otra investigación, realizada por Modat, identificó aproximadamente 4,38 millones de servicios PHP distribuidos en 1,89 millones de equipos únicos.
Los resultados no representan necesariamente servidores vulnerables confirmados, pero permiten dimensionar el problema.
Además, las cifras utilizan metodologías diferentes: algunas mediciones cuentan servicios, otras direcciones IP y otras instalaciones de paquetes.
No deben sumarse ni interpretarse como un número exacto de sistemas comprometidos.
El aspecto más preocupante es la presencia de instalaciones antiguas que ya no reciben actualizaciones regulares.
En estos entornos, una vulnerabilidad crítica puede permanecer explotable durante mucho tiempo después de que se publique su solución.
Qué deben hacer los administradores
Con las actualizaciones disponibles, la prioridad es identificar y corregir las instalaciones vulnerables.
El primer paso consiste en inventariar los entornos que ejecutan PHP, incluyendo servidores web, aplicaciones internas expuestas a Internet, contenedores e infraestructuras administradas por terceros.
Luego corresponde verificar las versiones utilizadas, consultar los avisos de seguridad del proveedor y aplicar los paquetes corregidos.
Las instalaciones con Apache y mod_php merecen especial atención por la existencia de una cadena de explotación particularmente directa.
Para los sistemas que no pueden actualizarse inmediatamente, las recomendaciones incluyen reducir temporalmente la superficie expuesta, restringir el acceso a servicios afectados y aplicar controles compensatorios.
Entre las medidas temporales se encuentra desactivar session.upload_progress.enabled, así como revisar los límites de procesamiento de solicitudes y cargas de archivos.
Sin embargo, algunas de estas medidas solamente afectan determinadas cadenas de explotación.
Bloquear completamente las solicitudes multipart/form-data puede reducir ciertos riesgos, pero también interrumpe funcionalidades legítimas, como la carga de documentos.
Ninguna de estas restricciones reemplaza la actualización.
Además de instalar los parches, las organizaciones deberían analizar los registros de actividad correspondientes al período previo a su disponibilidad.
Los intentos de explotación comenzaron antes de la publicación oficial de las correcciones, por lo que actualizar un servidor no descarta que haya sido atacado previamente.
Es recomendable investigar solicitudes HTTP anómalas, errores inesperados del intérprete, fallos de procesos PHP, actividades sospechosas originadas desde cuentas del servidor web y posibles cambios no autorizados.
Dado que algunos mecanismos actúan antes de que comience a ejecutarse la aplicación, los registros propios de WordPress, Drupal u otros sistemas podrían no contener evidencia suficiente.
La revisión debería incluir también los registros del servidor web, del sistema operativo y de las herramientas de detección disponibles.
Una vulnerabilidad en la infraestructura que sostiene la web
PHP2Shell muestra una característica particularmente incómoda de la seguridad informática moderna: una vulnerabilidad en un componente ampliamente utilizado puede afectar simultáneamente a organizaciones que no tienen ninguna relación entre sí.
Un parlamento europeo, una universidad, un portal de noticias y un foro de Internet pueden compartir una misma dependencia tecnológica.
Cuando esa dependencia presenta una vulnerabilidad crítica, todos quedan potencialmente expuestos.
En este caso, la respuesta llegó hasta el punto de que organismos públicos y servicios privados optaron por desaparecer temporalmente de Internet.
La filtración anticipada agravó la situación, reduciendo el margen de tiempo disponible para preparar las defensas y acelerando la circulación de información técnica sobre las vulnerabilidades.
Pero el problema de fondo no terminó con la publicación de los parches.
La cantidad de instalaciones antiguas de PHP, la dificultad para mantener inventarios completos y la dependencia de componentes compartidos seguirán condicionando la exposición de numerosas organizaciones.
La emergencia del 21 de octubre terminó con una actualización de seguridad. El riesgo, para quienes todavía no la aplicaron, continúa.