En pocas palabras: La vulnerabilidad CVE-2026-19949 (CVSS 8.8) en All-in-One WP Migration and Backup expone más de 5 millones de sitios WordPress a inyección SQL sin autenticación: cualquier visitante puede extraer la secret key del plugin y lograr ejecución remota de código. Actualizá a la versión 7.110 de inmediato.
All-in-One WP Migration padece una vulnerabilidad de inyección SQL de segundo orden (CVE-2026-19949, CVSS 8.8) que afecta más de 5 millones de sitios WordPress activos. Wordfence la reportó el 14 de agosto de 2026: el atacante puede extraer la secret key del plugin y potencialmente ejecutar código de forma remota. La versión parcheada es la 7.110. Si tenés algo anterior, actualizá ya.
En 30 segundos
- La vulnerabilidad CVE-2026-19949 (CVSS 8.8) en All-in-One WP Migration afecta todas las versiones anteriores a 7.110.
- Es unauthenticated SQL injection de segundo orden: cualquier visitante puede iniciar el ataque, sin cuenta ni sesión.
- Más de 5 millones de sitios WordPress están expuestos.
- El exploit permite extraer la secret key del plugin y potencialmente lograr ejecución remota de código.
- Solución inmediata: actualizar a 7.110 desde Escritorio > Actualizaciones.
¿Qué es la vulnerabilidad SQL injection en All-in-One WP Migration?
All-in-One WP Migration and Backup es un plugin de ServMask que permite exportar, importar y restaurar sitios WordPress completos sin tocar código. Con más de 5 millones de instalaciones activas, es uno de los plugins de migración más usados del ecosistema WordPress. La CVE-2026-19949 es una inyección SQL de segundo orden, sin autenticación requerida, calificada con CVSS 8.8 (Alto) y reportada por Wordfence el 14 de agosto de 2026.
El punto crítico: «sin autenticación» significa que cualquier visitante del sitio puede iniciar el ataque. No hace falta ser administrador ni editor. Eso eleva considerablemente el riesgo frente a otras vulnerabilidades donde el atacante primero necesita comprometer una cuenta con privilegios.
Esta no es la primera vez que el plugin aparece en los reportes de seguridad este año. En 2026 ya acumuló al menos otras dos CVEs: CVE-2026-17533 (instalaciones multisite, versiones anteriores a 7.108) y CVE-2026-5753. Tres CVEs en el mismo plugin en lo que va del año es un número que conviene tener presente al evaluar cuánto confiás en él para operaciones críticas.
¿Cómo funciona esta inyección SQL de segundo orden?
La «gracia» del SQL de segundo orden es precisamente esa: el atacante no necesita estar presente cuando el daño se produce. El payload malicioso no se ejecuta en el momento de inyectarlo, sino más tarde, cuando otro proceso lo procesa.
- Primera etapa (inyección): el atacante carga un archivo de respaldo (.wpress) que contiene SQL malicioso embebido en los metadatos o en el contenido serializado. No necesita privilegios para esto.
- Segunda etapa (ejecución): cuando un administrador restaura ese archivo, WordPress procesa el SQL embebido y lo ejecuta contra la base de datos real del sitio.
- Resultado: el atacante puede extraer la secret key del plugin, leer datos de la base de datos y, en combinación con otras técnicas, potencialmente lograr Remote Code Execution (RCE).
Ponele que sos administrador de un sitio y alguien te manda un archivo wpress «para que veas cómo quedó la migración». Lo restaurás en tu instancia de staging, que tiene los mismos plugins activos. Eso es suficiente para que el exploit funcione (sí, en serio, no necesitás hacer nada más raro que eso). Ya lo cubrimos antes en fortalecer la base de datos contra inyecciones SQL.
Subís el archivo, el plugin lo acepta sin validar el origen, un administrador lo restaura en cualquier momento del futuro, el SQL se ejecuta contra la base de datos real, y para cuando alguien nota que algo está mal, los datos ya están fuera del servidor.
Por eso se llama «de segundo orden»: dos eventos separados, dos actores distintos. La separación temporal entre la inyección y la ejecución es lo que hace a este tipo de vulnerabilidad más difícil de detectar con los controles habituales.
¿Qué versiones de All-in-One WP Migration están afectadas?
Todas las versiones anteriores a 7.110 son vulnerables a CVE-2026-19949. Para CVE-2026-17533, que afecta específicamente instalaciones multisite, el umbral es la versión 7.108. La versión 7.110 es la primera que cierra ambas vulnerabilidades.
| Versión instalada | CVE-2026-19949 | CVE-2026-17533 (multisite) | Acción recomendada |
|---|---|---|---|
| Anterior a 7.108 | Vulnerable | Vulnerable | Actualizar directo a 7.110 |
| 7.108 o 7.109 | Vulnerable | Parcialmente parcheada | Actualizar a 7.110 |
| 7.110 o superior | Parcheada | Parcheada | Segura al momento del reporte |
Ojo: si usás extensiones pagas del plugin (la extensión multisite, la de Dropbox o cualquier addon de ServMask), verificá sus actualizaciones por separado. El parche del plugin base no cubre automáticamente los addons.
¿Cómo verificar si tu sitio WordPress está vulnerable?
Verificar la versión instalada lleva menos de un minuto. Desde el panel de WordPress, entrá a Plugins > Plugins instalados, buscá «All-in-One WP Migration» y mirá el número de versión debajo del nombre. Si es menor a 7.110, el sitio está expuesto. Más contexto en implementar monitoreo de seguridad especializado.
- Dashboard de WordPress: Plugins > Plugins instalados > verificar número de versión en la descripción del plugin.
- Via wp-cli (SSH): ejecutá
wp plugin get all-in-one-wp-migration --fields=version. Devuelve la versión en segundos sin entrar al panel. - Via REST API:
/wp-json/wp/v2/pluginslista todos los plugins con sus versiones actuales (requiere autenticación de administrador).
Si tenés Wordfence o algún plugin de monitoreo de vulnerabilidades activo, probablemente ya recibiste una alerta. Si no tenés ningún sistema de alertas, este incidente sirve como señal para instalar uno: detectar una CVE semanas después del reporte es demasiado tarde si alguien aprovechó la ventana.
Guía paso a paso para actualizar All-in-One WP Migration
Antes de tocar el plugin, hacé un backup completo del sitio usando una herramienta externa. Actualizar un plugin de migración sin backup previo tiene una ironía particular que no vale la pena descubrir.
- Paso 1 — Backup previo: usá una solución a nivel servidor (cPanel, snapshots del hosting) independiente del plugin que vas a actualizar. No uses All-in-One WP Migration para hacer el backup de sí mismo.
- Paso 2 — Ir a Escritorio > Actualizaciones: WordPress lista automáticamente los plugins con nuevas versiones disponibles.
- Paso 3 — Actualizar: marcá la casilla de All-in-One WP Migration y hacé clic en «Actualizar plugins». El proceso tarda entre 30 segundos y 2 minutos según la velocidad del servidor.
- Paso 4 — Verificar la versión: volvé a Plugins > Plugins instalados y confirmá que la versión dice 7.110 o superior.
- Paso 5 — Probar funcionalidad: generá un export de prueba para confirmar que el plugin opera correctamente tras la actualización.
¿Y si la actualización automática falla? En servidores con restricciones de red pasa a veces. La alternativa: descargar la versión 7.110 desde el repositorio oficial de WordPress, descomprimirla y subir los archivos via FTP sobreescribiendo wp-content/plugins/all-in-one-wp-migration/. Más manual, pero igual de efectivo.
Medidas preventivas después de la actualización
Actualizar cierra la puerta, pero si el sitio estuvo expuesto entre el 14 de agosto y tu actualización, hay pasos adicionales que conviene dar.
- Revisá los logs de acceso: buscá peticiones POST inusuales a endpoints del plugin, especialmente cargas de archivos .wpress desde IPs desconocidas en las semanas previas.
- Verificá usuarios administradores: cuentas nuevas con rol de administrador que no reconocés son una señal clásica de post-explotación.
- Comparación de archivos: comparalos contra la versión oficial descargada del repositorio. Archivos con fechas de modificación más recientes que la instalación original y contenido diferente merecen atención.
- Reinstalación completa si sospechás compromiso: el camino más seguro es restaurar desde un backup a nivel servidor anterior al período de exposición, no solo parchear el plugin.
Un WAF activo puede bloquear patrones de SQL injection incluso en la ventana entre el descubrimiento de una CVE y la actualización. No es un reemplazo para el parche, pero reduce el riesgo cuando hay demora. Si tu hosting en donweb.com o cualquier otro proveedor incluye backups diarios automáticos a nivel servidor, activarlos es la mejor red de seguridad complementaria a cualquier plugin de respaldo.
¿El respaldo externo al plugin es más confiable?
Para operaciones críticas: sí. El principio es simple: el respaldo más seguro es el que mantenés fuera del plugin. Snapshots del servidor a nivel de hosting, backups de base de datos via SSH con mysqldump, copias del sistema de archivos a nivel cPanel. Esos no dependen de que el plugin esté sano.
All-in-One WP Migration resuelve un problema real y tiene más de 5 millones de instalaciones activas por alguna razón. Pero plugins mantenidos activamente con equipos que responden rápido a CVEs generan más confianza que el número de instalaciones. La frecuencia de actualizaciones y el tiempo de respuesta ante reportes son las métricas que importan al evaluar cualquier herramienta con acceso a la base de datos. Esto se conecta con lo que analizamos en aplicar hardening integral en WordPress.
Qué está confirmado y qué no
- Confirmado: CVE-2026-19949 existe, CVSS 8.8, reportada por Wordfence el 14 de agosto de 2026.
- Confirmado: afecta todas las versiones anteriores a 7.110 del plugin.
- Confirmado: la vulnerabilidad es unauthenticated SQL injection de segundo orden.
- Confirmado: la versión 7.110 incluye el parche para CVE-2026-19949 y CVE-2026-17533.
- No confirmado al cierre de esta nota: casos documentados de explotación activa en producción a escala. Wordfence no reportó ataques masivos conocidos en el reporte inicial, pero la ventana de exposición estuvo abierta varias semanas.
- No confirmado: si las extensiones pagas del plugin tienen sus propios parches o comparten el mismo ciclo.
Errores comunes al manejar esta vulnerabilidad
Error 1: Creer que el atacante necesita una cuenta. La vulnerabilidad es unauthenticated. Cualquier visitante puede subir el archivo malicioso; solo hace falta que un administrador lo restaure en algún momento. No hay que comprometer primero una cuenta con privilegios para iniciar el ataque.
Error 2: Actualizar el plugin base y olvidar los addons. Si tenés extensiones pagas instaladas (Dropbox, Google Drive, multisite), cada una tiene su propio ciclo de actualizaciones. El parche de la versión base no las cubre automáticamente.
Error 3: Usar el mismo plugin para hacer el backup antes de actualizarlo. Si el sitio estuvo comprometido, el archivo wpress que genera el plugin vulnerable puede contener datos de una base de datos ya afectada. Para un punto de restauración confiable, usá una copia a nivel servidor, independiente del plugin.
Preguntas Frecuentes
¿Qué versión de All-in-One WP Migration está vulnerable?
Todas las versiones anteriores a 7.110 son vulnerables a CVE-2026-19949. Para la CVE-2026-17533, que afecta específicamente instalaciones multisite, el umbral es la versión 7.108. La versión 7.110, publicada tras el reporte de Wordfence del 14 de agosto de 2026, es la primera con los parches para ambas CVEs aplicados.
¿Cómo sé si mi sitio WordPress está afectado por esta vulnerabilidad?
Entrá a Plugins > Plugins instalados en el panel de WordPress y verificá el número de versión del plugin. Si es menor a 7.110, el sitio está expuesto. Con acceso SSH podés ejecutar wp plugin get all-in-one-wp-migration --fields=version para verificarlo sin entrar al panel. Lo explicamos a fondo en reforzar la seguridad con cabeceras HTTP.
¿Qué debo hacer si tengo All-in-One WP Migration instalado?
Actualizar a la versión 7.110 o superior de inmediato desde Escritorio > Actualizaciones. Antes de hacerlo, hacé un backup completo del sitio usando una herramienta externa al plugin. Si el sitio estuvo expuesto varias semanas antes de que te enteraras, revisá también los logs de acceso y el listado de usuarios administradores.
¿Cómo actualizar All-in-One WP Migration de forma segura?
La ruta más directa es Escritorio > Actualizaciones > marcar el plugin > Actualizar plugins. Si preferís hacerlo de forma manual, descargá la versión 7.110 desde el repositorio oficial de WordPress y subí los archivos via FTP sobreescribiendo la carpeta del plugin. En ambos casos, verificá que la versión quede en 7.110 o superior antes de restaurar ningún archivo externo.
¿Puedo confiar en All-in-One WP Migration después de la vulnerabilidad?
Tres CVEs en el plugin en lo que va de 2026 es un número para tener presente. El equipo de ServMask publica parches, lo que habla de mantenimiento activo. El riesgo mayor está en restaurar archivos wpress de fuentes externas no confiables: eso es el vector real de explotación. Si solo restaurás backups que generaste vos mismo desde instalaciones limpias, el riesgo es considerablemente menor.
Conclusión
La vulnerabilidad CVE-2026-19949 en All-in-One WP Migration dejó expuestos 5 millones de sitios WordPress durante semanas, con CVSS 8.8 y sin requerir autenticación para iniciar el ataque. El parche está disponible desde el 14 de agosto y la actualización a 7.110 lleva menos de dos minutos. No hay justificación para postergarlo.
Lo que cambia con esta CVE no es solo el número de versión: es entender que los archivos wpress de terceros son vectores de ataque reales. Tratá cualquier backup recibido de una fuente externa con la misma desconfianza que tratarías un ejecutable desconocido. Y si no tenés backups automáticos a nivel servidor funcionando hoy, este es el momento para activarlos, independientemente de qué plugin de migración uses.