Saltar al contenido
Tecnologías emergentes en Latinoamérica y el mundoMiércoles 21 oct 2026

CiberseguridadVulnerabilidades

Gobiernos alertan por dos fallas críticas en PHP y una firma de seguridad espera ataques masivos apenas salga el parche

Japón, Australia y la Unión Europea piden prepararse para el parche de este miércoles a las 14:00 UTC. Sansec pronostica ataques en minutos y casi la mitad de los sitios con PHP usa versiones que no recibirán corrección.

Por Redacción LatamByte

Asistida por IA

Alerta crítica de PHP: las versiones 8.5, 8.4, 8.3 y 8.2 reciben parche; las 8.1, 8.0, 7 y 5 quedan sin parche oficial
Imagen: LatamByte

Japón, Australia y la Unión Europea pidieron a empresas, organismos y usuarios que se preparen para actualizar PHP, el lenguaje con el que funciona buena parte de los sitios de internet, por dos fallas críticas cuyos datos se filtraron antes de tiempo. El parche sale este miércoles 21 de octubre a las 14:00 UTC, que son las 11 en Buenos Aires, San Pablo y Santiago, las 10 en Caracas, las 9 en Bogotá y Lima, y las 8 en Ciudad de México. La empresa de seguridad Sansec espera ataques masivos dentro de los 15 minutos posteriores a su publicación.

El aviso del equipo de seguridad de PHP califica a las dos fallas con 9,2 sobre 10 en la escala CVSS 4.0 y no da más detalles. Según la empresa watchTowr, que dice haber reproducido una de ellas, permiten ejecutar código a distancia en el servidor, es decir, tomar el control del sitio.

Los avisos oficiales llegaron en pocas horas. La Oficina Nacional de Ciberseguridad de Japón pidió revisar si los sitios publicados usan PHP y aplicar el parche lo antes posible. La Dirección de Señales de Australia emitió una alerta de nivel crítico y advirtió que las fallas "pueden afectar a todas las versiones desde PHP 5". CERT-EU, el equipo de respuesta de las instituciones europeas, habló de ejecución remota de código sin autenticación y recomendó, si no se puede actualizar enseguida, aislar de internet las aplicaciones expuestas hasta que exista una solución.

Una filtración adelantó el reloj

Todo empezó el 20 de octubre con un mensaje en el foro Hacker News que anunciaba dos fallas de PHP con puntaje 10, presentes desde la versión 5, que se iban a revelar el jueves 22. Su autor admitió que no tenía más prueba que un "créanme", según el sitio especializado The Hacker News. Horas después, watchTowr confirmó que la información era real y que las fallas estaban bajo embargo, el acuerdo por el que investigadores y desarrolladores guardan silencio hasta que exista el parche. "Se suponía que todos íbamos a esperar hasta el jueves", escribió la empresa, citada por Huntress.

PHP publicó su aviso esa misma noche, a las 19:33 UTC, y adelantó la corrección un día. También se reservó el derecho de publicarla antes si aparecen los detalles técnicos o pruebas de ataques reales. LatamByte contó ese anuncio el mismo martes.

Lo confirmado y lo que circula

La filtración trajo la existencia de las fallas, un puntaje, una fecha y dos identificadores, CVE-2026-109618 y CVE-2026-109619. No trajo cómo funcionan. Desde entonces, buena parte de lo que circula en redes no tiene respaldo oficial.

El puntaje de 10 es el de la filtración, y lo repitieron watchTowr, según BleepingComputer, e investigadores como Florian Roth. PHP fija 9,2. Algunos medios de la región titularon "10 de 10". Que todas las versiones desde PHP 5 estén afectadas tampoco está confirmado, y el propio watchTowr aclara que ese alcance no figura en ningún aviso del fabricante. Los identificadores CVE que usan los investigadores salieron del mensaje filtrado, y el aviso de PHP no nombra ninguno. Las versiones sobre qué parte de PHP falla, como una que apunta al registro del progreso de las subidas de archivos, siguen siendo rumores.

Tampoco hay ataques confirmados. Huntress no vio explotación en los sistemas que vigila ni conoce código público para aprovechar las fallas, y watchTowr las lista sin explotación reportada al 21 de octubre.

Casi la mitad de los sitios con PHP queda afuera del parche

Cualquiera sea el alcance final, PHP solo corrige sus ramas con soporte, de la 8.2 a la 8.5. Todo lo anterior, incluidas las versiones 8.1, 8.0, 7 y 5, no recibirá parche del fabricante.

Esa frontera deja afuera a muchos. Según W3Techs, el 69 % de los sitios cuyo lenguaje se conoce usa PHP, y de esos, el 27 % sigue en PHP 7 y casi el 8 % en PHP 5. Si se suman las versiones 8.0 y 8.1, que también perdieron soporte, cerca de la mitad de los sitios con PHP corre versiones sin corrección, según un cálculo de LatamByte con los datos de W3Techs sobre PHP 8.

La empresa Mallory llegó a una cifra parecida por otro camino. Contó en el buscador Shodan unos 884.000 servidores expuestos a internet con PHP 8.1 o anterior, el 59 % de los que muestran su versión, y otros 740.000 que no la muestran.

Argentina, entre los países más expuestos

En Latinoamérica la proporción es más alta. En los quince países de la región con datos suficientes en el conteo de Mallory, el 72 % de los servidores que informan su versión usa ramas sin soporte, contra el 59 % del total mundial. Argentina aparece con el 88 %, unos 12.700 servidores, por encima de México (73 %) y Brasil (64 %). Bolivia (90 %) y Venezuela (84 %) también pasan el 80 %. En números absolutos, Brasil y México concentran la mayor cantidad de equipos, con casi 19.000 y unos 14.200.

Los conteos se basan en lo que cada servidor declara y no prueban que esté afectado. Al mismo tiempo, un servidor de alojamiento compartido puede tener muchos sitios, así que las páginas en riesgo pueden ser más que los equipos contados. Hasta la madrugada del miércoles, LatamByte no encontró avisos de los equipos nacionales de respuesta a incidentes de la región.

Actualizar apenas salga y vigilar después

El antecedente marca el ritmo. Cuando se conoció CVE-2024-4577, una falla de PHP en servidores Windows, en junio de 2024, Akamai registró intentos de ataque en menos de 24 horas, recuerda The Hacker News. Sansec, que protege tiendas en línea, habla de minutos y advierte que la defensa no puede venir del código del sitio, porque el ataque apunta a PHP mismo, antes de que corra la aplicación.

Los equipos de seguridad coinciden en los pasos. El primero es hacer ya el inventario de cada instalación de PHP, incluidas las que vienen dentro de paneles como cPanel o Plesk y de equipos de terceros. Después, actualizar apenas salga el parche, empezando por los servidores expuestos a internet, y revisar si la distribución de Linux o el proveedor de alojamiento ofrecen paquetes corregidos. En versiones sin soporte, la salida es migrar a una rama vigente o, mientras tanto, sacar el sistema de internet o ponerlo detrás de una VPN o de un firewall de aplicaciones web. Huntress recomienda además vigilar si los procesos de PHP lanzan intérpretes de comandos o herramientas de descarga, una señal típica de intrusión.

Con el parche, PHP tiene que publicar qué versiones están afectadas, qué parte del lenguaje falla y si el ataque exige alguna configuración especial. Hasta entonces, cada servidor sin actualizar corre contra el reloj.

Ficha técnica

Contexto (1 término)
catá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.

Glosario de LatamByte

Vulnerabilidades

Fuentes