53 por cento de sites WordPress com CVE sem patch: auditoria GuardingWP

#53 por cento dos sites WordPress correm com CVE sem patch: o que a auditoria GuardingWP 2026 realmente prova

Mais de metade. O primeiro relatório State of WordPress Security 2026 da GuardingWP, extraido da análise de 424 instalações WordPress confirmadas em mais de quarenta setores, diz que 53 por cento dos sites correm pelo menos um plugin que carrega uma CVE conhecida sem patch. O mesmo relatório coloca 93,2 por cento sem cabeçalhos de segurança modernos, 55,9 por cento com a versão do WordPress a vazar pela meta tag generator e 35,8 por cento que ainda servem XML-RPC.

Os números não são uma surpresa. A surpresa seria um resultado abaixo dos trinta por cento, porque a estrutura da economia de plugins do WordPress devolve esta taxa por defeito. Este artigo le os dados da GuardingWP como prova de que a cura não e uma firewall melhor, são os controlos de cadeia de abastecimento já inscritos no artigo 21 parágrafo 2 alinea d) da NIS2 e no artigo 28 do DORA, com aplicação em Portugal pelo Centro Nacional de Cibersegurança (CNCS) e supervisão financeira pelo Banco de Portugal.

Este texto fica ao lado dos nossos pilares sobre NIS2 e DORA em WordPress: a stack de conformidade 2026 e sobre cadeia de abastecimento de plugins WordPress, e complementa o trabalho sobre WCAG, BFSG e EAA, porque as equipas de compras agrupam hoje acessibilidade, segurança e resiliência numa única ficha de fornecedor.

#O essencial num parágrafo

• A GuardingWP 2026 analisou 424 instalações WordPress confirmadas em mais de 40 setores. Os quatro principais resultados são detetáveis a partir de uma única resposta HTTP por site.
• 53 por cento dos sites com pelo menos uma CVE de plugin sem patch. 93,2 por cento sem cabeçalhos modernos. 55,9 por cento com fuga da versão. 35,8 por cento com XML-RPC aberto.
• A taxa de 53 por cento não e desleixo do utilizador. E o resultado por defeito de uma economia de plugins com 20 a 40 fornecedores terceiros por instalação, ciclos de patches desalinhados e o dono do site como integrador de última linha.
• O WordPress 7.0 acrescentou infraestrutura de IA e portanto chaves API a superfície de segredos do admin. Oliver Sild, da Patchstack, previu publicamente uma “absolute rush by hackers to steal API keys”.
• O artigo 21 parágrafo 2 alinea d) da NIS2 e o artigo 28 do DORA já codificam a cura: política documentada de tratamento de vulnerabilidades, cadência de patches, avaliação de fornecedores, registo de acordos contratuais com terceiros de TIC.
• A alavanca que faz mover uma organização WordPress de falha para passe em conformidade não e um plugin. E um quadro de controlos.

#Os números, com fonte

As quatro métricas principais do relatório GuardingWP 2026 são observáveis a partir do exterior do site. Um scanner precisa apenas da resposta da página inicial e do estado HTTP de /xmlrpc.php para derivar cada uma delas. Isto importa porque os auditores de conformidade tendem cada vez mais a partir de evidência externa, e a telemetria da Patchstack, a GreyNoise e o Internet Archive são infraestruturas de medição permanentes.

Para o leitor regulado na UE, a base de referência para cada uma destas quatro métricas é diferente. CSP e HSTS estão mencionadas nas boas práticas da ENISA para segurança de sistemas expostos à internet. A exposição de XML-RPC é referida explicitamente nos OWASP Top 10. As CVE de plugins sem patch mapeiam-se diretamente para o artigo 21 da NIS2 sobre controlo da cadeia de abastecimento. O relatório GuardingWP não é uma lista de curiosidades. É uma medição de quatro lacunas de conformidade já codificadas.

#Porque é que 53 por cento é um número estrutural

Um site WordPress típico corre entre vinte e quarenta plugins. O WordPress.org publica mais de 60 000 plugins, com uma longa cauda de autores sem equipas de segurança financiadas. O ciclo de patches do plugin A e do plugin B não está coordenado. O dono do site é o integrador de última linha. Quando a CVE-2025-XYZW aterra no plugin A numa terça-feira, o dono do site e a única parte que pode decidir se aplica o patch, se testa contra o resto da stack e se o patch parte o plugin B.

A economia da situação não favorece o integrador. Aplicar patches a vinte plugins por mês exige teste de regressão e trabalho de engenharia. A maior parte dos sites WordPress não tem orçamento para esse trabalho. Por isso, a maior parte dos sites WordPress não recebe patches. A taxa de 53 por cento é o equilíbrio do mercado.

Há duas saídas deste equilíbrio, e só uma é duradoura.

A primeira via é encolher a stack de plugins. Um site WordPress com oito plugins, todos sob manutenção ativa, todos individualmente delimitados a uma função que o dono consegue descrever numa frase, é uma superfície de patches tratável. A disciplina custa mais inicialmente porque a equipa tem de construir a função em código próprio ou viver sem ela, mas o custo mensal de manter-se atualizado cai proporcionalmente.

A segunda via e externalizar a cadência de patches a um fornecedor gerido que de facto o faz. E isto que os bons alojamentos WordPress geridos e as agências serias entregam, onde o contrato diz explicitamente “aplicamos patches de segurança dentro de X horas após o lançamento pelo fornecedor, primeiro em staging, depois em produção”. Se o contrato não diz isto, a cadência não existe, e o site esta estatisticamente nos 53 por cento.

#O que o WordPress 7.0 mudou

O WordPress 7.0 “Armstrong” saiu na mesma semana de publicação do relatório GuardingWP. A versão 7.0 acrescentou o AI Services Registry e a Abilities API, o que significa que a superfície de admin guarda agora chaves API para fornecedores de modelos alojados (Anthropic, OpenAI), gateways de IA (Vercel) e endpoints auto-alojados. Estas chaves tem um lado faturável. Uma credencial de admin comprometida deixou de ser apenas um problema de integridade de conteúdo. E também um problema de fuga de custos.

O fundador da Patchstack, Oliver Sild, escreveu publicamente no X no día do lançamento: “there will be an absolute rush by hackers to steal API keys.”

Justin Nealey, a escrever no seu blogue, sinalizou a dor de cabeca prática associada: o WP AI Client não tem throttle integrado, e vários plugins a partilhar uma chave API conseguem rebentar o limite de tokens em menos de um minuto. Não e um adversario hipotetico, e uma configuração mal feita por boa fe. As duas formas de fuga de custos implicam o mesmo controlo: scoping de chaves por conector, limites de taxa no gateway e não no plugin, registo de auditoria que faz emergir consumo inesperado de tokens dentro de um ciclo de faturação.

A superfície de controlo e bem compreendida. E a mesma que uma equipa financeira aplicaria a qualquer credencial faturável recem-emitida. O WordPress so e invulgar porque historicamente não tinha esta categoria de credencial no admin.

#Como a NIS2 le os dados GuardingWP

A Diretiva NIS2 (2022/2555), artigo 21, parágrafo 2, lista dez medidas técnicas e organizativas que entidades essenciais e importantes tem de aplicar. A alinea d), nas palavras da própria diretiva, exige “segurança da cadeia de abastecimento, incluindo aspetos relacionados com a segurança que digam respeito as relações entre cada entidade e os seus fornecedores ou prestadores de serviços diretos”. Uma instalação WordPress com CVE de plugin sem patch falha na alinea d) independentemente de o plugin ser individualmente crítico, porque a entidade não avaliou nem geriu o risco do fornecedor.

A cura sob a NIS2 e procedimental. Inclui:

• Uma política documentada de tratamento e divulgação de vulnerabilidades que a entidade efetivamente cumpre. Alinea b) do parágrafo 2.
• Uma cadência de patches e atualizações com um tempo-alvo para aplicar correções classificadas como CVE. Alinea f) do parágrafo 2 em conjugação com a alinea b).
• Uma avaliação de fornecedores que cubra os autores dos plugins enquanto prestadores terceiros de TIC, incluindo a sua maturidade de segurança, canal de divulgação e latência de patches. Alinea d) do parágrafo 2.
• Um registo de acordos com terceiros de TIC, que sob o DORA tem uma obrigação explicita do artigo 28 para entidades financeiras.

Um site WordPress pode passar a leitura técnica da NIS2 (ou seja, não ter CVE de plugin sem patch no día da auditoria) e ainda assim falhar na leitura procedimental se a entidade não conseguir mostrar os documentos. A taxa de 53 por cento sugere que os documentos não existem para metade dos sites no âmbito.

Em Portugal a aplicação deste enquadramento e feita pelo Centro Nacional de Cibersegurança (CNCS), ponto de contacto único para a NIS2 e CSIRT nacional, com obrigação de notificação de incidentes para operadores de serviços essenciais e entidades importantes. O lado RGPD continua sob fiscalização da CNPD, e o Banco de Portugal supervisiona o DORA. Um perfil de 53 por cento na carteira de plugins de uma entidade abrangida não e so risco operacional, e risco regulatorio claro.

E esta a parte da conversa que a maior parte dos fornecedores de ferramentas de segurança evita. Vender uma firewall e mais fácil do que vender um quadro de controlos. O quadro de controlos e o que a NIS2 efetivamente exige.

#Como o DORA le os dados GuardingWP para entidades financeiras

O Regulamento DORA (2022/2554) e diretamente aplicável desde 17 de janeiro de 2025. Aplica-se a instituições de credito, instituições de pagamento, seguradoras, sociedades de investimento, prestadores de serviços de criptoativos e cerca de quinze outras categorias listadas no artigo 2. Para entidades portuguesas, a supervisão cabe ao Banco de Portugal.

O artigo 28 do DORA rege a gestão do risco de terceiros de TIC. Os autores dos plugins WordPress de um site público de uma entidade financeira enquadram-se nessa definição. Decorrem duas consequências práticas do perfil GuardingWP.

Em primeiro lugar, a entidade tem de manter um registo de acordos contratuais com prestadores terceiros de TIC (artigo 28 parágrafo 3). Este registo tem de cobrir os editores dos plugins cujo código corre no site público. Para a maior parte das entidades financeiras este registo não inclui de todo os autores dos plugins WordPress. A cura não e técnica, e administrativa: extrair a lista de plugins ativos, mapear cada plugin ao seu editor, anexar o canal de tratamento de vulnerabilidades e a latência de patches do editor, e acrescentar a entrada ao registo.

Em segundo lugar, o artigo 28 parágrafo 5 exige que os acordos contratuais com prestadores terceiros de TIC que apoiem funções críticas ou importantes incluam “estratégias de saída, em particular o estabelecimento de um período de transição obrigatório adequado”. Para um site WordPress que depende de um único plugin especializado para um fluxo crítico (entrega de documento assinado, adaptador KYC, montagem do PDF de relato regulatorio), a estratégia de saída tem de existir por escrito. Raramente existe.

Não são controlos glamorosos. São papelada. São também aquilo que uma auditoria DORA real parece.

#Onde o relatório GuardingWP esta demasiado silencioso

Os números principais do relatório estão bem fundamentados, mas o relatório subestima uma coisa que o leitor prático tem de ver com clareza: a taxa de 53 por cento concentra-se na longa cauda de instalações de pequenos negócios e e muito mais baixa em instalações com fornecedor gerido sob contrato que cubra explicitamente o patching de segurança. Não temos a segmentação da GuardingWP, mas a nossa própria concentração de sites WordPress sob contrato de manutenção apresenta taxa de CVE sem patch num digito em qualquer semana de auditoria.

A implicação não e que os alojamentos WordPress geridos e as agências focadas em segurança sejam perfeitos. E que o equilibrio de 53 por cento e uma media de mercado que mistura duas populações muito diferentes. Um comprador a ler o relatório não deve concluir “WordPress não e seguro”. Deve concluir: “os sites WordPress sem quadro de controlos são inseguros, e o tamanho da cauda não gerida e metade do mercado”.

#O que muda se o WordPress 7.0 for levado a sério

O lançamento do WordPress 7.0 com infraestrutura de IA e uma função de força útil para a cauda não gerida, porque a adição de chaves API a superfície de admin torna o caso de fuga de custos visível de forma que o XSS ou a exfiltração de credenciais armazenadas nunca foram. Uma pessoa de finanças que não se moveu com “pode ter uma CVE sem patch” move-se com “a fatura do fornecedor de IA no mes passado ficou três digitos acima do habitual e não conseguimos justificar o tráfego”.

A superfície de controlo que fecha o risco da chave de IA fecha também grande parte do resto dos resultados GuardingWP, porque os controlos sobrepoem-se:

• Cabeçalhos de segurança modernos (CSP, HSTS, X-Content-Type, Referrer-Policy) na edge. Um Cloudflare Worker ou um bloco .htaccess. Fecha a lacuna de 93,2 por cento.
• Supressão da meta tag generator. Um filtro. Fecha a lacuna de 55,9 por cento.
• XML-RPC desativado ou com limite de taxa na edge. Uma regra de firewall ou uma linha de .htaccess. Fecha a lacuna de 35,8 por cento.
• Scoping de chaves API, limite de taxa por conector, alerta de anomalia no consumo de tokens. Nova superfície de controlo. Fecha o risco do 7.0 antes de ele ter escala.

Não são tarefas heróicas de engenharia. São itens de uma proposta de serviços geridos.

#Uma leitura de quem trabalha no terreno

Faço auditorias de segurança a sites WordPress sob jurisdições da UE há quinze anos. O padrão da semana em 2026 é o mesmo de 2018: o site chega com vinte e oito plugins, o dono não consegue listar o que oito deles fazem, e o esforço de teste de regressão para aplicar patches a tudo num ciclo excede o orçamento. A taxa GuardingWP é uma descrição fiel deste padrão. A cura que efetivamente funciona num horizonte de um ano é aquela de que ninguém gosta:

1. Audite a lista de plugins. Remova todos os plugins cuja função o dono não consiga descrever numa frase.
2. Substitua os dois ou três plugins que sobreviverem mas tenham canais de manutenção estagnados.
3. Estabeleça uma cadência documentada de patches e uma política de tratamento de vulnerabilidades. Escreva-a. Refira-a pelo nome no contrato de manutenção.
4. Acrescente um registo de acordos com terceiros de TIC que reflita a lista ativa de plugins e seja atualizado a cada adição ou remoção de plugin.
5. Para instalações em WordPress 7.0, delimite cada chave de fornecedor de IA por conector, aplique limites de taxa no gateway e alerte sobre anomalias no consumo de tokens.

Os primeiros quatro pontos são trabalho de conformidade sob o artigo 21 da NIS2. O quinto e a nova classe de controlos introduzida pelo 7.0. Nenhum dos cinco se compra como produto a um fornecedor. E a forma como o profissional de WordPress aparece para o trabalho.

#Argumento final

O relatório GuardingWP 2026 e o documento individual mais útil que a comunidade de segurança WordPress publicou em cinco anos, porque reformula um debate que esta ha demasiado tempo preso em modo de comparação de ferramentas. A leitura certa não e “passe para a Patchstack” ou “instale o Wordfence”. E: metade do mercado não opera um quadro de controlos, os controlos que fecham a lacuna estão codificados na NIS2 e no DORA, e o comprador na ponta recetora da regulação da UE em 2026 e quem tem a alavanca para forçar os controlos para dentro do contrato de fornecedor.

Para quem le este texto a partir de uma agência WordPress, este e o momento comercial mais forte em anos para vender o quadro, não a ferramenta. O número 53 por cento e o lead da próxima apresentação a cliente.

#Fontes

• GuardingWP, State of WordPress Security 2026 (página do relatório)
• Diretiva (UE) 2022/2555 relativa a segurança das redes e sistemas de informação (NIS2), artigo 21
• Regulamento (UE) 2022/2554 sobre resiliência operacional digital do setor financeiro (DORA), artigo 28
• Patchstack
• ENISA: boas práticas para segurança de sistemas expostos a internet
• Centro Nacional de Cibersegurança (CNCS)
• Comissão Nacional de Proteção de Dados (CNPD)
• Banco de Portugal
• OWASP Top 10 2021

#Textos relacionados

• Pilar: NIS2 e DORA em WordPress: a stack de conformidade 2026
• Cadeia de abastecimento de plugins WordPress 2026: quatro backdoors num mes
• WCAG 2.2, BFSG e Ato Europeu de Acessibilidade: a stack de conformidade 2026 para WordPress
• Auditoria de segurança WordPress
• DORA artigo 28 risco de terceiros de TIC: auditoria de fornecedores de alojamento e WAF WordPress

Atualizado em: 2026-05-23