CVE-2026-19949 en All-in-One WP Migration: qué revisar antes de restaurar

Respuesta corta: si una web usa All-in-One WP Migration and Backup 7.109 o anterior, actualiza a 7.110 o una versión posterior antes de importar o restaurar un archivo. CVE-2026-19949 es una inyección SQL de segundo orden: la entrada maliciosa puede quedar almacenada y adquirir efecto más tarde, cuando un administrador ejecuta una restauración. Actualizar corrige la ruta vulnerable, pero no demuestra por sí solo que una restauración anterior fuera limpia.

Esta alerta está dirigida a agencias, freelancers y responsables que administran varias webs WordPress. Los datos de versión, mecanismo y severidad proceden de Wordfence, el registro CVE y la ficha oficial del plugin en WordPress.org. La priorización por condiciones y el flujo de respuesta son criterio editorial de WSN/Vulnity. No hay confirmación primaria de explotación generalizada en el momento de esta revisión.

Publicado y revisado el 4 de septiembre de 2026.

Datos verificados de CVE-2026-19949

Dato	Estado verificado	Implicación operativa
Componente	All-in-One WP Migration and Backup	Busca el plugin por slug y por nombre en toda la cartera.
Versiones afectadas	Hasta 7.109 inclusive	No importes ni restaures con una versión dentro de ese rango.
Versión corregida	7.110	Actualiza y confirma la versión realmente observada en cada sitio.
Tipo	Inyección SQL de segundo orden durante la restauración de archivos	La entrada y el efecto no ocurren necesariamente en el mismo momento.
Impacto descrito	Extracción de información sensible y posible ejecución remota de código mediante la cadena documentada	Una restauración realizada con la versión vulnerable merece revisión adicional.
Severidad	CVSS 8.8, alta, según el registro CVE publicado por Wordfence como CNA	Prioridad alta, pero condicionada por versión y actividad de restauración.
Adopción	Más de 5 millones de instalaciones activas según WordPress.org	Es probable que aparezca en carteras heterogéneas; no equivale a 5 millones de sitios explotables.
Explotación activa	No confirmada por una fuente primaria revisada; no figura en CISA KEV al revisar	No la presentes como campaña confirmada, pero no retrases el parche.

La investigación de Wordfence describe una entrada plantada mediante la función de trackbacks de WordPress y procesada después por la restauración del archivo. El registro oficial de CVE-2026-19949 sitúa las versiones afectadas en 7.109 o anteriores y explica que la cadena puede exponer ai1wm_secret_key y conducir a ejecución remota de código. La ficha oficial del plugin en WordPress.org muestra la versión 7.110 y atribuye en su changelog la corrección de valores terminados en barra invertida al reporte responsable de Jack Taylor.

Importante: «más de 5 millones de instalaciones» describe la adopción del plugin, no el número de webs comprometidas ni siquiera el número exacto de instalaciones que siguen en 7.109. La exposición real de una cartera se calcula con su inventario observado.

Por qué esta vulnerabilidad no se parece a una SQLi inmediata

En una inyección SQL de segundo orden, el dato se introduce en una fase y se interpreta de forma peligrosa en otra. Según Wordfence, en esta cadena un atacante sin autenticar puede plantar entradas mediante trackbacks en una publicación pública. El contenido queda almacenado. La condición decisiva aparece cuando un administrador restaura posteriormente un archivo con la versión vulnerable del plugin.

Eso cambia la respuesta. No basta con preguntar «¿recibimos una petición sospechosa hoy?». También hay que preguntar «¿qué webs tenían la versión afectada?» y «¿en cuáles se ejecutó una restauración durante la ventana relevante?». Una copia que parece un artefacto pasivo forma parte del límite de confianza: restaurarla puede reintroducir datos antiguos, configuración y contenido de base de datos.

Juicio editorial: las operaciones de backup y migración deben tratarse como cambios privilegiados, no como simples tareas de mantenimiento. Antes de restaurar, una agencia debería validar la herramienta, el origen del archivo, el entorno de destino y el plan de verificación posterior.

Prioriza por condiciones, no solo por el CVSS

Condición	Qué comprobar	Decisión
Plugin ausente	Inventario actual y, si importa, historial de uso o restos de una migración reciente.	Documenta el descarte; no asumas que nunca estuvo instalado.
Versión 7.110 o posterior y sin restauraciones previas conocidas	Versión observada, fecha de actualización y cola de cambios.	Mantén la versión corregida y registra evidencia.
Versión 7.109 o anterior, sin restauración en curso	Estado del sitio y del plugin.	Pausa importaciones/restauraciones, actualiza y prueba el flujo en un entorno controlado.
Restauración realizada con una versión afectada	Fecha, archivo usado, origen, operador, logs disponibles y estado posterior.	Amplía la revisión; el parche posterior no descarta efectos previos.
No hay inventario o historial fiable	Sitios sin conexión, versiones desconocidas y cambios no documentados.	Trátalo como falta de evidencia, no como ausencia de exposición.

El catálogo KEV de CISA no incluía CVE-2026-19949 durante esta revisión. Esa ausencia solo significa que CISA no la había añadido al catálogo; no prueba que nadie haya intentado explotarla. Del mismo modo, una prueba de concepto pública o un titular de un tercero no equivalen a telemetría primaria de una campaña.

Checklist para una cartera WordPress

1. Obtén el denominador real

Lista todas las webs gestionadas y separa cuatro estados: plugin ausente, presente y corregido, presente y vulnerable, o versión desconocida. Incluye staging, copias de producción, sitios pausados y webs que solo se conectan durante tareas de mantenimiento. Una lista de «sitios revisados» sin sitios pendientes oculta el hueco más importante.

2. Congela restauraciones en versiones afectadas

Si detectas 7.109 o una versión anterior, no ejecutes una importación para «probar si funciona». Pausa el cambio, conserva el estado y actualiza primero. Si el plugin solo se instala de forma temporal para migraciones, comprueba la versión del paquete que guarda el equipo: reinstalar más tarde un ZIP antiguo puede reabrir la condición.

3. Actualiza y confirma el resultado

Despliega 7.110 o una versión posterior desde un origen legítimo. Después vuelve a consultar la versión en el sitio, prueba la función necesaria con un archivo controlado y registra quién hizo el cambio y cuándo. Un gestor central que muestre «actualización enviada» no sustituye la verificación en el destino.

4. Localiza restauraciones dentro de la ventana de exposición

Revisa tickets, registros de cambios, actividad administrativa, logs del hosting y documentación del equipo para identificar importaciones o restauraciones realizadas mientras el plugin seguía afectado. Anota también cuándo se creó cada archivo y de qué sistema procede. Si no existe historial suficiente, escribe esa limitación.

5. Revisa más allá de la versión si hubo una restauración vulnerable

La descripción técnica de Wordfence vincula la cadena con acceso a una clave del plugin y posible ejecución de código. Si una restauración coincide con la ventana vulnerable, compara usuarios administradores, plugins y temas instalados, archivos ejecutables modificados, tareas programadas, opciones sensibles y registros del hosting. Aumenta el alcance o escala a respuesta forense si aparecen indicios.

No conviertas la ausencia de una señal concreta en una garantía. Los logs pueden no cubrir todo el periodo y una restauración puede reemplazar parte del estado que querías investigar. Preserva evidencias antes de hacer más cambios.

6. Decide si rotar secretos y credenciales

No toda instalación afectada exige la misma rotación. Si hubo una restauración vulnerable o aparecen señales compatibles con acceso no autorizado, determina qué claves, credenciales de base de datos, usuarios, tokens, contraseñas de aplicación o accesos de hosting pudieron quedar en alcance. La rotación debe seguir el análisis de impacto y evitar dejar integraciones rotas o credenciales antiguas aún válidas.

7. Cierra con evidencia y riesgo residual

Registra: sitios en alcance, versiones antes y después, restauraciones localizadas, fuentes consultadas, acciones, verificación funcional, indicios encontrados y datos ausentes. La guía para cerrar alertas WordPress con evidencia propone el contrato señal → alcance → decisión → acción → verificación → riesgo residual. Aquí resulta especialmente útil porque parchear y revisar una restauración son dos preguntas distintas.

Qué puedes afirmar —y qué no— después de actualizar

Con evidencia suficiente	No demostrado solo por actualizar
La web ejecuta 7.110 o una versión posterior.	Que nunca recibió una entrada manipulada.
La siguiente restauración se probará con la ruta corregida.	Que una restauración anterior no procesó datos peligrosos.
La cartera revisada tiene un porcentaje concreto de cobertura.	Que los sitios sin conexión están limpios.
No aparecieron indicios en las fuentes y el periodo consultados.	Que no hubo compromiso en ningún momento.

Si necesitas ordenar varias exposiciones a la vez, el marco para priorizar vulnerabilidades en una cartera WordPress separa presencia, explotabilidad, impacto y capacidad de respuesta. CVE-2026-19949 merece prioridad por adopción e impacto, pero su cadena también permite tomar una decisión más precisa que «cinco millones de webs están en peligro».

Dónde encaja Vulnity y dónde no

Vulnity ayuda a centralizar señales, actividad sospechosa, hardening, bloqueos de IPs maliciosas cuando corresponde e informes entre varios WordPress. Esa vista común puede reducir el coste de coordinar una revisión de cartera, mantener visibles los sitios sin datos y documentar qué se hizo después de una restauración.

Las limitaciones son explícitas: Vulnity no detecta CVE-2026-19949, no identifica versiones vulnerables de All-in-One WP Migration y no inspecciona archivos .wpress ni valida restauraciones. Tampoco sustituye el parche, un WAF, un escáner de malware, backups probados, logs completos del hosting, gestión de secretos, recuperación ni análisis forense.

Conclusión: parchea antes de restaurar y revisa el historial

La acción inmediata es sencilla: localiza All-in-One WP Migration, pausa restauraciones en 7.109 o anteriores y actualiza a 7.110 o más reciente. La parte que diferencia una respuesta rigurosa de una actualización rutinaria es revisar si ya se restauró algún archivo mientras la versión era vulnerable y declarar qué evidencia existe.

Una copia de seguridad no es automáticamente fiable por llamarse «backup». Tiene procedencia, fecha, contenido y una herramienta que la interpreta. En este caso, la restauración es precisamente el momento que convierte un dato almacenado en un riesgo operativo.