A segurança WordPress em 2027 resume-se a uma lista curta de hábitos: manter o núcleo, os plugins e os temas atualizados, proteger os acessos com palavras-passe fortes e autenticação de dois fatores, eliminar o que não usa e guardar cópias de segurança testadas fora do servidor. Quase todos os ataques bem-sucedidos a um site WordPress entram por uma destas portas abertas, e não por uma falha exótica do próprio WordPress.
Última atualização: 20 de outubro de 2026.
Este guia percorre as principais ameaças, uma tabela de soluções com o esforço de cada uma, uma lista de proteção numerada, as regras da UE que tocam o seu website e o que fazer nas primeiras horas depois de um ataque.
O WordPress é seguro?
O núcleo do WordPress é mantido por uma grande equipa de segurança, recebe por predefinição atualizações menores automáticas e é revisto constantemente. Sozinho, é uma base sólida. O risco vem do que lhe é acrescentado e da forma como é gerido: plugins e temas de muitos autores, contas de administrador com palavras-passe fracas, versões antigas de PHP, alojamento barato sem isolamento entre sites e ninguém a vigiar.
Em resumo: o WordPress é tão seguro quanto a forma como é construído e mantido. Um site enxuto, com poucos plugins bem escolhidos, software atualizado e acessos controlados, é um alvo difícil. Um site com quarenta plugins, cinco deles abandonados, e uma palavra-passe de administrador partilhada é um alvo fácil. A diferença raramente está na plataforma; está no cuidado à volta dela.
Na Odduel, agência de criatividade e tecnologia em Barcelona e São Paulo, construímos sites WordPress com temas de blocos próprios e o menor número possível de plugins, em parte pela velocidade e em parte porque cada plugin é código em que tem de confiar. Se está a planear um novo website, o nosso trabalho de criação de websites começa por essa pergunta: do que precisa realmente este site para funcionar?
Quais são as principais ameaças à segurança do WordPress?
Os ataques ao WordPress são sobretudo automatizados. Os bots percorrem a web à procura de fraquezas conhecidas e experimentam-nas em todos os sites que encontram, por isso o website de uma pequena empresa tem tantas probabilidades de ser sondado como um grande. Estas são as cinco ameaças que mais contam.
Plugins e temas desatualizados
É a forma de entrada mais comum. É encontrada uma falha num plugin, sai uma correção, os detalhes tornam-se públicos e os bots começam a experimentar a falha em todos os sites que não atualizaram. O intervalo entre a correção e os primeiros ataques pode ser curto. Os plugins abandonados são piores: nunca chegam a ser corrigidos.
Acessos fracos e palavras-passe roubadas
A página de início de sessão em `/wp-login.php` é pública em todos os sites. Os bots experimentam palavras-passe comuns e palavras-passe roubadas noutros serviços (credential stuffing). Uma conta de administrador com uma palavra-passe reutilizada, ou com o nome de utilizador predefinido “admin”, entrega o site inteiro a um atacante sem precisar de qualquer falha.
XML-RPC e outras portas de entrada antigas
O XML-RPC é uma interface antiga de publicação remota. A maioria dos sites já não precisa dela, mas continua ativa por predefinição e permite a um atacante experimentar muitas palavras-passe num só pedido. O mesmo vale para a lista pública de nomes de utilizador na REST API, que entrega aos bots metade de cada início de sessão.
Envio de ficheiros
Qualquer formulário ou plugin que aceite ficheiros pode tornar-se uma forma de colocar um script no servidor. Se o servidor executar depois PHP a partir da pasta de uploads, o atacante tem uma porta das traseiras. Os formulários de contacto com anexos, os perfis de utilizador e os plugins de media são os suspeitos do costume.
Cadeia de fornecimento
Um plugin em que confia pode mudar de mãos. Um novo dono, ou um atacante que tomou a conta do autor, pode publicar uma atualização com código escondido para todos os sites que a instalam automaticamente. Os plugins e temas premium pirateados (nulled) são, por natureza, um ataque à cadeia de fornecimento: chegam muitas vezes com malware já lá dentro.
Ameaças, soluções e esforço num relance
A tabela junta cada ameaça à solução que a fecha e a uma ideia aproximada do esforço envolvido num site típico.
| Ameaça | Solução | Esforço |
|---|---|---|
| Plugins e temas desatualizados | Atualizações semanais, teste em staging, remoção de plugins abandonados | Baixo, contínuo |
| Acessos fracos | Palavras-passe únicas, autenticação de dois fatores, limite de tentativas de início de sessão | Baixo, uma vez |
| XML-RPC e listas de utilizadores | Desativar o XML-RPC e a lista pública de utilizadores | Baixo, uma vez |
| Envio de ficheiros | Bloquear PHP nos uploads, limitar os tipos de ficheiro, analisar os ficheiros enviados | Médio, uma vez |
| Cadeia de fornecimento | Poucos plugins de autores conhecidos, nenhum código pirateado, rever as atualizações | Médio, contínuo |
| Servidor comprometido | Alojamento isolado, PHP atual, firewall, permissões de ficheiros mínimas | Médio, uma vez |
| Perda de dados após um ataque | Cópias de segurança fora do servidor, com versões e testadas | Baixo, contínuo |
Repare que a maior parte do trabalho exige pouco esforço. A parte cara da segurança WordPress não são as soluções; é a limpeza quando foram ignoradas.
Lista de verificação de segurança WordPress em dez passos
Use esta lista de proteção num site novo antes do lançamento e num site existente como auditoria. Siga-a por ordem: os primeiros passos fecham as portas que os atacantes mais experimentam.
- Atualize tudo. Núcleo, plugins, temas e PHP. Ative as atualizações menores automáticas do núcleo, teste primeiro as atualizações de plugins numa cópia de staging e defina um ritmo semanal para o resto.
- Elimine o que não usa. Apague os plugins e temas inativos, não se limite a desativá-los. Substitua qualquer plugin que não tenha tido uma atualização há um ano.
- Reveja as funções dos utilizadores. Dê a cada pessoa a sua própria conta, com a função mais baixa que lhe permita fazer o trabalho. Os editores não precisam de ser administradores. Remova as contas de antigos colaboradores e de agências no dia em que saem.
- Ative a autenticação de dois fatores. Torne-a obrigatória pelo menos para os administradores. Junte palavras-passe fortes e únicas, guardadas num gestor de palavras-passe.
- Limite as tentativas de início de sessão. Limite os pedidos a `/wp-login.php` no servidor ou na firewall, e esconda os nomes de utilizador dos arquivos públicos e da REST API.
- Desative o XML-RPC, a não ser que um serviço de que depende precise dele, e desative a edição de ficheiros na administração (`DISALLOW_FILE_EDIT`).
- Guarde as cópias de segurança fora do servidor. Diárias, com versões, guardadas noutro lugar e restauradas uma vez num teste, para saber que funcionam.
- Acrescente uma firewall. Uma firewall de aplicações web no alojamento ou à frente do site filtra ataques conhecidos antes de chegarem ao WordPress.
- Envie cabeçalhos de segurança. HTTPS em todo o lado com HSTS, mais `X-Content-Type-Options`, proteção contra frames, uma política de referrer e, quando estiver pronto, uma política de segurança de conteúdos.
- Escolha um alojamento que isole os sites. Cada site com o seu próprio utilizador de sistema, PHP atual, PHP bloqueado nos uploads e acesso ao servidor apenas por chave.
A segurança também faz parte das verificações de lançamento. A nossa lista de verificação de QA de websites cobre os testes a fazer antes de um site ir para o ar, e a segurança está ao lado da velocidade, da acessibilidade e dos formulários nessa revisão.
Como proteger um website WordPress com o alojamento certo?
O alojamento decide quanto da lista consegue realmente cumprir. Num alojamento partilhado básico, muitas vezes não consegue definir cabeçalhos no servidor, bloquear PHP numa pasta ou ver os registos. Num alojamento WordPress gerido ou num servidor bem gerido, consegue.
Faça quatro perguntas ao fornecedor de alojamento. Cada site está isolado dos outros na mesma máquina? Que versões de PHP oferecem, e com que rapidez passam às novas? As cópias de segurança são guardadas fora do servidor, e pode restaurar uma sozinho? Existe uma firewall e um limite de tentativas de início de sessão ao nível do servidor?
Se as respostas forem vagas, o alojamento faz parte do seu risco. A escolha da plataforma também conta: o nosso guia Como escolher um CMS: WordPress, headless ou outro? compara o WordPress com outras opções quando a segurança e a manutenção pesam muito.
Que regras da UE se aplicam à segurança WordPress?
Há duas leis europeias recentes muitas vezes citadas em artigos de segurança, e ambas são muitas vezes exageradas. Eis o que dizem realmente para um site WordPress típico.
O Regulamento de Ciber-Resiliência
O Regulamento de Ciber-Resiliência, Regulamento (UE) 2024/2847, define regras de segurança para produtos com elementos digitais colocados no mercado da UE. Os deveres de notificação de falhas ativamente exploradas aplicam-se a partir de 11 de setembro de 2026 e a maioria das outras obrigações a partir de 11 de dezembro de 2027. Dirige-se aos fabricantes de software e de produtos ligados, por isso conta sobretudo para as empresas que vendem plugins ou temas comercialmente. Uma empresa que simplesmente gere o seu próprio website não passa por isso a ser fabricante, mas vai beneficiar à medida que os plugins que compra ficarem sujeitos às regras.
NIS2
A Diretiva NIS2 aplica-se a organizações médias e grandes de setores listados, como energia, transportes, saúde, infraestruturas digitais e alguma indústria, através da lei nacional de cada Estado-Membro. Se a sua organização estiver abrangida, o website faz parte dos sistemas que tem de proteger e os seus deveres de notificação de incidentes vão além do website. Se não estiver, a NIS2 não se aplica ao seu site.
RGPD
A regra que se aplica a quase todos é o RGPD. Um site WordPress que guarda mensagens de formulários, contas de clientes ou encomendas guarda dados pessoais, e uma violação desses dados é uma violação de dados pessoais. Isso traz um prazo claro, descrito abaixo.
O que fazer depois de uma intrusão num website WordPress?
A rapidez e a ordem contam mais do que as ferramentas. Siga estes passos quando suspeitar que o site foi comprometido.
- Contenha. Ponha o site em modo de manutenção ou tire-o do ar, e mude as palavras-passe de todos os administradores, da conta de alojamento, da base de dados e de qualquer serviço ligado.
- Preserve as provas. Copie os ficheiros, a base de dados e os registos do servidor antes de limpar seja o que for, para conseguir perceber como o atacante entrou.
- Avalie os dados pessoais. Descubra se mensagens de formulários, contas ou encomendas ficaram expostas. É isso que decide os seus deveres legais.
- Notifique, se for obrigatório. Nos termos do artigo 33.º do RGPD, uma violação de dados pessoais tem de ser notificada à autoridade de controlo sem demora injustificada e, sempre que possível, até 72 horas depois de ter tido conhecimento dela, a menos que não seja suscetível de resultar num risco para as pessoas. Quando o risco para as pessoas for elevado, também elas têm de ser informadas.
- Limpe ou restaure. Restaure a partir de uma cópia de segurança anterior ao ataque, ou reinstale o núcleo, os plugins e os temas a partir das fontes oficiais e limpe a base de dados. Não confie em ficheiros que estavam no servidor durante o ataque.
- Feche a porta. Encontre e corrija a forma de entrada, normalmente um plugin desatualizado ou uma palavra-passe roubada, ou o atacante volta em poucos dias.
- Monitorize. Acompanhe os registos, as alterações de ficheiros e os resultados de pesquisa à procura de páginas de spam nas semanas seguintes, e peça uma revisão no Google Search Console se o site tiver sido assinalado.
Guarde um registo escrito de cada passo e de cada decisão. O RGPD pede que documente todas as violações, mesmo as que não teve de notificar.
Perguntas frequentes
O WordPress é seguro para o website de uma empresa?
Sim, quando é construído de forma enxuta e mantido. O núcleo do WordPress tem uma equipa de segurança dedicada e atualizações regulares. A maioria das violações vem de plugins desatualizados ou abandonados, de palavras-passe de administrador fracas e de mau alojamento. Um site com poucos plugins bem escolhidos, autenticação de dois fatores, PHP atual e cópias de segurança fora do servidor é um alvo difícil para os ataques automatizados que compõem a maioria das ameaças.
Com que frequência devo atualizar os plugins do WordPress?
Verifique se há atualizações pelo menos uma vez por semana e aplique as correções de segurança assim que saem, porque os ataques começam muitas vezes pouco depois de uma falha se tornar pública. Teste primeiro as atualizações maiores numa cópia de staging. Qualquer plugin que esteja há um ano sem atualização deve ser substituído, porque um plugin abandonado nunca vai receber uma correção.
Preciso de um plugin de segurança?
Nem sempre. Muitas proteções, como o limite de tentativas de início de sessão, o bloqueio de PHP nos uploads, os cabeçalhos de segurança e a firewall, funcionam melhor ao nível do servidor ou do alojamento, onde travam os ataques antes de o WordPress carregar. Um plugin de segurança pode ajudar num alojamento que não ofereça nada disto, mas não substitui as atualizações, os acessos fortes e as cópias de segurança testadas.
Devo desativar o XML-RPC no WordPress?
Na maioria dos casos, sim. O XML-RPC é uma interface antiga de publicação remota de que poucos sites ainda precisam, e permite aos atacantes experimentar muitas palavras-passe num só pedido. Desative-o no servidor ou com uma pequena definição, a não ser que um serviço de que depende, como uma app móvel de publicação mais antiga, ainda precise dele. Confirme antes de o desativar.
O Regulamento de Ciber-Resiliência aplica-se ao meu site WordPress?
Normalmente, não diretamente. O Regulamento de Ciber-Resiliência impõe deveres aos fabricantes de software e de produtos ligados colocados no mercado da UE, por isso diz sobretudo respeito às empresas que vendem plugins, temas ou software comercialmente. Uma empresa que gere o seu próprio website não é, por isso, fabricante, mas ganha à medida que os plugins comerciais têm de cumprir os novos requisitos de segurança.
Com que rapidez tenho de notificar uma violação de dados no WordPress?
Se houve dados pessoais expostos, o RGPD exige que notifique a violação à autoridade de controlo sem demora injustificada e, sempre que possível, até 72 horas depois de ter tido conhecimento dela, a menos que não seja suscetível de pôr as pessoas em risco. Se o risco para as pessoas for elevado, tem também de as informar. Documente todas as violações, notificadas ou não.
Se o seu site cresceu plugin a plugin, ou não sabe quem o atualizou pela última vez, uma auditoria curta com base na lista acima é o ponto de partida; o nosso guia de desenvolvimento de websites explica como se planeia um site enxuto desde o primeiro briefing. Quando quiser um site WordPress seguro desde o início, conheça o nosso serviço de criação de websites ou fale connosco sobre o seu projeto.
Leituras recomendadas: Next.js ou React para o website de uma empresa, Webflow ou WordPress em 2027: qual se adapta à sua empresa, Custo da manutenção de websites: o que incluem os planos.
