Segurança WordPress, atualizações e hardening

Um site WordPress raramente é comprometido por uma técnica nova. É comprometido por uma falha cuja correção já estava publicada e que ninguém instalou a tempo. Este artigo parte da versão de segurança mais recente do core e segue o caminho completo: o que foi corrigido, o que se atualiza sozinho, o que não se atualiza, como fazer a atualização sem partir o site e o que a lei espera do responsável pelo tratamento de dados.

#O que corrigiu o WordPress 7.1.3

O WordPress 7.1.3 saiu a 6 de outubro de 2026 com 7 correções de segurança e 4 correções de erros. O anúncio enumera os tipos de falha:

• XSS armazenado na página de administração de comentários, através de comentários pendentes
• um problema de negação de serviço em WP_Http::make_absolute_url()
• uma injeção SQL de segunda ordem na exportação WXR
• uma fragilidade que permitia a utilizadores com o papel de Autor fixar artigos no topo
• divulgação não autenticada de comentários em artigos privados e não publicados
• XSS em incorporações do Imgur
• parâmetros falsificáveis no hook {status}_{type}, com colisão de nomes de ação

Entre os créditos estão Thomas Chauchefoin (Trail of Bits) e Ananda Dhakal (Patchstack). A Anthropic é creditada por três destas falhas: a negação de serviço, a injeção SQL e a fragilidade dos artigos fixados.

A 17 de setembro de 2026, o WordPress 7.1.1 já tinha trazido 11 correções de segurança, entre elas um XSS armazenado em wpautop(), um path traversal autenticado no controlador de modelos da REST API e a substituição arbitrária de artigos por Colaboradores.

Lida com atenção, a lista mostra falhas que exigem um papel autenticado, um comentário pendente ou uma funcionalidade concreta. Por isso mesmo costumam ser adiadas. O argumento a favor da pressa é aritmético: a correção e o respetivo diff são públicos no dia do lançamento, e o intervalo entre esse dia e o dia da sua atualização é a janela em que uma falha conhecida está no seu site. O próprio anúncio recorda que “apenas a versão mais recente do WordPress é suportada ativamente” (tradução própria), com as correções de segurança retroportadas, quando necessário, para ramos antigos (atualmente até à 4.7).

#Como a equipa de segurança do WordPress trata vulnerabilidades no núcleo

Segundo wordpress.org/about/security, a equipa de segurança do WordPress tem mais de 50 especialistas de confiança, entre programadores principais e investigadores de segurança. A equipa desenvolve e testa as correções e publica-as em versões de correção de erros. A página descreve também a colaboração com grandes empresas de alojamento e fornecedores de segurança na distribuição das correções e em regras de WAF que travam ataques antes de todos atualizarem.

Daqui resultam duas consequências para a manutenção. No núcleo, a correção vem de uma fonte coordenada e a atualização automática em segundo plano é o canal de entrega. Se estiver ligada, a maior parte do trabalho no núcleo está feita. Nos plugins e temas é diferente: as vulnerabilidades são reportadas ao autor e à equipa de plugins ou de temas, e a rapidez da correção depende de uma só pessoa. Por isso, a maior parte do seu trabalho de atualização está na lista de plugins, não no núcleo.

#O que se atualiza sozinho e o que não

O anúncio da 7.1.3 diz que, nos sites que suportam atualizações automáticas em segundo plano, o processo arranca sozinho. A documentação de atualização explica a constante: true ativa versões de desenvolvimento, menores e maiores, false desativa-as todas e 'minor' só admite as menores. Em cada site, confirme três pontos: a constante não ficou em false no wp-config.php por vontade de um programador antigo, o site não é um checkout de controlo de versões que abdica em silêncio e o alojamento entrega de facto a atualização. Um wp core version no servidor, no dia seguinte a uma versão de segurança, resolve a terceira dúvida.

Para plugins e temas, a documentação diz que as atualizações em segundo plano só acontecem em casos especiais, “conforme determinado pela resposta da API do WordPress.org, que é controlada pela equipa de segurança do WordPress” (tradução própria). Desde o WordPress 5.5 pode ligar ou desligar a atualização automática de cada plugin e tema nos ecrãs habituais. Ligar tudo não é estratégia. Ligue-a nos plugins pequenos e com bom historial de versões, e deixe a loja, os formulários e a gestão de membros num circuito com staging.

#O que acontece quando um plugin é fechado no diretório

Segundo as orientações do diretório, as vulnerabilidades são comunicadas à equipa de plugins, que tenta contactar o programador, e “a maioria dos plugins é fechada para impedir novos downloads até o problema estar resolvido” (tradução própria). O fecho bloqueia novas instalações. Não entra no seu site, pelo que um plugin fechado que instalou no ano passado continua a funcionar. Uma vez por trimestre, compare os plugins ativos com o que o diretório ainda lista, e substitua os fechados ou abandonados. Vale o mesmo para ataques à cadeia de abastecimento, quando um plugin de confiança muda de dono e a atualização seguinte é o ataque. Sobre o prazo de retenção das atualizações no WordPress.org, veja esta nota.

#Como atualizar o WordPress com segurança num site real

Saber se uma atualização compensa depende de poder desfazê-la. A rotina que funciona:

1. Faça uma cópia de segurança que já tenha restaurado pelo menos uma vez. Uma cópia nunca testada é uma esperança.
2. Aplique as atualizações em staging e percorra os caminhos que geram receita ou recolhem dados: checkout, formulários, início de sessão, pesquisa.
3. Atualize a produção numa janela de pouco tráfego e repita o mesmo percurso.
4. Consulte o registo de erros do PHP à procura de avisos novos, porque um plugin pode falhar em silêncio.
5. Conheça a reversão antes de começar. Se correr mal, o guia para restaurar uma versão anterior após uma atualização falhada descreve o processo.

Dois comandos WP-CLI fazem quase todo o inventário: wp plugin list --update=available mostra o que está pendente e wp core check-update mostra o estado do core. As versões de segurança vão primeiro, o resto segue semanalmente. Um plano de manutenção é, no essencial, alguém a fazer isto com calendário e a registá-lo.

Em alojamentos com staging num clique, a barreira é baixa. Num VPS próprio, use wp-cli ou um pipeline de deploy e mantenha o staging atrás de autenticação HTTP ou VPN. Um clone aberto da produção com dados reais já é, por si, um problema de proteção de dados.

Evite também um «staging» que é só uma subpasta na mesma base de dados. Tabelas partilhadas e cookies partilhados dão uma falsa sensação de segurança. Um staging a sério tem base de dados e URL próprios.

#Como o WordPress reverte uma atualização de plugin falhada

Desde o WordPress 6.3, o núcleo tem uma reversão integrada para atualizações manuais de plugins e temas. Segundo a nota de desenvolvimento do 6.3, a versão instalada é movida para wp-content/upgrade-temp-backup/plugins/ ou wp-content/upgrade-temp-backup/themes/ antes da atualização. Se a instalação falhar, volta ao sítio. Se correr bem, a cópia é apagada. O Site Health ganhou duas verificações: se a pasta de backup tem permissão de escrita e se há espaço em disco suficiente para atualizar em segurança.

O limite está na mesma nota. «Falhar» significa que a própria instalação devolve um erro, por exemplo um pacote vazio ou ficheiros que não podem ser movidos. Uma atualização que instala bem, mas parte o checkout, conta como bem-sucedida, e a versão antiga já foi apagada.

O WordPress 6.6 foi mais longe nas atualizações automáticas de plugins. A proposta de integração descreve o processo: durante as atualizações automáticas o site fica em modo de manutenção, o WordPress envia um pedido loopback à página inicial para detetar erros fatais de PHP e, se este devolver um erro, repõe a versão anterior do plugin e envia um email para o endereço em admin_email. O apelo a testes do 6.6 confirma que este é o comportamento por omissão desde o 6.6.

O mecanismo apanha o óbvio: um erro fatal que deita abaixo a página inicial. Não apanha um erro que só aparece no checkout, num formulário ou numa tarefa cron, e a proposta só fala de plugins, não de temas. A reversão integrada não substitui o staging nem um backup que já restaurou pelo menos uma vez.

#Como controlar as atualizações automáticas no código

A documentação de atualizações descreve mais interruptores do que a constante WP_AUTO_UPDATE_CORE. São úteis quando uma equipa mantém muitos sites com as mesmas regras:

• AUTOMATIC_UPDATER_DISABLED em wp-config.php desliga todas as atualizações automáticas, do núcleo e de tudo o resto. A documentação desaconselha-o fortemente. Se encontrar esta constante num site, descubra quem a definiu e porquê.
• Os filtros auto_update_plugin e auto_update_theme recebem o elemento a atualizar, por isso pode verificar $item->slug e ativar a atualização automática só para plugins escolhidos. Se o filtro devolver false para tudo, bloqueia também as atualizações de segurança que o WordPress.org envia em casos especiais.
• auto_update_translation controla os ficheiros de tradução, que se atualizam sozinhos por omissão.
• auto_core_update_send_email controla os emails sobre atualizações do núcleo. O filtro recebe o tipo (success, fail ou critical), por isso pode silenciar os avisos de sucesso e manter os de erro.
• automatic_updates_is_vcs_checkout decide se uma pasta .git, .hg ou .svn no diretório do WordPress ou acima dele trava as atualizações automáticas.

A documentação diz que os filtros devem ficar num plugin must-use e não em wp-config.php, porque aí o WordPress ainda não está totalmente carregado e podem surgir conflitos, nomeadamente com o WP-CLI. Um pequeno mu-plugin no controlo de versões torna também as regras visíveis para o próximo programador que pegar no site.

#Como proteger plugins próprios de uma atualização errada

Um plugin feito à medida com o mesmo slug de um plugin do diretório WordPress.org podia ser sobrescrito quando a versão do diretório recebia uma atualização. A nota de desenvolvimento do WordPress 5.8 introduziu o cabeçalho de plugin Update URI para o evitar: se o valor apontar para algo que não seja o WordPress.org, o WordPress não tenta atualizar o plugin a partir de lá. Update URI: false trava as atualizações por completo, e o filtro update_plugins_{$hostname} permite que um servidor de atualizações próprio entregue novas versões. Ponha este cabeçalho em todos os plugins internos. Leva um minuto e elimina uma classe inteira de acidentes em que código alheio chega à produção pelo botão de atualizar.

#Como reforçar o WordPress enquanto o patch não chega

Nenhuma rotina é instantânea. O hardening decide o que um atacante consegue fazer entretanto.

• Sem editor de ficheiros. define('DISALLOW_FILE_EDIT', true); no wp-config.php retira do painel o editor de temas e plugins, e uma sessão de administrador roubada deixa de poder escrever PHP a partir do navegador.
• Sem PHP em uploads. Bloqueie a execução em wp-content/uploads no servidor web. Uma falha de upload acaba num ficheiro guardado, não numa shell.
• Permissões justas. O wp-config.php legível apenas pelo utilizador do site e nenhuma pasta gravável por todos.
• Poucos administradores. Várias correções da série 7.1.x dependem de um papel. Menos contas privilegiadas, menos caminhos exploráveis. Dê o papel de Editor a quem edita, não o de Administrador.
• Início de sessão forte. 2FA em todas as contas que publicam ou instalam, como descreve o guia de segurança do início de sessão.
• XML-RPC desligado se nenhuma aplicação ou ligação Jetpack o usar: add_filter('xmlrpc_enabled', '__return_false');.

A lista completa, com exemplos de servidor, está no guia de hardening.

#Contra o que protege uma WAF no WordPress

As Web Application Firewalls (Cloudflare, Sucuri, a WAF do alojamento ou o virtual patching por plugin de fornecedores como a Patchstack) são úteis. Não substituem as atualizações.

Uma WAF é boa em:

• rate limiting contra brute force no login,
• bloqueio de assinaturas de exploits conhecidas e user-agents maliciosos,
• virtual patching: bloqueio temporário de um padrão de ataque conhecido enquanto testa a atualização em staging,
• filtragem por país ou ASN quando surgem padrões de varrimento óbvios.

Uma WAF é fraca ou cega perante:

• erros de lógica num plugin próprio («se ?token= coincidir, dá admin»),
• sessões de administrador legítimas comprometidas (cookie roubado após phishing),
• permissões de ficheiros erradas que deixam correr um ficheiro PHP carregado,
• backdoors que já estão em wp-content/uploads desde uma invasão anterior,
• problemas de cadeia de fornecimento em que o próprio plugin atualizado está comprometido (mais raro, mas documentado no ecossistema).

Por isso, a ordem é sempre a mesma: atualizar e endurecer primeiro, usar a WAF como camada extra e como margem na janela do patch. «Pôr o Cloudflare à frente» e dar o trabalho por terminado é um erro comum, sobretudo quando o DNS está certo mas o servidor de origem continua a abrir wp-admin diretamente pelo IP.

#Porque a versão de PHP faz parte da rotina de atualizações

As atualizações do WordPress pouco valem se o PHP por baixo já não recebe correções de segurança. A página de requisitos de wordpress.org recomenda PHP 8.3 ou superior, MySQL 8.0 ou superior ou MariaDB 10.11 ou superior, e HTTPS. Diz também que o WordPress funciona com PHP 7.4 e MySQL 5.5.5, mas que estas versões chegaram ao fim de vida e podem expor o site a vulnerabilidades.

A tabela de php.net mostra, em outubro de 2026, que o PHP 8.2 só recebe correções de segurança e que estas terminam a 31 de dezembro de 2026. O PHP 8.3 recebe correções de segurança até 31 de dezembro de 2027, e o 8.4 e o 8.5 ainda têm suporte ativo. Ramos anteriores ao 8.2 não recebem correções. Veja a versão em Ferramentas, Saúde do site, separador Informação, ou com php -v no servidor, e planeie a mudança em staging como uma atualização maior do WordPress. Um plugin antigo que não aguenta um PHP mais recente é um argumento para trocar o plugin, não para ficar num ramo de PHP sem correções.

#O que o RGPD e a CNPD esperam depois de uma violação

O artigo 32.º do RGPD exige “medidas técnicas e organizativas adequadas” para proteger os dados pessoais. O artigo 33.º impõe notificar a autoridade de controlo sem demora injustificada e, sempre que possível, até 72 horas após o conhecimento da violação, salvo se esta não for suscetível de implicar risco para os direitos e liberdades das pessoas. O incumprimento das obrigações dos artigos 25.º a 39.º cai no escalão inferior de coimas do artigo 83.º, n.º 4: até 10 milhões de euros ou 2 % do volume de negócios anual a nível mundial, consoante o valor mais elevado.

Em Portugal, a página da CNPD sobre violação de dados afirma que é obrigação do responsável pelo tratamento notificar a CNPD e que a notificação deve ser feita no prazo de 72 horas após ter tido conhecimento da violação. O regulamento não escreve “instale as atualizações”. Mas uma loja que recolhe dados de clientes e manteve durante semanas um plugin com correção já publicada terá dificuldade em defender essa medida. Guarde o registo que prova o contrário: datas das atualizações, o teste em staging, o plano de reversão. O mesmo registo ajuda numa auditoria de conformidade UE.

#Como detetar um site WordPress comprometido

O spam de SEO injetado é feito para o dono não reparar. As páginas são mostradas ao Googlebot e não aos visitantes, por isso uma página inicial limpa não prova nada. Estas verificações provam:

• wp core verify-checksums e wp plugin verify-checksums --all comparam os ficheiros com as versões oficiais e assinalam alterações.
• Procure ficheiros PHP mais recentes do que o wp-config.php, começando pela pasta do tema.
• wp user list --role=administrator só deve mostrar pessoas que reconhece.
• Uma alteração de ficheiros que ninguém da equipa sabe explicar é um incidente. Passe de imediato à contenção.

Se preferir que as verificações sejam feitas por quem não é dono do site, uma auditoria de segurança WordPress cobre componentes desatualizados, utilizadores expostos e configuração do servidor numa só passagem.

#Erros comuns de segurança WordPress nas empresas

Alguns padrões repetem-se em pequenas empresas e clientes de agências:

Stack de pagamentos e reservas sem responsável. MB WAY, Multibanco, Stripe, Easy Digital Downloads, Bookly ou Amelia são atualizados «quando houver tempo». O plugin de pagamento é exatamente o sítio que os atacantes procuram, porque o ganho é direto. Defina um responsável que acompanhe os avisos de segurança desses slugs.

Dados de produção em staging sem anonimização. Cópias de listas de clientes, histórico de encomendas e subscrições num URL de staging aberto são um problema de proteção de dados antes de alguém invadir. Mascare os dados ou limite o acesso. A CNPD olha para a segurança do tratamento, não para o nome «dev» do ambiente.

Agência e cliente sem responsabilidades claras. O cliente pensa que a agência aplica os patches. A agência pensa que o cliente clica no wp-admin. Escreva-o: quem acompanha as atualizações, quem aprova a passagem de staging para produção, quem tem 2FA no painel do alojamento. Sem essa frase, o patch fica para depois da Black Friday ou do Natal, precisamente quando há menos tempo para apagar fogos.

«Plugin de segurança» em vez de hardening. Um plugin que analisa ficheiros é útil como sinal. Não substitui permissões de ficheiros, atualizações nem o bloqueio do acesso a install.php depois da instalação. Siga os pontos do hardening no manual do programador antes de comprar mais uma licença.

Email e chaves SMTP. Um plugin SMTP comprometido ou uma chave SendGrid ou Mailgun divulgada servem para phishing em nome da sua empresa. Mude as chaves quando alguém sai e limite os âmbitos da API.

#O que verificar no seu site WordPress esta semana

Confirme que a 7.1.3 está instalada em todos os sites. Liste os plugins com atualizações pendentes e ordene-os pelo que cada um alcança. Retire o que está abandonado. Conte as contas de administrador e reduza-as. Marque depois a próxima revisão no calendário, porque a próxima versão de segurança não vai esperar.