Si tienes All-in-One WP Migration and Backup instalado en WordPress, hay una actualización que yo no dejaría pendiente para otro día.
El plugin ha sido afectado por CVE-2026-19949, una vulnerabilidad de inyección SQL de segundo orden sin autenticación que afecta a todas las versiones hasta la 7.109 inclusive. La versión 7.110 corrige el problema y, en el momento de publicar este artículo, sigue siendo la versión disponible en el repositorio oficial de WordPress.
No estamos hablando precisamente de un plugin desconocido. All-in-One WP Migration and Backup supera los 5 millones de instalaciones activas y se utiliza para migrar sitios, crear copias de seguridad y restaurar instalaciones completas de WordPress.
Y ahí está precisamente una de las razones por las que esta vulnerabilidad me parece especialmente preocupante.
Un plugin de migración y backups necesita trabajar con algunas de las partes más sensibles de una web: la base de datos, los archivos, plugins, temas y prácticamente todo aquello que necesitamos conservar cuando trasladamos o restauramos un WordPress.
Por eso, cuando aparece una vulnerabilidad que puede terminar exponiendo información sensible y, bajo determinadas condiciones, evolucionar hasta una ejecución remota de código (RCE), no creo que sea una actualización que debamos posponer hasta “cuando tengamos un rato”.
La recomendación inmediata es muy sencilla:
| Versión de All-in-One WP Migration | Estado | Qué hacer |
|---|---|---|
| 7.109 o anterior | Vulnerable | Actualizar cuanto antes |
| 7.110 | Corregida frente a CVE-2026-19949 | Mantener actualizada |
| Una versión posterior | Comprobar que sigue siendo la última disponible | Mantener política de actualizaciones |
Wordfence asigna a CVE-2026-19949 una puntuación CVSS de 8.8, severidad alta, y describe una posible cadena que puede acabar en el control completo del sitio.
Así que, antes de entrar en detalles técnicos, mi recomendación es esta: si utilizas All-in-One WP Migration and Backup 7.109 o anterior, actualiza ya.
Después de hacerlo, sigue leyendo, porque actualizar soluciona la vulnerabilidad, pero si sospechas que el sitio pudo haber sido comprometido anteriormente, hay algunas comprobaciones que también merece la pena realizar.
Qué ha ocurrido con All-in-One WP Migration and Backup
El 14 de agosto de 2026, el investigador de seguridad Jack Taylor comunicó a Wordfence una vulnerabilidad localizada en All-in-One WP Migration and Backup. Wordfence validó el problema, lo notificó a ServMask —desarrollador del plugin— y la versión corregida 7.110 fue publicada el 20 de agosto de 2026.
La vulnerabilidad recibió el identificador CVE-2026-19949.
Su particularidad es que estamos ante una SQL Injection de segundo orden.
Esto significa que el código SQL malicioso no tiene por qué ejecutarse en el mismo momento en que el atacante introduce los datos manipulados. Esos datos pueden quedar almacenados y convertirse en peligrosos posteriormente, cuando otro proceso los recupera y los utiliza de una forma vulnerable.
Ese detalle es importante para entender este caso.
Qué es la vulnerabilidad CVE-2026-19949
Wordfence explica que un atacante no autenticado puede introducir datos especialmente preparados mediante la funcionalidad de trackbacks de WordPress en una entrada pública que acepte pings. Esos valores quedan almacenados en la tabla de comentarios.
En ese momento todavía no se produce necesariamente la inyección SQL.
El problema aparece después.
Cuando un administrador realiza determinadas operaciones normales del plugin —concretamente un proceso de exportación seguido de una importación/restauración— All-in-One WP Migration procesa la información almacenada en la base de datos para adaptar URLs y prefijos de tablas al sitio de destino.
En las versiones vulnerables existe un problema al procesar determinados valores terminados en barras invertidas. Esa situación puede hacer que datos controlados por el atacante terminen modificando la estructura de una consulta y sean interpretados como SQL ejecutable.
De hecho, el registro de cambios oficial de All-in-One WP Migration 7.110 menciona precisamente una corrección relacionada con la búsqueda y sustitución de valores que terminan en una barra invertida y agradece a Jack Taylor la divulgación responsable.
Por qué una inyección SQL en este plugin es especialmente preocupante
Una inyección SQL ya merece atención en prácticamente cualquier aplicación, porque la base de datos almacena buena parte de la información esencial de WordPress.
Pero, en mi opinión, aquí el contexto importa todavía más.
All-in-One WP Migration no es un pequeño complemento que añade un botón visual o cambia un color del tema. Su función consiste precisamente en exportar, importar, migrar y restaurar una web completa.
El propio plugin genera archivos .wpress que pueden incluir la base de datos, medios, temas y plugins de la instalación.
Eso implica necesariamente trabajar con información y operaciones especialmente sensibles.
Por eso llevo tiempo defendiendo una idea que este incidente vuelve a poner sobre la mesa: un plugin de copias de seguridad o migración no debe considerarse una herramienta secundaria desde el punto de vista de la seguridad.
Cuanto mayor sea el nivel de acceso que necesita una herramienta para hacer su trabajo, mayor debería ser también nuestra atención cuando aparece una vulnerabilidad.
Qué versiones de All-in-One WP Migration están afectadas
Aquí no hay demasiada ambigüedad.
Wordfence identifica como vulnerables a todas las versiones de All-in-One WP Migration and Backup hasta la 7.109 inclusive.
La versión corregida es la 7.110.
El repositorio oficial de WordPress muestra actualmente la versión 7.110 y su changelog incluye la corrección relacionada con los valores terminados en una barra invertida.
Versiones vulnerables hasta la 7.109
Si al entrar en tu instalación encuentras alguno de estos escenarios:
- All-in-One WP Migration 7.109.
- All-in-One WP Migration 7.108.
- Una versión 7.107, 7.106 o anterior.
- Una copia antigua del plugin que llevas tiempo sin actualizar.
deberías asumir que estás utilizando una versión afectada por CVE-2026-19949 y actualizar.
No me limitaría a pensar que una versión “solo un poco antigua” supone poco riesgo. En seguridad, la diferencia entre 7.109 y 7.110 en este caso es precisamente que una contiene el fallo y la otra incorpora la corrección.
También conviene tener especial cuidado con esas instalaciones antiguas que mantenemos desactivadas “por si algún día hacen falta”.
Un plugin desactivado reduce la superficie disponible en comparación con tenerlo permanentemente activo, pero yo evitaría conservar software vulnerable e innecesario dentro de la instalación. Si no necesitas un plugin, prefiero eliminarlo. Y si lo necesitas, mantenerlo actualizado.
Qué versión corrige la vulnerabilidad
La primera versión parcheada frente a CVE-2026-19949 es All-in-One WP Migration 7.110.
Wordfence indica que ServMask publicó esta versión el 20 de agosto de 2026, seis días después de recibir inicialmente el informe de la vulnerabilidad.
A fecha de esta revisión, WordPress.org continúa mostrando 7.110 como versión actual del plugin.
Dicho esto, mi recomendación no sería guardar mentalmente “7.110” como si tuviera que quedarse para siempre.
Si estás leyendo este artículo semanas o meses después de su publicación y existe una versión posterior, instala la última versión estable disponible, no una versión antigua simplemente porque fue la primera que corrigió este CVE.
Cómo funciona la vulnerabilidad de All-in-One WP Migration
La explicación técnica completa es bastante más compleja que “hay una inyección SQL en un formulario”.
De hecho, uno de los aspectos interesantes de CVE-2026-19949 es que necesita varias fases.
Esto también significa que no deberíamos interpretar “sin autenticación” como “cualquier visitante entra inmediatamente en tu servidor y ejecuta código con un clic”. Hay condiciones que deben cumplirse.
Pero tampoco deberíamos minimizar el problema.
Qué es una inyección SQL de segundo orden
En una SQL Injection convencional, solemos imaginar una entrada manipulada que llega a una consulta vulnerable y se ejecuta inmediatamente.
En una inyección SQL de segundo orden, la secuencia cambia.
Primero, el atacante consigue almacenar información especialmente preparada dentro del sistema.
Ese dato puede parecer inofensivo inicialmente.
Después, en otro momento y quizá mediante una operación completamente distinta, la aplicación recupera ese dato y lo utiliza al construir o procesar una consulta SQL. Es entonces cuando aparece el problema.
En este caso, Wordfence describe cómo determinados datos pueden introducirse a través de trackbacks y almacenarse en la tabla de comentarios de WordPress. Más tarde, durante el proceso de exportación e importación realizado por All-in-One WP Migration, esos datos son procesados y la vulnerabilidad puede activarse.
Por qué el ataque puede comenzar sin autenticación
Este es uno de los puntos que más me preocupan.
La primera fase no exige que el atacante tenga previamente una cuenta de administrador, editor o suscriptor.
Wordfence describe una introducción inicial de los valores manipulados mediante la funcionalidad de trackbacks de WordPress en una entrada pública que acepte pings.
Ahora bien, hay una condición fundamental que no debemos omitir: los datos maliciosos no se convierten automáticamente en SQL ejecutable en cuanto llegan al sitio.
Para que la cadena descrita continúe, un administrador debe realizar posteriormente un ciclo de exportación e importación/restauración con el plugin.
Wordfence subraya explícitamente este requisito.
Esta precisión es importante porque nos permite evaluar el riesgo correctamente: el ataque puede iniciarse sin autenticación, pero necesita también una acción posterior del administrador para que el payload almacenado llegue al proceso vulnerable.
El papel de la clave ai1wm_secret_key
Aquí es donde la vulnerabilidad se vuelve todavía más seria.
All-in-One WP Migration utiliza una clave secreta almacenada en la opción ai1wm_secret_key para proteger determinadas operaciones de importación.
Según el análisis técnico de Wordfence, la explotación de la inyección SQL puede utilizarse para obtener esa clave y hacerla accesible al atacante.
Esto cambia considerablemente el escenario.
Ya no estaríamos hablando únicamente de intentar leer determinada información de la base de datos.
La obtención de esa clave puede permitir al atacante superar la comprobación utilizada por el controlador de importación.
Cómo podría evolucionar el ataque hasta una ejecución remota de código
Una vez obtenida la clave secreta, Wordfence describe una fase posterior en la que el atacante puede utilizar directamente la funcionalidad de importación del plugin con un archivo .wpress especialmente preparado.
Ese archivo puede contener un must-use plugin malicioso que, al ser extraído en el directorio correspondiente, termina ejecutándose en WordPress.
El resultado potencial es Remote Code Execution o RCE.
Y cuando hablamos de ejecución remota de código, ya no estamos ante una filtración menor.
Estamos hablando de la posibilidad de comprometer completamente la instalación.
Qué podría hacer un atacante si consigue comprometer WordPress
Llegar a RCE significa que el atacante puede conseguir ejecutar código en el contexto del servidor web.
A partir de ahí, el alcance exacto dependerá de la configuración del hosting, permisos del sistema, aislamiento de la cuenta y otras medidas de seguridad.
Pero el escenario es suficientemente serio como para no conformarnos con decir que “puede acceder a algunos datos”.
Acceder o manipular información de la base de datos
WordPress depende intensamente de su base de datos.
Entradas, páginas, configuración, usuarios, hashes de contraseñas, opciones de plugins y multitud de datos relacionados con el funcionamiento del sitio terminan almacenados allí.
Una intrusión que permita manipular la base de datos podría utilizarse para cambiar configuraciones, alterar contenidos o preparar mecanismos adicionales de persistencia.
Por supuesto, el impacto concreto dependerá también de los plugins instalados y del tipo de web.
No contiene la misma información un pequeño blog que una tienda WooCommerce, una plataforma de membresía o una web que almacena datos de clientes.
Modificar archivos e instalar puertas traseras
Aquí entramos en una de las situaciones que más intentaría evitar.
Si un atacante consigue ejecutar código con los permisos del proceso web, podría intentar modificar archivos accesibles, introducir webshells, añadir código malicioso a plugins o temas o crear otros mecanismos que le permitan regresar posteriormente.
Por eso actualizar el plugin no debería confundirse con limpiar automáticamente una web que ya hubiera sido comprometida.
El parche corrige la vulnerabilidad.
Pero no viaja atrás en el tiempo ni elimina por arte de magia cualquier cambio que pudiera haberse producido antes de instalarlo.
Crear usuarios administradores y mantener acceso al sitio
Una técnica habitual después de comprometer un WordPress consiste en buscar persistencia.
Una nueva cuenta de administrador que nadie reconoce es una señal evidente, pero no es la única posibilidad.
También pueden existir modificaciones de archivos, tareas programadas, plugins desconocidos, código inyectado en una extensión legítima o cambios dentro de la base de datos.
Por eso, si tienes motivos reales para pensar que tu sitio pudo haber sido explotado, yo no limitaría la respuesta a pulsar “Actualizar” y dar el incidente por cerrado.
Qué hacer si tienes All-in-One WP Migration instalado
Si has llegado hasta aquí porque acabas de descubrir All-in-One WP Migration entre tus plugins, no hace falta complicarse.
Lo primero es comprobar la versión.
Cómo comprobar qué versión tienes instalada
Desde el panel de administración de WordPress:
- Entra en Plugins.
- Abre Plugins instalados.
- Localiza All-in-One WP Migration and Backup.
- Comprueba el número de versión.
- Si aparece 7.109 o una versión anterior, actualiza.
Si administras servidores mediante línea de comandos y tienes WP-CLI disponible, también puedes consultar la información del plugin desde allí, pero para la mayoría de usuarios comprobarlo desde el escritorio de WordPress será suficiente.
Actualizar All-in-One WP Migration a la última versión
Antes de realizar cambios importantes en una web, conviene disponer de una copia de seguridad funcional.
En este caso, si tienes opción, me parece especialmente razonable que esa copia de seguridad sea independiente del propio plugin que estás a punto de actualizar: por ejemplo, un snapshot proporcionado por el hosting o un sistema externo de backups.
Después:
- Entra en Escritorio → Actualizaciones o en Plugins.
- Localiza la actualización de All-in-One WP Migration.
- Instala la última versión disponible.
- Comprueba que la actualización ha finalizado correctamente.
- Verifica nuevamente el número de versión.
- Revisa brevemente las funciones principales de la web.
En el momento de redactar este artículo, 7.110 es la versión disponible en WordPress.org y la que contiene el parche frente a CVE-2026-19949.
Qué hacer si no puedes actualizar inmediatamente
Mi primera opción sería averiguar por qué no puedes actualizar y resolverlo cuanto antes.
Si existe una incompatibilidad, una web crítica que no puede modificarse sin pruebas o cualquier otro bloqueo operativo, reduce la exposición mientras preparas el parche.
Podrías valorar desactivar temporalmente el plugin si no necesitas utilizarlo y probar primero la actualización en staging.
Pero no convertiría una solución temporal en permanente.
Un WAF puede añadir una capa de protección adicional, y Wordfence desplegó una regla específica para sus usuarios Premium, Care y Response el 16 de agosto de 2026. Sin embargo, una protección perimetral no sustituye a corregir el software vulnerable.
Actualizar el plugin puede no ser suficiente
Este es probablemente el punto que más me interesa destacar.
Actualizar corrige la puerta de entrada conocida, pero no necesariamente elimina aquello que un atacante hubiera podido dejar dentro previamente.
Si únicamente tenías una versión vulnerable pero no existe ningún indicio de compromiso, actualizar puede ser la medida principal.
Si, por el contrario, encuentras actividad extraña, archivos sospechosos, administradores desconocidos o cualquier señal que te haga pensar que algo no cuadra, la respuesta debería ir más allá.
Revisar usuarios administradores desconocidos
Entra en Usuarios y revisa especialmente las cuentas con privilegios de administrador.
Pregúntate:
- ¿Reconozco todas?
- ¿Hay alguna creada recientemente?
- ¿Existe alguna dirección de correo que no corresponda con nadie del equipo?
- ¿Alguna cuenta tiene más privilegios de los que debería?
Una cuenta administrativa desconocida requiere investigación.
No me limitaría simplemente a borrarla y continuar trabajando como si nada, porque su presencia puede ser la consecuencia de un compromiso más amplio.
Comprobar archivos modificados recientemente
También revisaría cambios recientes en los archivos del sitio.
Prestaría especial atención a:
wp-content/plugins/wp-content/themes/wp-content/mu-plugins/- directorios de uploads donde no deberían aparecer archivos PHP
- archivos principales de WordPress modificados sin una actualización que lo justifique.
Comparar plugins y el core con copias limpias oficiales puede ayudar a detectar diferencias inesperadas.
El directorio mu-plugins merece especial atención en este incidente porque Wordfence describe precisamente una posible fase final de la explotación basada en importar un archivo que introduce un must-use plugin malicioso.
Revisar los logs del servidor y de WordPress
Los registros pueden ayudarnos a reconstruir qué ocurrió.
Si tienes acceso, revisaría:
- logs del servidor web;
- registros del WAF;
- logs del hosting;
- actividad administrativa;
- eventos anómalos próximos a procesos de exportación o restauración.
También resulta útil conocer si durante el periodo vulnerable se realizaron migraciones o restauraciones con All-in-One WP Migration, porque la cadena descrita necesita precisamente que un administrador realice una exportación seguida de una importación para ejecutar el SQL almacenado.
Buscar señales de puertas traseras o actividad sospechosa
Yo prestaría atención, entre otras cosas, a:
- nuevos administradores;
- plugins que nadie recuerda instalar;
- must-use plugins desconocidos;
- archivos PHP recientes;
- tareas programadas inesperadas;
- modificaciones de
.htaccess; - redirecciones extrañas;
- contenido spam;
- procesos o consumo de recursos anómalo.
Si confirmas un compromiso serio, lo más prudente puede ser trabajar desde una copia limpia conocida, rotar credenciales y claves y analizar completamente la instalación en lugar de intentar reparar únicamente los síntomas visibles.
Por qué los plugins de backup y migración son especialmente sensibles
Esta vulnerabilidad vuelve a demostrar algo que considero fundamental cuando se habla de seguridad en WordPress.
No todos los plugins tienen el mismo impacto potencial.
Un plugin que únicamente añade una pequeña funcionalidad visual no necesita necesariamente el mismo nivel de acceso que una herramienta diseñada para copiar y reconstruir una web completa.
Acceso a la base de datos, archivos y copias de seguridad
All-in-One WP Migration puede empaquetar un sitio en un archivo .wpress con su base de datos, medios, temas y plugins, y después restaurarlo en otra instalación.
Ese es precisamente su valor.
Pero esa capacidad también explica por qué debemos tratar con especial cuidado la seguridad de este tipo de herramientas.
Para realizar una migración correctamente, el plugin tiene que trabajar con:
- la base de datos;
- rutas internas;
- URLs;
- archivos;
- plugins;
- temas;
- contenido multimedia;
- datos serializados;
- procesos de importación y restauración.
No quiero decir con esto que utilizar un plugin de backups sea inseguro por definición.
Todo lo contrario: las copias de seguridad son una parte esencial de una estrategia de seguridad y recuperación.
Lo que digo es que una herramienta con tanto acceso debe mantenerse especialmente vigilada.
Por qué no deberían tratarse como plugins secundarios
A veces veo una distinción mental entre “plugins importantes” y “plugins que solo utilizo para hacer backups de vez en cuando”.
Ese planteamiento me parece peligroso.
Un plugin puede utilizarse una vez al mes y, aun así, tener permisos extremadamente potentes.
Precisamente porque estas herramientas pueden tocar prácticamente toda la instalación, yo las incluiría entre los componentes que más rápido actualizaría cuando aparece un aviso de seguridad.
Y también revisaría periódicamente si siguen siendo necesarias.
Si un plugin lleva meses instalado, no se utiliza y no existe ningún motivo para conservarlo, eliminarlo reduce superficie de ataque y mantenimiento.
Cómo reducir el riesgo ante futuras vulnerabilidades de WordPress
CVE-2026-19949 terminará desapareciendo de los titulares, pero habrá nuevas vulnerabilidades.
No solo en este plugin.
WordPress dispone de un ecosistema enorme de temas y extensiones y, estadísticamente, siempre aparecerán nuevos fallos.
La cuestión importante es cómo reducimos el tiempo durante el cual nuestras instalaciones permanecen expuestas.
Mantener plugins y temas actualizados
Actualizar el core es importante, pero no basta.
En mi caso, una de las conclusiones que saco de incidentes como este es precisamente esa: mantener WordPress actualizado significa mantener actualizado todo el ecosistema que ejecutamos sobre él.
Esto incluye:
- WordPress;
- plugins;
- temas;
- extensiones premium;
- componentes del servidor cuando estén bajo nuestra responsabilidad.
Para determinados plugins de confianza puede tener sentido utilizar actualizaciones automáticas, siempre que exista una estrategia de backups y supervisión adecuada.
Eliminar plugins que ya no utilizas
Si ya no necesitas una extensión, plantéate eliminarla.
Tener veinte plugins desactivados “por si algún día hacen falta” implica mantener veinte piezas de software adicionales que pueden envejecer y quedar olvidadas.
Menos componentes innecesarios significa menos cosas que actualizar, revisar y proteger.
Mantener copias de seguridad externas
También mantendría al menos una copia que no dependa exclusivamente de la propia instalación WordPress.
Puede ser:
- un sistema de backups del hosting;
- snapshots del servidor;
- almacenamiento remoto;
- una infraestructura externa de copias de seguridad.
La idea es sencilla: si WordPress queda completamente comprometido, quiero poder recuperar información desde un sistema que el atacante no haya podido modificar fácilmente desde esa misma instalación.
Monitorizar cambios y actividad sospechosa
Por último, intentaría no depender únicamente de descubrir una vulnerabilidad leyendo una noticia días después.
Alertas de vulnerabilidades, monitorización de cambios, registros centralizados y un WAF pueden reducir el tiempo entre el incidente y nuestra respuesta.
Ninguna de estas medidas sustituye a actualizar.
Pero varias capas trabajando juntas son mucho más útiles que confiar toda la seguridad de WordPress a una única herramienta.
¿Es seguro seguir utilizando All-in-One WP Migration?
Que un plugin tenga una vulnerabilidad no significa automáticamente que debamos dejar de utilizarlo para siempre.
El software complejo puede tener fallos.
Para mí son importantes también otros factores:
- la gravedad del problema;
- cómo responde el desarrollador;
- cuánto tarda en publicar una corrección;
- si existe mantenimiento activo;
- y si nosotros aplicamos esas actualizaciones.
En este caso, Wordfence notificó la vulnerabilidad a ServMask el 15 de agosto, el desarrollador reconoció el informe el día 17 y la versión corregida se publicó el 20 de agosto.
Eso no elimina la gravedad de CVE-2026-19949, pero sí es un dato relevante a la hora de valorar la respuesta del proyecto.
Por tanto, no diría que todo el mundo tenga que desinstalar All-in-One WP Migration exclusivamente por este incidente.
Sí diría algo mucho más claro:
no utilizaría una versión vulnerable del plugin y no mantendría instalada una copia antigua sin necesidad.
Si utilizas All-in-One WP Migration, mantenlo actualizado, vigila sus avisos de seguridad y asegúrate de disponer de backups independientes.
CVE-2026-19949 – All-in-One WP Migration and Backup
La vulnerabilidad CVE-2026-19949 de All-in-One WP Migration and Backup es un buen ejemplo de por qué los plugins de migración y copias de seguridad merecen tanta atención como cualquier otro componente crítico de WordPress.
Las versiones 7.109 y anteriores están afectadas por una inyección SQL de segundo orden sin autenticación que, bajo las condiciones descritas por los investigadores, puede utilizarse para filtrar la clave secreta del plugin y evolucionar posteriormente hasta una ejecución remota de código. La versión 7.110 contiene la corrección.
Lo que más me preocupa no es únicamente la etiqueta “SQL Injection”.
Es la combinación de factores:
- más de cinco millones de instalaciones activas;
- un plugin que trabaja directamente con backups, base de datos y archivos;
- una primera fase que no requiere autenticación;
- posibilidad de obtener una clave interna especialmente sensible;
- y un impacto potencial que puede terminar en RCE.
Por eso, si tienes instalado All-in-One WP Migration, yo no dejaría esta actualización para más adelante.
Comprueba la versión, actualiza y, si tienes motivos para sospechar que el sitio pudo haber sido comprometido, revisa también usuarios, archivos y registros.
Porque instalar el parche evita futuras explotaciones de esta vulnerabilidad, pero no elimina necesariamente aquello que un atacante hubiera podido introducir antes.
Una vez más, este incidente demuestra que mantener WordPress actualizado no debería limitarse al núcleo.
Los plugins forman una parte enorme de la superficie de ataque de cualquier web y, especialmente cuando hablamos de herramientas con acceso a copias de seguridad, bases de datos o archivos del servidor, reaccionar rápido puede marcar la diferencia entre hacer una simple actualización y tener que recuperar una web completamente comprometida.
Dudas de la comunidad
¿Qué es CVE-2026-19949?
CVE-2026-19949 identifica una vulnerabilidad de inyección SQL de segundo orden sin autenticación localizada en All-in-One WP Migration and Backup.
Wordfence le asigna una puntuación CVSS 8.8, severidad alta.
¿Qué versiones de All-in-One WP Migration son vulnerables?
Todas las versiones hasta la 7.109 inclusive están afectadas.
La primera versión corregida es 7.110.
¿A qué versión debo actualizar All-in-One WP Migration?
Debes instalar como mínimo la 7.110, que contiene el parche de CVE-2026-19949.
Si cuando lees esto existe una versión estable posterior, actualiza a la versión más reciente disponible.
¿Puede explotarse la vulnerabilidad sin iniciar sesión?
La primera fase descrita por Wordfence puede iniciarse sin autenticación mediante trackbacks enviados a un post público que acepte pings.
Sin embargo, la explotación no es completamente automática: el payload almacenado necesita que un administrador realice posteriormente un proceso de exportación seguido de una importación/restauración para que llegue al código vulnerable.
¿La vulnerabilidad permite ejecutar código en WordPress?
Potencialmente, sí.
Según Wordfence, la inyección SQL puede utilizarse para filtrar ai1wm_secret_key. Con esa clave, el atacante puede intentar utilizar el proceso de importación con un archivo preparado para introducir código malicioso y alcanzar ejecución remota de código.
¿Actualizar el plugin elimina una infección previa?
No necesariamente.
Actualizar corrige CVE-2026-19949 para impedir nuevas explotaciones mediante ese fallo, pero no elimina automáticamente archivos, usuarios, puertas traseras u otras modificaciones que pudieran haberse producido antes del parche.
Si existen indicios de compromiso, hace falta investigar y limpiar el sitio.
¿Cómo puedo saber si mi WordPress ha sido comprometido?
No existe una comprobación única que permita descartarlo al 100 %.
Yo empezaría revisando:
- usuarios administradores;
- archivos modificados;
mu-plugins;- plugins desconocidos;
- logs del servidor;
- actividad administrativa;
- tareas programadas;
- modificaciones inesperadas;
- alertas del WAF o sistema de seguridad.
Ante evidencias claras de intrusión, conviene realizar una revisión completa del sitio y no limitarse a actualizar el plugin.
¿Debo desinstalar All-in-One WP Migration?
No necesariamente.
La vulnerabilidad dispone de una versión corregida y el desarrollador publicó el parche 7.110.
Si necesitas el plugin, mantenlo actualizado.
Si ya no lo utilizas, mi recomendación general sería eliminarlo, exactamente igual que haría con cualquier otra extensión innecesaria de WordPress.
