Plugins desatualizados no WordPress, caso real com CVE

#Auditoria de segurança WordPress de uma pequena empresa

O desconfortável é o quão normal isto é. O site funcionava. Parecia bem. O dono não tinha motivo para suspeitar de nada, porque plugins desatualizados não dão sintomas até serem explorados. A auditoria existia para encontrar a falha antes de outra pessoa o fazer.

#Porque são perigosos os plugins WordPress desatualizados

Um plugin está seguro enquanto recebe correções. No momento em que uma vulnerabilidade é publicada como CVE e não atualizou, o exploit é conhecimento público e a versão instalada torna-se um alvo nomeado para scanners automáticos. Os ataques ao WordPress são esmagadoramente cegos e automáticos. Bots varrem a rede à procura de versões conhecidamente vulneráveis de plugins populares, por isso correr um Elementor ou Contact Form 7 antigo não é um risco abstrato. É um risco anunciado.

Neste site:

• Elementor 3.11.1 estava abaixo das correções de cinco CVE registadas no NVD: SQL injection (CVE-2023-0329, corrigida na 3.12.2), falta de autorização (CVE-2023-33922, corrigida na 3.13.3), cross-site scripting (CVE-2023-47505) e autenticação imprópria (CVE-2023-47504, a que o NVD classifica como crítica, 9,8), ambas a afetar versões até à 3.16.4, e um upload de ficheiros perigosos (CVE-2023-48777, corrigida na 3.18.2). Cada uma das cinco estava ativa em produção.
• Contact Form 7 5.8 estava exposto à CVE-2023-6449, uma falha de upload arbitrário de ficheiros no próprio plugin (versões até à 5.8.3, inclusive) que permitia a um utilizador autenticado com direitos de editor carregar ficheiros arbitrários. Sozinha raramente leva à execução de código, mas encadeada com uma segunda falha, como uma inclusão local de ficheiros, pode levar.

Nenhum dos plugins era invulgar. Ambos estão numa fatia enorme de sites WordPress. É exactamente por isso que as vulnerabilidades conhecidas deles valem o tempo de um scanner. O Patchstack, no relatório State of WordPress Security in 2026, mede a mediana de tempo desde a divulgação pública de uma vulnerabilidade de alto impacto até à exploração em massa em cinco horas. A janela entre «a CVE é pública» e «um bot já está a scanear a sua versão» conta-se em horas, não em semanas.

O mesmo relatório da Patchstack contabiliza 11.334 vulnerabilidades novas no ecossistema WordPress em 2025: 91 por cento em plugins, 9 por cento em temas e apenas 6 no núcleo do WordPress, todas de baixa prioridade. Uma auditoria que fica pela versão do núcleo verifica a parte mais pequena da superfície de ataque.

Plugins abandonados pioram o quadro. Quando o autor deixa de publicar correções, a CVE só se fecha por remoção ou troca de ferramenta. Deixar um plugin morto «por precaução» em wp-content/plugins/ mantém a superfície de ataque viva mesmo após desativação, se os ficheiros continuarem no disco e forem alcançáveis por caminhos conhecidos.

#Como priorizar CVE em plugins WordPress

O painel WordPress mostra atualizações por ordem alfabética ou por data. A triagem de segurança ordena de outra forma:

1. Gravidade e classe de ataque. Upload de ficheiros, execução remota de código e SQL injection vão à frente de XSS que exige um admin autenticado.
2. Privilégios necessários. Uma falha não autenticada, ou alcançável como subscritor/editor, tem prioridade sobre uma que exige um administrador de que tem um e protege com 2FA.
3. Se o caminho de código vulnerável está em uso. Uma CVE numa funcionalidade opcional só importa em sites onde essa funcionalidade é alcançável. A auditoria verifica se a função afetada é mesmo usada no site, não apenas se o plugin está instalado.
4. Se existe exploit público. Quando um proof of concept circula em threat intel, o tempo de resposta encolhe para horas. O Patchstack também regista que 46 por cento das vulnerabilidades não têm correção no momento da divulgação, por isso por vezes a única resposta imediata é desativar a funcionalidade ou o plugin, não «clicar em Atualizar».

No site deste caso, a triagem foi simples: primeiro Contact Form 7 (upload), depois Elementor (injection e XSS), depois limpeza dos restantes plugins sem CVE ativa. O número da CVE e a data de publicação não substituem essa ordem.

#Como ler a pontuação CVSS de uma CVE de plugin WordPress

As bases de dados de vulnerabilidades atribuem uma pontuação base CVSS a quase todas as CVE. A especificação CVSS v3.1 da FIRST converte o número numa classificação: 0,0 é None, de 0,1 a 3,9 Low, de 4,0 a 6,9 Medium, de 7,0 a 8,9 High e de 9,0 a 10,0 Critical. A pontuação é calculada a partir de métricas como Attack Vector, Attack Complexity, Privileges Required e User Interaction, e o vetor que aparece ao lado do número diz mais sobre o seu site do que o próprio número.

A CVE-2023-6449 mostra porquê. A entrada do NVD apresenta duas pontuações CVSS 3.1 para a mesma falha:

A única diferença é a Attack Complexity. A Wordfence classificou-a como High, o que na definição da FIRST significa que o sucesso depende de condições fora do controlo do atacante; o NVD classificou-a como Low. Essa métrica sozinha muda a classificação de Medium para High. Ambos concordam em PR:H, privilégios elevados, o nível que a FIRST descreve como controlo significativo, por exemplo direitos de administração. Para a triagem, é essa a parte útil: num site com uma única conta de editor protegida por autenticação de dois fatores, o risco prático é menor do que num site onde uma dúzia de acessos de editor é partilhada entre equipa interna, agência e freelancers.

A FIRST também recomenda a quem usa o CVSS que complemente a pontuação base com as pontuações temporal e ambiental. A especificação CVSS v4.0, publicada a 1 de novembro de 2023, refere que fornecedores como os responsáveis pelos produtos e o NVD costumam publicar apenas pontuações base, identificadas como CVSS-B. A parte ambiental, o grau de exposição da funcionalidade vulnerável no seu site concreto, continua a ser trabalho do auditor.

#Quem atribui o identificador CVE a uma vulnerabilidade de plugin WordPress

Os identificadores CVE são atribuídos pelas CVE Numbering Authorities (CNA): fabricantes, investigadores, CERT e outras organizações que o programa CVE autoriza a atribuir identificadores e a publicar registos CVE dentro do seu próprio âmbito. A Patchstack, a Wordfence e a WPScan constam dessa lista de parceiros como CNA. O registo da CVE-2023-6449 no cve.org indica a Wordfence como entidade atribuidora: o identificador foi reservado a 30 de novembro de 2023 e publicado a 1 de dezembro de 2023. O registo marca como afetadas as versões do Contact Form 7 até à 5.8.3, inclusive, e liga como correção a alteração de código entre a 5.8.3 e a 5.8.4. O NVD acrescenta depois a sua própria análise, e é daí que vem a segunda pontuação da tabela.

Numa auditoria, o fabricante, a CNA e o NVD publicam em momentos diferentes e podem pontuar de forma diferente. Um scanner mostrar Medium e outro High para a mesma versão de um plugin não é um conflito que se resolva escolhendo o número mais baixo. A auditoria regista o identificador CVE, o intervalo de versões afetadas segundo o registo e a primeira versão corrigida, e compara esse intervalo com a versão realmente instalada.

#Como atualizar plugins WordPress com staging

O salto do Elementor de 3.11.1 para a linha 3.18+ não é só um patch de segurança. Muda renderizadores, widgets e muitas vezes templates do tema filho. Um formulário de contacto com shortcode de upload antigo pode, após a atualização, devolver ecrã branco ou silenciar anexos. Por isso a correção após a auditoria foi assim:

• Cópia completa de ficheiros e base de dados para staging com o mesmo PHP e as mesmas constantes em wp-config.php (sem WP_DEBUG_DISPLAY de produção).
• Atualizar plugins com CVE na ordem da triagem, depois passagem manual: página inicial, carrinho ou formulário de lead, ecrã de edição do Elementor, envio do formulário com anexo.
• Comparar logs PHP e HTTP 500 antes de publicar em produção.
• Em produção, o mesmo par de versões de plugins, smoke test curto e só depois remover plugins desnecessários.

Atualizar diretamente no site em live sem cópia de segurança transforma a correção de CVE num segundo incidente: checkout morto ou hero partido. Staging não é luxo de agência. Faz parte do processo que o hardening oficial do WordPress descreve na camada de manutenção, não só na dos ficheiros.

#Como ativar as atualizações automáticas de plugins no WordPress

As atualizações automáticas de plugins fazem parte do núcleo desde o WordPress 5.5. O anúncio da equipa de core indica que as atualizações automáticas de plugins e temas estão desativadas por predefinição, por isso nada acontece até um administrador as ativar plugin a plugin no ecrã de plugins. O núcleo funciona ao contrário: segundo a documentação de atualização do WordPress, as instalações existentes recebem automaticamente, por predefinição, as versões menores do núcleo, que incluem as de manutenção e de segurança.

A mesma documentação enumera os interruptores que uma auditoria deve procurar no wp-config.php e no código:

• define( 'AUTOMATIC_UPDATER_DISABLED', true ); desativa todos os tipos de atualização automática, incluindo o núcleo. Num site sem rotina manual de atualizações, esta linha basta para explicar como os plugins ficam anos para trás.
• WP_AUTO_UPDATE_CORE com false desativa as atualizações do núcleo, com 'minor' mantém apenas as menores e com true permite também as maiores.
• add_filter( 'auto_update_plugin', '__return_true' ); força as atualizações automáticas de todos os plugins, e uma função no mesmo filtro pode limitá-las a uma lista de slugs.

Na linha de comandos, wp plugin auto-updates enable (WP-CLI 2.5.0 ou posterior) ativa-as para um plugin, ou para todos com --all.

As atualizações automáticas não substituem o percurso por staging descrito acima. Servem para plugins pequenos, de função única, cujas versões raramente mudam o que se vê no front-end. Page builders, plugins de formulários e tudo o que está ligado ao checkout seguem pelo staging, porque um salto de várias versões menores altera templates. A auditoria regista em que grupo fica cada plugin, para que a decisão seja tomada de propósito e não deixada às predefinições.

#Um WAF chega para proteger o WordPress

Um WAF (Cloudflare, Sucuri, regras de hosting) e o virtual patching compram tempo entre a divulgação da CVE e a aplicação da correção. A documentação da Sucuri Website Firewall descreve o bloqueio de padrões de pedido conhecidos, não a remoção de código vulnerável do disco. Essa distinção importa quando o dono do site ouviu «temos firewall, logo estamos seguros».

O relatório Patchstack State of WordPress Security in 2026 indica que conjuntos típicos de hosting mais WAF param cerca de 12 por cento dos ataques conhecidos ao WordPress. O resto contorna assinaturas, usa sessão autenticada, acerta num endpoint fora das regras ou ataca um plugin para o qual ainda não há regra. Um WAF não:

• remove um plugin abandonado de wp-content/plugins/,
• corrige a falta de nonce e current_user_can em código próprio,
• substitui o confronto de versões com a base de CVE,
• garante proteção quando o ataque passa por um editor autenticado (como na CVE-2023-6449).

O arranjo sensato é WAF como primeira linha mais rotina de atualização como linha duradoura. Só WAF sem triagem e staging deixa exactamente o estado que encontrámos: Elementor e formulário sem patch durante anos porque «o firewall deveria bastar».

#O que verifica uma auditoria de segurança WordPress

Uma auditoria de segurança é metódica, não esperta. O núcleo:

• Inventariar cada plugin e tema instalado e confrontar cada versão com as suas CVE conhecidas e a versão mínima segura. Foi isto que revelou a exposição do Elementor e do Contact Form 7 aqui.
• Fazer a triagem das CVE encontradas por gravidade, privilégios e se a funcionalidade está ativa em produção.
• Testar código próprio e do tema quanto aos fundamentos de segurança WordPress: verificação de nonce e permissões nas ações, entrada saneada antes da base de dados, saída escapada antes da página, endpoints que exigem autorização.
• Verificar exposição ao nível do servidor: xmlrpc.php aberto, erros PHP em produção a revelar caminhos, cabeçalhos de segurança em falta.
• Rever a política de atualização, staging e cópias de segurança, porque um site sem manutenção regressa a este estado em meses.
• Avaliar se o WAF vê de facto os caminhos de ataque das CVE encontradas, ou se só dá sensação de cobertura.

O confronto de versões é a parte pouco espectacular que apanha mais, porque a vulnerabilidade WordPress mais comum não é um zero-day engenhoso. É um plugin popular três versões atrás da correção.

#Como listar as versões dos plugins para uma auditoria WordPress com WP-CLI

O inventário de versões não precisa de um scanner pago para começar. Num servidor com WP-CLI, wp plugin list mostra o que está instalado, que versão está disponível e se as atualizações automáticas estão ativas:

wp plugin list --fields=name,status,version,update_version,auto_update --format=csv

Com --status=inactive a lista fica reduzida aos plugins desativados, os ficheiros que continuam no disco apesar de ninguém os usar. Para plugins do diretório WordPress.org, os campos opcionais wporg_status e wporg_last_updated mostram se o plugin continua listado e quando saiu a última versão, o sinal mais rápido de abandono:

wp plugin list --fields=name,version,wporg_status,wporg_last_updated

O CSV é a entrada do cruzamento com as CVE: cada par de nome e versão é comparado com os intervalos de versões afetadas da base de vulnerabilidades usada na auditoria. Um segundo comando, wp plugin verify-checksums --all, compara os ficheiros dos plugins com as somas de verificação publicadas pelo WordPress.org e deteta ficheiros alterados por um comprometimento anterior. Só consegue verificar plugins para os quais o WordPress.org tem somas, por isso os plugins comerciais distribuídos fora do diretório precisam de uma verificação à parte.

#Riscos de segurança em sites WordPress feitos com IA

Esta auditoria incidiu sobre plugins de terceiros desatualizados, um padrão de negligência. As implementações assistidas por IA acrescentam uma segunda camada. Instalam plugins depressa, muitas vezes sem rotina de atualização e staging, pelo que as versões ficam para trás das correções ainda mais depressa. O código próprio gerado por IA surge frequentemente sem as verificações de nonce, permissões e saneamento que o WordPress espera, pelo que herda de uma vez o problema de plugins desatualizados e o de código gerado.

#Como corrigir vulnerabilidades de plugins desatualizados

A ordem da correção segue o risco, não a comodidade:

• Corrigir ou remover de imediato plugins com CVE ativas, começando pelos caminhos de upload e injection, após teste em staging.
• Remover plugins abandonados ou já desnecessários, reduzindo a superfície de forma permanente (ficheiros fora do disco, não só desativação).
• Fechar exposição ao nível do servidor (xmlrpc.php, exibição de erros em produção, cabeçalhos em falta).
• Definir o WAF como buffer de tempo, não como substituto de atualizações.
• Implementar uma rotina real de atualização, staging e cópias de segurança para o site não voltar a cinco CVE ativas dentro de um ano.

Se precisa de passar de uma lista de CVE a um plano de correção num site em live, comece pela auditoria de segurança WordPress.

#Glossário

• CVE - identificador Common Vulnerabilities and Exposures, entrada pública de catálogo para uma vulnerabilidade conhecida específica.
• Triagem de CVE - ordenar falhas por gravidade, privilégios e exposição da funcionalidade, não pela ordem no ecrã de atualizações.
• SQL injection - ataque que introduz comandos de base de dados através de entrada não saneada.
• Stored cross-site scripting - script malicioso guardado no site e servido a outros utilizadores.
• WAF - firewall de aplicação web que filtra pedidos HTTP; reduz janelas de ataque, não remove código vulnerável.
• Verificação de nonce / permissões - mecanismos WordPress que confirmam que o pedido é intencional e que o utilizador tem direito a fazê-lo.
• CVSS - Common Vulnerability Scoring System, a norma da FIRST para pontuar a gravidade de uma vulnerabilidade de 0,0 a 10,0.
• CNA - CVE Numbering Authority, organização autorizada pelo programa CVE a atribuir identificadores CVE e a publicar registos CVE.

#Conclusão

Um site WordPress não precisa de ser interessante para ser atacado. Precisa de correr uma versão conhecida como vulnerável de um plugin popular, o que descreve uma grande fatia dos sites que não foram auditados. O risco dominante também é o mais aborrecido de corrigir: confronte cada versão de plugin com as suas CVE, faça triagem, corrija via staging, não confie só no WAF e remova o que já não usa. O site desta auditoria estava a um scan de distância de problemas e não sabia. A maior parte dos sites nessa situação também não sabe.