Cuando estalló PHP2Shell, un gobierno del G7 pidió a Red Sift todos los hosts expuestos de su infraestructura nacional, y recibió la lista con cada host vinculado al departamento responsable.
Dos fallos críticos en PHP ponen en riesgo todas las versiones desde PHP 5. Los gobiernos de todo el mundo se hacían la misma pregunta: ¿dónde ejecutamos PHP? La mayoría recurrió al botón de apagado. Uno nos lo preguntó a nosotros y obtuvo la respuesta para toda su infraestructura nacional antes de que se publicaran los parches.
Son los mejores datos que hemos visto.
El equipo de PHP anuncia con un día de antelación una corrección de emergencia. Los identificadores CVE aparecen en internet esa misma tarde, y CERT-EU publica un aviso antes de que exista ningún parche. Los honeypots de Amazon ya habían registrado un sondeo contra los fallos tres días antes.
Para quien gestiona infraestructura gubernamental, el problema es inmediato. Todas las versiones desde PHP 5 pueden estar afectadas. Filtrar por versión no sirve de nada. El único punto de partida seguro es una lista completa de todos los hosts expuestos a internet que ejecutan PHP, en cualquier versión y en cualquier parte de la infraestructura.
Ni una muestra ni un solo departamento. Todos los departamentos y organismos de los que es responsable el gobierno, con cada host identificado por su nombre. Elaborar esa lista a mano implica rastrear inventarios de activos, cuentas en la nube, proveedores y dispositivos que integran PHP sin indicarlo. Son semanas de trabajo, y la ventana de parcheo se abre la tarde siguiente.
Red Sift Hardenize, nuestra solución de gestión de la superficie de ataque (ASM), detecta y supervisa de forma continua los servidores expuestos a internet y registra el software que ejecuta cada uno. El inventario que necesitaba el gobierno ya existía. Lo consultamos, vinculamos cada host PHP al departamento responsable y entregamos la lista de toda la infraestructura en una sola vista, antes de que se publicaran las versiones corregidas a las 13:30 UTC del 21 de octubre.
El mismo análisis se ejecutó para todos los clientes de ASM. Todos los directamente afectados recibieron sus propios nombres de host, la hora de publicación y los avisos oficiales antes del parche.
Otros proveedores nos dicen que es imposible obtener el nivel de datos que Red Sift puede ofrecer.
El parche lleva minutos. Encontrar todos los hosts que lo necesitan puede llevar semanas. Los gobiernos que actuaron más rápido ya tenían la lista.
Un gobierno lo pidió. Todos los clientes de Red Sift ASM afectados recibieron lo mismo: una lista nominal de sus hosts PHP, antes de que saliera la corrección el 21 de octubre. Después medimos lo que hicieron con ella, cada día durante cinco días.
PHP CVE-2026-109618 / 109619 · 21–26 oct. 2026
10.114
servidores vulnerables conocidos menos entre los clientes en cinco días.
Un descenso del 62 %, de 16.203 a 6.089. Las organizaciones cliente con algún servidor vulnerable conocido pasaron de 443 a 254.
Todos los clientes afectados tenían su lista nominal de hosts antes de que saliera la corrección.
redsift.comFuente: análisis diarios de Red Sift de los servidores de clientes expuestos a internet; variación neta, 21 frente a 26 oct. 2026.
El 26 de octubre, 4.909 de los 6.089 servidores de clientes que seguían expuestos ejecutaban PHP 8.1 o anterior. No existe ninguna versión oficial de PHP que instalar para esas versiones, así que necesitan un backport del proveedor o una actualización. Ahí está ahora el trabajo, y empieza con la misma pregunta que el primer día: ¿cuáles de sus servidores son?
¿Podría obtener hoy esta vista de sus propios servidores? Si la respuesta no está clara, le enviaremos una instantánea externa puntual de su dominio.
Alcance: hosts expuestos a internet en los que se detectó PHP, en las instancias de clientes de Red Sift ASM (Hardenize), comparados a diario del 21 al 26 de octubre de 2026. Se excluyen las instancias de demostración, sandbox e investigación. Las organizaciones corresponden a instancias de cliente.
Parcheado significa que el host indica 8.5.12, 8.4.27, 8.3.36, 8.2.35 o una versión posterior de la misma rama; un host que indica varias versiones solo cuenta si todas están corregidas. Vulnerable conocido significa que indica una versión sin corregir en cualquier rama. Los hosts con 8.1 o anterior pueden tener ya un backport que no es visible desde fuera.
Las variaciones son netas: un servidor sale del recuento cuando se parchea, se actualiza, se da de baja o deja de indicar su versión. Unos 9.185 hosts de clientes no mostraban ninguna versión el 26 de octubre y no se cuentan en ningún sentido. Todas las versiones desde PHP 5 están afectadas, así que trátelos como potencialmente expuestos.
Nuestra solución de gestión de la superficie de ataque (ASM) detecta y supervisa de forma continua sus servidores expuestos a internet y registra el software que ejecuta cada uno. Cuando aparece un fallo como este, la primera pregunta deja de ser «¿por dónde empezamos?» y pasa a ser «aquí está la lista».
Antes de que el equipo de PHP publicara las correcciones, analizamos todos los hosts que supervisamos en toda nuestra base de clientes de ASM para encontrar los que ejecutaban PHP.
Vinculamos cada host afectado con el cliente, departamento u organismo responsable, para que cada aviso se refiriera a una sola infraestructura.
Todos los directamente afectados recibieron los nombres de los hosts que podían estar expuestos, la hora de publicación y enlaces a los avisos oficiales, antes de que se publicaran las versiones corregidas.
Aviso al cliente · 21 de octubre de 2026 · antes de la versión de seguridad de PHP
Hora de publicación anunciada: 21 oct., 14:00 UTC. Versiones corregidas: 8.5.12 · 8.4.27 · 8.3.36 · 8.2.35. Parchee primero los hosts expuestos a internet y reinicie todos los procesos worker.
Los nombres de host son ejemplos. Los avisos reales incluyen los hosts del propio cliente.
El análisis externo ve lo que revela cada host y cubre los activos de su cuenta. Los sistemas internos, los hosts fuera del ámbito supervisado y los productos que ocultan su entorno de ejecución PHP debe revisarlos usted.
Si es cliente de Red Sift ASM y no recibió ninguna notificación, no encontramos PHP en los hosts que supervisamos para usted. Aun así, le recomendamos hacer comprobaciones básicas por su parte.
El valor está en la precisión: hosts identificados, en su infraestructura, antes de que se abra la ventana de parcheo.
Sea cual sea su punto de partida, el primer paso es el mismo: conocer cada host expuesto a internet que posee y lo que ejecuta. Así podemos ayudarle, según su situación.
Ya ha recibido nuestra información preliminar: los hosts que supervisamos para usted que ejecutan PHP, con el calendario de publicación y los avisos. Estamos dispuestos a ir más allá con usted en toda su infraestructura, incluido el ámbito que aún no ha añadido, y a ayudarle a priorizar la larga cola de hosts que no se pueden parchear rápidamente.
Si es un gobierno nacional o un organismo del sector público y aún no utiliza nuestra gestión de la superficie de ataque, hable con nosotros. Ya elaboramos listas de exposición de infraestructuras completas a escala nacional, con cada host identificado, y esos datos se están comparando con lo que pueden ofrecer otros proveedores.
PHP impulsa la mayor parte de la web, está integrado en productos que usted no ha creado y el ataque se produce antes de que su aplicación lo vea. Si hoy no puede decir cuántos hosts PHP expuestos a internet tiene, ese es el primer problema que debe resolver, y podemos ayudarle con él esta misma semana.
Basadas en el aviso de seguridad de PHP, la alerta del NCSC del Reino Unido y nuestro propio artículo técnico.
Empiece por los hosts expuestos a internet. No filtre por versión. Incluya contenedores, imágenes base y todo lo compilado desde el código fuente.
8.5.12, 8.4.27, 8.3.36 u 8.2.35, o el paquete parcheado de su distribución. Para 8.1 y anteriores, use un backport del proveedor o actualice.
Un binario parcheado no sirve de nada para los pools de FPM ni para los procesos hijo de Apache que siguen ejecutando el código antiguo.
Establezca memory_limit=-1 a nivel administrativo, reduzca post_max_size, establezca session.upload_progress.enabled=0 y, en 8.5, fatal_error_backtraces=0. Vuelva a reiniciar los procesos worker. Estas medidas bloquean las vías de ataque confirmadas y deben considerarse una solución puente hasta aplicar el parche.
CERT-EU y el NCSC recomiendan desconectar cualquier aplicación expuesta a internet hasta que esté corregida.
Busque indicios de compromiso en todo lo que no haya podido actualizar rápidamente y lea los avisos de los proveedores de productos que integran PHP.
PHP2Shell es el nombre que reciben CVE-2026-109618 y CVE-2026-109619, dos fallos de ejecución remota de código sin autenticación en el motor central de PHP. Se encuentran en el código que se ejecuta cuando un proceso worker se queda sin memoria o sufre un error fatal, por lo que no dependen de la aplicación que funciona por encima. WordPress, Drupal, Laravel, las aplicaciones a medida y las consolas de dispositivos están todos afectados.
Cualquier instalación de PHP que atienda peticiones web puede estar afectada, ya sea con PHP-FPM, Apache mod_php, php-cgi, FrankenPHP o LiteSpeed. mod_php es el caso de mayor riesgo, porque el exploit demostrado se activa durante el análisis de la petición, antes de que pueda detectarlo una regla de firewall de aplicaciones web vinculada a las rutas de la aplicación.
Hay correcciones compiladas para cuatro ramas. Las ramas más antiguas recibieron solo backports en código fuente o nada. Un tercer problema relacionado, CVE-2026-115560, se divulgó el 23 de octubre y queda cubierto por la mitigación existente.
| Rama | Corregido en | Estado |
|---|---|---|
| 8.5 | 8.5.12 | Con soporte |
| 8.4 | 8.4.27 | Con soporte |
| 8.3 | 8.3.36 | Solo correcciones de seguridad |
| 8.2 | 8.2.35 | Fin de vida: 31 dic. 2026 |
| 8.1 · 8.0 · 7.4 | Solo backports en código fuente | Sin versión compilada. Backport del proveedor o actualización. |
| 7.3 y anteriores | Ninguna | Incluye PHP 5. Actualice. |
Versiones corregidas publicadas el 21 de octubre de 2026 a las 13:30 UTC. Fuente: php.net y avisos de seguridad de GitHub.
Los dispositivos y las consolas lo integran. Palo Alto Networks, Fortinet y Cisco ya estaban evaluando sus productos en cuestión de horas.
Todas las versiones desde PHP 5 pueden estar afectadas. Primera medida del NCSC: identificar todos los sistemas que ejecutan cualquier versión.
En torno al 42 % de los hosts PHP expuestos a internet ejecutan ramas al final de su vida útil sin corrección compilada (VulnCheck).
Un binario parcheado no sirve de nada para los pools de FPM ni para los procesos hijo de Apache hasta que se reinician todos los procesos worker.
En 48 horas, agencias nacionales de ciberseguridad de cuatro continentes pidieron a las organizaciones que parchearan de inmediato o desconectaran sus sistemas. Varios gobiernos retiraron primero sus propios servicios públicos, porque aún no podían saber cuáles estaban expuestos.
Alerta del NCSC y más de 50.000 avisos directos. Identifique todos los sistemas PHP, parchéelos o valore desconectarlos. Según informó el ministro al Parlamento el 22 de octubre, 32 servicios gubernamentales dejaron de estar disponibles y cuatro lo estuvieron parcialmente, en su mayoría por precaución. La supervisión básica de los dominios del sector público que realiza la Government Cyber Unit utiliza Hardenize, la herramienta de gestión de la superficie de ataque de Red Sift, que analiza .gov.uk cada ocho horas.
Servicios gubernamentales desconectados por recomendación del NCSC-NL, entre ellos DigiD y el sitio web del Parlamento. El NCSC-NL mantiene el inventario público de productos que integran PHP.
Todos los servicios web públicos del gobierno, cerrados por Valtori, la agencia estatal de TI, mientras se aplicaban los parches.
El primer ministro instó a los responsables de sitios web a prepararse y a valorar su desconexión. El Ministerio de Finanzas, la Agencia Meteorológica y la Agencia Tributaria Nacional suspendieron servicios. JPCERT publicó indicadores de compromiso.
Advertencia crítica del BSI. El centro federal de TI, ITZBund, desconectó los sitios web federales como medida puramente preventiva.
Alerta del CERT-FR: aislar los sistemas afectados. El Ministerio del Interior desconectó los sitios web de las prefecturas.
CISA y NSA: parchee ya o desconecte el sistema. La NSA afirmó que es probable que actores cibernéticos conviertan los fallos en armas y pidió parchear de inmediato en todos los departamentos y agencias del gobierno de EE. UU.
Aviso 2026-018 de CERT-EU antes de los parches, seguido de una declaración conjunta de la Comisión, ENISA, CERT-EU y Europol.
Alerta AL26-026 del Cyber Centre. Algunos sitios web del Gobierno de Canadá no estuvieron disponibles temporalmente; la alerta se actualizó el 23 de octubre para incluir el tercer CVE.
Alerta crítica del ACSC: actúe ya. Identifique los sistemas PHP, vigile la actividad maliciosa y aplique los parches a medida que se publiquen.
Desconectar un servicio es el último recurso, y gobiernos de cuatro continentes recurrieron a él en cuestión de horas. Esa es la magnitud del problema del inventario, incluso para equipos con muchos recursos.
La gestión de la superficie de ataque de Red Sift identifica cada host expuesto a internet de su infraestructura y lo que ejecuta, para que la próxima vulnerabilidad crítica llegue con la respuesta ya preparada.
Todo el contenido de esta página procede de fuentes públicas a fecha de 23 de octubre de 2026, salvo los resultados de la sección 02, que proceden de datos de clientes de Red Sift ASM hasta el 26 de octubre de 2026. El estado de explotación y las cifras de exposición cambian cada hora; consulte los avisos originales antes de actuar en función de una cifra.