CVE-2026-115806: falla crítica en Prime Mover WordPress

En pocas palabras: CVE-2026-115806, con CVSS 9.8, permite a un atacante sin login inyectar un objeto PHP serializado vía comentarios en Prime Mover – Backup and Migration (versiones ≤2.2.1). Al exportar o restaurar, el admin dispara la deserialización y habilita ejecución remota de código completa.

El 24 de octubre de 2026 se publicó el análisis de CVE-2026-115806, una falla de deserialización de objetos PHP en el plugin Prime Mover – Backup and Migration con CVSS 9.8. Un atacante sin cuenta puede dejar un comentario trampa en cualquier WordPress con el plugin instalado y lograr ejecución remota de código cuando el administrador hace una exportación o restauración.

Prime Mover – Backup and Migration es un plugin de WordPress desarrollado por codexonics para exportar, migrar y restaurar sitios completos. La vulnerabilidad afecta a todas las versiones hasta la 2.2.1 inclusive y está catalogada bajo CWE-502 (deserialización de datos no confiables), según el detalle técnico publicado por Strix.

¿Cómo logra un atacante inyectar el payload sin iniciar sesión?

El vector de entrada es el formulario de comentarios estándar de WordPress, el mismo que usa cualquier visitante para dejar una opinión en un post. Un atacante anónimo manda un comentario donde el «texto» en realidad es un objeto PHP serializado codificado en base64, y WordPress lo guarda sin problema en la tabla wp_comments, campo comment_content.

Ahí está la parte incómoda del asunto: no hace falta robar credenciales, no hace falta phishing, no hace falta nada que requiera interacción del usuario. El comentario queda ahí, inerte, esperando.

¿Y cuándo se activa la bomba? Cuando el administrador del sitio hace lo que hace siempre: un backup de rutina. Para más detalles técnicos, mirá otra falla crítica detectada en asVereinbase.

¿Qué función del plugin dispara la deserialización insegura?

La función recursiveUnserializeReplace(), parte de la rutina de búsqueda y reemplazo de migración en PrimeMoverSearchReplace.php, es la que convierte el comentario envenenado en código ejecutable. Cuando un admin corre una exportación o restauración, Prime Mover recorre los datos del sitio (incluidos los comentarios) buscando URLs para reemplazar, y en ese proceso decodifica el base64 almacenado y lo pasa directo a unserialize().

El problema de fondo es que esa llamada a unserialize() no tiene la restricción allowed_classes activada. Eso significa que PHP va a instanciar cualquier clase que el objeto serializado le pida, sin preguntar si es segura o no. Es la receta clásica de PHP Object Injection: subís el comentario, esperás a que el admin exporte el sitio, el plugin decodifica el payload, lo deserializa sin filtro y ahí arranca la cadena que termina en ejecución de código.

¿Qué es la cadena POP que convierte la falla en ejecución remota de código?

La cadena POP (Property-Oriented Programming) que hace posible la ejecución remota está en FS_Clone_Manager::__set → FS_Option_Manager::set_option → store() → update_option(), dentro de la librería Freemius que Prime Mover trae empaquetada en su propia carpeta vendor. Esto quiere decir que el «gadget» necesario para explotar la falla no depende de ningún otro plugin ni tema instalado en el sitio: el atacante tiene todo lo que necesita usando solamente Prime Mover.

Una cadena POP es, básicamente, un conjunto de métodos mágicos de PHP (como __set o __wakeup) que un objeto serializado malicioso puede encadenar para forzar comportamientos no previstos por el desarrollador original. En este caso, el flujo termina llamando a update_option(), una función nativa de WordPress que modifica valores en wp_options, la tabla donde vive buena parte de la configuración del sitio. Desde ahí hasta la ejecución de código hay un paso corto si el atacante elige bien qué opción sobreescribir. En la falla que afecta a WordPress desde 2016 profundizamos sobre esto.

¿Qué versiones de Prime Mover están afectadas y cuál es la versión segura?

Todas las versiones de Prime Mover hasta la 2.2.1 inclusive son vulnerables a CVE-2026-115806. Para aplicar la mitigación conviene revisar las referencias del fabricante, incluida la de Wordfence Threat Intelligence.

El puntaje CVSS 3.1 es 9.8 sobre 10, con vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Traducido: ataque explotable por red (AV:N), complejidad baja (AC:L), sin privilegios requeridos (PR:N), sin interacción de usuario necesaria más allá del admin que hace su backup habitual (UI:N), y compromiso total de confidencialidad, integridad y disponibilidad (C:H/I:H/A:H). La clasificación CWE es CWE-502, deserialización de datos no confiables. Si administrás un sitio con Prime Mover, el número de versión que tenés instalado hoy es el primer dato que tenés que chequear.

¿Qué está confirmado y qué no?

• Confirmado: la falla existe en todas las versiones hasta 2.2.1 inclusive, según el análisis de Strix.
• Confirmado: el CVSS es 9.8 y la deserialización ocurre sin restricción allowed_classes, según el análisis de Strix.
• Confirmado: el vector de entrada es el endpoint público de comentarios, sin necesidad de autenticación previa.
• No confirmado: no hay reporte público de explotación activa en sitios reales al momento de esta publicación. Eso puede cambiar apenas se publique un proof-of-concept funcional.
• No confirmado: no hay cifra oficial de cuántas instalaciones de WordPress corren versiones vulnerables de Prime Mover.

¿Cómo saber si mi WordPress está hackeado por esta vulnerabilidad?

La señal más directa está en la tabla wp_comments: buscá comentarios con contenido largo, sin sentido legible, que parezca una cadena base64 (letras, números y algunos signos +/= mezclados sin estructura de frase). Eso no es un comentario, es el payload esperando su turno.

Otras pistas a revisar:

• Opciones nuevas o modificadas en wp_options que no reconocés, sobre todo si aparecieron justo después de una exportación o restauración con Prime Mover.
• Accesos de administrador fuera de horario habitual o desde IPs que no son las tuyas ni las de tu equipo.
• Archivos modificados recientemente en el servidor que no coinciden con ningún despliegue o actualización que hayas hecho vos.
• Comentarios pendientes de moderación con contenido sospechoso que nunca llegaste a revisar antes de correr un backup.

Si encontrás alguna de estas señales después de haber usado Prime Mover en los últimos días, lo prudente es tratar el sitio como potencialmente comprometido y no simplemente borrar el comentario raro y seguir como si nada.

¿Cómo protegerse si usás plugins de backup o migración en WordPress?

Actualizar Prime Mover en cuanto el fabricante publique una versión corregida es el paso no negociable, sin excusas de «lo hago después». Mientras eso no pase, cualquier exportación o restauración que corras es una ruleta rusa. Sobre eso hablamos en cómo comparar Wordfence y Sucuri para parchear.

Más allá del parche, hay buenas prácticas que conviene mantener siempre activas cuando trabajás con plugins que tocan datos sensibles del sitio: moderar comentarios antes de cualquier operación de backup, activar autenticación en dos pasos para las cuentas de administrador y hacer auditorías de seguridad periódicas, no solo cuando sale una CVE con nombre y apellido. Si tu hosting incluye un firewall de aplicación web (WAF) que filtra patrones de ataque conocidos antes de que lleguen a tu instalación, mejor.

Errores comunes al manejar este tipo de vulnerabilidades

• Confiar en que «nadie va a encontrar mi sitio»: los scanners automatizados no eligen objetivos, prueban contra todo lo que encuentran indexado. El tamaño del sitio no es protección.
• Actualizar el plugin pero no revisar comentarios viejos: si el payload ya estaba guardado en wp_comments antes del parche, actualizar Prime Mover no borra lo que ya quedó almacenado en la base.
• Pensar que «es solo un plugin de backup, no maneja datos críticos»: justamente porque tiene permisos amplios para leer y modificar toda la base de datos es que una falla ahí es tan grave.
• Ignorar el CWE-502 como «cosa de desarrolladores»: la deserialización insegura es un vector recurrente en vulnerabilidades de plugins de WordPress, y entender el patrón ayuda a detectar el próximo caso antes de que se publique.

Preguntas Frecuentes

¿Qué es CVE-2026-115806?

CVE-2026-115806 es una vulnerabilidad crítica (CVSS 9.8) de deserialización de objetos PHP en el plugin Prime Mover – Backup and Migration para WordPress, que permite a un atacante sin autenticar ejecutar código remoto cuando un administrador hace una exportación o restauración del sitio. Cobertura relacionada: la filtración de memoria descubierta en Vercel.

¿Cómo funciona la vulnerabilidad en Prime Mover sin necesitar login?

El atacante usa el formulario público de comentarios de WordPress (wp-comments-post.php) para guardar un objeto PHP serializado codificado en base64 en la base de datos. Ese comentario queda inactivo hasta que el admin corre una exportación con Prime Mover, momento en el que el plugin deserializa el contenido sin validación. Nuestros colegas de donweb.news lo analizan en el caso donde el scanner de Next.js falló.

¿Qué versión de Prime Mover corrige la falla?

Todas las versiones de Prime Mover hasta la 2.2.1 inclusive están expuestas a CVE-2026-115806; para identificar una versión corregida y aplicar la mitigación conviene revisar las referencias del fabricante.

¿Cómo saber si mi WordPress está hackeado por este plugin?

Revisá la tabla wp_comments buscando entradas con texto codificado en base64 sin sentido legible, y chequeá wp_options por cambios recientes que coincidan con una exportación o restauración hecha con Prime Mover. Accesos de administrador inusuales también son señal de alerta.

¿Qué es un objeto PHP serializado y por qué es peligroso?

Un objeto PHP serializado es una representación en texto de una estructura de datos de PHP, pensada para guardarse o transmitirse y luego reconstruirse con unserialize(). Es peligroso cuando el código reconstruye un objeto que viene de una fuente no confiable sin restringir qué clases puede instanciar, porque eso permite que un atacante dispare métodos internos del sistema (una cadena POP) y termine ejecutando acciones que nunca debería poder ejecutar.

Conclusión

CVE-2026-115806 muestra algo que ya se repitió varias veces en el ecosistema de plugins de WordPress: un endpoint público pensado para algo tan inocuo como un comentario puede ser la puerta de entrada a ejecución remota de código, si en algún punto del flujo alguien deserializa datos sin filtrarlos. Aplicar la actualización correspondiente, en cuanto el fabricante la publique, no debería tomar más de cinco minutos.

Lo que sí toma más tiempo es revisar si tu base de datos ya tiene un comentario envenenado guardado desde antes del parche. Esa revisión, y no solo el update, es la que marca la diferencia entre estar protegido y estar protegido demasiado tarde.

Fuentes

• Wordfence Threat Intelligence – referencia citada en el análisis de Strix sobre CVE-2026-115806
• Strix – análisis técnico de CVE-2026-115806