Chaves roubadas do UpdraftCentral instalam backdoor no WordPress
A invasão ao site da TeamUpdraft expôs chaves de conexão do painel de gerenciamento remoto, usadas para instalar plugins maliciosos em sites WordPress. Não há CVE envolvida: as ordens chegaram assinadas e válidas, e apagar o plugin não encerra o incidente.
Imagem editorial original gerada para o Plugged Ninja.
Um invasor obteve acesso ao site da TeamUpdraft, empresa responsável pelo UpdraftPlus, e usou chaves legítimas do serviço de gerenciamento remoto UpdraftCentral para instalar plugins maliciosos em sites WordPress de terceiros. A própria fabricante confirmou o incidente em comunicado publicado em 19 de outubro de 2026 e atualizado em 20 de outubro, enquanto duas empresas de segurança — a estoniana Patchstack e a eslovaca Nethemba — documentaram a campanha de backdoor que começou antes do aviso oficial.
O ponto que diferencia este caso de um ataque comum a plugins é que não houve exploração de falha de código. As ordens enviadas aos sites eram assinadas com chaves válidas, geradas pelo próprio painel do UpdraftCentral. Do ponto de vista do site atacado, tudo estava correto: a verificação de assinatura passava, e o WordPress instalava o plugin solicitado como se o administrador tivesse pedido. Não existe CVE associado ao incidente, e isso tem uma consequência prática desconfortável — atualizar o plugin, por si só, não remove o problema.
A Patchstack estima que cerca de 10% das instalações do UpdraftPlus possuem uma chave do UpdraftCentral ou do Migrator, o que coloca algo próximo de 400 mil sites na faixa de exposição potencial. O UpdraftPlus está entre os plugins de backup mais usados do ecossistema, com mais de 4 milhões de instalações ativas.
O que a TeamUpdraft informou sobre o acesso indevido
Segundo o comunicado da fabricante, o acesso não autorizado ao site teamupdraft.com foi identificado no fim de semana de 17 e 18 de outubro de 2026 — o resumo do próprio aviso cita a detecção em 18 de outubro. A empresa afirma acreditar que a base de clientes foi acessada, sem confirmar exfiltração, e lista o que esse banco de dados armazenava:
- nomes, endereços de e-mail, endereços de cobrança e histórico de pedidos;
- senhas de conta, guardadas em forma de hash;
- configurações de autenticação em dois fatores;
- chaves de conexão do UpdraftCentral, do UpdraftVault e do UpdraftClone.
A TeamUpdraft informa que não armazena dados de cartão, já que os pagamentos passam por Stripe e PayPal, e que os arquivos do plugin, os downloads e os backups enviados ao armazenamento remoto do próprio cliente não foram afetados. Instalações autogerenciadas do UpdraftCentral, hospedadas pelo próprio usuário, também estão fora do escopo: o problema está na versão em nuvem do painel.
Na atualização de 20 de outubro, a fabricante afirma ter fechado a via de acesso, encerrado todas as sessões e substituído as chaves e os segredos que poderiam ter sido afetados. No mesmo texto, a empresa contesta a caracterização de um ataque em andamento feita pela imprensa, mas mantém a recomendação de que os usuários verifiquem seus sites.
Como o backdoor chegou pelo canal do UpdraftCentral
A análise técnica mais detalhada vem da Patchstack, que credita à Nethemba a primeira investigação do plugin malicioso. O cliente do UpdraftCentral é embarcado em toda cópia do UpdraftPlus e escuta requisições POST no endereço raiz do site. Com uma chave válida, o atacante enviou o comando plugin.upload_plugin por esse canal, e o WordPress cumpriu a ordem.
O plugin instalado se registra cedo no ciclo de execução de cada requisição e fica à espera de um parâmetro de URL secreto acompanhado de um token de 32 caracteres. Quando o token confere, ele cria um usuário com senha fixa, atribui o papel de Editor e em seguida concede as capacidades manage_options e install_plugins. Essa combinação permite execução de código arbitrário e autopromoção a administrador. O plugin também grava diretamente um cookie de sessão persistente, o que contorna o formulário de login — e, com ele, a autenticação em dois fatores, os limitadores de tentativa e os plugins de proteção de acesso.
Dois detalhes agravam o quadro. O primeiro é que a conta criada continua existindo depois que o plugin é removido, de modo que apagar o plugin não encerra o incidente. O segundo é um erro de programação na variante inicial: uma falha fatal disparava antes da verificação do token e fazia o site responder com HTTP 500 em requisições não armazenadas em cache. A Patchstack alerta explicitamente que corrigir esse erro ativaria o backdoor — ou seja, o reparo intuitivo é o pior movimento possível.
A Nethemba observou variantes mais recentes que criam contas de nível administrativo disfarçadas ou se escondem da lista de plugins, e relata ao menos uma variante funcional que não deixa rastro no banco de dados. A empresa afirma que seus três sites atingidos estavam totalmente atualizados, rodando WordPress 7.1.3 e UpdraftPlus 2.26.11, e que não houve invasão de servidor nem falha de configuração própria.
Janela de atividade e indicadores
A Patchstack registrou a primeira instalação de backdoor em 18 de outubro de 2026, às 15h32 UTC, e a última em 19 de outubro, às 9h23 UTC — uma janela de aproximadamente 18 horas. Foram observados 99 nomes distintos de plugin, em geral combinações aleatórias de duas ou três palavras; “Site Health Cache” é o nome que mais se repete. Dois endereços de origem atuaram em paralelo, um IPv4 e um IPv6, e houve rotação de infraestrutura em menos de um dia, o que torna o bloqueio por IP insuficiente como controle isolado.
Os indicadores mais estáveis divulgados pelas duas empresas são de natureza textual e estrutural:
| Tipo de indicador | O que procurar |
|---|---|
| Descrição do plugin | A frase “Small maintenance toolkit: keeps option storage tidy.” no cabeçalho do arquivo principal |
| Conta de backdoor | Nome de usuário com duas palavras e dois dígitos (exemplos confirmados: data-ops43 e media-staff96), e-mail em @example.org e nome de exibição “Site Tools” |
| Banco de dados | Opção cujo nome termina em _sync_token |
| Logs de acesso | Requisições cujo User-Agent cita class-udrpc.php sem a versão da biblioteca que o UpdraftCentral legítimo envia |
| Log do UpdraftCentral | Chamada a probe.central.updraftplus.com seguida de “Command received: plugin.upload_plugin” |
A Patchstack destaca que a conta maliciosa aparece como Editor na interface, e não como administrador, por isso a verificação deve ser feita por capacidade e não por papel. Instalações que nunca foram ativadas também devem ser tratadas como afetadas.
Versões corrigidas e a armadilha das chaves residuais
As versões a instalar são a 1.26.13 na linha gratuita e a 2.26.13 na linha Premium, ou posteriores. As versões 1.26.12 e 2.26.12 foram publicadas com a intenção de remover automaticamente as chaves do UpdraftCentral Cloud, mas um defeito impediu a remoção — e é por isso que o aviso da própria fabricante, que em alguns trechos aponta a 1.26.12/2.26.12 como suficiente, deve ser lido junto da versão 13.
Há ainda um recorte temporal que exige ação manual: segundo a Nethemba, a 1.26.13 não apaga chaves criadas em 18 de outubro entre 12h07 e 21h00 UTC. Nesses casos, a exclusão precisa ser feita à mão. Vale registrar uma divergência entre as fontes sobre o horário de corte aplicado pela atualização — o comunicado da TeamUpdraft menciona conexões feitas antes das 22h00 BST de 18 de outubro, enquanto a Nethemba trabalha com a janela em UTC. Diante da inconsistência, o caminho seguro é não confiar na remoção automática e conferir a presença de chaves no site.
Outro ponto que explica a escala do problema é o comportamento padrão do plugin: a caixa “Add this website to UpdraftCentral” vem marcada ao fazer login em uma conta teamupdraft.com pelo UpdraftPlus. Muitos sites, portanto, têm chaves que o administrador nunca pretendeu criar. E as chaves não expiram — a Patchstack verificou chaves emitidas em novembro de 2025 ainda válidas em outubro de 2026.
Em paralelo, sites em versões anteriores à 1.26.5/2.26.5 continuam expostos à CVE-2026-10795, falha de junho de 2026 no mesmo canal de comunicação, para a qual a Patchstack diz observar tentativas de exploração ainda ativas. É uma questão distinta deste incidente, mas que atinge o mesmo componente.
O que fazer agora
- Verifique se o site tem chave. Com o WP-CLI, consulte a opção
updraft_central_localkeys. Qualquer retorno indica exposição — inclusive em sites que nunca usaram o painel. - Apague as chaves no site, em Configurações → UpdraftPlus Backups → Ferramentas avançadas → UpdraftCentral → gerenciar chaves existentes. Remover o site do painel não basta. Os backups continuam funcionando.
- Atualize para 1.26.13 ou 2.26.13, ou versão posterior, e só depois considere reconectar.
- Troque a senha da conta teamupdraft.com digitando o endereço diretamente no navegador, troque-a onde houver reuso e redefina a autenticação em dois fatores.
- Procure contas e plugins desconhecidos, incluindo plugins do tipo must-use, e revise todos os usuários com capacidades elevadas.
- Se encontrar o plugin malicioso, apague primeiro a chave do UpdraftCentral — sem isso o atacante pode reinstalar. Desative o plugin e mova-o para fora da raiz web em vez de desinstalá-lo pelo painel, porque a rotina de desinstalação apaga os próprios rastros. Não tente consertar o plugin.
- Se a conta de backdoor existir ou o gatilho aparecer nos logs, trate o site como comprometido por completo: restaure a partir de um backup anterior a 17 de outubro, compare arquivos com uma instalação limpa, encerre todas as sessões e rotacione as senhas administrativas.
- Reautorize o armazenamento remoto e troque as chaves de acesso do serviço de destino dos backups, por precaução.
Leitura do caso
O incidente é um exemplo didático de risco de terceiro em um componente que concentra poder: um painel de gerenciamento remoto precisa, por definição, poder instalar plugins nos sites que administra. Quando a credencial desse painel vaza na origem, a confiança delegada se converte em execução de código remota em escala, sem que nenhuma verificação do lado do site falhe. É o mesmo padrão do comprometimento de plugins da Awesome Motive, em junho de 2026: canais de administração remota merecem o mesmo inventário e a mesma rotação que se dá a chaves de API.
Há limites no que se sabe até agora. A TeamUpdraft não explicou publicamente como o invasor entrou em seu site, não há contagem confirmada de sites efetivamente comprometidos — apenas a estimativa de exposição — e a divergência entre fontes sobre horários de corte permanece sem conciliação.
O que observar a seguir: a explicação da causa-raiz pelo fabricante, eventual confirmação de uso das credenciais de armazenamento remoto que estavam na mesma base, e o surgimento de novas variantes do plugin — a Nethemba já descreveu versões sem rastro em banco, o que encurta a vida útil dos indicadores publicados.
Fontes e referências
- BleepingComputer — “Stolen UpdraftCentral keys used to backdoor WordPress sites”: bleepingcomputer.com
- TeamUpdraft — “TeamUpdraft security incident: What customers need to know”: teamupdraft.com
- Patchstack — “Stolen UpdraftCentral Keys Are Backdooring WordPress Sites”: patchstack.com
- Nethemba — “Critical security problem in UpdraftCentral: an attacker holding the service’s keys planted a backdoor on our websites”: nethemba.com
- The Hacker News — “Attackers Abuse UpdraftCentral Keys to Plant Backdoors on WordPress Sites”: thehackernews.com
