Saltar al contenido
Tecnologías emergentes en Latinoamérica y el mundoViernes 23 oct 2026

Cobertura especialCaso PHP

CiberseguridadVulnerabilidades

PHP suma una tercera falla y Palo Alto fija fechas para corregir sus firewalls

La nueva vía de ataque es poco probable y se mitiga igual que las anteriores. Una botnet derivada de Mirai intenta usar PHP2Shell, pero nadie confirmó un servidor vulnerado.

Logo de PHP sobre una red de puntos y líneas rojas y blancas
Imagen: BleepingComputer

Al tercer día de PHP2Shell, las dos fallas críticas de PHP, los atacantes siguen probando y nadie mostró todavía un servidor tomado. El viernes 23 de octubre, PHP avisó de una tercera vía de ataque, Palo Alto puso fechas a la corrección de sus firewalls y una empresa de seguridad dijo tener un ataque que funciona en servidores reales, aunque solo lo comparte con sus clientes. LatamByte ya contó cómo respondieron las empresas y cuán expuesta está la región.

Una tercera falla, poco probable

El equipo de PHP publicó en su sitio un aviso informativo sobre CVE-2026-115560, otra falla que permite ejecutar código a distancia y que todavía no tiene parche. Solo aparece con una combinación rara de configuración y código. La aplicación tiene que cambiar en plena ejecución el formato en que guarda las sesiones de los usuarios, y además tener activa la función que informa el progreso de las subidas de archivos.

PHP la considera "poco probable en la práctica" y la va a corregir en la próxima versión regular, sin parche de emergencia. La medida que recomienda es apagar esa función con session.upload_progress.enabled=0, la misma que había sugerido el 21 de octubre para las dos primeras fallas. Quien ya la aplicó no tiene que hacer nada más. Las aplicaciones que nunca cambian ese formato pueden dejar la función encendida, según BleepingComputer.

Palo Alto pone fechas

Palo Alto Networks actualizó su aviso con fechas estimadas para las versiones corregidas de PAN-OS, el sistema de sus firewalls, y de Panorama, su consola de gestión. Las primeras llegarían el lunes 26 de octubre y las últimas el viernes 30, según la rama. Hasta ahora no publicó ninguna.

La falla afecta solo a la interfaz web de administración. El riesgo es mayor cuando esa interfaz se puede abrir desde internet, y la empresa recomienda restringirla a direcciones internas de confianza. Dos servicios en la nube que estaban afectados, Cortex XCORE y WildFire Cloud, ya se corrigieron el 21 y el 22 de octubre. GlobalProtect, la VPN de la marca, no está afectado. Palo Alto dice no conocer ataques contra sus productos.

Intentos, botnets y ningún éxito

La empresa de seguridad Sophos vio a atacantes que intentaban usar las fallas para instalar Potassium, probablemente una variante de Mirai, la familia de botnets que toma equipos para lanzar ataques de denegación de servicio. El intento fue bloqueado y la carga maliciosa no llegó a entregarse. A las 21:21 UTC del 22 de octubre, Sophos corrigió un aviso de cinco horas antes en el que había informado de ataques exitosos en clientes. "Tras un análisis más profundo, corregimos esa evaluación", escribió. Su telemetría muestra escaneos y unos pocos intentos fallidos, y "no hay evidencia de un compromiso exitoso". "La falta de ataques exitosos sugiere que los atacantes también tienen dificultades", dijo la empresa, según SecurityWeek.

La firma Hunt.io encontró el servidor de un atacante con sus archivos a la vista. Hizo 10 rondas contra hasta 123 servidores de nubes, alojamientos compartidos y proveedores de internet. Unos 57 corrían PHP, 10 rechazaron los pedidos y ninguno fue vulnerado. SOCRadar halló otro servidor con un ataque para PHP 8.4.26 que solo funciona en configuraciones de prueba, y su operador no logró entrar en ninguno de los sitios que revisó.

Sansec, que el día del parche había previsto ataques masivos, cambió su evaluación el 22 de octubre. Según su análisis, un ataque necesita conocer el servidor y que se den condiciones particulares, y los exploits públicos no funcionan contra una instalación de PHP con la configuración por defecto.

Las empresas que miran sitios reales coinciden. Wordfence, que protege más de 5 millones de sitios WordPress, interceptó más de 74.000 intentos de ataque o sondeo y dijo el 22 de octubre a las 22:24 UTC que no observó ningún compromiso confirmado, lo que muestra "la complejidad del exploit". Dataminr informó a las 19:13 UTC del mismo día que la actividad se limita a escaneos, identificación de sistemas y exploits que no funcionan, aunque advirtió que "es solo cuestión de tiempo" que aparezcan pruebas que funcionen o ataques exitosos.

El exploit que sí funciona

La excepción es VulnCheck. La empresa dice tener un exploit que logra ejecutar código en servidores x86-64 con la configuración recomendada para producción, es decir, con ASLR activo (la protección que cambia de lugar los datos en la memoria) y sin mostrar errores en pantalla. Funciona en PHP 8.4.10 a 8.4.26 y solo lo reciben sus clientes. "No conocemos otro exploit público o comercial que lo logre en varias versiones de PHP", dijo VulnCheck, que espera que eso cambie.

De los cientos de pruebas de ataque publicadas en GitHub, muy pocas son legítimas, según la misma empresa. Una evade ASLR, pero solo en PHP 8.4.26 y con la configuración de memoria por defecto.

Pocos parches en los primeros días

La empresa Qualys analizó datos anónimos de 12.000 de sus clientes y encontró 167 millones de instalaciones de paquetes PHP, el 73 % en equipos expuestos a internet. Unos 110 millones, el 71 % de las que tienen versión conocida, usan ramas de la 5.4 a la 8.1, que ya no tienen soporte. Otros 44 millones están en ramas con corrección disponible, pero sin aplicarla, y solo 199.000 se corrigieron en las primeras 12 horas. Las cifras corresponden a los clientes de Qualys, no al total de internet.

Sin alta en el catálogo de la CISA

Ninguna de las dos fallas figura en el catálogo de vulnerabilidades explotadas de la CISA, la agencia de ciberseguridad de Estados Unidos, que suma una falla cuando hay pruebas de ataques reales. La última alta del catálogo es del 20 de octubre.

Qué hacer

  • Actualizar a PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o al paquete corregido de la distribución.
  • Mantener o aplicar session.upload_progress.enabled=0 hasta la próxima versión.
  • Con firewalls de Palo Alto, cerrar a internet la interfaz de administración y seguir el aviso hasta que salga la versión corregida de cada rama.

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