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 relatorio State of WordPress Security 2026 da GuardingWP, extraido da analise de 424 instalacoes 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 relatorio coloca 93,2 por cento sem cabecalhos de seguranca modernos, 55,9 por cento com a versao do WordPress a vazar pela meta tag generator e 35,8 por cento que ainda servem XML-RPC.

Os numeros nao sao 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 nao e uma firewall melhor, sao os controlos de cadeia de abastecimento ja inscritos no artigo 21 paragrafo 2 alinea d) da NIS2 e no artigo 28 do DORA, com aplicacao em Portugal pelo Centro Nacional de Ciberseguranca (CNCS) e supervisao 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, seguranca e resiliencia numa unica ficha de fornecedor.

#O essencial num paragrafo

• A GuardingWP 2026 analisou 424 instalacoes WordPress confirmadas em mais de 40 setores. Os quatro principais resultados sao detetaveis a partir de uma unica resposta HTTP por site.
• 53 por cento dos sites com pelo menos uma CVE de plugin sem patch. 93,2 por cento sem cabecalhos modernos. 55,9 por cento com fuga da versao. 35,8 por cento com XML-RPC aberto.
• A taxa de 53 por cento nao e desleixo do utilizador. E o resultado por defeito de uma economia de plugins com 20 a 40 fornecedores terceiros por instalacao, ciclos de patches desalinhados e o dono do site como integrador de ultima linha.
• O WordPress 7.0 acrescentou infraestrutura de IA e portanto chaves API a superficie de segredos do admin. Oliver Sild, da Patchstack, previu publicamente uma “absolute rush by hackers to steal API keys”.
• O artigo 21 paragrafo 2 alinea d) da NIS2 e o artigo 28 do DORA ja codificam a cura: politica documentada de tratamento de vulnerabilidades, cadencia de patches, avaliacao de fornecedores, registo de acordos contratuais com terceiros de TIC.
• A alavanca que faz mover uma organizacao WordPress de falha para passe em conformidade nao e um plugin. E um quadro de controlos.

#Os numeros, com fonte

As quatro metricas principais do relatorio GuardingWP 2026 sao observaveis a partir do exterior do site. Um scanner precisa apenas da resposta da pagina 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 evidencia externa, e a telemetria da Patchstack, a GreyNoise e o Internet Archive sao infraestruturas de medicao 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 é 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 cadencia de patches a um fornecedor gerido que de facto o faz. E isto que os bons alojamentos WordPress geridos e as agencias serias entregam, onde o contrato diz explicitamente “aplicamos patches de seguranca dentro de X horas apos o lancamento pelo fornecedor, primeiro em staging, depois em producao”. Se o contrato nao diz isto, a cadencia nao 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 publicacao do relatorio GuardingWP. A versao 7.0 acrescentou o AI Services Registry e a Abilities API, o que significa que a superficie 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 faturavel. Uma credencial de admin comprometida deixou de ser apenas um problema de integridade de conteudo. E tambem um problema de fuga de custos.

O fundador da Patchstack, Oliver Sild, escreveu publicamente no X no dia do lancamento: “there will be an absolute rush by hackers to steal API keys.”

Justin Nealey, a escrever no seu blogue, sinalizou a dor de cabeca pratica associada: o WP AI Client nao tem throttle integrado, e varios plugins a partilhar uma chave API conseguem rebentar o limite de tokens em menos de um minuto. Nao e um adversario hipotetico, e uma configuracao 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 nao no plugin, registo de auditoria que faz emergir consumo inesperado de tokens dentro de um ciclo de faturacao.

A superficie de controlo e bem compreendida. E a mesma que uma equipa financeira aplicaria a qualquer credencial faturavel recem-emitida. O WordPress so e invulgar porque historicamente nao tinha esta categoria de credencial no admin.

#Como a NIS2 le os dados GuardingWP

A Diretiva NIS2 (2022/2555), artigo 21, paragrafo 2, lista dez medidas tecnicas e organizativas que entidades essenciais e importantes tem de aplicar. A alinea d), nas palavras da propria diretiva, exige “seguranca da cadeia de abastecimento, incluindo aspetos relacionados com a seguranca que digam respeito as relacoes entre cada entidade e os seus fornecedores ou prestadores de servicos diretos”. Uma instalacao WordPress com CVE de plugin sem patch falha na alinea d) independentemente de o plugin ser individualmente critico, porque a entidade nao avaliou nem geriu o risco do fornecedor.

A cura sob a NIS2 e procedimental. Inclui:

• Uma politica documentada de tratamento e divulgacao de vulnerabilidades que a entidade efetivamente cumpre. Alinea b) do paragrafo 2.
• Uma cadencia de patches e atualizacoes com um tempo-alvo para aplicar correcoes classificadas como CVE. Alinea f) do paragrafo 2 em conjugacao com a alinea b).
• Uma avaliacao de fornecedores que cubra os autores dos plugins enquanto prestadores terceiros de TIC, incluindo a sua maturidade de seguranca, canal de divulgacao e latencia de patches. Alinea d) do paragrafo 2.
• Um registo de acordos com terceiros de TIC, que sob o DORA tem uma obrigacao explicita do artigo 28 para entidades financeiras.

Um site WordPress pode passar a leitura tecnica da NIS2 (ou seja, nao ter CVE de plugin sem patch no dia da auditoria) e ainda assim falhar na leitura procedimental se a entidade nao conseguir mostrar os documentos. A taxa de 53 por cento sugere que os documentos nao existem para metade dos sites no ambito.

Em Portugal a aplicacao deste enquadramento e feita pelo Centro Nacional de Ciberseguranca (CNCS), ponto de contacto unico para a NIS2 e CSIRT nacional, com obrigacao de notificacao de incidentes para operadores de servicos essenciais e entidades importantes. O lado RGPD continua sob fiscalizacao da CNPD, e o Banco de Portugal supervisiona o DORA. Um perfil de 53 por cento na carteira de plugins de uma entidade abrangida nao e so risco operacional, e risco regulatorio claro.

E esta a parte da conversa que a maior parte dos fornecedores de ferramentas de seguranca evita. Vender uma firewall e mais facil 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 aplicavel desde 17 de janeiro de 2025. Aplica-se a instituicoes de credito, instituicoes de pagamento, seguradoras, sociedades de investimento, prestadores de servicos de criptoativos e cerca de quinze outras categorias listadas no artigo 2. Para entidades portuguesas, a supervisao cabe ao Banco de Portugal.

O artigo 28 do DORA rege a gestao do risco de terceiros de TIC. Os autores dos plugins WordPress de um site publico de uma entidade financeira enquadram-se nessa definicao. Decorrem duas consequencias praticas do perfil GuardingWP.

Em primeiro lugar, a entidade tem de manter um registo de acordos contratuais com prestadores terceiros de TIC (artigo 28 paragrafo 3). Este registo tem de cobrir os editores dos plugins cujo codigo corre no site publico. Para a maior parte das entidades financeiras este registo nao inclui de todo os autores dos plugins WordPress. A cura nao e tecnica, e administrativa: extrair a lista de plugins ativos, mapear cada plugin ao seu editor, anexar o canal de tratamento de vulnerabilidades e a latencia de patches do editor, e acrescentar a entrada ao registo.

Em segundo lugar, o artigo 28 paragrafo 5 exige que os acordos contratuais com prestadores terceiros de TIC que apoiem funcoes criticas ou importantes incluam “estrategias de saida, em particular o estabelecimento de um periodo de transicao obrigatorio adequado”. Para um site WordPress que depende de um unico plugin especializado para um fluxo critico (entrega de documento assinado, adaptador KYC, montagem do PDF de relato regulatorio), a estrategia de saida tem de existir por escrito. Raramente existe.

Nao sao controlos glamorosos. Sao papelada. Sao tambem aquilo que uma auditoria DORA real parece.

#Onde o relatorio GuardingWP esta demasiado silencioso

Os numeros principais do relatorio estao bem fundamentados, mas o relatorio subestima uma coisa que o leitor pratico tem de ver com clareza: a taxa de 53 por cento concentra-se na longa cauda de instalacoes de pequenos negocios e e muito mais baixa em instalacoes com fornecedor gerido sob contrato que cubra explicitamente o patching de seguranca. Nao temos a segmentacao da GuardingWP, mas a nossa propria concentracao de sites WordPress sob contrato de manutencao apresenta taxa de CVE sem patch num digito em qualquer semana de auditoria.

A implicacao nao e que os alojamentos WordPress geridos e as agencias focadas em seguranca sejam perfeitos. E que o equilibrio de 53 por cento e uma media de mercado que mistura duas populacoes muito diferentes. Um comprador a ler o relatorio nao deve concluir “WordPress nao e seguro”. Deve concluir: “os sites WordPress sem quadro de controlos sao inseguros, e o tamanho da cauda nao gerida e metade do mercado”.

#O que muda se o WordPress 7.0 for levado a serio

O lancamento do WordPress 7.0 com infraestrutura de IA e uma funcao de forca util para a cauda nao gerida, porque a adicao de chaves API a superficie de admin torna o caso de fuga de custos visivel de forma que o XSS ou a exfiltracao de credenciais armazenadas nunca foram. Uma pessoa de financas que nao se moveu com “pode ter uma CVE sem patch” move-se com “a fatura do fornecedor de IA no mes passado ficou tres digitos acima do habitual e nao conseguimos justificar o trafego”.

A superficie de controlo que fecha o risco da chave de IA fecha tambem grande parte do resto dos resultados GuardingWP, porque os controlos sobrepoem-se:

• Cabecalhos de seguranca 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.
• Supressao 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 superficie 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 adicao ou remocao de plugin.
5. Para instalacoes 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 sao 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 relatorio GuardingWP 2026 e o documento individual mais util que a comunidade de seguranca WordPress publicou em cinco anos, porque reformula um debate que esta ha demasiado tempo preso em modo de comparacao de ferramentas. A leitura certa nao e “passe para a Patchstack” ou “instale o Wordfence”. E: metade do mercado nao opera um quadro de controlos, os controlos que fecham a lacuna estao codificados na NIS2 e no DORA, e o comprador na ponta recetora da regulacao da UE em 2026 e quem tem a alavanca para forcar os controlos para dentro do contrato de fornecedor.

Para quem le este texto a partir de uma agencia WordPress, este e o momento comercial mais forte em anos para vender o quadro, nao a ferramenta. O numero 53 por cento e o lead da proxima apresentacao a cliente.

#Fontes

• GuardingWP, State of WordPress Security 2026 (pagina do relatorio)
• Diretiva (UE) 2022/2555 relativa a seguranca das redes e sistemas de informacao (NIS2), artigo 21
• Regulamento (UE) 2022/2554 sobre resiliencia operacional digital do setor financeiro (DORA), artigo 28
• Patchstack
• ENISA: boas praticas para seguranca de sistemas expostos a internet
• Centro Nacional de Ciberseguranca (CNCS)
• Comissao Nacional de Protecao 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 seguranca WordPress
• DORA artigo 28 risco de terceiros de TIC: auditoria de fornecedores de alojamento e WAF WordPress

Atualizado em: 2026-05-23