RCE crítico de 6 pasos en Avada: lo que encontró Argus

En pocas palabras: Wordfence Argus detectó CVE-2026-6279, una cadena de ejecución remota de código crítica de seis pasos en el tema Avada. Publicada en agosto de 2026, la falla permite a un atacante sin credenciales tomar el control del servidor de cualquier sitio con este tema, que supera el millón de ventas.

El equipo de Wordfence Argus encontró una cadena de ejecución remota de código (RCE) crítica de seis pasos en el tema Avada de WordPress, según el aviso que Wordfence publicó en agosto de 2026. La falla, registrada bajo el identificador CVE-2026-6279, le permite a un atacante sin credenciales tomar el control del servidor de cualquier sitio que use este tema.

Para ubicarnos: Wordfence Argus es el sistema automatizado de detección de vulnerabilidades de Wordfence, la empresa detrás del plugin de seguridad más instalado de WordPress. El blanco del hallazgo es Avada, el tema premium más vendido de la historia de ThemeForest, que incluye el constructor Avada Builder (antes conocido como Fusion Builder). Con más de un millón de ventas, cualquier RCE pre-autenticación en este tema abre una superficie de ataque enorme, porque al atacante no le hace falta usuario, contraseña ni ningún acceso previo.

¿Qué descubrió Wordfence Argus en el tema Avada?

Wordfence Argus encontró en Avada un RCE pre-autenticación encadenable en seis pasos, difundido como CVE-2026-6279 en agosto de 2026. Lo que vuelve ruidoso este descubrimiento es la cadena: ninguna pieza aislada sería catastrómica, pero combinadas terminan en ejecución de código arbitrario en el servidor. La suma pesa más que las partes. Lo explicamos a fondo en qué firewall de WordPress bloquea más ataques.

Según el aviso oficial de Wordfence, el equipo aplicó un proceso de divulgación responsable con ThemeFusion, coordinando el lanzamiento del parche antes de publicar los detalles técnicos. Y no fue lo único que sacaron a la luz en el mismo ciclo de investigación (spoiler: había cuatro CVE en total, ya llegamos a eso). Si querés revisar el historial completo de fallas del tema, la base de threat intel de Wordfence mantiene la lista actualizada por identificador.

¿Cómo funciona el ataque RCE de 6 pasos en Avada Builder?

Ponele que tenés un ecommerce con Avada, todo al día en plugins, certificado SSL vigente, contraseña de admin robusta. Nada de eso importa acá. La cadena arranca justo donde termina la autenticación: afuera.

1. Acceso al endpoint AJAX. Avada Builder expone fusion_get_widget_markup como acción de WordPress AJAX disponible para cualquiera, sin verificar identidad.
2. Filtrado del nonce. En páginas que muestran Post Cards, el propio tema imprime un nonce válido en el HTML (sí, en el código fuente, para cualquiera que mire). Esa «capa de protección» queda servida en bandeja.
3. Decodificación del payload. El endpoint acepta un parámetro JSON codificado en base64 y lo procesa sin validar estructura ni origen.
4. Puente hacia call_user_func(). El contenido decodificado termina en una llamada a call_user_func() sin lista blanca de funciones permitidas.
5. Ejecución de código arbitrario. Desde ahí el atacante corre funciones PHP a elección: escribir archivos, crear un usuario administrador, bajar una webshell.
6. Control del servidor. Base de datos, archivos del sitio, correo saliente. Todo.

¿Y qué hizo falta para arrancar todo esto? Nada. Ni registro, ni suscripción, ni ingeniería social. Un endpoint abierto acá, un nonce filtrado allá, una validación faltante en el medio, y cuando te querés acordar ya tienen shell en tu servidor mandando spam desde tu IP mientras vos seguís mirando métricas de tráfico que, claro, empezaron a caer y todavía no sabés por qué.

¿Qué otras vulnerabilidades tiene Avada además del RCE?

Además de CVE-2026-6279, Argus reportó tres fallas adicionales en el mismo ciclo, y una de ellas alcanzó un CVSS de 9.1, según el análisis de Okitup sobre CVE-2026-8713 y la bitácora de INCIBE-CERT. Este es el mapa completo:

Cuatro fallas en un mismo tema no es mala suerte: es deuda técnica acumulada. Y para quien ataca, es un buffet. La lectura de archivos sirve para ir por wp-config.php y sus credenciales de base de datos, la inyección SQL para manipular contenido, y el borrado para eliminar pistas o romper copias de seguridad (que no es poco). Sobre eso hablamos en nuestra comparativa entre Wordfence y Sucuri.

¿Cuántos sitios WordPress están en riesgo y qué puede hacer un atacante?

Más de un millón de instalaciones activas usan Avada, de acuerdo con el dato que maneja el propio Wordfence en su anuncio. Hablamos de uno de los temas más extendidos del ecosistema, presente en tiendas, portfolios, medios y sitios corporativos de todo el mundo, Latinoamérica incluida. La popularidad, acá, juega en contra.

• Robo de credenciales: con lectura de archivos, el archivo wp-config.py… perdón, wp-config.php, entrega usuario y contraseña de la base de datos.
• Contenido malicioso: la inyección SQL permite meter spam o enlaces dentro de tus propios posts.
• Redirecciones: tu tráfico puede terminar en sitios de phishing sin que toque el diseño.
• Persistencia: un backdoor bien escondido sobrevive a la actualización del tema.

Eso último merece una pausa. El escenario típico no termina con el exploit inicial: el atacante crea un usuario admin que no aparece en la portada, instala un plugin de «cache» que en realidad es una puerta trasera, y se queda viviendo en el servidor. Al cierre de esta nota las fuentes consultadas no documentan campañas masivas explotando CVE-2026-6279, pero los detalles ya son públicos. Tomalo como cuenta regresiva, no como calma.

¿Qué versiones de Avada están afectadas y cuándo salió el parche?

Quedan afectadas todas las versiones de Avada hasta la 3.15.2 inclusive. ThemeFusion distribuyó las correcciones en dos tandas: la 3.15.3 cerró CVE-2026-4782 y CVE-2026-4798, y la 3.15.4 sumó el arreglo de CVE-2026-8713. Traducción práctica: si estás en 3.15.4 o superior, cubrís el paquete completo de fallas que Argus reportó. Tema relacionado: qué plugin limpia mejor el malware tras un exploit.

El proceso siguió el camino correcto: Argus detectó la cadena, avisó al desarrollador, ThemeFusion preparó el parche y recién entonces Wordfence publicó los detalles técnicos. Es divulgación responsable funcionando como debe. El problema es el otro lado de la ecuación: cada sitio que tarda semanas en actualizarse es ventana abierta, y con un millón de instalaciones, hay muchas ventanas.

¿Cómo proteger tu WordPress si usás el tema Avada?

Primero lo primero: actualizar. Después, auditar. Esta es la secuencia que yo seguiría, en orden:

• Actualizá a Avada 3.15.4 o superior ahora. Entrá a Escritorio → Actualizaciones en tu panel de WordPress y aplicá la versión antes de hacer cualquier otra cosa.
• Hacé backup completo antes de tocar nada. Archivos y base de datos. Si tu proveedor de hosting guarda copias automáticas (los planes de donweb.com, por ejemplo, las incluyen), verificá que la más reciente sea de ayer y no de hace tres meses.
• Revisá los logs de acceso. Buscá peticiones a admin-ajax.php con la acción fusion_get_widget_markup y POST extraños. Si aparecen de IPs desconocidas, asumí compromiso y actuá en consecuencia.
• Pasá un escaneo con Wordfence después de actualizar. El parche cierra la puerta, pero el escaneo busca lo que pudo haber entrado antes.
• Activá firewall y 2FA. Un WAF delante del sitio más autenticación en dos pasos para todos los usuarios administrador.
• Auditá los usuarios admin. Nombres que no reconozcas, cuentas creadas hace poco, roles sospechosos: afuera.

¿Es seguro seguir usando Avada o conviene migrar a otro tema?

Si actualizaste a 3.15.4 y limpiaste logs y usuarios, seguir con Avada es una decisión razonable. El desarrollador respondió, el parche existe y la divulgación fue prolija. Migrar por pánico casi siempre cuesta más de lo que ahorra: cambiar de tema implica rearmar plantillas, CSS personalizado y funcionalidades enteras. Para más detalles técnicos, mirá cómo parchear vulnerabilidades críticas en WordPress.

Ahora bien, si tu criterio es de largo plazo, fijate en señales concretas antes de casarte con cualquier tema: frecuencia de actualizaciones, claridad del changelog de seguridad, velocidad de respuesta ante reportes y si el equipo de desarrollo tiene tamaño suficiente para sostener el proyecto. Temas con ciclos de parcheo visibles y comunidad activa (Divi, Astra y GeneratePress son ejemplos conocidos de ese perfil) reducen el riesgo de quedarte colgado ante una falla futura. Popularidad sin mantenimiento es pasivo, no activo.

¿Cuáles son los errores más comunes tras un aviso como este?

• Actualizar y respirar tranquilo. El parche cierra la puerta nueva, no expulsa al ladrón que ya entró. Sin limpieza posterior, muchos sitios «parcheados» siguen comprometidos.
• Delegar todo en el firewall. Las reglas virtuales del WAF comprueban tiempo, pero son puente, no destino. Nadie debería vivir eternamente de reglas virtuales teniendo el parche disponible.
• Backups que nadie restauró jamás. Un backup no probado es una suposición carísima. Probá una restauración al menos una vez al año, idealmente en un entorno aparte.
• Actualizar solo el tema. Avada arrastra su constructor y componentes asociados; dejá alguno desactualizado y el agujero sigue abierto aunque el panel diga «todo al día».

Preguntas Frecuentes

¿Cuál es el CVE de la vulnerabilidad de Avada?

La falla principal lleva el identificador CVE-2026-6279, un RCE pre-autenticación encadenable en seis pasos descubierto por Wordfence Argus. En el mismo ciclo se reportaron CVE-2026-4782 (lectura de archivos), CVE-2026-4798 (inyección SQL) y CVE-2026-8713 (borrado de archivos). Podés ver la ficha técnica del RCE en la base de vulnerabilidades de SentinelOne.

¿Qué versiones de Avada están afectadas?

Todas las versiones hasta la 3.15.2 inclusive. Las correcciones llegaron con la 3.15.3 (dos CVE) y la 3.15.4 (el tercero restante), así que 3.15.4 es hoy la versión mínima segura. El historial completo de fallas del tema está listado en WPScan.

¿Se está explotando activamente la vulnerabilidad de Avada?

Las fuentes consultadas no documentan campañas masivas de explotación al cierre de esta nota. Ojo con relajarse: los detalles técnicos ya son públicos, los escaneos automáticos suelen aparecer días después de cada publicación, y un millón de sitios potenciales es un objetivo demasiado grande.

¿Cómo actualizo Avada a la versión segura?

Andá a Escritorio → Actualizaciones en tu panel de WordPress (o Apariencia → Temas) y aplicá Avada 3.15.4 o superior. Hacé backup completo antes, y si tu licencia de soporte del tema venció, vas a necesitar renovarla para recibir el paquete actualizado. Después del update, corré un escaneo de malware.

¿Qué puntaje CVSS tiene la vulnerabilidad de Avada?

CVE-2026-8713 (borrado arbitrario de archivos) tiene un CVSS de 9.1, nivel crítico. Para el RCE principal (CVE-2026-6279), Wordfence lo clasifica como crítico en su aviso; el valor numérico exacto figura en su base de threat intel junto al resto de los CVE del tema.

Conclusión

Lo que cambió: Wordfence Argus demostró, con CVE-2026-6279, que un tema tan maduro como Avada puede esconder un RCE completo sin autenticación, armado con piezas que por separado parecen inocuas. Lo que importa: más de un millón de sitios comparten esa misma superficie de ataque, y el exploit requiere cero credenciales.

Lo que hacés hoy: actualizá a 3.15.4 o superior, revisá logs y usuarios admin, y corroborá tus backups. Son quince minutos de trabajo que evitan semanas de desastre. La popularidad de un tema no lo protege; lo expone. Mantenimiento constante o riesgo constante. Elegí uno.

Fuentes

• Wordfence Blog – Anuncio oficial del RCE de 6 pasos en Avada (agosto 2026)
• Wordfence Threat Intel – Base de vulnerabilidades del tema Avada
• SentinelOne Vulnerability Database – Ficha de CVE-2026-6279
• Okitup – Análisis de CVE-2026-8713 en Avada Builder
• INCIBE-CERT – Bitácora de seguridad sobre la vulnerabilidad crítica en Avada Builder