La actividad relacionada con las vulnerabilidades PHP2Shell habría comenzado varios días antes de que sus detalles se hicieran públicos. Amazon afirma que identificó un intento de explotación el 17 de octubre de 2026, cuatro días antes de la divulgación de los fallos CVE-2026-109618 y CVE-2026-109619.
Según el análisis de Amazon Threat Intelligence, el intento se detectó en la telemetría de su honeypot MadPot y se originó en una dirección IP asociada a una red comercial de anonimización. La empresa considera que el contexto apunta a la posible participación de un actor malicioso, pero señala que todavía no está claro cómo obtuvo información sobre las vulnerabilidades mientras seguían bajo embargo.
## Un periodo de divulgación complicado
Los dos fallos, denominados en conjunto PHP2Shell, recibieron una puntuación de gravedad de 9,2 sobre 10. De acuerdo con la información publicada, podrían permitir la toma de control de un sitio web afectado. Dado el amplio uso de PHP, la preparación y publicación coordinada de las correcciones era especialmente importante.
La fecha prevista para publicar los parches era el 21 de octubre. Sin embargo, horas antes de que concluyera el embargo, se habría difundido información sobre imágenes de contenedores que incluían correcciones. Casi al mismo tiempo comenzaron a circular informes de actividad maliciosa. La situación llevó a organizaciones de distintos sectores a tomar medidas preventivas, mientras la Fundación PHP instaba a los administradores a aplicar las actualizaciones en cuanto estuvieran disponibles.
Amazon también detectó varias pruebas de concepto el día de la publicación de los parches. Las diferencias entre sus cargas y la infraestructura empleada sugieren que podrían haber intervenido distintos actores. La empresa continúa analizando esos elementos para determinar si las pruebas podían funcionar en entornos reales.
## Por qué la explotación no sería sencilla
Una posible barrera para los atacantes es ASLR, o aleatorización del diseño del espacio de direcciones. Esta protección cambia la ubicación de datos y código en la memoria, lo que puede dificultar la ejecución remota fiable de código.
Yotam Perkal, director de investigación de seguridad de Pluto Security, señaló que superar ASLR puede ser complicado y que muchas de las pruebas de concepto públicas no funcionarían de manera consistente en sistemas reales. Aun así, advirtió que las técnicas podrían mejorar y que una gran cantidad de servidores PHP seguía sin actualizarse. Su recomendación es instalar los parches y reiniciar los procesos de PHP para asegurarse de que las correcciones estén activas.
La aparente dificultad técnica no debe confundirse con ausencia de riesgo. Cloudflare informó de un aumento acelerado de los intentos tras la divulgación: según su director ejecutivo, Matthew Prince, la actividad pasó de miles de solicitudes en las horas previas al anuncio a decenas de miles en la primera hora, cientos de miles en la segunda y, posteriormente, millones.
La compañía también observó que algunos actores modificaban sus cargas en función de las solicitudes bloqueadas, aparentemente para intentar sortear los cortafuegos de aplicaciones web. Esa adaptación subraya que la actividad puede evolucionar con rapidez.
## Qué deberían hacer los administradores
Aunque los investigadores describen como limitada la explotación confirmada en sistemas reales hasta el momento, el volumen de intentos y la cantidad de instalaciones potencialmente expuestas justifican actuar sin demora. Los responsables de sistemas deberían:
– Aplicar las actualizaciones disponibles para las versiones de PHP con soporte.
– Reiniciar los procesos y servicios pertinentes para que los cambios entren en vigor.
– Revisar registros y alertas en busca de solicitudes sospechosas relacionadas con PHP2Shell.
– Mantener actualizadas las reglas del cortafuegos de aplicaciones web, sin depender de ellas como sustituto del parche.
– Confirmar qué sitios, contenedores y servidores utilizan las versiones afectadas.
La actividad previa a la divulgación plantea preguntas sobre cómo se obtuvo la información del fallo, pero no permite determinar por sí sola quién estuvo detrás ni cuántos sistemas fueron comprometidos. Mientras se aclaran esos puntos, la prioridad para las organizaciones es reducir la exposición y comprobar que las correcciones se hayan aplicado correctamente.
from Latest from TechRadar https://ift.tt/XfMBSpi
via IFTTT IA
