WP-SHELLSTORM: 25.000 sitios WordPress hackeados

WP-SHELLSTORM, un ataque de seguridad a WordPress, ocupó titulares en toda la comunidad de ciberseguridad cuando un servidor de atacantes quedó expuesto el 11 de junio de 2026, revelando una operación de backdooring masiva que comprometió 25.195 sitios WordPress confirmados, apuntó a 1,4 millones de objetivos y dejó más de 5.700 webshells activos plantados en servidores de todo el mundo.

WP-SHELLSTORM es el nombre que los investigadores de Ctrl-Alt-Intel y SOCRadar le dieron a una operación de brokerage de acceso mediante webshells que apuntó masivamente a sitios WordPress en junio de 2026. La operación combinó escaneo automatizado vía FOFA, explotación de CVE-2026-3844 (una vulnerabilidad crítica de CVSS 9.8 en el plugin Breeze Cache) y distribución de backdoors PHP para revender acceso a sitios comprometidos. El origen probable: un operador chino o sinohablante usando la herramienta BestShell.

¿Qué es WP-SHELLSTORM y cómo funcionan los webshells en WordPress?

Un webshell es un archivo PHP malicioso que el atacante planta en el servidor para ejecutar comandos de forma remota. A diferencia de un ransomware que buscás y detectás por el ruido que hace, un webshell es silencioso: puede estar meses en tu directorio /uploads/ sin que nadie lo note, esperando que el operador lo active cuando lo necesite.

Lo que hace particular a WP-SHELLSTORM es que no es un ataque puntual a un sitio específico sino una operación de brokerage. El atacante no quiere tu sitio porque es interesante, sino porque forma parte de una lista de miles. Comprometés la mayor cantidad posible, plantás el webshell, y después revendés ese acceso a otros actores en foros de cibercrimen, sea para spam, phishing, minería de criptomonedas o cualquier otro fin.

La firma «BestShell», de origen chino, aparece asociada a esta operación según el análisis de los investigadores. Los webshells PHP que usaron incluyen ofuscación con base64 y funciones eval encadenadas para dificultar la detección por antivirus y escáneres de firma.

La diferencia clave con el malware tradicional: el malware se ejecuta y actúa. Un webshell solo espera. Eso lo hace mucho más difícil de detectar. Tema relacionado: herramientas de análisis de seguridad.

Descubrimiento y escala del ataque WP-SHELLSTORM (junio 2026)

El 11 de junio de 2026, investigadores de Ctrl-Alt-Intel detectaron que el servidor con IP 137.175.93.126 estaba accesible públicamente sin ningún tipo de autenticación. Abrís la IP en el navegador, explorás los directorios, encontrás la lista completa de 1,4 millones de sitios WordPress ordenados como objetivos, junto con los logs detallados de cada compromiso exitoso, los webshells listos para desplegar clasificados por tipo y los registros de qué comandos se ejecutaron en qué sitio, todo sin contraseña, sin ninguna barrera, accesible para cualquiera que encontrara la dirección correcta.

Según el análisis publicado por SOCRadar, los números confirmados de la operación:

• 1,4 millones de sitios WordPress en la lista de objetivos del atacante
• 25.195 sitios comprometidos de forma confirmada según los logs del servidor expuesto
• 5.700+ webshells activos y funcionales al momento del descubrimiento
• 800MB en 434 archivos incluyendo herramientas, scripts de explotación y registros de actividad

¿Y qué significa que el servidor quedó expuesto? Exacto: fue un error del propio atacante. Esa exposición accidental permitió a los investigadores documentar la operación completa antes de que la infraestructura se cerrara, cosa que en la mayoría de estas operaciones nunca ocurre.

CVE-2026-3844: La vulnerabilidad crítica en el plugin Breeze Cache

Breeze Cache es un plugin de optimización de rendimiento para WordPress. CVE-2026-3844 recibió una puntuación CVSS de 9.8, la más alta posible en la escala práctica, y la razón es simple: cualquier persona en internet puede explotarla sin tener usuario ni contraseña en el sitio.

El problema está en la función fetch_gravatar_from_remote. Cuando un usuario activa la opción «Host Files Locally» (que guarda avatares de Gravatar de forma local en el servidor), la función descarga archivos remotos sin validar la extensión ni el tipo MIME. Un atacante puede hacer que esta función descargue un archivo PHP malicioso que queda alojado en el servidor y es accesible vía web.

La precondición importante: «Host Files Locally» está desactivada por defecto. Si nunca la habilitaste, tu sitio no era vulnerable por este vector. Pero si en algún momento alguien la activó (y muchos lo hacen para mejorar performance), la exposición era completa con solo enviar la request correcta.

Según el análisis de CyCognito y Security Affairs, los números de impacto de esta vulnerabilidad específica:

• 45.000+ intentos de explotación registrados desde que se hizo pública la vulnerabilidad
• 17.000+ sitios comprometidos a través de Breeze Cache específicamente
• Versiones vulnerables: Breeze Cache 2.4.4 y anteriores
• Versión con el fix: 2.4.5 (la actualización es urgente)

¿Cómo WP-SHELLSTORM comprometió miles de sitios sin usar vulnerabilidades de día cero?

Ponele que sos un atacante con acceso a herramientas automatizadas pero sin capacidad técnica para encontrar vulnerabilidades nuevas. No hace falta: alcanza con usar exploits ya publicados contra sitios que no actualizaron sus plugins. Lo explicamos a fondo en autenticación de dos factores.

La metodología de WP-SHELLSTORM fue exactamente esa. El operador usó FOFA, un motor de búsqueda de activos expuestos en internet de origen chino (similar a Shodan), para identificar sitios WordPress que potencialmente usaban Breeze Cache con la configuración vulnerable. Después lanzó un escáner automático que probaba CVE-2026-3844 y otros exploits conocidos contra esa lista masiva.

El atacante no necesitó un solo zero-day. Todo fueron exploits de vulnerabilidades ya documentadas y con parches disponibles (spoiler: los sitios comprometidos simplemente no los habían aplicado).

Los investigadores también encontraron similitudes con el ataque EssentialPlugin, una operación previa que comprometió sitios usando más de 30 plugins vulnerables distintos y pasó 8 meses en estado latente antes de activarse. WP-SHELLSTORM parece seguir el mismo modelo: comprometer muchos sitios, plantar el webshell, esperar o revender el acceso a quien pague.

¿Cómo detectar si tu WordPress fue comprometido por WP-SHELLSTORM?

Tu sitio puede funcionar perfectamente mientras un webshell activo espera en segundo plano. El atacante no tiene ningún interés en que el sitio se caiga: un sitio caído es un sitio que alguien va a investigar. Los síntomas a revisar:

• Archivos PHP en /uploads/: El directorio de medios no debería tener archivos .php. Si encontrás uno, asumí compromiso hasta probarlo.
• Usuarios administradores desconocidos: Revisá WordPress > Usuarios. Un admin que vos no creaste es señal de compromiso activo.
• Modificaciones recientes en wp-config.php: Revisá el timestamp. Cambios no planeados en este archivo son críticos.
• Archivos con nombres sospechosos: down.php, shell.php, wso.php, cmd.php son nombres comunes para webshells. Si encontrás algo así en cualquier parte del servidor, es malware.
• Tráfico saliente inusual: Requests HTTP desde tu servidor hacia IPs externas que vos no iniciaste pueden indicar un webshell activo comunicándose con su C2.

Para escaneo automatizado, Wordfence, Sucuri SiteCheck e Imunify360 detectan webshells conocidos. Eso sí: no te fíes solo del escaneo online de Sucuri (que revisa el front-end), hacé también un escaneo del sistema de archivos del servidor.

Pasos para eliminar el backdoor y limpiar tu WordPress

Si encontraste un webshell, no alcanza con desactivar el plugin. El proceso completo: Complementá con protección adicional con 2FA.

• No solo desinstalés el plugin: Desactivar o desinstalar Breeze Cache no elimina los archivos PHP maliciosos ya subidos al servidor. El webshell puede estar en /uploads/2026/06/archivo.php y seguir activo aunque el plugin no esté.
• Tomá un backup antes de limpiar: Incluso del estado comprometido, para análisis forense posterior si lo necesitás.
• Eliminá el plugin completamente: Desde la interfaz de WordPress (desinstalar, no solo desactivar) para que borre los archivos del plugin del servidor.
• Revisá y borrá archivos PHP en /uploads/: Conectate por FTP o SSH y revisá todo wp-content/uploads/ en busca de archivos .php. Si encontrás alguno, borralo.
• Reemplazá el core de WordPress: Descargá una versión limpia desde WordPress.org y reemplazá los archivos del core sin tocar wp-content/ ni wp-config.php.
• Rotá todas las credenciales: Contraseña de WordPress, FTP, base de datos y del hosting. Si tenés tu sitio en donweb.com u otro proveedor, cambiá también la contraseña del panel de hosting: si el webshell tuvo acceso al servidor, puede haber leído wp-config.php.
• Reinstalá plugins y temas desde fuentes oficiales: No restaures desde backups potencialmente comprometidos si son anteriores al análisis forense.

El riesgo de reinfección es real. Si no limpiás todos los archivos maliciosos, el atacante puede volver usando el mismo vector o credenciales capturadas durante el compromiso.

¿Cómo proteger WordPress contra backdoors y vulnerabilidades de plugins?

El 100% de los sitios comprometidos en WP-SHELLSTORM tenían algo en común: plugins desactualizados con vulnerabilidades públicamente conocidas. Nada más.

• Actualizá plugins y temas regularmente: El vector más común sigue siendo plugins sin actualizar. Las actualizaciones automáticas para plugins de seguridad son mínimo indispensable.
• Eliminá lo que no usás: Un plugin desactivado pero instalado sigue siendo un vector de ataque. Si no lo usás, borralo completamente.
• Para Breeze Cache específicamente: Actualizá a 2.4.5 o superior. Si no podés actualizar de inmediato, desactivá la opción «Host Files Locally» en la configuración del plugin.
• Monitoreo de integridad de archivos: Wordfence tiene esta función activa por defecto. Si un archivo del core de WordPress cambia sin que vos lo hayas actualizado, te avisa.
• Backups regulares fuera del servidor: Un backup que vive en el mismo servidor comprometido no te sirve de nada.
• Revisá usuarios administradores periódicamente: Una auditoría mensual de los usuarios con permisos de admin tarda dos minutos y puede revelar un compromiso silencioso de semanas.

Comparativa: WP-SHELLSTORM vs ataques masivos previos a WordPress

Qué está confirmado y qué no sobre WP-SHELLSTORM

Confirmado

• Servidor expuesto: 137.175.93.126 accesible el 11 de junio de 2026 con 434 archivos y 800MB de datos sin autenticación
• Compromisos confirmados: 25.195 sitios WordPress según los logs del servidor expuesto
• Webshells activos: 5.700+ al momento del descubrimiento
• Vulnerabilidad central: CVE-2026-3844 fue el vector principal (CVSS 9.8)
• Falla técnica: La función fetch_gravatar_from_remote en Breeze Cache ≤2.4.4 permite upload sin autenticación con «Host Files Locally» activo
• Fix disponible: Breeze Cache 2.4.5 corrige la vulnerabilidad
• Escala de explotación: Más de 45.000 intentos registrados

No confirmado o en investigación

• Identidad del operador: Solo hay indicios de origen chino o sinohablante basados en las herramientas usadas (BestShell, FOFA)
• Alcance real de los 1,4M: No se sabe qué porcentaje de esa lista llegó a ser probado activamente
• Estado actual de la infraestructura: Si la operación está desmantelada o si el atacante migró a nueva infraestructura
• Compromisos secundarios: Posibles movimientos laterales o uso posterior del acceso establecido en sitios ya comprometidos

Errores comunes al responder a un compromiso de WordPress

Error 1: Creer que desinstalar el plugin alcanza

Desactivar o desinstalar Breeze Cache no elimina los archivos PHP maliciosos que el atacante ya subió al servidor antes de que actualizaras. El webshell puede estar en /uploads/2026/06/imagen.php y seguir accesible vía web aunque el plugin no esté instalado. La limpieza requiere revisar el sistema de archivos del servidor, no solo la interfaz de WordPress.

Error 2: Escanear solo el front-end del sitio

El scanner online de Sucuri SiteCheck revisa el HTML que el sitio sirve públicamente. Un webshell en /uploads/ que el atacante accede directamente por URL puede no aparecer en ese escaneo. Necesitás un escaneo del sistema de archivos del servidor con Wordfence o Imunify360, no solo del front-end visible.

Error 3: No rotar credenciales después de la limpieza

Si el atacante tuvo acceso al servidor mediante el webshell, pudo leer wp-config.php y capturar las credenciales de base de datos, accesos FTP u otras claves almacenadas. Limpiar el webshell sin rotar todas las credenciales es resolver la mitad del problema: el acceso con credenciales robadas puede persistir.

Error 4: Asumir que si el sitio «anda bien» no fue comprometido

WP-SHELLSTORM planta webshells diseñados para ser invisibles. El sitio sigue funcionando con normalidad porque un sitio caído es un sitio que alguien investiga. Los mejores backdoors son los que nadie nota, y la operación estuvo activa semanas antes de que el servidor del atacante quedara expuesto accidentalmente. Ya lo cubrimos antes en mejores prácticas de seguridad.

Preguntas Frecuentes

¿Qué es WP-SHELLSTORM?

WP-SHELLSTORM es una operación de brokerage de acceso mediante webshells dirigida a sitios WordPress, descubierta en junio de 2026 cuando el servidor del atacante (137.175.93.126) quedó expuesto públicamente. La operación comprometió 25.195 sitios WordPress confirmados usando CVE-2026-3844 del plugin Breeze Cache, con una lista de 1,4 millones de objetivos y origen probable en un operador chino o sinohablante que usó la herramienta BestShell.

¿Cómo sé si mi sitio WordPress fue comprometido por WP-SHELLSTORM?

Revisá el directorio wp-content/uploads/ en busca de archivos con extensión .php (no deberían existir), chequeá los usuarios de WordPress en busca de administradores que no creaste, y analizá el timestamp de wp-config.php para detectar modificaciones no autorizadas. Escaneá el sistema de archivos del servidor con Wordfence o Imunify360. Si tenés o tuviste instalado Breeze Cache ≤2.4.4 con «Host Files Locally» activado, tratá el sitio como comprometido hasta confirmarlo.

¿Cuál es la vulnerabilidad del plugin Breeze Cache (CVE-2026-3844)?

CVE-2026-3844 es una falla de subida de archivos sin autenticación (CVSS 9.8) en Breeze Cache versión 2.4.4 y anteriores. La función fetch_gravatar_from_remote descarga archivos remotos sin validar la extensión, lo que permite a cualquier persona en internet subir un archivo PHP malicioso al servidor. La condición: que la opción «Host Files Locally» esté activada (desactivada por defecto). Breeze Cache 2.4.5 corrige el problema.

¿Cuántos sitios WordPress fueron afectados por WP-SHELLSTORM?

Los registros del servidor expuesto confirman 25.195 sitios WordPress comprometidos y más de 5.700 webshells activos. La lista de objetivos del atacante incluía 1,4 millones de sitios, de los cuales más de 17.000 fueron específicamente comprometidos a través de la vulnerabilidad de Breeze Cache. Se registraron más de 45.000 intentos de explotación en total según el análisis conjunto de Ctrl-Alt-Intel y SOCRadar.

¿Cómo detectar y eliminar backdoors PHP en WordPress?

Para detectar backdoors, buscá archivos .php en /uploads/, usá Wordfence File Integrity Monitoring para detectar cambios en archivos del core, y revisá los logs del servidor para accesos a rutas inusuales. Para eliminar, borrá los archivos maliciosos del servidor, reemplazá el core de WordPress con una versión limpia de WordPress.org, reinstalá plugins desde fuentes oficiales y rotá todas las credenciales. El artículo de backdoors PHP en WordPress en este mismo sitio cubre el proceso paso a paso con más detalle.

Conclusión

WP-SHELLSTORM dejó en claro algo que cuesta aprender: los ataques masivos a WordPress no necesitan tecnología sofisticada. Alcanza con un exploit conocido, un motor de búsqueda de activos expuestos y una lista de sitios que no actualizaron sus plugins. Los 25.195 compromisos confirmados no se lograron con ingeniería de punta, sino con automatización y descuido del lado de los administradores.

El descubrimiento del servidor expuesto el 11 de junio de 2026 fue una suerte para la comunidad de seguridad: permitió documentar la operación antes de que siguiera creciendo. Sin esa exposición accidental del atacante, los 5.700 webshells activos podrían haber operado meses más sin que nadie lo supiera.

Si usás Breeze Cache, actualizá a 2.4.5 hoy. Si alguna vez tuviste «Host Files Locally» activado, revisá el directorio /uploads/ antes de dar el tema por cerrado. Y si no tenés monitoreo de integridad de archivos en tu WordPress, este es el recordatorio que necesitabas para instalarlo.

Fuentes

• The Hacker News – Exposed Hacker Server Reveals WP-SHELLSTORM Backdooring Thousands of WordPress Sites
• SOCRadar – WP-SHELLSTORM Expose 1.4M WordPress Sites
• CyCognito – CVE-2026-3844: Breeze Cache Plugin Unauthenticated File Upload
• Security Affairs – Más de 400.000 sitios en riesgo por CVE-2026-3844 en Breeze Cache
• Seguridad en WordPress – Backdoors PHP: cómo detectar y eliminar