Las fallas de PHP suman intentos de ataque sin intrusiones probadas

Diez horas después del parche de PHP, los sensores de las empresas de seguridad registran intentos de ataque contra sus dos fallas críticas, pero nadie mostró todavía un servidor real tomado. A las 23:43 UTC, que son las 20:43 en Buenos Aires, San Pablo y Santiago, las 19:43 en Caracas, las 18:43 en Bogotá y Lima y las 17:43 en Ciudad de México, CVE-2026-109618 y CVE-2026-109619 seguían fuera del catálogo de fallas explotadas de la agencia de ciberseguridad de Estados Unidos (CISA).

LatamByte ya contó la filtración y las alertas de los gobiernos y la salida del parche.

Intentos en los señuelos, ninguna intrusión probada

La señal más concreta la registró la empresa VulnCheck. A las 17:22 UTC, desde una red de China, alguien intentó plantar un programa de control remoto en sus servidores trampa a través del registro de progreso de subidas de PHP. Las diez peticiones con que quiso activarlo fallaron.

La firma Hadrian dijo a las 11:35 UTC que veía las fallas "explotadas a escala", según SecurityWeek, y watchTowr las marca como explotadas por lo que recibe su red de señuelos. Pero su jefe de inteligencia, Jake Knott, aclaró que "nadie tuvo éxito hasta ahora" y que no espera "que eso dure mucho".

Quienes miran servidores reales no vieron ataques consumados. Huntress no detectó explotación en sus clientes hasta las 20:30 UTC. La CISA dijo en su alerta del miércoles que no la observó, y el centro de ciberseguridad de Países Bajos informó a las 21:04 UTC que tampoco, aunque notó más tráfico de búsqueda de sitios vulnerables, según el liveblog de Hart van Nederland.

El estado a esta hora es de intentos reportados y escaneo masivo, sin intrusiones confirmadas. Un señuelo que recibe una petición maliciosa cuenta un intento, y nadie publicó un servidor real comprometido. Según VulnCheck, ninguna de las decenas de pruebas de ataque publicadas logra saltear ASLR, la protección que reordena la memoria, en los servidores más comunes.

Un parche que todavía casi no se ve

Mallory, que cuenta servidores con el buscador Shodan, encontró 312 servicios con versiones corregidas tres horas y media después del parche, sobre unos 610.000 en ramas con soporte. Es el 0,05 %. No cuenta los arreglos de las distribuciones, que mantienen el número de versión, pero tampoco hay datos públicos de una actualización masiva.

CloudLinux, sistema de muchos servidores con el panel cPanel, confirmó a las 21:45 UTC que los paquetes de PHP de cPanel, de la 5.2 a la 8.5, ya estaban corregidos. Otros de sus paquetes seguían pendientes a las 23:00 UTC, y la empresa tuvo que desmentir un aviso propio que los daba por disponibles.

Tres de cada cuatro servidores, fuera del parche oficial

Mallory corrigió el miércoles su conteo del día anterior. Con el método nuevo, el 73,5 % de los servicios que muestran su versión de PHP, unos 1,9 millones, usa la 8.1 o una anterior, y no el 59 % publicado antes. VulnCheck llega a una proporción parecida con datos propios.

Para PHP 5 y las 7 anteriores a la 7.4, más de 700.000 equipos según VulnCheck, no hay nada del fabricante. Si no hay arreglo, la CISA recomienda sacar de línea esos sistemas.

Latinoamérica, más expuesta y con menos avisos

Según el conteo corregido de Mallory, hecho entre las 16:04 y las 16:22 UTC, en Argentina el 90 % de los servicios que muestran su versión, unos 21.000, usa ramas sin soporte. Siguen Perú (81 %), México (79 %), Brasil (78 %), Colombia (77 %) y Chile (76 %). Las cifras que LatamByte publicó antes, 88 % para Argentina, 73 % para México y 64 % para Brasil, venían del conteo que Mallory después corrigió.

• 75 a 80 %
• 80 a 85 %
• 85 a 90 %
• 90 a 95 %
• 95 a 100 %
• Sin datos
• Mundo: 73,5 %

Fuente de la métrica: Mallory. Medición: 2026-10-21 16:04 a 16:22 UTC.Corte: 22 oct 2026, 00:50 UTC. Referencia mundial: 73,5 %.Países en gris: sin datos.

PHP sin parche oficial en Latinoamérica: datos por país

País	Sin soporte oficial	Servicios	Aviso del CERT	Incidentes	Detalle y fuentes
Venezuela	99 %	1.059	Sin aviso	Ninguno informado	1.059 de 1.073 servicios que muestran versión usan PHP 8.1 o anterior, según Mallory. El sitio de VenCERT no respondió. Mallory
Paraguay	97 %	1.277	CERT-PY, 21 oct 2026	Ninguno informado	1.277 de 1.321 servicios que muestran versión usan PHP 8.1 o anterior, según Mallory. El sitio del CERT-PY rechazaba conexiones a las 00:46 UTC del 22/10. Mallory, CERT-PY
Ecuador	96 %	1.950	EcuCERT (alerta AL-2026-056), 21 oct 2026	Ninguno informado	1.950 de 2.039 servicios que muestran versión usan PHP 8.1 o anterior, según Mallory. Mallory, EcuCERT
Bolivia	95 %	1.647	Centro de Gestión de Incidentes Informáticos (CGII), 21 oct 2026, 12:58 UTC	Ninguno informado	1.647 de 1.737 servicios que muestran versión usan PHP 8.1 o anterior, según Mallory. El CGII publicó su alerta a las 08:58 de Bolivia, antes del parche. Mallory, CGII
Argentina	90 %	21.134	Sin aviso	Ninguno informado	21.134 de 23.446 servicios que muestran versión usan PHP 8.1 o anterior, según Mallory. CERT.ar no publicó aviso. Mallory
Perú	81 %	3.091	Sin aviso	Ninguno informado	3.091 de 3.796 servicios que muestran versión usan PHP 8.1 o anterior, según Mallory. La PCM no publicó aviso. Mallory
México	79 %	23.656	Sin aviso	Ninguno informado	23.656 de 29.996 servicios que muestran versión usan PHP 8.1 o anterior, según Mallory. El CERT-MX no publicó aviso. Mallory
Brasil	78 %	43.054	CTIR Gov (Recomendación Técnica 19/2026), 21 oct 2026, 15:28 UTC	Ninguno informado	Anatel cortó el acceso externo a su sistema SEI y la Justicia Federal de la 4.ª Región hizo lo mismo con sus plataformas desde las 11:00 de Brasilia (14:00 UTC), como medida preventiva y sin intrusiones confirmadas. La recomendación del CTIR Gov es de acceso restringido; CERT.br no publicó aviso. Mallory, Canaltech, Antihype
Colombia	77 %	4.419	ColCERT (alerta AL-20261021-123), 21 oct 2026	Ninguno informado	ColCERT contó 8.699 servicios con PHP expuestos en el país, el 88 % en redes de proveedores de internet, y MuchoHacker.LOL halló unos 170 servidores .gov.co con PHP: en una muestra no aleatoria de 19, 18 usaban ramas sin soporte. Mallory, ColCERT, MuchoHacker.LOL, Impacto TIC
Chile	76 %	4.546	Sin aviso	Ninguno informado	4.546 de 5.963 servicios que muestran versión usan PHP 8.1 o anterior, según Mallory. El sitio del CSIRT de Gobierno rechazó las consultas (error 403). Mallory
Costa Rica	Sin datos	Sin datos	MICITT y CSIRT-CR, 20 oct 2026	Ninguno informado	El MICITT pidió a todas las instituciones públicas actualizar PHP; el aviso no está publicado en línea y lo informó Delfino.cr. Mallory no publica porcentaje: solo 308 servicios muestran su versión de PHP (su mínimo es 1.000). Mallory, Delfino.cr
Cuba	Sin datos	Sin datos	Sin aviso	Ninguno informado	Mallory no publica porcentaje: solo 2 servicios muestran su versión de PHP (su mínimo es 1.000). Mallory
El Salvador	Sin datos	Sin datos	Sin aviso	Ninguno informado	Mallory no publica porcentaje: solo 37 servicios muestran su versión de PHP (su mínimo es 1.000). Mallory
Guatemala	Sin datos	Sin datos	Sin aviso	Ninguno informado	Mallory no publica porcentaje: solo 104 servicios muestran su versión de PHP (su mínimo es 1.000). El sitio del CSIRT-GT no respondió. Mallory
Honduras	Sin datos	Sin datos	Sin aviso	Ninguno informado	Mallory no publica porcentaje: solo 82 servicios muestran su versión de PHP (su mínimo es 1.000). El sitio del CERT de Honduras no respondió. Mallory
Nicaragua	Sin datos	Sin datos	Sin aviso	Ninguno informado	Mallory no publica porcentaje: solo 63 servicios muestran su versión de PHP (su mínimo es 1.000). Mallory
Panamá	Sin datos	Sin datos	Sin aviso	Ninguno informado	Mallory no publica porcentaje: solo 74 servicios muestran su versión de PHP (su mínimo es 1.000). El sitio del CSIRT Panamá no respondió. Mallory
Puerto Rico	Sin datos	Sin datos	Sin aviso	Ninguno informado	Mallory no publica porcentaje: solo 62 servicios muestran su versión de PHP (su mínimo es 1.000). Mallory
República Dominicana	Sin datos	Sin datos	Sin aviso	Ninguno informado	Mallory no publica porcentaje: solo 255 servicios muestran su versión de PHP (su mínimo es 1.000). El CNCS no publicó aviso. Mallory
Uruguay	Sin datos	Sin datos	Sin aviso	Ninguno informado	Mallory no publica porcentaje: solo 189 servicios muestran su versión de PHP (su mínimo es 1.000). El sitio de CERTuy estaba en mantenimiento (error 503). Mallory

El medio colombiano MuchoHacker.LOL encontró unos 170 servidores con dominios .gov.co que anuncian PHP. En una muestra de 19, no aleatoria, 18 usaban ramas sin soporte y el único en la 8.2 no tenía el parche.

El Equipo de Respuesta a Emergencias Cibernéticas de Colombia (ColCERT) publicó una alerta crítica y el de Paraguay, CERT-PY, un aviso. A las 23:30 UTC, LatamByte no encontró avisos de CERT.br ni del CERT de México, y los sitios de CSIRT de Chile y CERT.uy no respondieron. No hubo reportes públicos de ataques en la región.

Europa apagó sitios por precaución. En Países Bajos salieron de línea DigiD, la identidad digitalConjunto de datos y credenciales que permiten a una persona demostrar quién es en servicios en línea, por ejemplo para iniciar sesión, consultar registros o hacer trámites con validez ante un organismo. del Estado, el portal MijnOverheid y las webs del Parlamento y del propio centro de ciberseguridad, que volvieron entre las 17:18 y las 19:58 UTC, según Hart van Nederland. En Finlandia, el centro de informática estatal Valtori empezó a cortar servicios cerca de las 10:00 UTC, informó Yle. En ambos países, las autoridades dijeron no tener señales de explotación.

La IA encontró las fallas y la filtración adelantó el reloj

Calif, con un modelo de OpenAI, y Wiz, con modelos de Google y OpenAI, hallaron las fallas por separado en agosto. Según SecurityWeek, Calif dice que un primer error se había detectado en 2020 y otra vez en 2024, pero no se corrigió porque nadie había probado que fuera explotable.

"Esto cambia la economía tanto del hallazgo como de la explotación", escribieron los investigadores de Wiz, citados por CyberScoop. OpenAI sostuvo que la IA encontró las fallas antes que los atacantes y abrió una "ventana del defensor". Esa ventana se achicó cuando los identificadores se filtraron el martes y circuló un video de la demostración, lo que obligó a adelantar el parche un día. Kelly Shortridge, de Fastly, calcula que la explotación masiva suele llegar "de horas a unos pocos días" después.

Seis conclusiones a las 23:45 UTC

Primera. Los ataques empezaron, pero ningún reporte público muestra un servidor comprometido. Que el primer intento documentado fallara y que las pruebas públicas no salteen la protección de memoria indica que explotar las fallas no es trivial en todas las configuraciones. Puede cambiar en horas.

Segunda. No se sabe cuántos servidores ya se actualizaron. El único conteo público ve un 0,05 % y no detecta los arreglos de las distribuciones, así que el tamaño real del problema sigue siendo una estimación.

Tercera. El riesgo se concentra en las ramas viejas, y Latinoamérica tiene más que el promedio mundial. Con nueve de cada diez servidores argentinos fuera de soporte, la solución depende de los proveedores, no del parche de PHP.

Cuarta. Lo que hay que hacer depende de la rama. En la 8.2 a la 8.5, instalar 8.5.12, 8.4.27, 8.3.36 o 8.2.35, o el paquete de la distribución, reiniciar Apache o PHP-FPM y comprobar la versión en una página del sitio, no en la línea de comandos, como indica Sansec. En la 8.1 o anteriores, conseguir el arreglo de la distribución o de soporte extendido, y si no existe, migrar o desconectar. En alojamiento compartido, pedirle al proveedor la versión corregida y la confirmación de los CVE.

Quinta. Sin acceso al servidor, el sitio no se arregla desde adentro. Los modos de mantenimiento de WordPress o Magento no protegen, porque PHP procesa la petición antes que la aplicación, advierte Sansec. Un firewall de aplicaciones web reduce el riesgo, pero no reemplaza el parche.

Sexta. Actualizar no borra lo que pudo pasar antes. "Un parche cierra la brecha, pero no deshace una intrusión anterior", dijo el hacker ético Wouter van Dongen a Hart van Nederland. Una de las fallas, además, puede filtrar memoria con contraseñas y claves, según Sansec. Quien tuvo PHP expuesto desde el martes debe revisar si sus procesos lanzaron intérpretes de comandos o herramientas de descarga, como pide la CISA, y evaluar cambiar las claves del servidor.

Ficha técnica

• CVSS: 9,2 (CVSS 4.0) según PHP; Red Hat asigna 8,1 (CVSS 3.1) a la primera
• Estado: intentos reportados; sin intrusiones confirmadas; fuera del KEVcatálogo de vulnerabilidades explotadas conocidas (KEV) Lista pública de la Agencia de Ciberseguridad y Seguridad de Infraestructura de Estados Unidos (CISA) que reúne vulnerabilidades con evidencia de explotación activa, para que se prioricen al corregir. a las 23:43 UTC
• Corregidas: 8.5.12, 8.4.27, 8.3.36 y 8.2.35; sin versión oficial para 8.1 y anteriores
• Exposición: 73,5 % en 8.1 o anterior; 90 % en Argentina (Mallory)