El 20 de octubre se filtraron en Internet detalles sobre dos fallos críticos en PHP antes de que estuvieran listas las correcciones. PHP, el lenguaje de scripting que sustenta una gran parte de la web, adelantó un día el lanzamiento de su parche y lo publicó el 21 de octubre. Las vulnerabilidades, CVE-2026-109618 y CVE-2026-109619 (apodadas «php2shell»), permitían a un atacante ejecutar comandos en un servidor web a través del propio PHP, sin necesidad de iniciar sesión.
Actualiza ya. Ese consejo es acertado, pero deja un vacío. Esta entrada trata sobre ese vacío.
Los atacantes ya estaban probando la vulnerabilidad antes de que existiera la solución.
Ya se han publicado parches para las versiones de PHP 8.2 a 8.5, y PHP ha anunciado que las versiones 8.1 y anteriores no recibirán actualizaciones. Según una estimación, aún hay unos 884 000 servidores de este tipo en funcionamiento, una cifra aproximada procedente de una única fuente.
Los «honeypots» de Amazon ( servidores señuelo creados para atraer a los atacantes) registraron el primer intento el 17 de octubre, cuatro días antes de que se hiciera pública la información, y el 21 de octubre Amazon ya describía las vulnerabilidades como ampliamente explotadas. Cloudflare detectó los primeros ataques, y el Centro Nacional de Ciberseguridad del Reino Unido advirtió a las organizaciones que actualizaran sus sistemas de inmediato o los desconectaran. Aún no está claro cuántos servidores reales fueron comprometidos. Amazon afirma que desconoce si los intentos que detectó habrían funcionado fuera de un «honeypot».
Todos los fallos llevan ya un tiempo a la vista antes de que alguien los dé a conocer.
Una vulnerabilidad se convierte en noticia el día en que se anuncia, no el día en que aparece. Los propios responsables del mantenimiento de PHP detectaron por primera vez indicios de este problema en una auditoría realizada en 2024, y los atacantes lo aprovecharon antes que el público.
Ya hemos visto este patrón antes. Cuando se produjo el incidente de Log4j en diciembre de 2021, Vectra señaló que el primer indicio de un ataque era difícil de detectar y que lo más prudente era dar por hecho que al menos un servidor del entorno ya había sido comprometido. Es muy probable que otras vulnerabilidades del software que utiliza tu empresa se encuentren hoy en la misma situación: alguien las conoce, pero no se han hecho públicas. La aplicación de parches se ocupa de aquellas de las que te enteras. No sirve de nada para el resto.
Los servidores PHP que echas de menos son los más importantes
PHP ejecuta sitios web de WordPress, Drupal, Joomla y Magento, paneles de control de alojamiento y un montón de software que ni siquiera menciona a PHP. A los servidores que conoces se les aplicarán parches. Los que no conoces son los que los atacantes encuentran primero, porque nadie los vigila.
Ningún equipo soluciona todos los problemas el mismo día en que se lanza una corrección. Saber qué servidores están expuestos a Internet y cuáles contienen los datos más valiosos permite reducir la lista de tareas pendientes a una serie de decisiones concretas, entre ellas, qué servicios hay que desactivar hasta que se solucionen los problemas. En cualquier servidor que sospeches que se haya visto afectado, guarda los registros y una instantánea de la memoria antes de reiniciarlo, ya que el reinicio borra los rastros.
¿Qué ocurre cuando se cae un servidor PHP?
Un atacante que consigue ejecutar código a través de PHP no suele necesitar un « malware ». El servidor web ya dispone de un shell, una conexión de red y acceso a los archivos, por lo que puede utilizar las herramientas ya instaladas en la máquina para explorar el sistema, encontrar credenciales y desplazarse de un sistema a otro. No parece haber nada raro, ya que el servidor web sigue realizando sus funciones habituales con comandos ligeramente diferentes. Esa es la primera de las tres lagunas de detección sobre las que escribo: no parece haber nada raro.
Lo que cambia es con quién se comunica el servidor. Un servidor web que lleva años sirviendo las mismas páginas de repente accede a lugares a los que nunca antes había accedido, envía solicitudes a direcciones desconocidas o empieza a comunicarse con sistemas internos. Ese comportamiento se refleja en el tráfico de red, no en el estado de las actualizaciones. Una visión de la red es la forma de ver con qué se conecta realmente un servidor, independientemente de si alguien está supervisando el propio servidor o no.
Lo que puede y no puede ver « Vectra AI »
Vectra AI No le preocupa realmente cuál sea el vector de ataque inicial. Lo que nos interesa es lo que ocurre después.
Hoy el tema es PHP. La semana que viene será otra cosa: otra falla, una llamada al servicio de asistencia técnica, alguien de dentro. Lo que analizamos no depende de qué puerta se haya utilizado. Observamos lo que hace un sistema una vez que el atacante está dentro, por lo que no necesitamos que se conozca la vía de acceso ni que se haya hecho pública la falla. Esto es lo más importante cuando se desconoce el punto de entrada o la vulnerabilidad aún no se ha anunciado.
Identificación de posibles servidores PHP y de la «TI en la sombra»
Uno de los retos a la hora de proteger la infraestructura de PHP es saber, para empezar, dónde se encuentra. Las aplicaciones olvidadas, los servidores no gestionados y la «TI en la sombra» pueden crear puntos ciegos de seguridad, incluso después de que se hayan corregido las vulnerabilidades conocidas.
Vectra AIEl panel de control de visibilidad del servidor PHP ofrece una herramienta de investigación adicional para ayudar a los equipos de seguridad a identificar servidores PHP que podrían haber pasado desapercibidos, utilizando indicadores observados en el tráfico HTTP no cifrado, tales como .php puntos finales y PHPSESSID cookies. De este modo, los analistas pueden investigar si estos servidores también están recibiendo tráfico cifrado procedente del exterior, lo que ayuda a priorizar los sistemas potencialmente expuestos para una investigación más exhaustiva.
El panel de control no pretende ofrecer un inventario completo de los servidores PHP. Solo puede identificar los sistemas que presentan indicadores observables relacionados con PHP, y es posible que el tráfico cifrado o la visibilidad limitada de la red impidan detectar algunos servidores. En cambio, actúa como una herramienta de apoyo a los flujos de trabajo existentes de detección de activos y búsqueda de amenazas, ayudando a los analistas a descubrir posibles casos de «TI en la sombra», investigar la exposición e identificar sistemas que requieran un examen más detallado, incluso después de aplicar los parches.
Lo que revela un servidor PHP comprometido sobre tu resiliencia
El antiguo criterio para medir el éxito era si los atacantes lograban entrar. El mejor criterio es hasta dónde llegan. La aplicación de parches, un diseño de red sólido, la división de la red en zonas, el principio del privilegio mínimo y saber qué sistemas albergan los procesos empresariales más importantes: todo ello limita esa distancia. El registro de la red puede mostrar si alguien entró por la puerta antes de que se cerrara y adónde se dirigió a continuación.
En el informe técnico «Mind Your Gaps in the Age of AI-Powered Attacks » se analizan estas tres lagunas de principio a fin.