Dos fallos críticos de PHP, con una calificación de 9,2 sobre 10, permiten a atacantes no autenticados ejecutar código en servidores web vulnerables. Las pruebas indican que los intentos de explotarlos comenzaron cuatro días antes de que se publicaran las correcciones de emergencia. Esta coincidencia temporal convierte lo que ya era una grave crisis de software en una prueba de la rapidez con la que internet puede proteger la infraestructura que da soporte a aproximadamente el 70 % de los sitios web.
El proyecto PHP publicó versiones parcheadas el 21 de octubre para las vulnerabilidades CVE-2026-109618 y CVE-2026-109619, conocidas como PHP2Shell. Su aviso oficial indica que todas las instalaciones de PHP que gestionan solicitudes web están en riesgo, siendo el riesgo más alto para los sistemas Apache que utilizan mod_php. Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
Los intentos de ataque precedieron a la divulgación
Amazon Threat Intelligence informó que su red de honeypots MadPot registró un intento de explotación el 17 de octubre, cuatro días antes de su divulgación pública. El tráfico provenía de una dirección asociada a una red comercial de anonimización. Amazon indicó que este patrón sugiere la participación de un ciberdelincuente, aunque aún se desconoce cómo obtuvo los detalles técnicos o si el intento habría tenido éxito en un sistema real. The Verge confirmó la cronología por separado con la Fundación PHP.
El proceso se aceleró. Según la telemetría de AWS, otros actores probaron vulnerabilidades a primera hora del 21 de octubre, horas antes de que se levantara el embargo de las 14:00 UTC. El código de prueba de concepto apareció pocas horas después de su publicación, y Amazon afirmó que sus sensores detectaron entonces numerosos intentos de explotación en la práctica.
Cloudflare declaró por separado que los atacantes se dirigieron a sus clientes tras la filtración de información sobre vulnerabilidades antes del lanzamiento previsto. La compañía informó que las cargas útiles maliciosas cambiaron a medida que los atacantes intentaban eludir la protección. Cloudflare había desarrollado reglas de firewall a principios de octubre y las activó por defecto para sus clientes unas nueve horas antes del anuncio público. Estas observaciones corroboran la existencia de sondeos activos, pero no demuestran que los atacantes lograran la ejecución remota de código.
Por qué estos defectos llegan tan lejos
Ambas vulnerabilidades residen en PHP, por debajo de la capa de aplicación. Esto significa que actualizar un plugin de WordPress, una plataforma de comercio electrónico o el código personalizado de un sitio web no soluciona el problema subyacente. Las solicitudes web multipart especialmente diseñadas pueden provocar problemas de memoria peligrosos antes de que se activen las medidas de seguridad habituales de la aplicación.
La vulnerabilidad CVE-2026-109618 implica una condición de falta de memoria que puede interrumpir PHP mientras los datos de la solicitud interna están solo parcialmente inicializados; la limpieza posterior puede tratar los datos no válidos como legítimos. La vulnerabilidad CVE-2026-109619 puede dejar un estado interno obsoleto después de liberar la memoria, lo que permite que una solicitud posterior gestionada por el mismo proceso de trabajo la reutilice. En ambos casos, una explotación exitosa podría permitir la ejecución de código con los privilegios del proceso del servidor, exponiendo potencialmente datos o abriendo una ruta más profunda en la red.
La exposición es inusualmente amplia porque, según AP y Cloudflare, PHP impulsa aproximadamente el 70 % de los sitios web. PHP es la base de sistemas ampliamente utilizados como WordPress, Drupal y MediaWiki, por lo que la responsabilidad se distribuye entre proveedores de servicios en la nube, empresas de alojamiento, agencias gubernamentales, empresas y operadores de sitios web individuales.
El parcheo es la única reparación completa
El equipo de seguridad de PHP afirma que la actualización es la única solución completa. Los controles temporales pueden limitar ciertas vías de ataque, pero ninguno garantiza la seguridad de una instalación afectada. Esta distinción es importante porque los firewalls de aplicaciones web pueden inspeccionar las solicitudes sospechosas sin acceder a la memoria de trabajo donde se producen las vulnerabilidades. Cloudflare y Amazon han implementado reglas de protección, pero ambas las describen como una defensa en profundidad, no como un sustituto de una actualización.
Los sistemas heredados complican la respuesta. PHP 8.1 y versiones anteriores ya no cuentan con soporte del proyecto, aunque algunas distribuciones de Linux y proveedores con soporte a largo plazo pueden ofrecer correcciones retrocompatibles. Por lo tanto, los administradores deben identificar no solo los sitios web visibles, sino también los servicios olvidados, los paneles de administración integrados y los productos de proveedores que incluyen su propio entorno de ejecución de PHP.
La NSA advirtió a las organizaciones que hicieran un inventario de los servicios afectados, aplicaran los parches de los proveedores, reforzaran el registro de eventos y reemplazaran las implementaciones obsoletas. Aconsejó desconectar un sistema cuando no sea factible una actualización inmediata y no se pueda mitigar completamente el problema de otra manera. Esta recomendación es inusualmente contundente y refleja la combinación de acceso no autenticado, exposición a internet y un margen de tiempo cada vez menor entre la divulgación y el ataque.
La IA comprimió el calendario de seguridad
La respuesta también ilustra el doble papel de la inteligencia artificial en la ciberseguridad. Inicialmente, los humanos identificaron las vulnerabilidades, mientras que los agentes de IA ayudaron a los investigadores a determinar su vulnerabilidad y a probar las soluciones, según informó AP. Por su parte, Amazon argumentó que el análisis asistido por IA está reduciendo el costo de convertir una diferencia de parche o un aviso técnico en código de explotación funcional, lo que permite que más actores actúen en cuestión de horas o minutos.
Eso no prueba que la IA haya causado la actividad previa a la divulgación. Amazon afirmó explícitamente que se desconoce la fuente de la información del actor del 17 de octubre. Esto significa que los plazos de aplicación de parches convencionales, medidos en siete o treinta días, no se ajustan cada vez más a las vulnerabilidades críticas en los sistemas de acceso público. En el caso de PHP2Shell, los equipos de seguridad también deben revisar los registros que se remontan al menos al 17 de octubre, en lugar de asumir que el riesgo comenzó cuando los parches se hicieron públicos.
La responsabilidad recae sobre los operadores
La mayoría de los usuarios de internet no pueden modificar el entorno de ejecución de PHP de los servicios que visitan. La responsabilidad operativa inmediata recae en los propietarios de sitios web, las empresas de alojamiento y los proveedores de software. Sus prioridades son identificar todos los entornos de ejecución afectados, instalar una versión corregida o una versión anterior verificada del proveedor, mantener controles de firewall temporales durante la implementación y examinar los registros en busca de cargas sospechosas, ejecuciones de procesos inesperadas o cambios en los archivos.
Para el público en general, este episodio recuerda que los sitios web conocidos pueden depender de una infraestructura que los visitantes nunca ven. Las protecciones básicas de las cuentas siguen siendo importantes, pero no pueden compensar un servidor sin actualizar. La pregunta clave ahora es cuantificable: ¿cuántas organizaciones pueden localizar sus sistemas PHP, repararlos e investigar el período previo a la aplicación de parches antes de que la explotación automatizada convierta una vulnerabilidad de software en una brecha de seguridad permanente?
