Por Canuto  

Amazon afirma que sus sensores registraron un intento de explotación de PHP2Shell el 17 de octubre de 2026, cuatro días antes de la divulgación pública de dos vulnerabilidades críticas. La compañía advierte que el embargo no impidió actividad temprana y recomienda parchear con rapidez, revisar registros desde la primera fecha observada y no depender únicamente de firmas para detectar ataques.
***

  • AWS identificó actividad contra sus honeypots desde el 17 de octubre de 2026, antes de la divulgación pública de CVE-2026-109618 y CVE-2026-109619.
  • En torno al día de la divulgación, aparecieron más intentos y AWS observó indicios de varios actores; la compañía no cuantificó los servidores afectados ni confirmó que los intentos tuvieran éxito.
  • La compañía recomienda instalar las versiones corregidas y revisar actividad sospechosa, incluidas solicitudes con PHP_SESSION_UPLOAD_PROGRESS.

AWS detectó intentos de explotar PHP2Shell antes de la divulgación pública

Actividad antes del aviso público

Amazon Threat Intelligence asegura que identificó un intento de explotación de PHP2Shell el 17 de octubre de 2026, cuatro días antes de que se divulgaran públicamente CVE-2026-109618 y CVE-2026-109619. La actividad apareció en la telemetría de MadPot, la red de honeypots de AWS, y procedió de una dirección IP asociada con una red comercial de anonimización. La compañía advirtió que no está claro cómo el actor obtuvo información sobre la vulnerabilidad durante el periodo de embargo.

AWS describe ambas fallas como críticas y señala que permiten ejecutar código de forma remota sin autenticación en un servidor vulnerable. La compañía las califica con una puntuación de 9,2 bajo CVSS v4.0. Un honeypot es un sistema diseñado para atraer y observar actividad maliciosa, sin ser un servicio ordinario destinado a usuarios. En este caso, AWS interpreta que el intento contra uno de esos sensores apunta a la intervención de un actor de amenazas, aunque esa observación no demuestra que el código vulnerable de una organización haya sido comprometido.

La ventana de embargo de PHP debía concluir el 21 de octubre de 2026 a las 14:00 UTC, fecha y hora en que se hizo pública la información, según el relato de la compañía. AWS señaló que el primer exploit de prueba de concepto identificado durante el día de divulgación apareció alrededor de las 02:00 UTC, doce horas antes de que terminara formalmente el embargo. Entre las 02:00 y las 08:00 UTC, sus sensores registraron intentos adicionales contra MadPot desde otras infraestructuras anonimizadas.

La secuencia descrita por AWS presenta dos momentos distintos: un intento detectado el 17 de octubre, antes del aviso, y actividad adicional alrededor del día de divulgación. La empresa observó variaciones tanto en las cargas útiles como en las opciones de infraestructura de anonimización, un patrón que, a su juicio, sugiere la participación de varios actores. Sin embargo, su análisis técnico seguía en curso y no había establecido si alguno de esos intentos logró afectar servidores expuestos en condiciones reales.

Una carrera más corta entre el parche y el ataque

AWS informó que PHP2Shell estaba siendo explotado ampliamente en la naturaleza, una valoración que atribuye a la actividad detectada por su inteligencia de amenazas. El reporte no cuantifica cuántos servidores fueron atacados ni afirma que todos los intentos tuvieran éxito. La compañía también señaló la aparición de más exploits de prueba de concepto el 21 de octubre, con el primero identificado alrededor de las 02:00 UTC, antes de la divulgación pública prevista para las 14:00 UTC.

El caso vuelve a poner en cuestión una suposición operativa habitual: que la fecha de divulgación pública marca el inicio del riesgo. AWS sostiene que la explotación puede empezar antes de que se publique el aviso, como sugieren los registros de MadPot correspondientes al 17 de octubre. Para los equipos defensivos, esto significa que la cronología de una vulnerabilidad no siempre comienza cuando los administradores reciben una alerta, y que las investigaciones retrospectivas deben considerar indicios anteriores.

La compañía también vincula la rapidez de los exploits con cambios estructurales en la capacidad de los atacantes. En el pasado, según su análisis, gran parte de la actividad de explotación observada ocurría después de que apareciera una prueba de concepto pública, porque un grupo reducido construía herramientas y otros actores esperaban a que estuvieran disponibles. AWS plantea que el análisis asistido por inteligencia artificial reduce el costo de convertir un parche comparativo o un aviso técnico en un exploit funcional.

Ese razonamiento no equivale a afirmar que la inteligencia artificial haya sido utilizada en cada intento observado contra PHP2Shell. La conclusión de AWS es más amplia: cuando los detalles técnicos quedan disponibles, un número mayor de actores puede pasar a la acción en horas o incluso minutos, debilitando la antigua dependencia de herramientas publicadas por terceros. En consecuencia, las organizaciones no deberían confiar en que transcurrirá un periodo prolongado entre la publicación de un parche y la aparición de intentos funcionales.

Medidas para reducir la exposición

AWS recomienda actualizar inmediatamente a las versiones corregidas de PHP y considera que el parche es la única remediación completa para CVE-2026-109618 y CVE-2026-109619. La empresa especifica que no hay soluciones alternativas basadas únicamente en cambios de configuración que resuelvan por completo ambos problemas. Si una implementación no puede actualizarse de inmediato, sugiere considerar el bloqueo de cargas de archivos multipartes, pero pide evaluar antes cómo afectaría esa medida a la aplicación.

La lista de comprobaciones propuesta incluye buscar solicitudes POST que contengan la cadena PHP_SESSION_UPLOAD_PROGRESS en cargas de formularios y revisar los registros del servidor web en busca de actividad sospechosa. AWS también recomienda investigar la ejecución inesperada de procesos y las modificaciones de archivos en los servidores de aplicaciones web. Esas señales deben analizarse junto con el contexto de cada sistema, porque el reporte no presenta una sola evidencia como prueba automática de compromiso.

La compañía identificó seis direcciones IP relacionadas con actividad observada: 103.216.220.92, registrada el 17 de octubre de 2026, y 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188 y 95.217.98.37, observadas el 21 de octubre. AWS advierte que esas direcciones pertenecen a infraestructura de anonimización compartida y no son exclusivas de esta actividad. Por ello, recomienda investigar cualquier coincidencia en los registros, en lugar de bloquearlas automáticamente.

Para los responsables de seguridad, AWS plantea tres cambios operativos: medir en horas los plazos de parcheo y mitigación para vulnerabilidades críticas en sistemas expuestos a Internet, iniciar investigaciones desde la explotación conocida más temprana y desarrollar detecciones que no dependan de una firma específica para cada CVE. La empresa utiliza como referencia el 17 de octubre para las pesquisas relacionadas con PHP2Shell, aunque esa fecha corresponde a la primera actividad que reportó en su propia telemetría. La recomendación busca que las defensas no empiecen a actuar únicamente cuando ya existe una firma pública.

Qué aporta la telemetría de MadPot

AWS afirma que sus sistemas internos de inteligencia de amenazas detectaron y restringieron automáticamente intentos de escaneo malicioso dirigidos a esta vulnerabilidad. La empresa dice analizar más de 200.000 millones de eventos por minuto e integrar información de su red MadPot para identificar y bloquear en tiempo real intentos de explotación conocidos. Esa cifra describe la escala de análisis que AWS atribuye a sus sistemas, no el volumen de ataques a PHP2Shell ni una medición independiente de la actividad mundial.

La utilidad de una red de honeypots reside, en parte, en ofrecer a los defensores señales tempranas sobre técnicas, cargas y fuentes de actividad, antes de que los mismos patrones aparezcan en sistemas productivos. En el caso reportado, esa capacidad permitió a AWS observar intentos previos a la divulgación pública y registrar cambios en la actividad durante las horas siguientes. La compañía no detalla en este informe qué organizaciones externas pudieron haberse visto afectadas ni ofrece una estimación del alcance total.

La principal cautela para los equipos que utilicen los indicadores es que una dirección IP asociada con anonimización puede servir a distintos usuarios y propósitos. AWS dice expresamente que las seis direcciones no identifican de forma exclusiva a los responsables del ataque, de modo que su presencia en un registro requiere investigación y contexto, no una atribución automática. La misma prudencia se aplica a los intentos detectados: la actividad contra un sensor no permite concluir que un servidor de producción haya sufrido una intrusión.

El aviso de AWS deja una conclusión práctica para administradores de PHP: ante fallas críticas en servicios expuestos, conviene reducir el intervalo entre la identificación del problema y la instalación de la corrección, además de buscar señales anteriores a la fecha de divulgación. La empresa atribuye a la rapidez creciente de los exploits, incluida la posible asistencia de herramientas de IA, la necesidad de abandonar plazos de parcheo de siete o 30 días como supuesto general. Para PHP2Shell, su recomendación inmediata es actualizar y revisar los registros desde la primera actividad que detectó.

Amazon Threat Intelligence publicó el análisis y las recomendaciones para clientes. AWS también remite a sus usuarios a una guía separada sobre mitigaciones mediante AWS Web Application Firewall, mientras aplican los parches correspondientes.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados