Um cliente liga numa sexta-feira à tarde. O site dele está a redirecionar os visitantes para uma farmácia online. Ou o Google colou-lhe um aviso. Ou o alojamento suspendeu a conta durante a noite, sem grande explicação.
Ninguém da tua equipa mexe nesse site há quatro meses. O tema é teu. O código à medida é teu. Ambos estão bem.
A porta de entrada foi um plugin. Normalmente é.
Se geres sites para mais do que um punhado de clientes, já viveste alguma versão deste fim de semana. Este artigo é sobre o porquê de isto continuar a acontecer, sobre porque é uma propriedade da arquitetura e não uma falha de diligência, e sobre quais são as opções realistas — incluindo ficares exatamente onde estás.
Onde vivem realmente as vulnerabilidades do WordPress
O importante é perceber que o core do WordPress não é o problema. O core tem uma equipa de segurança dedicada, aplica atualizações automáticas em segundo plano nas versões menores e tem um processo de divulgação que funciona. As vulnerabilidades graves no core são raras e corrigidas depressa.
As vulnerabilidades estão no ecossistema à sua volta. Dezenas de milhares de plugins e temas, uma grande parte mantidos por uma única pessoa nos tempos livres, e um número significativo abandonados há anos mas ainda a correr em centenas de milhares de sites em produção. Ano após ano, a esmagadora maioria das vulnerabilidades do WordPress divulgadas publicamente é encontrada em plugins e temas, e não no core.
Essa distinção importa mais do que parece à primeira vista, por causa do que instalar um plugin realmente faz.
Não estás a adicionar uma funcionalidade. Estás a adicionar PHP de terceiros que corre no teu servidor, dentro da tua aplicação, com acesso à tua base de dados e ao teu sistema de ficheiros, em cada pedido. Um plugin de formulário de contacto e um plugin de pagamentos têm exatamente os mesmos privilégios. E o mesmo vale para o plugin de slider que alguém instalou em 2021 para corrigir uma página e que nunca foi removido.
Três padrões explicam a maior parte do que vemos:
- Abandono. Um plugin deixa de ser mantido. Não o anuncia. Continua a funcionar na perfeição, e é precisamente esse o problema — nada no site parece estar mal até ser divulgada uma vulnerabilidade para a qual não vem correção nenhuma. O mesmo acontece à escala de plataforma: quando o Magento 2.4.5 e o 2.4.6 deixaram de receber patches de segurança, nenhuma dessas lojas reparou.
- A popularidade como alvo. Um plugin presente em 200,000 sites vale o tempo de um investigador e o de um atacante. A divulgação é pública, e a varredura em massa à procura da versão vulnerável começa em poucas horas.
- Cadeia de fornecimento. Um mantenedor vende um plugin popular. O novo dono publica uma atualização que adiciona tracking, links injetados ou uma backdoor. O dono do site vê uma notificação de atualização de rotina.
Nada disto é algo que uma agência consiga evitar sendo cuidadosa. Só podes reagir mais depressa.
Porque é arquitetura, e não descuido
É tentador ler o que está acima como "os utilizadores de WordPress são desleixados". Não é isso. Há três decisões estruturais que produzem o risco, e as três são deliberadas.
O CMS e o site público são a mesma aplicação. Aquilo que os teus visitantes carregam e aquilo em que o teu cliente inicia sessão são uma única aplicação PHP, num único servidor, a partilhar uma única base de dados. Não há fronteira a atravessar porque não há fronteira.
Os plugins correm do lado do servidor com privilégios totais. A extensibilidade do WordPress é a razão pela qual ganhou. Os hooks e filtros permitem que o código dos plugins corra em praticamente qualquer ponto do ciclo de vida do pedido. Isso é imensamente poderoso, e significa que uma vulnerabilidade em qualquer plugin instalado é uma vulnerabilidade no site inteiro.
O login de administração está no domínio público. /wp-admin e /wp-login.php estão no mesmo hostname do site de marketing, acessíveis a qualquer pessoa. O credential stuffing automatizado contra eles começa poucas horas depois de um domínio ficar online — não porque tenhas sido escolhido como alvo, mas porque tudo é varrido.
Juntando tudo: a superfície de ataque não é algo aparafusado ao WordPress. É aquilo que faz do WordPress o WordPress. O ecossistema de plugins que permite a uma agência pequena lançar um sistema de reservas numa tarde é o mesmo mecanismo que põe código de terceiros não revisto no caminho de cada pedido do site de um cliente.
Onde o WordPress ainda ganha
Qualquer comparação que salte esta parte é marketing, por isso vamos ser diretos. Há boas razões para o WordPress alimentar uma grande parte da web, e para muitos projetos continua a ser a escolha certa.
O ecossistema não tem rival. Seja o que for que o cliente queira — eventos, áreas de membros, um fornecedor de pagamentos específico, uma integração com um CRM obscuro — já existe alguma coisa. Construir o equivalente de raiz custa dinheiro a sério.
Custo e rapidez em sites simples. Para um site institucional de cinco páginas com blog e formulário de contacto, o WordPress com um tema decente é difícil de bater em tempo de lançamento ou em orçamento. Insistir aí num stack à medida é fazer engenharia pela engenharia.
Disponibilidade de talento. Consegues contratar competências de WordPress em qualquer cidade e em qualquer gama de preços. Isso não acontece com todos os stacks, e importa para a manutenção num horizonte de cinco anos.
Os clientes já o conhecem. Muitos já usaram o painel de administração. A familiaridade tem um valor real, fácil de desvalorizar até seres tu a dar a sessão de formação.
Se o site é de baixo risco, o orçamento é pequeno e alguém está genuinamente empenhado em manter os plugins atualizados — o WordPress é uma escolha razoável e defensável. Os problemas começam quando o site importa, a avença não cobre a manutenção e ninguém está realmente a vigiar.
O que muda ao desacoplar
A alternativa que se tornou padrão para as agências que gerem muitos sites de clientes é separar os dois trabalhos que o WordPress faz ao mesmo tempo: gerir conteúdo e servir o site.
Numa arquitetura desacoplada, o CMS corre na sua própria infraestrutura. O site público é uma aplicação separada que lê o conteúdo através de uma API com um token só de leitura e renderiza as páginas. Essa única separação muda o panorama de segurança de forma estrutural, e não incremental:
- Não há login de administração no site servido. Não há
/wp-adminpara atacar por força bruta, porque a administração não está lá. O tráfego de credential stuffing que atinge todos os sites WordPress não tem onde bater. - Não corre código de terceiros no site público. Não há runtime de plugins porque não há sistema de plugins. A funcionalidade é código no teu próprio repositório, revisto e implementado como o resto do teu trabalho.
- A base de dados não é acessível a partir do site público. O site lê o conteúdo através de uma API com um token limitado ao conteúdo publicado. Comprometer o frontend não entrega o repositório de conteúdos.
- As correções aplicam-se num só lugar. Uma plataforma, atualizada uma vez, em vez da mesma atualização aplicada separadamente em cada site que manténs.
As categorias de ataque que explicam a maioria dos comprometimentos de WordPress não ficam mais difíceis neste modelo. Deixam de ter onde aterrar.
Aquilo de que abdicas
Com honestidade: conveniência e alguma flexibilidade.
Não há instalação em dois cliques para uma nova capacidade. Adicionar um novo tipo de bloco de conteúdo significa que um programador escreve um componente. O teu cliente não pode percorrer um marketplace e resolver o seu próprio problema às 11 da noite — o que é uma perda quando o plugin ia funcionar, e um alívio em todas as outras vezes.
Também assumes um stack que menos pessoas conhecem. É uma consideração real quando pensas em quem vai manter o site daqui a três anos.
É uma troca genuína. Estás a trocar a capacidade de instalar qualquer coisa pela garantia de que nada que não tenha sido revisto corre no site do teu cliente. Para um site institucional, essa troca pode não compensar. Para um site que recebe pagamentos, guarda dados pessoais ou transporta uma marca que não sobreviveria a um defacement, normalmente compensa.
Se vais continuar no WordPress
A maioria das agências vai manter uma carteira de clientes em WordPress, e não há problema nisso. Se for o teu caso, o trabalho é reduzir a superfície em vez de fingir que ela não existe:
- Faz inventário e corta sem piedade. Cada plugin que removes é superfície de ataque apagada para sempre. Audita o que está instalado em cada site e apaga tudo o que não justifique claramente o seu lugar — os plugins desativados continuam no disco e podem continuar acessíveis.
- Verifica o estado de manutenção, não só os números de versão. Um plugin atualizado pela última vez há três anos é um passivo, mesmo que neste momento não reporte vulnerabilidades.
- Tira o login da internet aberta. Restringe
/wp-adminpor IP sempre que possível, coloca-o atrás de SSO ou de uma regra de WAF e exige autenticação multifator em todas as contas com permissões de publicação. - Remove as contas de administrador que ninguém usa. As contas de antigos freelancers e do ex-responsável de marketing do cliente são um risco permanente sem qualquer vantagem.
- Automatiza as atualizações e monitoriza-as a sério. Atualizações automáticas com alertas batem um lembrete trimestral que é ignorado quando um projeto se atrasa.
- Tem backups que já restauraste. Um backup não testado é uma hipótese. Restaura um num ambiente de staging e confirma que funciona antes de precisares dele às 2 da manhã.
- Testa-o como um atacante faria. Testes de intrusão periódicos encontram o subdomínio de staging exposto, o painel de administração esquecido e o plugin que ninguém se lembra de ter instalado — coisas que um inventário em papel não revela.
Nada disto faz desaparecer a exposição arquitetural. Mas torna-te um alvo muito mais difícil do que o site do lado, que é a maior parte do que a segurança prática te compra.
A pergunta que vale a pena fazer
A pergunta útil não é "o WordPress é seguro?" — um site WordPress bem mantido é mais seguro do que um site negligenciado em qualquer stack.
A pergunta é: quem é responsável por mantê-lo seguro, e isso está refletido no que cobras?
Se a avença de um cliente não paga a alguém para acompanhar os alertas de segurança dos plugins, testar atualizações e responder quando algo é divulgado, então ninguém o está a fazer. O site não está a ser mantido; está a ser deixado em paz até avariar. E quando avaria, a primeira chamada do cliente é para a agência que o construiu, diga o contrato o que disser.
É este o cálculo que empurra as agências para uma plataforma gerida e desacoplada: não o facto de o WordPress ser mau, mas o facto de o esforço de manutenção de gerir corretamente uma dúzia deles ser real, recorrente e raramente incluído no preço.
Criámos o Privum CMS exatamente para essa posição — um CMS gerido e multi-tenant em que os teus clientes editam o seu próprio conteúdo, o teu design fica sob o teu controlo de versões e a plataforma é submetida a testes de intrusão quinzenalmente pelos mesmos engenheiros que realizam avaliações de segurança externas para os nossos clientes de consultoria. Não há plugins para corrigir nem painel de administração no site que os teus visitantes carregam.
Se quiseres uma segunda opinião sobre o que o teu parque atual de sites de clientes realmente expõe, fala com a nossa equipa de segurança — uma avaliação externa diz-te o que é realmente acessível, o que normalmente não coincide com o que diz o inventário.
Leitura relacionada: como funciona o email spoofing e quanto custa — a mesma lição sobre superfície de ataque, aplicada ao domínio em vez de ao site.