WPvivid CVE-2026-1357: RCE en 900.000 sitios

La vulnerabilidad WPvivid CVE-2026-1357 es una falla crítica de ejecución remota de código (CVSS 9.8) en el plugin WPvivid Backup & Migration que permite a cualquier atacante sin autenticación subir archivos PHP arbitrarios y tomar control total de un sitio WordPress. Afecta todas las versiones hasta 0.9.123 y tiene más de 900.000 instalaciones activas expuestas. El parche llegó el 28 de enero de 2026 con la versión 0.9.124.

WordPress es un sistema de gestión de contenidos de código abierto desarrollado originalmente por Matt Mullenweg y Mike Little en 2003. Se utiliza para crear, publicar y administrar sitios web, blogs y tiendas en línea sin necesidad de conocimientos avanzados de programación.

Qué es CVE-2026-1357 en WPvivid

CVE-2026-1357 es una vulnerabilidad de ejecución remota de código sin autenticación en el plugin WPvivid Backup & Migration para WordPress, con una puntuación CVSS de 9.8 sobre 10. Afecta todas las versiones hasta la 0.9.123 inclusive y fue corregida el 28 de enero de 2026 con el lanzamiento de la versión 0.9.124.

Para ponerlo en perspectiva: CVSS 9.8 es casi el techo. Estamos hablando de una vulnerabilidad que un atacante anónimo, desde cualquier parte del mundo, puede explotar sin tener cuenta en tu sitio. El resultado posible es control total del servidor.

WPvivid Backup & Migration tiene más de 900.000 instalaciones activas según el repositorio de WordPress.org. No es un plugin marginal. Es uno de los más usados para backups y migraciones en WordPress, y justamente por eso el impacto potencial es tan grande.

Cómo funciona el ataque

La falla vive en la función que gestiona la recepción de backups desde otro sitio. El plugin tiene una característica que permite que un sitio WordPress «receptor» reciba archivos de backup enviados desde otro sitio «emisor». El problema está en cómo se valida ese proceso.

Según el análisis de Ostorlab, la vulnerabilidad combina dos fallas: una validación incorrecta en openssl_private_decrypt() y un path traversal no sanitizado en los nombres de archivo. Básicamente, el plugin acepta el nombre del archivo tal como llega en la petición, sin limpiarlo. Un atacante puede usar ../../shell.php como nombre de archivo, y el plugin lo escribe en un directorio accesible desde el navegador.

Una vez que hay un archivo PHP en un directorio público, ya terminó. Lo accedés desde el navegador, ejecutás lo que quieras en el servidor.

Eso sí: para que el ataque funcione, el sitio tiene que tener habilitada la opción «receive backup from another site». La clave de autenticación generada para esta función tiene una validez de aproximadamente 24 horas, lo que significa que el atacante necesita actuar dentro de esa ventana. Pero como veremos ahora, ese «requisito» no es tan restrictivo como suena.

Quién está en riesgo

Técnicamente, solo están expuestos los sitios que tienen activa la función de recepción de backups. Por defecto no está habilitada. Pero acá viene lo interesante: muchos admins la activan cuando hacen una migración o una sincronización entre staging y producción, y después la dejan prendida porque se olvidan de apagarla.

¿Cuántos de los 900.000 tienen esa opción activa? No hay cifras oficiales. Pero si el 10% la dejó encendida, estamos hablando de 90.000 sitios con exposición directa. Y los atacantes lo saben. Escanear sitios buscando el endpoint /?wpvivid_action=send_to_site con respuestas que indiquen que la función está habilitada es trivial con herramientas automatizadas.

BleepingComputer reportó que ya había actividad de escaneo masivo detectada poco después de la divulgación pública del CVE. No es una vulnerabilidad que espere.

Impacto potencial y escala

RCE sin autenticación en 900.000 sitios. Eso es lo que hay sobre la mesa.

En términos concretos, un atacante que explota esta vulnerabilidad puede: leer y modificar cualquier archivo del servidor, acceder a la base de datos (usuario, contraseñas, datos de clientes, pedidos si es WooCommerce), instalar backdoors que sobrevivan actualizaciones, redirigir tráfico a sitios de phishing, usar el servidor como parte de una botnet, o simplemente eliminar todo el contenido del sitio.

Para un sitio de e-commerce con WooCommerce, el escenario más preocupante es el robo silencioso de datos de tarjetas. Un atacante sofisticado no va a dejar rastros obvios. Va a plantar un skimmer en el checkout, recolectar datos durante semanas y salir sin hacer ruido. Cuando te enterás, ya pasaron meses (y las multas de PCI-DSS llegaron).

Cómo actualizar WPvivid a la versión segura

La versión segura es la 0.9.124 o posterior. La actualización tarda menos de dos minutos.

• Entrá al panel de WordPress y andá a Plugins > Plugins instalados
• Buscá «WPvivid Backup» en la lista
• Si hay una actualización disponible, vas a ver el link «Actualizar ahora» directamente
• También podés ir a Escritorio > Actualizaciones para ver todas las pendientes de una vez
• Si usás la versión PRO, verificá también en el panel de WPvivid si hay actualización disponible para la versión premium

Si por alguna razón no podés actualizar desde el panel (servidor con problemas de conexión, plugin roto), descargá la versión 0.9.124 desde el repositorio oficial de wordpress.org, descomprimí el zip y subí los archivos vía FTP reemplazando los existentes en wp-content/plugins/wpvivid-backuprestore/.

Una cosa más: si tenés múltiples sitios en la misma instalación de WordPress (multisite) o si replicás configuraciones entre staging y producción, actualizá en todos los entornos. Un staging vulnerable con acceso a la base de datos de producción es un vector de ataque igual de válido.

Medidas de protección adicionales

Actualizar es el paso uno. Pero si tenés el tiempo, hay algunas cosas más que vale hacer.

Deshabilitá «receive backup from another site» si no lo usás activamente. En el panel de WPvivid, andá a la configuración de transferencia de backups y desactivá esa opción. Si no la necesitás, que no esté disponible.

Bloqueá el acceso directo a wp-content/uploads para archivos PHP. El ataque requiere que el archivo PHP sea accesible desde el navegador. Si agregás una regla en tu .htaccess o en la configuración del servidor para denegar la ejecución de PHP en el directorio de uploads, el impacto de cualquier upload malicioso se reduce drásticamente. En Apache:

<Directory /wp-content/uploads>
php_flag engine off
</Directory>

Activá un WAF. Wordfence tiene reglas específicas para bloquear requests maliciosos a endpoints de WPvivid. Si tenés el firewall activo y actualizado, debería bloquear intentos de explotación incluso en versiones vulnerables (aunque eso no reemplaza actualizar).

Revisá logs de acceso. Si no miraste los logs en las últimas semanas, ahora es un buen momento. Buscá peticiones POST a /?wpvivid_action=send_to_site con códigos 200 en las últimas semanas. Si encontrás algo, tomalo en serio.

Cómo detectar si fue explotado

Supongamos el peor caso: el plugin estaba vulnerable y sin actualizar hace semanas. ¿Cómo sabés si alguien lo aprovechó?

Primero, buscá archivos PHP sospechosos en directorios que no deberían tenerlos:

• wp-content/uploads/ y sus subdirectorios
• wp-content/wpvivid/ (directorio de trabajo del plugin)
• Cualquier directorio de backups configurado en WPvivid

Los nombres típicos de webshells que plantan los atacantes: shell.php, cmd.php, c99.php, r57.php, admin.php en directorios donde no debería haber un admin.php. También buscá archivos con nombres aleatorios tipo a3f7b2.php.

En Linux, un comando como find /wp-content/uploads -name "*.php" -newer wp-config.php te muestra archivos PHP creados después de que instalaste WordPress. Si encontrás algo ahí, lo más probable es que no sea tuyo.

Segundo, revisá los logs del servidor web. Si usás Donweb u otro hosting con cPanel o Plesk, los logs de acceso están disponibles en el panel. Buscá peticiones POST al endpoint mencionado, especialmente con respuestas 200 desde IPs desconocidas.

Si encontrás indicios de compromiso, no apagues ni sobrescribas nada antes de hacer un snapshot. Después contactá a tu hosting para que revisen a nivel de servidor. Un scanner como Wordfence o Sucuri puede ayudar a identificar archivos modificados, pero hay malware que evita los scanners comunes, así que no te quedes solo con eso.

Diferencia con otras vulnerabilidades de backup en 2026

En 2026 también salió a la luz CVE-2026-6227, una vulnerabilidad en BackWPup. Pero es un LFI (Local File Inclusion), requiere autenticación como editor, y tiene una puntuación CVSS bastante más baja. Está catalogada como «alta» pero no «crítica».

La diferencia con WPvivid es sustancial. Un LFI con autenticación requiere que el atacante ya tenga una cuenta con privilegios en el sitio. Un RCE sin autenticación requiere cero. Literalmente cualquiera con acceso a internet puede intentarlo.

Si usás BackWPup también tenés que actualizar, claro. Pero la urgencia no es comparable. WPvivid CVE-2026-1357 es del tipo de vulnerabilidad que los atacantes explotan de forma masiva y automatizada en cuestión de días después de la divulgación.

Errores comunes al responder a este tipo de alertas

Error 1: «Lo voy a actualizar el fin de semana». Con vulnerabilidades de CVSS 9.8 sin autenticación, el fin de semana puede ser tarde. Según el análisis de Indusface, la actividad de escaneo automatizado arranca a las horas de la divulgación pública. La ventana de exposición importa.

Error 2: Asumir que el plugin estaba desactivado, no instalado. Un plugin desactivado pero instalado puede seguir siendo vulnerable. En WordPress, algunos endpoints de plugins responden aunque el plugin esté desactivado, dependiendo de cómo esté construido. Si lo tenés instalado, actualizalo o borralo.

Error 3: Actualizar y no revisar si ya hubo acceso. Actualizar cierra la puerta, pero no limpia lo que ya entró. Si el plugin estuvo vulnerable por semanas antes de que te enteraras, la actualización no elimina ningún webshell que ya estuviera plantado. Necesitás buscar activamente y verificar.

Error 4: Confiar solo en el scanner de malware. Los scanners son útiles pero no infalibles. Los atacantes sofisticados usan ofuscación para que sus webshells no aparezcan en búsquedas de strings típicos. El scanner dice «limpio» pero el shell sigue ahí, codificado en base64 y ejecutándose cada vez que alguien accede a una URL específica. El análisis manual de archivos recientes en directorios clave es necesario como complemento.

Preguntas Frecuentes

¿Qué es la vulnerabilidad CVE-2026-1357 en WPvivid?

CVE-2026-1357 es una vulnerabilidad crítica (CVSS 9.8) de ejecución remota de código en el plugin WPvivid Backup & Migration para WordPress, que afecta todas las versiones hasta la 0.9.123. Permite a un atacante sin cuenta en el sitio subir archivos PHP arbitrarios y ejecutar código en el servidor. El parche está disponible en la versión 0.9.124, lanzada el 28 de enero de 2026.

¿Cómo actualizo WPvivid Backup a la versión segura?

Andá a Escritorio > Actualizaciones en tu panel de WordPress y buscá WPvivid en la lista de plugins con actualizaciones disponibles. También podés ir directo a Plugins > Plugins instalados y clicar «Actualizar ahora» en WPvivid. La versión objetivo es 0.9.124 o posterior. Si usás la versión PRO, verificá también las actualizaciones desde el panel de WPvivid.

¿Mi sitio WordPress está en riesgo por WPvivid?

Estás en riesgo si tenés WPvivid Backup en versión 0.9.123 o anterior con la opción «receive backup from another site» habilitada. Si la opción está desactivada, el vector de ataque principal no aplica, pero igual actualizá. Si ya estás en versión 0.9.124 o posterior, estás protegido contra esta vulnerabilidad específica.

¿Qué versión de WPvivid es segura?

La versión 0.9.124, lanzada el 28 de enero de 2026, incluye el parche para CVE-2026-1357. Cualquier versión 0.9.124 o posterior está protegida contra esta falla específica. Verificá la versión instalada en Plugins > Plugins instalados en tu panel de WordPress.

¿Cómo sé si alguien explotó esta vulnerabilidad en mi sitio?

Buscá archivos PHP en wp-content/uploads/ y en el directorio de WPvivid que no deberían estar ahí (webshells típicos: shell.php, cmd.php, o archivos con nombres aleatorios). Revisá los logs de acceso HTTP buscando peticiones POST a /?wpvivid_action=send_to_site desde IPs desconocidas con respuestas 200 en las últimas semanas. Un scanner como Wordfence puede ayudar, pero complementalo con revisión manual de archivos recientes.

Conclusión

CVE-2026-1357 en WPvivid es una de esas vulnerabilidades donde no hay mucho debate: CVSS 9.8, sin autenticación, más de 900.000 instalaciones, y explotación activa reportada desde los días posteriores a la divulgación. La respuesta correcta es una sola: actualizar a 0.9.124 hoy.

Si gestionás varios sitios WordPress, este tipo de fallas son el argumento más claro para tener un proceso de actualización regular y monitoreado. Un sitio desatendido durante tres semanas después de que salga una vuln crítica en un plugin popular es un sitio comprometido esperando que alguien lo descubra. Miralo desde ese ángulo.

Lo bueno, si algo tiene de bueno, es que el parche llegó el mismo día en que la vulnerabilidad empezó a circular ampliamente. El equipo de WPvivid respondió rápido. Ahora la responsabilidad es de cada admin que tiene el plugin instalado.

Fuentes

• BleepingComputer – WordPress plugin with 900K installs vulnerable to critical RCE flaw
• Ostorlab – CVE-2026-1357 Unauthenticated RCE en WPvivid (análisis técnico)
• Indusface – CVE-2026-1357 WordPress RCE WPvivid Plugin
• Security Boulevard – CVE-2026-1357 WordPress Plugin RCE Exposes Sites to Full Takeover
• SentinelOne Vulnerability Database – CVE-2026-1357