A Monocultura dos CMS: O WordPress Controla 43% da Web, Esse é o Problema

O problema dos 43%

Segundo a W3Techs, o WordPress alimenta aproximadamente 43% de todos os websites na internet. Na agricultura, quando uma única variedade de cultura domina uma região inteira, os biólogos chamam-lhe monocultura. As monoculturas são eficientes no curto prazo e catastróficas no longo prazo, porque um único patogéneo pode dizimar toda a colheita. O mesmo princípio aplica-se à infraestrutura web.

O WordPress não é inerentemente mau software. É um sistema de gestão de conteúdos open-source, flexível, bem documentado e com um ecossistema massivo. Mas a sua dominância criou uma vulnerabilidade estrutural que afeta cada empresa (desde lojas de retalho a firmas de manufatura), empresa de media e organização que dele depende, quer o saibam ou não.

A superfície de ataque dos plugins

A instalação base do WordPress é mantida pela equipa de segurança da Automattic e é, pela maioria dos critérios, razoavelmente segura. O problema é que o core é irrelevante. O site WordPress médio executa 20 a 30 plugins. Cada plugin é mantido por um programador diferente, com práticas de segurança diferentes, cadências de atualização diferentes e níveis de compromisso diferentes. Muitos plugins populares são mantidos por programadores individuais como projetos secundários.

A base de dados de vulnerabilidades do WPScan cataloga mais de 50.000 vulnerabilidades conhecidas em plugins, temas e core do WordPress. Só em 2024, foram divulgadas mais de 8.000 novas vulnerabilidades. Isso equivale a aproximadamente 22 novos vetores de ataque por dia em todo o ecossistema WordPress.

Uma cadeia de exploração típica funciona assim:

1. O atacante analisa o alvo usando o wpscan para enumerar os plugins instalados e as suas versões
2. Cruza a versão contra a base de dados do WPScan para CVEs conhecidos
3. Encontra uma vulnerabilidade de upload de ficheiros não corrigida num plugin de formulário de contacto (versão 3.2.1)
4. Faz o upload de uma web shell PHP disfarçada de ficheiro de imagem
5. Usa a web shell para estabelecer persistência e exfiltrar dados

# O fluxo de trabalho do atacante é trivialmente automatizável
wpscan --url https://site-alvo.com --enumerate p --api-token TOKEN

# O output revela:
# [+] contact-form-pro v3.2.1  -  VULNERÁVEL
# [!] CVE-2024-XXXXX: Upload Arbitrário de Ficheiros (Crítico)

Isto não é teórico. É o padrão de ataque mais comum na web moderna. Segundo o relatório anual de ameaças da Sucuri, os sites WordPress representam mais de 90% de todos os comprometimentos baseados em CMS. O ataque não é sofisticado. Não requer competências avançadas. Requer um scanner e uma base de dados de vulnerabilidades conhecidas que está publicamente disponível.

A passadeira rolante das atualizações

A defesa padrão é: “Mantém tudo atualizado.” Este conselho é tecnicamente correto e operacionalmente irrealista para a vasta maioria das instalações WordPress.

Consideremos uma operação de publicação media de média dimensão a usar WordPress com WooCommerce para subscrições, Advanced Custom Fields para fluxos editoriais, Yoast para SEO e uma dúzia de outros plugins para cache, formulários, analítica e integração com redes sociais.

Atualizar a versão do WordPress core arrisca quebrar a compatibilidade com os plugins. Atualizar um único plugin arrisca quebrar o tema. Atualizar o tema arrisca quebrar as funções PHP personalizadas que o programador original codificou no functions.php há três anos. Todo o ecossistema é uma torre de restrições de versão interdependentes.

Na prática, isto significa que as atualizações são adiadas. Um site que estava “totalmente atualizado” em janeiro estará a correr versões de plugins com 6 meses de idade em julho. Cada uma dessas versões desatualizadas é um vetor de ataque documentado e pesquisável.

O imposto de performance da renderização dinâmica

Para além da segurança, o WordPress impõe um custo fundamental de performance que frequentemente é invisível até se tornar num problema de negócio.

O WordPress é uma aplicação PHP que gera HTML dinamicamente em cada pedido. Quando um visitante carrega uma página, o WordPress executa código PHP, consulta uma base de dados MySQL, monta a página a partir do template do tema, aplica filtros e ações dos plugins, e serve o resultado. Para um simples artigo de blogue, este processo envolve 30 a 80 consultas à base de dados por carregamento de página.

A solução da indústria é caching agressivo (WP Super Cache, W3 Total Cache, LiteSpeed Cache). Mas o caching é um penso rápido sobre uma inadequação arquitetónica fundamental. A verdadeira questão é: porque é que esta página está a ser gerada dinamicamente?

Um artigo noticioso publicado às 9:00 da manhã não muda entre as 9:01 e as 9:02. É conteúdo estático disfarçado de conteúdo dinâmico. Cada consulta à base de dados, cada ciclo de execução PHP, cada camada de cache é desperdício computacional que impacta diretamente os Core Web Vitals, particularmente o Largest Contentful Paint (LCP) e o Time to First Byte (TTFB).

Para websites de alta performance que servem páginas pesadas em conteúdo, o fosso de performance entre uma página WordPress em cache (TTFB: 200-800ms) e uma página pré-renderizada estática servida a partir de um CDN edge (TTFB: 15-50ms) não é marginal. É uma ordem de magnitude.

A alternativa arquitetónica

A solução não é “um WordPress melhor.” A solução é reconhecer que, para a maioria dos websites orientados a conteúdo (blogues, sites de notícias, páginas de marketing, portais de documentação) o modelo de CMS server-rendered com base de dados é simplesmente a arquitetura errada.

Os geradores de sites estáticos modernos e as frameworks híbridas (Astro, Next.js, Hugo, 11ty) pré-renderizam o conteúdo em tempo de build. O resultado é HTML, CSS e JavaScript mínimo. Não há servidor. Não há base de dados. Não há execução de PHP. Os ficheiros HTML são implantados diretamente numa rede CDN edge.

---
// Componente Astro: busca conteúdo em tempo de BUILD, não em tempo de pedido
import { getCollection } from 'astro:content';

const artigos = await getCollection('articles');
const ordenados = artigos.sort((a, b) => 
  new Date(b.data.publishedAt) - new Date(a.data.publishedAt)
);
---

<html lang="pt">
  <body>
    <h1>Artigos Recentes</h1>
    {ordenados.map(artigo => (
      <article>
        <h2>{artigo.data.title}</h2>
        <time>{artigo.data.publishedAt}</time>
        <p>{artigo.data.excerpt}</p>
      </article>
    ))}
  </body>
</html>

A equipa editorial continua a ter um CMS. Mas em vez de WordPress, o CMS é headless, Directus, Sanity ou Strapi fornecem a interface editorial, enquanto o frontend é um site estático pré-renderizado que não pode ser hackeado via vulnerabilidades de plugins porque não há plugins, não há PHP e não há superfície de ataque server-side.

Quando o WordPress é realmente a escolha certa

O WordPress ainda tem o seu lugar legítimo. Para catálogos de e-commerce em rápida evolução com centenas de SKUs, sistemas de membros complexos com conteúdo restrito, ou organizações em que a equipa editorial tem profunda experiência em WordPress e nenhum suporte de engenharia, a natureza plug-and-play do ecossistema é genuinamente valiosa.

Mas para publicação de conteúdo, sites de marketing e presença institucional web (que representa a vasta maioria das instalações WordPress) a plataforma é uma responsabilidade. É mais lenta do que as alternativas. É menos segura do que as alternativas. E requer manutenção perpétua que as arquiteturas estáticas modernas simplesmente não exigem.

A monocultura dos CMS não é um problema do WordPress. É um problema de gestão de risco. Qualquer tecnologia que controla 43% de uma camada crítica da infraestrutura global merece ceticismo, não celebração.

Recursos da Indústria

Para leitura adicional e documentação técnica, consulte os seguintes recursos autorizados: web.dev guidelines, Moz insights, Google Search Central, Schema.org structured data.