O seu alojamento foi atacado: o que mudar no WordPress e no WooCommerce

Quando o fornecedor de alojamento é atacado, o problema passa a ser seu no momento em que recebe o aviso. Em outubro de 2026, a DreamHost confirmou que um terceiro não autorizado acedeu ao servidor do seu gestor de ficheiros web e que ficaram expostas credenciais FTP e SFTP de clientes. Com essas credenciais lê-se o wp-config.php de qualquer site WordPress, e com ele a palavra-passe da base de dados. Neste artigo descrevo o que a DreamHost disse e o que não disse, o que mudo num site WordPress e numa loja WooCommerce e por que ordem, como procuro sinais de intrusão com o WP-CLI e quando o dono da loja tem de notificar a CNPD.

O artigo descreve os factos publicados e a documentação técnica à data de publicação. Não é aconselhamento jurídico individual.

#O que aconteceu na DreamHost em 2026?

A DreamHost publicou o aviso a 29 de outubro de 2026 (anúncio da DreamHost). Na sexta-feira, 23 de outubro, à tarde, a empresa descobriu que um terceiro não autorizado tinha acedido ao servidor que corre o seu gestor de ficheiros web. Retirou esses servidores do ar, preservou-os para análise forense e enviou pedidos de reposição de palavras-passe de e-mail e de FTP/SFTP nessa noite e durante o fim de semana.

O vetor foi o gestor de ficheiros em files.dreamhost.com, construído sobre software de terceiros. Segundo a carta enviada aos clientes, o atacante explorou uma vulnerabilidade nesse software. A DreamHost não diz que software é nem que vulnerabilidade; ao TechCrunch, um porta-voz recusou identificá-lo. A empresa acrescenta que o incidente não está relacionado com as atualizações recentes de PHP nos seus servidores.

As datas variam conforme o documento:

Os documentos não esclarecem se o atacante esteve presente desde meados de agosto ou se as credenciais foram apenas recolhidas a partir dessa altura. A expressão “de meses” e a ideia de que os atacantes “roubaram ficheiros e caixas de correio” (tradução própria) são do título do TechCrunch. A carta da DreamHost usa formulações condicionais.

#Que dados foram expostos no ataque à DreamHost?

A carta enumera o seguinte (tradução própria):

• Nomes de utilizador e palavras-passe FTP/SFTP “de pessoas que iniciaram sessão neste gestor de ficheiros entre aproximadamente agosto de 2026 e 23 de outubro de 2026”.
• No webmail, o ataque “pode ter exposto a informação de sessão (os dados que mantêm um utilizador com a sessão iniciada, incluindo credenciais de sessão) de um número limitado de utilizadores”.
• “Outra informação, como o conteúdo do seu e-mail e os ficheiros no servidor FTP/SFTP, pode também ter sido acedida.”

Há uma diferença entre os dois textos da própria DreamHost. A carta fala de informação de sessão do webmail; o anúncio público fala de credenciais de início de sessão do webmail, e diz que o conteúdo das caixas de correio “pode” ter sido visto num pequeno número de casos.

Segundo a DreamHost, não há indícios de acesso aos dados de início de sessão do painel de controlo nem aos dados de faturação. Os números completos dos cartões não são guardados pela DreamHost, porque são tokenizados por um processador externo. A escala anunciada é “bem abaixo de aproximadamente 10%” das contas de e-mail e FTP/SFTP. Ao TechCrunch, a empresa indicou ter cerca de 400 000 clientes pagantes, sem dar um número exato de afetados, e o registo na Califórnia também não o dá.

O que a DreamHost não menciona: palavras-passe de bases de dados MySQL, utilizadores SSH enquanto tais e chaves de API. É aqui que entra o meu raciocínio, que não é uma afirmação da DreamHost: quem tem acesso SFTP aos ficheiros de um site WordPress pode ler o wp-config.php. Esse ficheiro guarda o nome, o utilizador e a palavra-passe da base de dados e as chaves e salts de autenticação. A partir daí, o atacante pode chegar a tudo o que está na base de dados, incluindo as encomendas e os clientes de uma loja WooCommerce.

#O que pede a DreamHost aos clientes?

A lista da DreamHost, em resumo:

1. Mudar as palavras-passe no painel (panel.dreamhost.com). Só o titular da conta o pode fazer, e a alteração pode demorar até 15 minutos a propagar-se.
2. Considerar comprometidas as credenciais FTP/SFTP usadas no gestor de ficheiros durante o período, e mudar a mesma palavra-passe, ou uma parecida, em qualquer outra conta onde tenha sido usada.
3. Atualizar os clientes de e-mail, FTP e SFTP que guardam a palavra-passe antiga.
4. Rever os ficheiros do site à procura de alterações inesperadas.
5. Rever as definições das contas de e-mail, incluindo regras de reencaminhamento e filtros.
6. Pensar se o conteúdo dos e-mails ou dos ficheiros dá acesso a outras contas, e rever essas contas.

A DreamHost lembra que nunca pede palavras-passe por e-mail e que os pedidos de reposição não solicitados devem ser ignorados. O apoio para este caso está no formulário de contacto da DreamHost, tema “Account security”.

#Que ordem sigo para mudar palavras-passe e chaves no WordPress?

Se mudar primeiro a palavra-passe do wp-admin e só depois o acesso SFTP, quem ainda tem o SFTP lê o wp-config.php outra vez e volta a entrar. A documentação do WordPress.org pede para mudar todos os pontos de acesso, “FTP / SFTP, WP-ADMIN, CPANEL (ou outro painel de administração do alojamento) e MYSQL”, para todos os utilizadores com acesso (FAQ “My site was hacked”, tradução própria).

A minha ordem, de fora para dentro:

O e-mail vem antes do WordPress por uma razão prática: os links de reposição de palavra-passe do wp-admin chegam a essas caixas. Uma regra de reencaminhamento colocada pelo atacante entrega-lhe cada reposição que fizer a seguir.

O WordPress.org recomenda também mudar as palavras-passe outra vez depois de confirmar que o site está limpo. Se as mudou no momento em que descobriu o ataque, mude-as de novo no fim.

#Como mudo a palavra-passe da base de dados e os salts?

Para a base de dados, o WordPress.org diz: “Pode considerar mudar a conta de utilizador e a palavra-passe da base de dados. Quando o fizer, não se esqueça de as atualizar no ficheiro wp-config.php” (tradução própria). A mudança faz-se no painel do alojamento; depois, no wp-config.php:

define( 'DB_USER', 'novo_utilizador' );
define( 'DB_PASSWORD', 'nova-palavra-passe-longa' );

Faço as duas alterações seguidas, porque entre a mudança no painel e a gravação do ficheiro o site fica sem ligação à base de dados.

Os salts e as chaves de autenticação assinam os cookies de sessão. A documentação do wp-config.php diz que podem ser mudados a qualquer momento para invalidar todos os cookies existentes, o que obriga todos os utilizadores a voltar a iniciar sessão (wp-config.php no developer.wordpress.org). Com o WP-CLI, um comando chega (wp config shuffle-salts):

wp config shuffle-salts

Sem WP-CLI, os valores novos obtêm-se em api.wordpress.org/secret-key/1.1/salt/ e substituem os antigos no wp-config.php. Numa loja, os clientes com sessão iniciada têm de entrar outra vez.

#Como verifico administradores e palavras-passe de aplicação?

Primeiro, a lista de administradores (wp user list):

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

O campo user_registered mostra quando cada conta foi criada. Uma conta de administrador criada entre agosto e outubro, que ninguém reconhece, é o sinal mais claro de intrusão. Apago-a depois de anotar os dados para o registo do incidente.

Depois, as palavras-passe de aplicação, que dão acesso à API REST sem passar pelo ecrã de início de sessão. Cada registo guarda a data e o endereço IP da última utilização, com uma precisão de 24 horas (guia de integração das palavras-passe de aplicação). Com o WP-CLI (wp user application-password):

wp user application-password list 1
wp user application-password delete 1 <uuid>

Repito para cada administrador. Uma palavra-passe de aplicação criada no período do ataque, ou usada a partir de um IP desconhecido, é revogada de imediato.

#Que chaves da loja WooCommerce e da Stripe tenho de rodar?

Uma loja WooCommerce guarda na base de dados as chaves das integrações e dos prestadores de pagamento, e quem leu a base de dados leu essas chaves.

As chaves da API REST do WooCommerce estão em WooCommerce, Definições, Avançado, API REST. Cada chave tem a opção “Revoke Key”; depois de revogar, crio chaves novas e entrego-as a cada integração (programa de faturação, ERP, transportadora) (documentação da API REST do WooCommerce). Antes de revogar, faço a lista das integrações que usam cada chave, para não deixar o programa de faturação parado sem saber porquê.

A Stripe diz que se deve rodar uma chave secreta ou restrita quando ela foi comprometida (chaves de API da Stripe). Na rotação pelo painel, a chave antiga e a nova funcionam em paralelo até 7 dias. Depois de um ataque não quero essa janela: escolho a expiração “Now”, que apaga a chave antiga de imediato, e atualizo a chave nova no plugin da loja logo a seguir. A Stripe permite também restringir as chaves em produção a endereços IP ou ASN, o que vale a pena configurar se o alojamento tiver IP fixo.

O segredo de assinatura dos webhooks é outro segredo, com outra regra. A Stripe recomenda renová-lo periodicamente ou quando há suspeita de comprometimento, e o segredo antigo pode ficar válido até 24 horas depois da renovação (webhooks da Stripe). Sem o segredo novo no plugin, as confirmações de pagamento deixam de chegar e as encomendas ficam pendentes.

Se a loja usar outros prestadores, como a ifthenpay para Multibanco e MB WAY, a lógica é a mesma: as chaves estão nas definições do plugin, na base de dados, e devem ser renovadas no painel do prestador. Não encontrei documentação oficial de cada prestador sobre rotação de chaves, por isso confirmo o procedimento com o próprio prestador.

#Como procuro sinais de intrusão nos ficheiros do WordPress?

Para o núcleo (wp core verify-checksums):

wp core verify-checksums --include-root

O comando compara os ficheiros com as somas de verificação do WordPress.org. Com --include-root, avisa também sobre ficheiros na raiz que não pertencem ao WordPress, onde costumam aparecer scripts deixados por atacantes.

Para os plugins (wp plugin verify-checksums):

wp plugin verify-checksums --all

Com --strict, o comando assinala também alterações em ficheiros readme. A verificação compara com as somas do WordPress.org, por isso plugins pagos, temas e código próprio ficam de fora. Esses comparo com uma cópia limpa descarregada do fornecedor ou do repositório git.

O WordPress.org indica os ficheiros a ver à mão: o .htaccess na raiz e nas subpastas, index.php, header.php, footer.php e functions.php. Recomenda substituir as pastas /wp-admin e /wp-includes por cópias da mesma versão. Se encontrar código estranho, o passo seguinte é uma limpeza completa, descrita no meu guia para limpar um WordPress pirateado.

#Quando tenho de notificar a CNPD?

No RGPD, o alojamento é subcontratante e o dono da loja é o responsável pelo tratamento. As obrigações de cada um, segundo o texto do regulamento (RGPD no EUR-Lex):

Quando começa o prazo? As orientações 9/2022 do Comité Europeu para a Proteção de Dados dizem, no ponto 44, que em princípio o responsável deve considerar-se “ciente” quando o subcontratante o informa da violação (orientações 9/2022, versão 2.0, tradução própria). No caso da DreamHost, a minha leitura é que o prazo de 72 horas começou quando o aviso chegou ao cliente, com o e-mail de reposição de 23 a 25 de outubro ou com a carta formal, e não a 15 de agosto. A avaliação do risco cabe ao responsável, não ao alojamento.

Em Portugal, a autoridade é a Comissão Nacional de Proteção de Dados. Na página sobre violações de dados, a CNPD diz que “a notificação deve ser feita no prazo de 72 horas após ter tido conhecimento da mesma” e que disponibiliza um formulário específico para o efeito (CNPD, violação de dados).

Como aplico isto a uma loja WooCommerce? Credenciais SFTP que abrem o wp-config.php dão acesso à base de dados com nomes, moradas, e-mails, telefones e histórico de encomendas dos clientes. Para mim, isso aponta para uma violação a notificar. Um site institucional sem formulários nem dados pessoais na base de dados pode precisar apenas do registo interno do artigo 33.º, n.º 5. É a minha leitura do caso, não uma decisão da CNPD sobre ele.

O registo interno faço-o sempre, com o que se sabe na altura:

1. Data e hora em que recebeu o aviso do alojamento, e por que meio.
2. Que credenciais e que dados podiam estar ao alcance do atacante.
3. Que categorias de titulares (clientes, subscritores da newsletter) e quantos, aproximadamente.
4. O que mudou e quando (a tabela de passos acima, com datas).
5. Resultado das verificações (wp user list, verify-checksums).
6. A decisão de notificar ou não, com a razão.

#O que fica para depois da emergência?

Depois de mudar tudo, há decisões que deixo para a semana seguinte.

O gestor de ficheiros web do alojamento: o ataque à DreamHost entrou por aí. Se trabalha com SFTP a partir do seu computador ou com deploy por git, o gestor de ficheiros web não faz falta, e deixar de o usar retira um ponto de entrada.

Palavras-passe repetidas: a DreamHost pede para mudar a mesma palavra-passe, ou uma parecida, noutras contas. Um gestor de palavras-passe com palavras-passe únicas por serviço resolve isto de vez.

Cópia de segurança fora do alojamento: uma cópia guardada no mesmo alojamento que foi atacado não serve para provar o estado do site antes do ataque. Uma cópia diária noutro fornecedor permite comparar ficheiros e base de dados com uma data anterior ao incidente.

#Por onde começar

Se recebeu hoje um aviso do seu alojamento, anote a data e a hora em que o recebeu, porque é daí que contam as 72 horas, e mude o acesso ao painel e ao SFTP antes de tudo o resto. Se a loja corre em WooCommerce e quer que a rotação das chaves e a verificação sejam feitas por quem já o fez noutras lojas, os passos seguintes estão na página de desenvolvimento WooCommerce. Se está a ponderar sair do alojamento próprio para uma plataforma alojada, veja a página de desenvolvimento Shopify.