Qué ocurrió en UpdraftPlus en octubre de 2026
El editor, TeamUpdraft, identificó un acceso no autorizado a su propio sitio el 17 y el 18 de octubre de 2026. Los datos afectados incluyen claves de conexión de UpdraftCentral, el servicio de gestión remota. Con una clave así, un atacante firma órdenes que el sitio acepta como procedentes de su panel, entre ellas la instalación de un plugin. Patchstack observó la primera instalación de una puerta trasera el 18 de octubre a las 15:32 UTC y contabiliza al menos 99 plugins maliciosos con nombres distintos, disfrazados de herramientas de mantenimiento. El punto central es otro: no se trata de un fallo del plugin de copias de seguridad. El editor indica que el plugin y sus descargas no están afectados, ni tampoco las copias guardadas en su propio almacenamiento remoto. El peligro viene de una clave de gestión remota robada, no de las copias de seguridad de WordPress en general.
Versiones y situaciones: dónde está cada sitio
Desplace la tabla
| Situación | Estado | Acción |
|---|---|---|
| UpdraftPlus 1.26.13 (gratuito) o 2.26.13 (Premium), o posterior | Las conexiones existentes a UpdraftCentral quedan revocadas, según el editor | Comprobar igualmente claves, plugins y cuentas |
| UpdraftPlus 1.26.12 | Según Nethemba, un error impedía eliminar las claves | Pasar a 1.26.13 o posterior y eliminar las claves |
| Versión anterior | Una clave puede seguir siendo válida | Actualizar y eliminar las claves |
| Plugin al día, plugin falso ya instalado | La actualización no retira el plugin falso | Auditar plugins y cuentas, véase más abajo |
| Sitio nunca conectado a UpdraftCentral | No se espera ninguna clave | Leer la opción de claves para estar seguro |
| UpdraftCentral autoalojado | No afectado, según el editor | Ninguna acción propia de este incidente |
| Copias en su propio almacenamiento remoto | No afectadas, según el editor | Reautorizar el almacenamiento y cambiar sus claves |
Por qué "al día" no significa "limpio"
La frase "mi plugin está al día, estoy cubierto" es falsa por dos motivos. Primero, la versión 1.26.12 debía eliminar las claves pero, según Nethemba citado por BleepingComputer, un error se lo impedía: solo la 1.26.13 y la 2.26.13 corrigieron ese punto. Segundo, una actualización cambia el código del plugin de copias; no retira ni un plugin falso ya instalado ni una cuenta de administrador ya creada. El editor señaló además, en una actualización de su aviso, sitios donde un plugin depositado por el atacante sobrevivió al incidente inicial y creó después un nuevo administrador, incluso tras la desconexión. Un sitio solo se declara limpio tras revisar claves, plugins y cuentas, nunca por un número de versión.
Los indicios que hay que buscar en cada sitio
- Un plugin desconocido — el nombre Site Health Cache aparece a menudo según Patchstack, pero la lista no es exhaustiva: el editor cita también Asset Forge 2, Core Smith, Image Forge y WP Forge.
- Una descripción típica — la cadena "Small maintenance toolkit: keeps option storage tidy." es el indicador de archivo más fiable según Patchstack; no encontrarla no prueba nada.
- Una cuenta oculta — nombres de usuario como data-ops43 o media-staff96, una dirección en example.org, el nombre visible Site Tools; algunos plugins ocultan estas cuentas de la pantalla Usuarios.
- Una opción que termina en
_sync_token— una entrada con ese final en la tabla de opciones acompaña a la puerta trasera. - Una instalación sin autor — un plugin aparecido sin acción de un administrador, o un correo de error de WordPress que nombra un plugin que nadie conoce.
- Una clave todavía presente — la opción
updraft_central_localkeysno está vacía: el sitio sigue expuesto mientras exista esa clave. - Una línea de registro — en el registro de UpdraftCentral,
probe.central.updraftplus.comseguido deCommand received: plugin.upload_plugin.
Auditar cada sitio, por orden
Trabajar desde el propio sitio
Abra el panel de WordPress del sitio, o una sesión SSH, pero no UpdraftCentral: el editor pide conectarse a cada sitio directamente.
Leer las claves existentes
wp option get updraft_central_localkeys
Una salida no vacía significa que el sitio está expuesto, según Patchstack, aunque nunca haya usado UpdraftCentral. Un error de "opción inexistente" indica que no hay clave.Actualizar y eliminar las claves
wp plugin update updraftpluswp option delete updraft_central_localkeys
La ruta gráfica es Ajustes > UpdraftPlus Backups > Herramientas avanzadas > UpdraftCentral, y luego "Manage existing keys"; el rótulo exacto varía según la versión, así que el comando es el gesto de referencia. Quitar el sitio del panel de UpdraftCentral no basta. Las copias siguen funcionando.Listar los plugins y comparar
wp plugin list --fields=name,status,versionls wp-content/mu-plugins/
Compare con la lista esperada de la cartera: un plugin que nadie validó es sospechoso, también en la carpeta Must-Use, que la pantalla de plugins no siempre muestra.Buscar la firma del plugin falso
grep -r "Small maintenance toolkit: keeps option storage tidy." wp-content/plugins/ wp-content/mu-plugins/
Un resultado es una alerta. Una búsqueda vacía no prueba que el sitio esté limpio.Listar las cuentas con privilegios
wp user list --role=administrator --skip-pluginswp user list --role=editor --skip-plugins
La opción--skip-pluginsimporta: evita cargar los plugins que ocultan cuentas en pantalla. Compare con la lista esperada de personas que administran realmente el sitio.Buscar la opción de la puerta trasera
wp option list --search="*_sync_token"
Cualquier entrada encontrada exige el tratamiento de "sitio comprometido" de la sección siguiente.Registrar el resultado
Una línea por sitio: versión de UpdraftPlus, claves presentes o no, diferencia de plugins, diferencia de cuentas, fecha de la auditoría, decisión. Este registro sirve de prueba al cliente y de punto de partida para el próximo incidente.
Las mismas comprobaciones según el entorno
Desplace la tabla
| Entorno | Comando tipo | Observación |
|---|---|---|
| Debian o Ubuntu | `sudo -u www-data wp --path=/var/www/html plugin list` | Adapte la ruta y el usuario a su instalación |
| RHEL, AlmaLinux o Rocky | `sudo -u apache wp --path=/var/www/html plugin list` | Usuario `nginx` si el servidor web es nginx |
| Docker Compose | `docker compose exec -u www-data wordpress wp plugin list` | El nombre del servicio depende de su archivo; WP-CLI suele faltar en la imagen de WordPress, compruébelo |
| Alojamiento compartido con SSH | `wp plugin list` desde la carpeta del sitio | Sin SSH, use el administrador de archivos o SFTP |
| Sin WP-CLI | Examinar `wp-content/plugins/` y `wp-content/mu-plugins/` por SFTP | Comparar cada carpeta con la lista esperada |
| Todos los entornos | `wp config shuffle-salts` | Cambia las claves de seguridad de WordPress y cierra las sesiones abiertas |
Ante el menor indicio, tratar el sitio como comprometido
Si existe una cuenta de puerta trasera o el activador aparece en los registros, Patchstack recomienda considerar el sitio totalmente comprometido. El orden importa. Elimine primero la clave de UpdraftCentral, o el atacante conserva su vía de entrada. Desactive después el plugin falso y borre su carpeta directamente en el servidor: el editor advierte de que algunos plugins están diseñados para borrar sus huellas cuando se eliminan desde el panel. No corrija un error de código de ese plugin para "repararlo": Patchstack advierte de que eso activa la puerta trasera. Retire la cuenta y la opción _sync_token y prefiera la restauración a la limpieza manual, porque nada prueba que una limpieza a mano lo haya encontrado todo.
Restaurar de forma limpia
Elegir el punto de restauración
Tome una copia anterior al 17 de octubre de 2026 y compruebe que precede de verdad a la intrusión: fechas de los archivos, última instalación de plugin conocida, registros del servidor.
Restaurar fuera de producción
Monte la copia en un sitio de pruebas o en un servidor desechable, nunca directamente en producción. Repita allí las comprobaciones de la sección de auditoría: claves, plugins, cuentas, firma.
Comparar con una instalación limpia
wp core verify-checksumswp plugin verify-checksums --all
Estos comandos comparan los archivos del núcleo y de los plugins con las sumas de verificación del directorio oficial; un archivo modificado se señala.Actualizar antes de volver a publicar
Pase UpdraftPlus como mínimo a 1.26.13 o 2.26.13, actualice el resto y elimine de nuevo las claves: una copia anterior al incidente puede contenerlas.
Volver a producción y vigilar
Active el sitio restaurado y revise plugins y cuentas durante los días siguientes. Un plugin o una cuenta que reaparece indica una puerta aún abierta en otro lugar.
Decidir la reconexión
TeamUpdraft permite reconectar con UpdraftCentral una vez comprobado y protegido el sitio. En la fecha de su artículo, Patchstack aconsejaba esperar a que se explicara la causa. Si no necesita la gestión remota, déjela desconectada.
Restaurar no sustituye a revocar
Restaurar una copia limpia no exime de eliminar las claves ni de cambiar las credenciales: el propio editor lo precisa. Siga siempre este orden: claves eliminadas, contraseñas cambiadas, sesiones cerradas y, por último, vuelta a línea.
Almacenamiento remoto, sesiones y contraseñas
Las copias guardadas en su almacenamiento remoto (Google Drive, Dropbox, Amazon S3) no están afectadas, según el editor, pero los sitios accesibles mediante UpdraftCentral deben reautorizar ese almacenamiento y cambiar sus claves de acceso. Rote las claves S3, renueve la autorización de las cuentas de Drive o Dropbox, cambie las claves de seguridad de WordPress con wp config shuffle-salts y las contraseñas de todas las cuentas legítimas de administrador y editor. Del lado del editor, cambie su contraseña escribiendo la dirección a mano en el navegador, restablezca la autenticación en dos pasos y, si usa UpdraftVault, reconecte el almacenamiento y lance una copia manual: los sitios habían sido desconectados. Los datos expuestos en el editor incluyen nombres, correos, direcciones de facturación e historial de pedidos; las contraseñas se guardan allí solo con hash.
Para una agencia: un inventario, no diez hojas de cálculo
Con decenas de sitios, el tiempo no se va en el comando sino en la pregunta "quién tiene qué". Mantenga un registro vivo por sitio: versión de UpdraftPlus, presencia de claves, lista de plugins esperada, lista de administradores esperada, fecha de la última auditoría, fecha de la última copia. Sin lista de referencia, un plugin nunca es "desconocido", solo "aún no visto". Revise sus puntos de restauración antes de necesitarlos: en ServOrbit.com, las copias son semanales en la gama de entrada y diarias en el plan Pro y en todos los planes Agency, y conviene comprobar que sigue existiendo una copia anterior al 17 de octubre de 2026. Nuestra guía sobre cómo probar la restauración de una copia de un VPS de cliente describe el procedimiento que conviene ensayar en frío, y la rutina de actualización de una cartera sigue siendo la de las dos alertas recientes de WordPress.
Documentación oficial
Aviso de TeamUpdraft sobre el incidente de octubre de 2026: https://teamupdraft.com/blog/security-incident-october-2026/
Análisis de Patchstack: https://patchstack.com/articles/updraftcentral-key-compromise-wordpress-backdoors/
Artículo de BleepingComputer: https://www.bleepingcomputer.com/news/security/stolen-updraftcentral-keys-used-to-backdoor-wordpress-sites/
WP-CLI, lista de usuarios: https://developer.wordpress.org/cli/commands/user/list/
WP-CLI, verificación de sumas de los plugins: https://developer.wordpress.org/cli/commands/plugin/verify-checksums/
WP-CLI, rotación de claves de seguridad: https://developer.wordpress.org/cli/commands/config/shuffle-salts/
