Claves robadas de UpdraftCentral siembran backdoors en WordPress

Un atacante entró en teamupdraft.com el fin de semana del 17 y 18 de octubre de 2026, se llevó las claves de conexión de UpdraftCentral y las usó durante 18 horas para instalar plugins con backdoor en sitios WordPress que tenían activo el cliente de gestión remota de UpdraftPlus, el plugin de copias de seguridad con más de cuatro millones de instalaciones. Patchstack contó 99 nombres distintos de plugin malicioso entre las 15:32 UTC del 18 de octubre y las 09:23 UTC del 19, y Nethemba registraba el 21 de octubre comandos del mismo atacante contra sitios que ya habían actualizado.

Qué ha pasado

TeamUpdraft, la empresa británica detrás de UpdraftPlus, WP-Optimize y All-In-One Security, publicó el 19 de octubre un aviso de incidente firmado por Joe Whittaker, que dirige producto, marketing y soporte en la compañía. El texto arranca así: «Over the weekend of 17-18 October we identified unauthorised access to the teamupdraft.com website» (durante el fin de semana del 17 y 18 de octubre identificamos un acceso no autorizado al sitio web teamupdraft.com). La empresa cree que el intruso llegó a la base de datos de clientes, con nombres, correos, direcciones de facturación, historial de pedidos, contraseñas en forma de hash, ajustes de doble factor y las claves de conexión de UpdraftCentral, UpdraftVault y UpdraftClone. Los datos de tarjeta no estaban ahí, porque los gestionan Stripe y PayPal.

El problema no se quedó en la filtración. La primera señal pública llegó de Nethemba, una empresa eslovaca de pentesting, que la madrugada del 19 de octubre recibió un correo automático de WordPress por un error en un plugin llamado Load Stack 35C que nadie había instalado. Su análisis descarta una a una las explicaciones del lado del sitio y concluye: «The attacker came in through the UpdraftCentral remote management channel» (el atacante entró por el canal de gestión remota de UpdraftCentral). Los comandos iban firmados con las claves privadas del panel, que nunca habían estado en sus servidores.

Patchstack confirmó el mismo día la campaña desde su telemetría. Dave Jong, responsable de investigación de seguridad de la empresa, lo deja claro en su informe: «This is not a vulnerability in UpdraftPlus» (esto no es una vulnerabilidad en UpdraftPlus). No hay fallo de código que parchear. Las peticiones pasaban todas las comprobaciones del plugin porque, vistas desde el sitio, eran legítimas. La única defensa era borrar la clave.

Es el segundo incidente de la semana en el ecosistema WordPress con el canal de confianza del fabricante como vector, tras el paquete de Rank Math PRO que sirvió un backdoor durante once horas. En ese caso el atacante tocó el servidor de descargas. En este no necesitó ni eso, le bastó con las claves que el propio servicio guarda para hablar con los sitios de sus clientes.

Detalles técnicos

UpdraftCentral es el servicio de gestión remota de TeamUpdraft, y su cliente viaja dentro de cada copia de UpdraftPlus, gratuita o Premium. Permanece dormido hasta que el sitio recibe una clave. En ese momento el sitio genera un par de claves RSA, guarda la clave pública del panel y, desde entonces, ejecuta cualquier comando firmado con la clave privada del panel con los permisos del usuario que creó la conexión. Nadie confirma cada orden. Nethemba comprobó en los sitios atacados que las claves eran RSA de 2.048 bits y que la librería phpseclib 2.0.55 que usa el plugin no tiene el fallo conocido de verificación de firmas. La criptografía aguantó. Lo que falló fue la custodia de las claves privadas en el servicio en la nube.

El diagrama resume la cadena tal como la describen Nethemba y Patchstack. El atacante envía un POST a la raíz del sitio con el comando plugin.upload_plugin y WordPress instala y activa el plugin adjunto con su instalador estándar. Antes de cada instalación llega un sondeo dirigido a una clave inexistente, probe.central.updraftplus.com, que sirve para saber si el sitio acepta comandos de UpdraftCentral. El tráfico del panel real se identifica con un User-Agent que incluye la versión de la librería (class-udrpc.php/2.0) y la URL de teamupdraft.com. El del atacante llevaba solo WordPress/6.4 y class-udrpc.php, sin ninguna de las dos cosas, y salía de su propio servidor.

El plugin instalado es un backdoor. En la primera variante, la que Nethemba analizó en su propio sitio, el código se engancha a la acción init con prioridad 1 y espera un parámetro GET con un token de 32 caracteres. Si coincide, crea un usuario como data-ops43 con contraseña fija, correo en example.org y nombre visible Site Tools, le asigna el rol Editor y le añade por separado las capacidades manage_options e install_plugins. Después lo autentica con una cookie de 14 días mediante wp_set_auth_cookie y lo redirige al panel. Como nunca pasa por el formulario de login, el doble factor, los límites de intentos y la protección de Wordfence no intervienen. La cuenta figura como Editor, así que una revisión rutinaria de administradores no la ve, y sobrevive a la eliminación del plugin.

Esa primera variante tenía un error de programación. Define las constantes con define() como globales y las lee como constantes de clase, de modo que PHP 8 lanza un error en cada petición antes de comprobar el token. El sitio responde con un error 500 y solo sirve páginas desde caché. Fue lo que alertó a las primeras víctimas en cuestión de minutos. Nethemba y Patchstack piden no reparar un plugin así, porque arreglar el error enciende el backdoor. Las dos fuentes describen después una segunda variante que funciona, con dos modos: sin parámetro adicional entra como el primer administrador existente y no deja rastro en la base de datos, y con m=setup crea un administrador completo con nombres como system_team850 o web.tech988. Una tercera variante mínima, de 673 bytes, solo inicia sesión como administrador, y una versión oculta de Site Health Cache se borra a sí misma de la lista de plugins con un filtro all_plugins mientras sigue activa.

Los indicadores que publican Patchstack y Nethemba son estos:

Patchstack propone estas comprobaciones, que buscan la descripción fija de la primera variante en los plugins y la cuenta Editor con capacidades de administrador por capacidad y no por nombre:

wp option get updraft_central_localkeys
grep -rl "Small maintenance toolkit: keeps option storage tidy\." /var/www/*/wp-content/plugins/
wp db query "SELECT u.user_login,u.user_email FROM wp_users u JOIN wp_usermeta m ON m.user_id=u.ID WHERE m.meta_key='wp_capabilities' AND m.meta_value LIKE '%editor%' AND m.meta_value LIKE '%manage_options%'"

Cualquier salida del primer comando significa que el sitio tiene una clave y está expuesto, aunque su dueño nunca haya abierto UpdraftCentral. Nethemba añade dos búsquedas en los registros del servidor web. La primera encuentra las peticiones de UpdraftCentral sin versión de librería en el User-Agent, como las del atacante, y la segunda localiza los disparos del backdoor de las variantes conocidas. Un estado 302 en esa segunda búsqueda significa redirección al panel y, casi con seguridad, que el atacante entró.

grep 'class-udrpc.php"' /var/log/apache2/*access*
zgrep -E '[?&](_[0-9a-f]{6}|[0-9a-f]{12})=[^&" ]{32}[& ]' /var/log/apache2/*access*

UpdraftPlus solo conserva los últimos 50 eventos del registro de UpdraftCentral, de modo que en un sitio muy visitado por escáneres la huella del ataque puede haber desaparecido de ese log y seguir en el del servidor. Quien no se fíe de la clave puede cortar el canal entero con el mu-plugin que propone Nethemba, que devuelve un 403 a cualquier petición con el campo udrpc_message antes de que UpdraftPlus la procese. Bloquea también las migraciones con UpdraftPlus Migrator, que usan el mismo canal.

<?php
// Nethemba: bloquea todos los comandos de UpdraftCentral (UDRPC) hasta que el fabricante resuelva el incidente de octubre de 2026.
if ( isset( $_POST['udrpc_message'] ) ) {
	http_response_code( 403 );
	exit;
}

El canal ya había fallado antes. En junio de 2026 Wordfence publicó el CVE-2026-10795, un salto de autenticación en UpdraftPlus hasta la 1.26.4 que permitía falsificar comandos de UpdraftCentral sin ninguna clave. NVD lo recoge con CVSS 3.1 de 8,1 y vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, en estado Deferred y sin entrada en el catálogo KEV de CISA a 21 de octubre. Se corrigió en la 1.26.5 y 2.26.5, y Nethemba sigue viendo intentos de explotarlo en sus logs. Los sitios por debajo de esas versiones tienen hoy los dos problemas a la vez.

A quién afecta

A cualquier sitio con UpdraftPlus, gratuito o Premium, que tenga una clave de UpdraftCentral creada contra el panel en la nube de TeamUpdraft. Las instalaciones autoalojadas de UpdraftCentral no están afectadas, según el fabricante. El matiz que explica por qué hay víctimas que juran no haber usado nunca el servicio está en la pantalla de inicio de sesión de la cuenta de teamupdraft.com dentro del plugin: la casilla Add this website to UpdraftCentral viene marcada por defecto, y basta con entrar en la cuenta para que el sitio genere una clave. Patchstack lo verificó en el código de admin.php y Nethemba en las versiones 2.26.11 y 1.26.13. Afecta sobre todo a sitios Premium, donde el dueño inicia sesión para la licencia y las actualizaciones.

No hay cifra oficial de sitios atacados. Nethemba parte de la estimación que dio el fabricante en junio, menos del 10 % de los usuarios con una clave de UpdraftCentral o Migrator, y calcula hasta unos 400.000 sitios expuestos, cifra que también recoge BleepingComputer. Patchstack habla de instalaciones de backdoor en un conjunto amplio de sitios sin dar número. TeamUpdraft reconoce en su actualización del 21 de octubre que el alcance de las cuentas y plugins creados por el atacante es desconocido. Una parte de las instalaciones nunca llegó a activarse porque el usuario dueño de la clave no tenía permiso para activar plugins, como ocurrió en el tercer sitio de Nethemba, y aun así esos sitios recibieron el fichero.

Las claves no caducan. Nethemba documenta el abuso de claves creadas en noviembre de 2025 y otro administrador le comunicó el abuso de claves de febrero y marzo de 2022 que seguían funcionando. Las copias de seguridad guardadas en el almacenamiento remoto del cliente (Google Drive, Dropbox, Amazon S3) no se vieron afectadas, aunque el fabricante pide volver a autorizarlas si el sitio fue accedido. En España, a 21 de octubre y en el momento de escribir esta noticia, no hemos localizado aviso de INCIBE-CERT ni del CCN-CERT sobre el incidente, ni un recuento de sitios afectados por país. UpdraftPlus es habitual en agencias y alojamientos españoles que gestionan decenas de instalaciones desde un panel, el perfil al que precisamente va dirigido UpdraftCentral.

Qué hacer

El árbol de decisión condensa las instrucciones de TeamUpdraft, Patchstack y Nethemba. En orden de urgencia:

1. Comprueba en cada sitio con UpdraftPlus si existe alguna clave de UpdraftCentral, con wp option get updraft_central_localkeys o en Ajustes, UpdraftPlus Backups, Herramientas avanzadas, UpdraftCentral. Hazlo también en los sitios donde crees que nunca activaste el servicio.
2. Actualiza UpdraftPlus a la 1.26.13 (gratuita) o 2.26.13 (Premium). La 1.26.12 y 2.26.12 del 19 de octubre no borran ninguna clave por un error que el fabricante corrigió esa misma noche. La 1.26.13 elimina las claves creadas antes de las 12:07 UTC del 18 de octubre. Las creadas entre las 12:07 y las 21:00 UTC de ese día siguen en el sitio y hay que borrarlas a mano.
3. Borra la clave en el propio sitio, con el botón Delete junto a cada clave o con wp option delete updraft_central_localkeys. Quitar el sitio del panel de teamupdraft.com no sirve, porque el atacante tiene la clave privada del panel. Si tienes alguna clave de Migrator que no uses, elimínala también con wp option delete updraft_migrator_localkeys.
4. Busca el backdoor con los comandos de arriba. Revisa la lista de plugins, incluida la pestaña Must-Use, los usuarios con correo en example.org o example.com, las opciones de wp_options terminadas en _sync_token, _uid, _installed o _ver, y el registro de UpdraftCentral en busca de probe.central.updraftplus.com seguido de Command received: plugin.upload_plugin.
5. Si encuentras un plugin sospechoso, borra primero la clave, desactívalo y sácalo fuera de la raíz web sin desinstalarlo desde el panel, porque su uninstall.php borra las opciones que sirven de prueba. Elimina sus opciones y cualquier cuenta que haya creado.
6. Si la cuenta existe o el log muestra una petición con el token, trata el sitio como comprometido. Restaura una copia anterior al 17 de octubre, compara los ficheros con una instalación limpia y revisa todos los usuarios con capacidades extra. Antes de elegir la copia conviene tener claros los objetivos de punto y tiempo de recuperación.
7. Rota credenciales. Contraseña de teamupdraft.com (tecleando la dirección, no desde un enlace de correo), contraseñas de todos los administradores, sesiones abiertas, doble factor de la cuenta del fabricante y, si el sitio fue accedido, las claves del almacenamiento remoto de copias.
8. Reconecta UpdraftVault en cada sitio con la nueva contraseña y lanza una copia de prueba. Si compartes las claves de UpdraftClone con clientes, envíales las nuevas desde Mi cuenta. Las antiguas ya no funcionan.
9. Refresca las reglas del firewall si usas Wordfence o Patchstack. Nethemba advierte de que la regla de Wordfence solo cubre UpdraftPlus hasta la 1.26.11 y por debajo de la 2.26.12, de modo que no protege a quien se quedó en la 1.26.12.
10. Notifica. Las empresas y particulares pueden acudir a INCIBE-CERT y el sector público al CCN-CERT. Si el sitio trata datos personales y confirmas el acceso, la brecha debe comunicarse a la AEPD en 72 horas.

Dos medidas baratas que Nethemba comprobó en sitios reales cierran la lista. Si PHP no puede escribir en wp-content/plugins, el sitio acepta el comando firmado pero la instalación falla, y así se paró el ataque en uno de los sitios afectados. Y el mu-plugin de arriba corta el canal entero mientras dure la incertidumbre.

Análisis

Para quien administra WordPress, lo preocupante no es el backdoor, que es tosco y en su primera versión ni siquiera funcionaba. Es el modelo de confianza. Un servicio en la nube guarda la clave privada que permite ejecutar código en cada sitio conectado, el sitio no confirma ninguna orden, la clave no caduca y se crea con una casilla marcada por defecto al iniciar sesión en la cuenta del fabricante. Cualquier fallo en el servidor del proveedor se convierte en acceso de administrador a decenas de miles de webs ajenas. Es el mismo patrón que vimos cuando una credencial robada de ConnectWise abrió 173 tenants de Microsoft 365: el proveedor cae y los clientes pagan.

Lo que no cuenta el aviso de TeamUpdraft pesa tanto como lo que cuenta. No explica cómo entró el atacante en teamupdraft.com, más allá de que usó una clave comprometida, ni cuántos sitios recibieron un backdoor. Su actualización del 20 de octubre sostiene que el acceso quedó resuelto y que la 1.26.13 bloqueó el vector, pero Nethemba seguía recibiendo comandos firmados desde 43.250.53.42 la mañana del 21 de octubre. Las dos cosas pueden ser ciertas a la vez: la brecha está cerrada y las claves robadas siguen valiendo en todo sitio que no haya actualizado ni borrado la suya. La propia empresa apunta en su resumen del 21 de octubre a que la velocidad de los ataques y los primeros backdoors defectuosos «suggest that the hackers used AI to accelerate their attack» (sugieren que los atacantes usaron IA para acelerar su ataque), sin aportar pruebas, y nosotros lo dejamos como hipótesis del fabricante.

Cabe esperar más de lo mismo. Nethemba vio a la misma IP explorar sitios ajenos desde el 23 de septiembre, un mes antes de la brecha, y el 20 de octubre el atacante probó los disparadores de backdoors ya retirados desde otras direcciones. Quien tenga un backdoor funcional todavía instalado no está en riesgo, está siendo usado. Y como en los instaladores manipulados de AOMEI Backupper, la limpieza del lado del proveedor no toca los sitios donde el plugin ya se activó. A eso hay que sumar que el canal UDRPC corre sobre el mismo intérprete afectado por los fallos PHP2Shell que PHP parcheó este mismo 21 de octubre, así que la semana de parcheo del administrador de WordPress tiene dos frentes. Quien quiera organizar la búsqueda en sus propios servidores puede partir de nuestros métodos de búsqueda de amenazas.

Cronología

• 5 de junio de 2026: TeamUpdraft publica UpdraftPlus 1.26.5 y 2.26.5, que corrigen el CVE-2026-10795. Wordfence lo divulga el 11 de junio.
• 17 y 18 de octubre: acceso no autorizado a teamupdraft.com, con la base de datos de clientes y las claves de conexión expuestas.
• 18 de octubre, 15:32 UTC: Patchstack registra la primera instalación de un backdoor. Nethemba sitúa otro sondeo a las 23:10 hora peninsular en el sitio de otro administrador.
• 19 de octubre, 02:14 hora peninsular: sondeo al sitio A de Nethemba. A las 04:14 se instala Load Stack 35C y el sitio cae con error 500 hasta las 06:13.
• 19 de octubre, 09:23 UTC: última instalación de la oleada vista por Patchstack, con 99 nombres distintos.
• 19 de octubre, 13:00 UTC: TeamUpdraft publica el aviso. Ese día lanza la 1.26.12 y 2.26.12, que no borran ninguna clave, y poco después de las 22:00 BST la 1.26.13 y 2.26.13.
• 20 de octubre: intentos de usar los disparadores de backdoors retirados desde 178.83.37.220, 178.83.37.243 y 178.94.218.31.
• 21 de octubre, 07:10 a 09:21 UTC: nuevos comandos firmados desde 43.250.53.42 contra dos sitios de Nethemba. TeamUpdraft pide a todos los usuarios Premium que revisen sus sitios aunque nunca hayan usado UpdraftCentral.

La cronología deja a la vista el hueco que importa. Entre la primera instalación que vio Patchstack y la versión que de verdad borra las claves pasaron más de 30 horas, y en ese intervalo el fabricante publicó una actualización que no hacía nada. Todo lo que ocurrió en esas horas sigue en los sitios que no han mirado.

Preguntas frecuentes

¿Me afecta si solo uso UpdraftPlus gratuito y nunca he abierto UpdraftCentral?

Depende de si el sitio tiene una clave. Si nunca iniciaste sesión en una cuenta de teamupdraft.com desde el plugin, no hay ninguna clave y este ataque no te alcanza. Si lo hiciste alguna vez, la casilla marcada por defecto pudo crearla sin que lo notaras. Compruébalo con wp option get updraft_central_localkeys y, si devuelve algo, sigue los pasos del apartado anterior.

¿Basta con actualizar a UpdraftPlus 1.26.13 o 2.26.13?

No del todo. La actualización borra las claves creadas antes de las 12:07 UTC del 18 de octubre, pero no las de las nueve horas siguientes ni los plugins, cuentas o sesiones que el atacante haya dejado. Tampoco impide que una clave reconectada después vuelva a aceptar comandos. Actualizar es el primer paso, borrar la clave a mano el segundo y revisar el sitio el tercero.

¿Cómo sé si el atacante llegó a entrar o se quedó en instalar el plugin?

Busca en el access log del servidor peticiones GET a la raíz con un parámetro de seis o doce caracteres hexadecimales y un valor de 32 caracteres. Un 302 ahí indica que el backdoor funcionó y redirigió al panel. Revisa después los usuarios con manage_options que no sean administradores, las opciones terminadas en _uid y, si hay cualquier indicio, da el sitio por comprometido.

¿Tengo que dejar de usar UpdraftPlus para las copias?

No. Las copias de seguridad funcionan sin UpdraftCentral y los ficheros ya enviados a tu almacenamiento remoto no se vieron afectados. Lo que conviene revisar es la conexión con UpdraftVault, que el fabricante ha desconectado en todos los sitios y requiere volver a conectar con la nueva contraseña, y las claves de acceso al almacenamiento remoto si el sitio fue accedido.