El 20 de agosto salió la versión 7.110 de All-in-One WP Migration and Backup. Parcheaba el CVE-2026-19949, una inyección SQL de segundo orden con puntuación 8,8 que permite ejecutar código remoto sin autenticación. Hoy, 3 de septiembre, WordPress.org dice que solo el 35% de las instalaciones activas se ha actualizado. Eso deja unos 3,2 millones de sitios corriendo una versión vulnerable. Tres semanas después del parche.
Si gestionas webs en WordPress, seguro que conoces este plugin. Más de cinco millones de instalaciones activas lo convierten en una de las herramientas de backup y migración más usadas del ecosistema. Lo instalas, exportas el .wpress, lo importas en otro servidor y listo. Rápido, cómodo, casi mágico. Y precisamente esa comodidad es lo que me preocupa: hemos normalizado meter en producción un plugin que puede restaurar bases de datos enteras con una clave secreta guardada en la propia base de datos.
La cadena de ataque, según SecurityWeek y BleepingComputer, es elegante en el peor sentido posible. Un atacante anónimo envía un trackback malicioso a tu WordPress. Ese contenido queda almacenado. Cuando un administrador hace lo que cualquiera haría — exportar e importar el sitio con All-in-One WP Migration — el plugin reescribe URLs y prefijos de tablas en el SQL almacenado. La entrada envenenada se convierte en SQL ejecutable. El resultado: la clave secreta de importación (ai1wm_secret_key) acaba escrita en un comentario público y aprobado.
A partir de ahí, el atacante consulta la REST API de comentarios, recupera la clave y sube un archivo .wpress con un must-use plugin malicioso. Siguiente carga de página: ejecución remota. Sin contraseña. Sin panel de admin. Sin aviso visible para el cliente que te paga el mantenimiento mensual.
Lo que más me irrita no es la vulnerabilidad en sí. En un ecosistema con millones de plugins, fallar pasa. Lo que no cuadra es la combinación de factores: un plugin de backup usado en sitios de producción, una operación de importación técnicamente sin autenticación (protegida solo por una clave en la base de datos), y una comunidad que actualiza a ritmo de tortuga incluso cuando el fallo lleva la etiqueta de RCE en mayúsculas.
Wordfence descubrió el bug a mediados de agosto. ServMask publicó el parche el 20 de agosto. Llevamos dos semanas de difusión en medios especializados y el 65% de instalaciones sigue en versiones hasta la 7.109. ¿Por qué? Porque All-in-One WP Migration no es un plugin que revises cada semana. Lo instalas para una migración, lo dejas ahí «por si acaso», y el panel de WordPress te enseña una actualización de seguridad que compite con otras cuarenta notificaciones que también pospones.
En mi experiencia con pymes y agencias, el plugin de migración es el típico «set olvidado»: nadie lo desinstala después de mover el sitio, nadie comprueba si sigue activo en el cliente que migraste hace dos años, y casi nadie audita si alguien ya explotó la cadena de ataque antes del parche. Si restauraste un backup con una versión vulnerable entre el 15 y el 20 de agosto, merece la pena revisar si hay must-use plugins nuevos o cuentas de administrador que no reconoces. Wordfence lo dice explícitamente en su informe; yo lo repito porque casi seguro que nadie lo hará salvo que se lo exijas tu mismo.
Y aquí viene el choque con la otra gran noticia del ecosistema: WordPress acaba de anunciar su Core Security Initiative, con IA para cazar vulnerabilidades antes que los atacantes. Suena bien. Pero mientras el core se vuelve proactivo, el riesgo real sigue viviendo en plugins populares que acumulan millones de instalaciones y tasas de actualización vergonzosas. La iniciativa de seguridad del core no parchea tu All-in-One WP Migration desactualizado. No limpia el must-use plugin que alguien coló ayer. No sustituye un proceso de mantenimiento que trate los plugins de backup y migración como software crítico, no como utilidades desechables.
Tampoco ayuda que Patchstack califique la vulnerabilidad como «baja prioridad» y «poco probable de explotarse» en su base de datos, con un CVSS 8,8 al lado. Esa contradicción confunde a quien decide si actualizar hoy o el mes que viene. Cuando el mensaje es ambiguo, gana la pereza. Y la pereza, en WordPress, suele terminar en un .wpress con código dentro.
¿La solución? Actualizar a la 7.110 o superior. Ya. Si el plugin no lo usas, desinstálalo: un backup tool sin política de revisión es un backup tool que algún día te traiciona. Si lo necesitas, limita quién puede importar, monitoriza must-use plugins y no confíes en que «nadie atacará una web pequeña». Los ataques automatizados no miran tu facturación; miran si tienes el plugin vulnerable y la REST API de comentarios abierta.
El mercado de plugins de WordPress sigue premiando la facilidad de uso por encima de la higiene operativa. All-in-One WP Migration es un producto útil — lo he recomendado — pero este CVE demuestra que utilidad y superficie de ataque van de la mano cuando el flujo de importación es tan potente y tan poco vigilado. No basta con parchear: hace falta cambiar la mentalidad. Un plugin que puede reescribir tu base de datos entera debería tratarse como acceso root, no como un widget más en el escritorio.
Si mañana un cliente te pide migrar su tienda WooCommerce con All-in-One WP Migration porque «siempre lo hemos hecho así», ¿le exiges auditoría post-migración y desinstalación, o asumes que el parche del 20 de agosto ya cubrió el riesgo aunque lleves tres proyectos pendientes?