Nome do plugin	Bem feito
Tipo de vulnerabilidade	Inclusão de Arquivo Local
Número CVE	CVE-2026-28118
Urgência	Alto
Data de publicação do CVE	2026-02-28
URL de origem	CVE-2026-28118

Urgente: Inclusão de Arquivo Local no Tema Welldone (<= 2.4) — O que os Proprietários de Sites WordPress Devem Fazer Agora

Uma vulnerabilidade de Inclusão de Arquivo Local (LFI) de alta severidade foi divulgada, afetando o tema WordPress Welldone (versões <= 2.4). Rastreada como CVE-2026-28118 e atribuída uma pontuação base CVSS de 8.1, essa fraqueza permite que atacantes não autenticados incluam arquivos locais em um site vulnerável e exponham seu conteúdo ao atacante. Como as informações armazenadas em arquivos locais (credenciais de banco de dados, chaves de API, detalhes de configuração) podem levar a uma comprometimento total, uma mitigação imediata é necessária para qualquer site que esteja executando o tema afetado.

Estou escrevendo como parte da equipe de segurança WP‑Firewall com orientações práticas e diretas: por que isso é perigoso, como funciona em um nível técnico, como detectar tentativas de exploração e uma lista de verificação priorizada de ações imediatas e de médio prazo que você pode tomar para proteger seu site WordPress. Se você administra vários sites ou clientes de hospedagem gerenciada, compartilhe este post com suas equipes — os passos abaixo foram triados por urgência e facilidade de implementação.

Resumo da divulgação

• Software afetado: Tema WordPress Welldone
• Versões vulneráveis: <= 2.4
• Tipo de vulnerabilidade: Inclusão de Arquivo Local (LFI)
• CVE: CVE-2026-28118
• CVSS: 8.1 (Alto)
• Privilégio necessário: Nenhum (não autenticado)
• Impacto: Leitura arbitrária de arquivos locais; possível divulgação de credenciais e arquivos sensíveis; pode levar a uma tomada total dependendo da configuração do servidor
• Reportado por: Tran Nguyen Bao Khanh (reportado em 19 de agosto de 2025; divulgação pública em 26 de fevereiro de 2026)

Por que LFI é tão perigoso para sites WordPress

A Inclusão de Arquivo Local ocorre quando um aplicativo constrói um caminho para um arquivo local usando entrada fornecida pelo usuário, sem validação ou sanitização adequadas, e então inclui ou lê esse caminho. Em PHP, funções como include(), require(), include_once(), e require_once() são lugares comuns onde tais bugs aparecem — particularmente em temas e plugins que carregam partes de template ou arquivos externos com base em parâmetros de URL.

Para sites WordPress, as consequências são particularmente severas:

• wp-config.php frequentemente inclui credenciais de banco de dados e sais; lê-las pode dar ao atacante acesso total ao banco de dados.
• Outros arquivos podem conter chaves de API, credenciais SMTP ou dados proprietários.
• Se wrappers PHP (por exemplo, php://filter) ou locais de upload forem acessíveis, um atacante pode escalar de leitura de arquivos para execução de código (por exemplo, localizando e puxando um upload gravável que será usado posteriormente para armazenar um backdoor).
• Como a falha é acessível sem autenticação, tentativas de varredura automatizada em massa e exploração são prováveis — e esperamos que atacantes oportunistas visem rapidamente instalações expostas.

Como os atacantes normalmente exploram LFI (nível alto)

Um atacante descobre um parâmetro que é usado em uma chamada de inclusão de arquivo (por exemplo, algo como include( $template_path . $_GET['page'] . '.php' ); ). Se esse parâmetro não for validado, o atacante pode enviar solicitações que referenciam outros arquivos locais via travessia de diretório (../../../../wp-config.php) ou via wrappers de stream PHP (php://filter, data://). Mesmo quando a inclusão direta é bloqueada, muitas cadeias de LFI podem ser transformadas em execução remota de código (RCE) expondo primeiro arquivos, logs ou incluindo outros recursos acessíveis.

Não compartilharemos cargas úteis de exploração funcionais aqui, mas é importante que os defensores reconheçam os padrões e indicadores descritos na seção de detecção abaixo.

Indicadores de ataque e comprometimento — o que procurar

Monitore seus logs (logs de acesso do servidor web, logs de erro do PHP, logs do WordPress) em busca desses sinais:

1. Solicitações contendo padrões de travessia de diretório em strings de consulta:
   • Não codificados ou codificados "../" sequências (por exemplo, ..%2F, %2e%2e%2f)
   • Tentativas de travessia repetidas como ../../../../
2. Solicitações referenciando nomes de arquivos sensíveis:
   • wp-config.php, wp-config.php.bak, .env, /etc/passwd, .htpasswd, etc.
3. Solicitações usando nomes de parâmetros LFI comuns:
   • Parâmetros de consulta nomeados arquivo, página, modelo, inc, caminho, módulo, ou outros
   • Explosões repentinas de solicitações para endpoint(s) de tema com cargas úteis de travessia variadas
4. Uso de padrões de wrapper de stream PHP:
   • php://filter, expect://, data:// aparecendo em parâmetros de consulta
5. Entradas de log anormais ou novos arquivos PHP/JS em wp-content/uploads, wp-content/temas/ /, ou outros diretórios graváveis:
   • Arquivos com nomes suspeitos
   • Modelos ou arquivos de plugin recentemente modificados que você não alterou
6. Consultas de banco de dados incomuns e repentinas, criação inesperada de usuários administradores ou alterações em arquivos principais de tema/plugin.

Se você encontrar algum dos itens acima, trate-os como alta prioridade e siga os passos de incidente abaixo.

Mitigação imediata (horas) — ações triadas e práticas

Se você tiver uma das versões afetadas ou não tiver certeza, aplique uma ou mais dessas mitig ações imediatas. Elas estão ordenadas por velocidade e impacto:

1. Desative temporariamente o tema vulnerável:
   • Mude para um tema padrão (por exemplo, um tema padrão limpo e mantido). Esta é a maneira mais rápida de remover a superfície de ataque se você puder suportar uma breve mudança visual.
   • Se isso não for possível, coloque o site em modo de manutenção enquanto aplica outras mitig ações.
2. Remova ou coloque o tema vulnerável em quarentena do sistema de arquivos:
   • Se você tiver acesso ao servidor (SFTP/SSH), renomeie ou remova o diretório do tema vulnerável de wp-content/themes/. Isso impede que o código do tema seja executado.
   • Importante: Mantenha uma cópia (fora do servidor) para análise se você estiver investigando.
3. Bloqueie solicitações suspeitas no servidor web ou firewall de aplicação web:
   • Bloqueie solicitações com sequências de travessia de diretório e tentativas de acessar arquivos principais:
   • Exemplo (nginx, simplificado): negue solicitações com codificado .. sequências ou php://:

   if ($request_uri ~* "(%2e|%2f|\.\./|\.\.\\)") {
       return 403;
   }
   if ($request_uri ~* "php://|data://|expect://|file://") {
       return 403;
   }
   

   • Observação: Use testes cautelosos antes de aplicar regras em todo o servidor para evitar quebrar URLs legítimas; teste em um site de staging quando possível.
   • Exemplo (Apache .htaccess) — negue o acesso direto ao wp-config e bloqueie strings de consulta com padrões suspeitos:

   <Files "wp-config.php">
     Order allow,deny
     Deny from all
   </Files>
   
   # Block attempts to access common sensitive files
   <IfModule mod_rewrite.c>
     RewriteEngine On
     # Block requests containing ../ or php:// or data:// (basic)
     RewriteCond %{QUERY_STRING} (\.\.|php://|data://) [NC,OR]
     RewriteCond %{REQUEST_URI} (\.\.|php://|data://) [NC]
     RewriteRule ^.* - [F,L]
   </IfModule>
   

4. Reforce permissões de arquivos e propriedade (verificações rápidas):
   • Garantir wp-config.php não é legível por todos. Permissões recomendadas:
     • wp-config.php → 400 ou 440 dependendo da configuração do servidor
     • Diretórios → 755
     • Arquivos → 644 (exceto arquivos de configuração sensíveis que devem ser mais restritivos)
   • Certifique-se de que os arquivos sejam de propriedade do usuário correto (o usuário do servidor web não deve ser o proprietário dos arquivos se seu host suportar uma separação mais segura).
5. Desative wrappers e funções PHP perigosos sempre que possível:
   • Em php.ini, certifique-se allow_url_fopen = Desligado e allow_url_include = Desligado. Isso reduz o risco de inclusão remota de arquivos ou abuso de wrappers de stream.
   • Considere desativar funções arriscadas (somente se sua aplicação não precisar delas): exec, shell_exec, sistema, passthru, proc_open, popen. Exemplo:

   disable_functions = exec,shell_exec,system,passthru,proc_open,popen
   

6. Bloquear parâmetros fornecidos pelo usuário usados para carregamentos de arquivos:
   • Se você identificar endpoints de tema específicos que aceitam arquivo ou modelo parâmetros, adicione regras rápidas de bloqueio do lado do servidor para solicitações que incluam esses nomes de parâmetros até que o tema seja corrigido.
7. Ative um WAF/patch virtual
   • Se você executar um firewall de aplicativo web gerenciado (WAF) ou um plugin de segurança que pode implantar patches virtuais, ative ou adicione regras que:
     • Detectem sequências de travessia de diretório
     • Detectar php:// e data:// invólucros
     • Bloquear solicitações que tentam acessar wp-config.php ou outros arquivos sensíveis
   • O patch virtual previne a exploração mesmo que o código subjacente permaneça vulnerável, comprando tempo até que um patch oficial esteja disponível.

Remediação e verificação de médio prazo (dias)

1. Substitua ou atualize o tema
   • Verifique se há um patch oficial ou uma nova versão do tema que aborde o CVE-2026-28118. Se um lançamento com patch oficial se tornar disponível, teste-o minuciosamente em staging e depois atualize a produção.
   • Se não existir um patch oficial, considere substituir o tema por uma alternativa mantida ou um filho codificado sob medida de um tema base mantido.
2. Audite seu sistema de arquivos em busca de webshells e arquivos suspeitos
   • Digitalizar wp-content/uploads, diretórios de temas e diretórios de plugins por:
     • Arquivos com PHP executável onde não deveria haver
     • Arquivos com timestamps recentemente alterados que você não reconhece
     • Indicadores conhecidos de seus sistemas de detecção de intrusões
3. Rotacionar credenciais e segredos
   • Altere todas as senhas de administrador do WordPress, senhas de banco de dados, chaves de API e quaisquer outras credenciais que possam estar armazenadas no servidor ou expostas.
   • Se você restaurar de um backup, gire as credenciais depois.
4. Revise os logs do servidor e da aplicação
   • Olhe para os logs do período antes e depois da data de divulgação em busca de atividade suspeita indicando uma exploração bem-sucedida (por exemplo, códigos de resposta que incluem saída de arquivos sensíveis ou tentativas de exploração repetidas).
   • Exporte logs relevantes para um local seguro para qualquer trabalho forense necessário.
5. Verificação completa de malware no site e verificação de integridade
   • Execute uma verificação completa de malware; muitos scanners detectarão webshells, backdoors e arquivos principais modificados.
   • Use ferramentas de integridade de arquivos para comparar sua base de código com fontes conhecidas como boas.
6. Restaure a partir de backups limpos se o comprometimento for confirmado
   • Se você encontrar evidências de comprometimento que não pode limpar completamente, restaure a partir de um backup feito antes dos primeiros sinais de comprometimento. Certifique-se de realizar as outras etapas de remediação (permissões rígidas, rotação de credenciais) após a restauração.

Prevenção e endurecimento a longo prazo (semanas / contínuo)

1. Princípio do menor privilégio
   • Certifique-se de que os usuários de arquivos e bancos de dados tenham apenas as permissões de que precisam.
   • Evite executar processos de servidor web como o mesmo usuário que pode modificar arquivos.
2. Isolar ambientes
   • Mantenha os ambientes de teste e produção isolados.
   • Use credenciais diferentes para ambientes diferentes.
3. Monitoramento e alerta contínuos
   • Centralize logs (acesso, erro, PHP) e adicione alertas para:
     • Tentativas de travessia de diretório
     • Solicitações referenciando wp-config.php e outros arquivos sensíveis
     • Picos incomuns em respostas 4xx/5xx
4. Escaneamento regular de vulnerabilidades
   • Realize varreduras automatizadas e revisões manuais programadas regularmente do código de temas e plugins.
   • Inscreva-se em feeds de inteligência de vulnerabilidades e configure seus procedimentos de gerenciamento de patches para serem responsivos.
5. Backups regulares e restaurações testadas
   • Mantenha backups versionados fora do site e teste procedimentos de restauração regularmente.
6. Endurecimento do WordPress em si
   • Mantenha o núcleo do WordPress, plugins e temas atualizados.
   • Remova plugins e temas não utilizados.
   • Desative ou proteja editores de temas e plugins.
   • Implemente cabeçalhos de segurança e HTTPS em todos os lugares.

Regras sugeridas de detecção e prevenção de WAF (conceitual)

Abaixo estão padrões defensivos que você pode adaptar ao seu WAF ou conjunto de regras do servidor. Estas são assinaturas regex conceituais e devem ser testadas antes da implantação para evitar falsos positivos.

• Bloquear solicitações com tentativas de travessia de diretório (básico):
  • Regex: (\.\./|\.\.\\|%2e%2e%2f|%2e%2e%5c)
• Bloquear wrappers php://, data://, expect://:
  • Regex: (php://|data://|expect://|zip://|phar://)
• Bloquear tentativas de referência a arquivos sensíveis em strings de consulta:
  • Regex: (wp-config\.php|/etc/passwd|/proc/self/environ|\.env|\.htpasswd)
• Bloquear longas sequências de caracteres codificados indicando ofuscação:
  • Regex: (%[0-9A-Fa-f]{2}){6,}

Exemplo de pseudo-regra (agnóstico a WAF):

• Se uma string de consulta de solicitação corresponder a qualquer um de:
  • (\.\./|\.\.\\|%2e%2e%2f|%2e%2e%5c) OU
  • (php://|data://|expect://) OU
  • (wp-config\.php|/etc/passwd|\.env)

  → então bloquear a solicitação (HTTP 403) e registrar detalhes para revisão.

Notas sobre falsos positivos: Muitos CMSs e bibliotecas legítimas podem incluir tokens que se assemelham a padrões arriscados. Teste cuidadosamente qualquer padrão, limite as regras a pontos finais prováveis (arquivos de tema, pontos finais de inclusão) e gradualmente aperte a cobertura.

Se o seu site foi comprometido — lista de verificação de resposta a incidentes

Se você confirmar um comprometimento, siga estas etapas imediatamente:

1. Coloque o site offline (modo de manutenção) ou isole o host.
2. Faça uma captura completa do site e dos logs para análise forense.
3. Altere todas as senhas (usuários administrativos, banco de dados, FTP/SFTP, painel de controle).
4. Rode todas as chaves e tokens que podem ter sido armazenados no servidor.
5. Digitalize e remova arquivos maliciosos e webshells. Se você não estiver confiante na limpeza manual, restaure a partir de um backup limpo.
6. Verifique a integridade do banco de dados e remova usuários admin não autorizados ou injeções de conteúdo.
7. Realize uma auditoria completa para identificar como o atacante obteve acesso e qual movimento lateral pode ter executado.
8. Reconstrua o ambiente a partir de fontes conhecidas e boas, se necessário; não confie apenas em “limpar” se as portas traseiras forem complexas.

Como o WP‑Firewall ajuda (o que um WAF gerenciado faz por você)

Do ponto de vista de um serviço de segurança WordPress gerenciado, endurecemos e protegemos sites combinando várias camadas:

• Patch virtual (regras WAF): Quando uma vulnerabilidade como este LFI aparece, podemos implantar regras direcionadas que detectam e bloqueiam padrões de exploração em seus sites até que um patch do fornecedor esteja disponível.
• Firewall gerenciado e inspeção de requisições: Análise em tempo real dos parâmetros de requisição para bloquear sequências de travessia, uso de wrappers PHP e outras assinaturas de exploração.
• Digitalização de malware e limpeza automatizada: Digitalizações contínuas para encontrar arquivos maliciosos e remoção automatizada para muitos webshells e portas traseiras conhecidas.
• Mitigação do OWASP Top 10: Proteções sistêmicas projetadas para reduzir riscos das classes de ameaças mais comuns (Injeção, Autenticação Quebrada, LFI/RFI, etc.).
• Monitoramento, alertas e relatórios: Monitoramos anomalias de tráfego e emitimos alertas oportunos se detectarmos tentativas de exploração ou evidências de comprometimento.

Recomendamos uma estratégia em camadas: combine patch virtual e proteção WAF com configuração segura, atualizações rápidas e monitoramento. O patch virtual oferece proteção imediata enquanto você realiza os testes cuidadosos necessários para atualizações oficiais ou substituições de tema.

Uma breve nota técnica para desenvolvedores e administradores de sistema

Esta classe de vulnerabilidade quase sempre se origina da concatenação insegura de entradas do usuário em caminhos de sistema de arquivos. Sua lista de verificação para arquivos seguros inclui:

• Nunca use diretamente a entrada do usuário para construir nomes de arquivos sem listar valores permitidos.
• Use mapeamentos seguros (por exemplo, mapeie chaves curtas e conhecidas para nomes de arquivos permitidos) em vez de aceitar entrada de caminho completo.
• Normalize e valide qualquer caminho antes de passar para include/require.
• Se o conteúdo do usuário determinar a seleção de template, restrinja as escolhas a um conjunto confiável que exista em seu código.

Exemplo de abordagem mais segura (pseudo-código):

<?php;

Este padrão mapeia a entrada do usuário para uma lista controlada e impede a inclusão arbitrária de arquivos.

Novo recurso para proprietários de sites: Comece com proteção imediata e gratuita

Proteja seu site agora com nosso plano Básico Gratuito — firewall gerenciado, WAF, verificação de malware e cobertura para os riscos do OWASP Top 10. Foi projetado para proteger sites imediatamente enquanto você planeja quaisquer atualizações necessárias ou substituições de tema.

Proteja seu site agora mesmo — Comece com WP‑Firewall Básico (Gratuito)

• O que você recebe instantaneamente:
  • Firewall gerenciado e WAF com capacidade de patch virtual
  • Largura de banda ilimitada para tráfego de segurança
  • Verificação de malware para encontrar arquivos e alterações suspeitas
  • Proteções contra ameaças do OWASP Top 10 (incluindo padrões LFI)
• Por que isso ajuda:
  • Você recebe bloqueio imediato de padrões de exploração conhecidos para vulnerabilidades recém-divulgadas
  • O patch virtual reduz a janela de ataque enquanto você testa atualizações oficiais ou migra
• Comece: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Também oferecemos níveis pagos se você precisar de remoção automatizada de malware, controles de bloqueio de IP, relatórios mensais ou serviços de segurança gerenciados.)

Exemplos práticos — regras rápidas que você pode colar e testar (resumo)

• Proteja wp-config.php (coloque em .htaccess):

<files wp-config.php>
  order allow,deny
  deny from all
</files>

• Regra Nginx para bloquear tentativas com wrapper php:

if ($query_string ~* "php://|data://|%2e%2e|(\.\./)") {
  return 403;
}

• Dureza do PHP ini:

allow_url_fopen = Off

Importante: teste essas regras em staging para garantir que não bloqueiem tráfego legítimo para o comportamento específico do seu tema ou plugin.

Recomendações finais — o que fazer nas próximas 24–72 horas

1. Inventário: Identifique quaisquer sites executando o tema Welldone ≤ 2.4.
2. Aplique pelo menos uma mitigação imediata:
   • Desative/renomeie a pasta do tema, ou
   • Bloqueie padrões de exploração no nível do servidor/WAF, e
   • Restrinja o acesso ao wp-config.php.
3. Ative a varredura e monitoramento contínuos.
4. Se puder, inscreva-se em um plano de proteção gerenciado (nível gratuito disponível) para aplicar patches virtuais imediatamente enquanto planeja uma correção permanente.
5. Comunique-se com as partes interessadas se você hospedar sites de clientes — transparência e mitigação rápida são importantes.

Se você precisar de assistência técnica

Se você executar várias instalações do WordPress ou gerenciar sites de clientes e quiser ajuda para triagem ou aplicação de mitigação, nossa equipe de operações de segurança pode ajudar a analisar logs, implantar patches virtuais em sua frota e auxiliar na resposta a incidentes e limpeza. Também fornecemos orientações passo a passo para atualizações seguras e substituições de temas vulneráveis.

Conclusão

Esta vulnerabilidade Welldone LFI (CVE-2026-28118) é uma vulnerabilidade séria e não autenticada que pode expor arquivos locais e levar à divulgação de credenciais e comprometimento total. O caminho mais rápido para a segurança é remover ou colocar em quarentena o tema vulnerável e implantar regras de patch virtual na periferia enquanto você planeja uma atualização ou substituição controlada. Reforçar o servidor (desativando wrappers arriscados, corrigindo permissões, restringindo o acesso a arquivos) e monitorar logs em busca dos indicadores acima reduzirá a exposição drasticamente.

Se você quiser proteção imediata sem mudanças complexas no servidor, experimente nosso plano gratuito de proteção básica, que fornece regras de firewall gerenciadas, proteções WAF e varredura de malware para bloquear padrões de exploração como os usados em ataques LFI. Comece a proteger seu site agora: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

— A Equipe de Segurança do Firewall WP

Referências e notas

• Vulnerabilidade rastreada como CVE-2026-28118 (Inclusão de Arquivo Local no tema Welldone, relatada em 19 de agosto de 2025; publicada em 26 de fevereiro de 2026).
• Este aviso é destinado a ajudar os defensores. Não publicamos código de exploração aqui. Se você é um administrador que suspeita de uma violação e precisa de assistência direta, escale para seus respondentes de segurança ou entre em contato com um provedor de segurança WordPress confiável.