Em 2025, o WordPress registrou 11.334 vulnerabilidades novas — um aumento de 42% em relação ao ano anterior. As altamente exploráveis subiram 113%. O tempo entre a divulgação de uma falha e a primeira exploração em massa: 5 horas. Na Tech86, já vimos o suficiente para afirmar: o problema não se resolve com mais plugins de segurança. A saída é estrutural — e chama-se arquitetura headless.
O ecossistema é o problema, não o core
O WordPress core é relativamente seguro. O Patchstack documentou que 97% das vulnerabilidades vêm de plugins. O site médio roda entre 20 e 40 plugins. Cada um é um vetor de ataque potencial. Um plugin desatualizado expõe XSS ou RCE — e é explorado dentro de horas.
A matemática é implacável: 20 plugins × 12 atualizações por ano × 5 horas de janela de exploração. Ninguém patcha em 5 horas. Nem equipes dedicadas. O problema é de supply chain estrutural — e não se resolve instalando mais um plugin de segurança que, por definição, também é um plugin.
Já atendemos clientes que rodavam 35 plugins e descobriram que 8 estavam abandonados há mais de um ano. Dois deles tinham vulnerabilidades conhecidas há meses. O site estava comprometido e ninguém tinha notado. Isso não é exceção — é a regra.
O que fica exposto no WordPress monolítico
Um WordPress tradicional expõe à internet tudo o que não deveria estar exposto. /wp-login.php fica acessível — e recebe em média 30.000 tentativas de brute-force por dia. XML-RPC fica ativo por padrão. O endpoint de upload fica acessível. O diretório de plugins fica acessível.
Cada um desses endpoints é uma porta que não precisa estar aberta. Mas no modelo monolítico, não tem como fechá-las sem quebrar funcionalidade. O WordPress precisa servir páginas, processar forms, aceitar uploads e autenticar usuários — tudo pelo mesmo servidor, tudo na mesma superfície.
O resultado é um site onde a mesma infraestrutura que serve o blog para visitantes também processa autenticação, aceita uploads e executa PHP por request. É o equivalente a deixar a porta dos fundos do escritório aberta porque o delivery precisa entrar.
O que headless elimina estruturalmente
Arquitetura headless separa o CMS do frontend. O WordPress vira uma origem de conteúdo atrás de API autenticada. O frontend é HTML pré-construído servido por CDN. As implicações de segurança são diretas:
- PHP por request no frontend → HTML pré-construído via CDN. Zero PHP no tráfego público.
- Database query por page load → Dados renderizados no build time. Sem SQL injection no frontend.
/wp-login.php→ Admin atrás de firewall, sem URL pública. Sem brute-force.- XML-RPC → Não existe no frontend. Upload endpoint → não existe. Diretório de plugins → não existe.
Headless não é um plugin a mais. É a remoção estrutural da superfície de ataque. O ataque que funcionava no WordPress monolítico simplesmente não encontra superfície para explorar.
Performance por design, não por workaround
A migração headless não é apenas sobre segurança. É sobre performance real — e os números de um caso concreto com 400 páginas B2B falam por si:
| Métrica | WordPress Monolítico | Headless (Next.js) | Redução |
|---|---|---|---|
| LCP | 2.8s | 0.7s | 75% |
| CLS | 0.18 | 0.01 | Praticamente eliminado |
| TTI | 5.1s | 1.2s | 76% |
| Page weight | 3.2MB | 480KB | 85% |
Core Web Vitals impacta conversão e ranking. No WordPress monolítico, a abordagem é compensar: plugin de cache, Cloudflare Pro, otimização manual de assets. No headless, performance é por design — o HTML já está pronto, servido do ponto mais próximo do usuário.
Aprendemos com um cliente que gastava 200 dólares/mês em Cloudflare Pro + plugins de cache premium para atingir LCP de 2.8s. Após a migração headless, o LCP caiu para 0.7s sem nenhum plugin de cache — porque não existe cache quando a página já é estática.
O que muda na operação do dia a dia
A operação de um site headless é fundamentalmente diferente. Sem plugin de cache para configurar. Sem Cloudflare Pro para compensar PHP lento. Sem auditoria de plugins semanal. Sem patch de emergência às 3h da manhã porque um plugin popular teve zero-day divulgado.
O CMS vive em origem separada, atrás de API autenticada. O frontend é estático. Quando uma vulnerabilidade é divulgada no WordPress, você atualiza o CMS — mas o frontend não é afetado porque não executa PHP. A janela de 5 horas entre disclosure e exploração deixa de ser um pesadelo.
O custo operacional cai. O risco cai. A performance sobe. Não é mágica — é arquitetura.
O custo da migração e o ROI real
O investimento em migração headless varia por porte:
- Pequeno (blog/institucional): 3K–7K
- Médio (B2B com integrações): 7K–15K
- Enterprise (e-commerce, multi-região): 15K+
O ROI vem em meses. Hosting mais barato porque serve HTML estático. Zero plugins premium de cache, segurança e otimização. Zero downtime por patch de emergência. Conversão que sobe porque o site carrega em 0.7s em vez de 2.8s.
A pergunta que fazemos a cada cliente WordPress: seu site tem quantos plugins? Quantos você atualizou na última semana? Quantos você não atualiza porque tem medo de quebrar? Se a resposta é "não sei", você está operando com uma bomba-relógio de supply chain. Timer: 5 horas.
Na Tech86, migramos sites WordPress para arquitetura headless com Next.js. Sem plugin. Sem /wp-login.php exposto. Sem pesadelo de patch. A segurança deixa de ser reativa e passa a ser estrutural.