Entradas Mensuales

Síguenos en:

Canal Oficial Telegram de elhacker.NET Grupo Facebook elhacker.NET Twitter elhacker.NET Canal Youtube elhacker.NET Comunidad Steam: Grupo elhacker.NET Mastodon

Entradas populares

PostHeaderIcon Filtran exploit crítico de PHP2Shell para desplegar botnets


Se ha publicado el código de prueba de concepto para dos vulnerabilidades críticas de PHP, conocidas conjuntamente como PHP2Shell (CVE-2026-109618 y CVE-2026-109619). Ambas poseen una puntuación de severidad CVSS de 9.2 y permiten a los atacantes ejecutar código sin necesidad de iniciar sesión. Se ha detectado que algunos atacantes ya están intentando aprovechar estos fallos para desplegar malware de botnets.





Ya está disponible el código público de prueba de concepto para dos vulnerabilidades críticas de PHP, y los atacantes han intentado utilizar estos fallos para desplegar malware de botnets.

Conocidas conjuntamente como PHP2Shell, las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 tienen una puntuación de gravedad CVSS de 9.2 y pueden permitir que los atacantes ejecuten código sin necesidad de iniciar sesión.

Sin embargo, no debes confundir los intentos de explotación con una brecha confirmada. En su última corrección, emitida el 22 de octubre a las 21:21 UTC, Sophos indicó que los datos de sus clientes mostraban escaneos y un pequeño número de intentos de explotación fallidos.

No se encontró evidencia de un compromiso exitoso a través de estas vulnerabilidades. Los investigadores de Sophos identificaron que la carga útil prevista era Potassium, probablemente una variante de la botnet Mirai. Los controles de seguridad bloquearon el intento, por lo que el malware no fue entregado.

No obstante, el análisis de la muestra mostró una versión más grande y actualizada de la amenaza derivada de Mirai vista a principios de 2026, con funciones de descarga e interrupción de red.

Esta actividad sigue a ataques previos de PHP2Shell realizados antes de que los parches fueran públicos. Los informes sobre ataques a PHP antes del parcheo describen observaciones de Amazon que datan del 17 de octubre, cuatro días antes de las correcciones.

Esos hallazgos subrayan por qué tú, como defensor, deberías revisar los registros antiguos, manteniendo separados los ataques intentados de la ejecución de código probada en servidores reales.

El código de explotación crítico de PHP2Shell se hace público

PHP lanzó actualizaciones de seguridad el 21 de octubre. El software afectado incluye instalaciones de PHP que atienden solicitudes web a través de PHP-FPM, Apache mod_php, php-cgi, FrankenPHP y LiteSpeed.

El Centro Nacional de Ciberseguridad de los Países Bajos señala que Apache mod_php conlleva el mayor riesgo porque la explotación puede ocurrir antes de que el código de la aplicación comience a ejecutarse.

Los fallos implican diferentes errores en cómo PHP maneja la memoria y los datos de las solicitudes. CVE-2026-109618 puede corromper la memoria durante la limpieza de la solicitud tras una condición de falta de memoria.

CVE-2026-109619 se refiere a datos de solicitudes antiguas dejados en un estado interno compartido, que una solicitud posterior manejada por el mismo trabajador puede reutilizar.

Estas debilidades pueden exponer más que un solo sitio web. Los productos que empaquetan PHP, incluidas las interfaces de gestión y los dispositivos de red, también pueden necesitar actualizaciones de sus proveedores.

Por lo tanto, debes comprobar el entorno de ejecución utilizado por cada servicio, en lugar de confiar únicamente en la versión de PHP mostrada por una comprobación en la línea de comandos.

Que exista código de explotación público no significa que cualquier servidor vulnerable pueda ser comprometido de forma fiable. Sophos afirmó que su propio equipo de investigación encontró difícil lograr la explotación, incluso con apoyo de IA.

La cobertura previa de Cloudflare sobre los ataques a PHP también muestra por qué las reglas del firewall de aplicaciones web son una salvaguarda temporal, no un sustituto de las actualizaciones.

Análisis de la carga útil de la botnet Potassium

El tráfico bloqueado incluía un User-Agent relacionado con el escaneo, un límite multipart y un patrón de solicitud POST distintivo. Sophos publicó una ruta de archivo temporal y un comando de ejecución como indicadores relacionados.

Dado que la afirmación anterior sobre el éxito fue retirada, esos detalles no deben presentarse como prueba de que los sistemas de los clientes ejecutaran la carga útil.

El análisis de la muestra mostró que Potassium resuelve una dirección de comando y control cifrada y realiza una solicitud HTTP. Verifica que haya una respuesta HTTP 200 exitosa y comprueba que el archivo devuelto comience con los bytes mágicos ELF de Linux.

Esa comprobación muestra que el descargador espera otro ejecutable de Linux, en lugar de contenido web ordinario. La muestra también admite la búsqueda de nombres de host y la resolución de respaldo a través de servicios DNS públicos.

Esos servicios públicos no son indicadores maliciosos por sí mismos. Al igual que otros malwares basados en Mirai, Potassium puede lanzar ataques de denegación de servicio distribuido (DDoS), utilizando máquinas comprometidas para inundar los objetivos con tráfico.

La actividad de explotación separada de la botnet RondoDoX ilustra un interés similar en convertir servidores de aplicaciones expuestos en recursos de botnet.

Tú y tu organización deberían actualizar a PHP 8.5.12, 8.4.27, 8.3.36, o 8.2.35, o instalar un backport aprobado por el proveedor. Reiniciar los servicios afectados y comprobar los trabajadores activos ayuda a asegurar que el código parcheado esté realmente en uso.

Los entornos de ejecución empaquetados, los contenedores y los dispositivos necesitan comprobaciones independientes porque actualizar un paquete de host puede dejar otras copias sin cambios.

Sophos ha añadido firmas de firewall y de prevención de intrusiones en los endpoints junto con las reglas de detección existentes. Debes mantener estas protecciones actualizadas, pero evalúa las alertas frente a la evidencia de procesos y de red.

Una solicitud bloqueada por sí sola no puede mostrar si otra solicitud tuvo éxito. Del mismo modo, una demostración pública de explotación no prueba que el mismo código funcione contra un sistema de producción con diferentes configuraciones, dependencias o comportamiento de los procesos trabajadores.

Cuando no sea posible parchear inmediatamente, Sophos recomienda considerar la eliminación de los sistemas PHP expuestos de internet o colocarlos detrás de una autenticación a nivel de red.

Tú y tu equipo deberíais monitorizar procesos inusuales, conexiones salientes inesperadas y solicitudes web sospechosas. Las configuraciones temporales y las firmas de firewall pueden reducir la exposición, pero no solucionan completamente ambos fallos.


Fuentes:
https://cybersecuritynews.com/critical-php2shell-exploit-code/

0 comments :

Post a Comment

Los comentarios pueden ser revisados en cualquier momento por los moderadores.

Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.

Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.