| Nome do plugin | Learnify |
|---|---|
| Tipo de vulnerabilidade | Inclusão de Arquivo Local |
| Número CVE | CVE-2025-60085 |
| Urgência | Alto |
| Data de publicação do CVE | 2026-04-25 |
| URL de origem | CVE-2025-60085 |
Inclusão Crítica de Arquivo Local no Tema Learnify (≤ 1.15.0) — Passos Imediatos para Proprietários de Sites WordPress
2026-04-25 | Equipe de Segurança WP‑Firewall
Resumo
Uma vulnerabilidade crítica de Inclusão de Arquivo Local (LFI) foi divulgada no tema WordPress Learnify afetando versões ≤ 1.15.0 (CVE-2025-60085). O problema permite que atacantes não autenticados incluam e exibam arquivos locais do servidor web. A vulnerabilidade relatada tem alta severidade (CVSS 8.1) e pode ser explorada em larga escala — permitindo que atacantes vazem arquivos sensíveis como wp-config.php, arquivos de ambiente, ou qualquer arquivo legível do lado do servidor. Isso pode levar à divulgação de credenciais, comprometimento de banco de dados e total controle do site, dependendo do ambiente.
Se você utiliza o Learnify ou sites que o usam, leia este post com atenção. Explicamos o que a vulnerabilidade significa, como os atacantes a abusam, como detectar sinais de exploração e o processo passo a passo de mitigação e resposta a incidentes que recomendamos. Também mostramos regras práticas de WAF e orientações de endurecimento do servidor para reduzir a superfície de ataque imediatamente.
O que é Inclusão de Arquivo Local (LFI)?
Inclusão de Arquivo Local (LFI) é uma classe de vulnerabilidade em aplicações web que ocorre quando a entrada controlada pelo usuário é usada para selecionar e incluir arquivos no servidor sem validação adequada. Em um site baseado em PHP, por exemplo, isso pode parecer:
include($_GET['template']);require_once($_REQUEST['page']);
Se um atacante puder controlar a entrada que determina qual arquivo é incluído, ele pode direcionar a aplicação para arquivos locais arbitrários e forçar o servidor a ler e exibir seu conteúdo. Consequências comuns:
- Divulgação de segredos (credenciais de banco de dados, chaves de API).
- Coleta de informações para preparar ataques adicionais.
- Em ambientes que permitem wrappers perigosos (php://input, php://filter) ou onde a inclusão de arquivo remoto está habilitada, a execução remota de código (RCE) pode ser possível.
LFI pode ser explorado usando strings de travessia simples (../../../../) e técnicas de wrapper (php://filter) para ler arquivos com segurança em contextos onde a inclusão direta não imprimirá o conteúdo do arquivo.
Por que este LFI do Learnify é perigoso
Fatos chave sobre este incidente:
- Afeta versões do tema Learnify ≤ 1.15.0.
- CVE: CVE-2025-60085.
- Privilégio necessário: nenhum (não autenticado).
- CVSS: 8.1 (Alto).
- Nenhum patch oficial do fornecedor está disponível no momento (os proprietários dos sites devem aplicar mitig ações).
Por que este LFI em particular é uma questão de alta prioridade:
- Não autenticado: Um atacante não precisa de credenciais para tentar a exploração.
- Fácil de automatizar: Verificações de LFI podem ser executadas por scanners automatizados em milhares de sites.
- Arquivos de destino sensíveis: O WordPress armazena credenciais de banco de dados e sais em
wp-config.php, tornando este arquivo um alvo principal. - Cadeabilidade: LFI pode ser encadeado com outras configurações incorretas (permissões de arquivo fracas, diretórios de plugins/temas graváveis, wrappers PHP perigosos) para escalar para RCE ou instalação de backdoor persistente.
Devido a esses fatores, sites que executam as versões vulneráveis do Learnify devem agir imediatamente.
Detalhes técnicos (como os atacantes normalmente exploram LFI)
Embora o nome exato do parâmetro vulnerável possa variar entre as versões do tema, o padrão de exploração para LFI segue etapas comuns. Abaixo explicamos o método geral que um atacante usaria — para que você possa reconhecer e se defender contra isso.
- Encontrando o ponto de entrada
– O atacante procura arquivos de tema que chamamincluir,exigir,obter_conteúdo_do_arquivo, ou funções semelhantes com variáveis influenciadas por valores GET/POST/cookie.
– Exemplo de padrão arriscado:include( $theme_dir . '/' . $_GET['tpl'] ); - Traversal de caminho
– O atacante envia payloads contendo sequências de traversal:
–../../../../etc/passwd
–../../../../wp-config.php
– Muitos servidores impedem a leitura de arquivos retornando erros ao incluir arquivos binários. Os atacantes então usam wrappers. - Usando wrappers para ler arquivos (técnica comum)
–php://filter/convert.base64-encode/resource=path/to/file— aplica um filtro para codificar um arquivo em base64 quando incluído, tornando-o imprimível nas respostas.
– Exemplo de carga útil:
–?tpl=php://filter/convert.base64-encode/resource=../../../../wp-config.php - Byte nulo e truques de codificação
– Em versões mais antigas do PHP e configurações de servidor, atacantes podem usar a truncagem de byte nulo (%00) para contornar verificações de sufixo. Muitas versões modernas mitigam isso, mas ainda é uma carga útil comum em varreduras automatizadas:
–?tpl=../../../../wp-config.php - Etapas pós-exploração
– Se as credenciais do wp-config forem encontradas, o atacante as usa para acessar o banco de dados ou criar um usuário administrador, fazer upload de backdoors ou exfiltrar segredos adicionais.
– Se os uploads de arquivos forem acessíveis e não sanitizados, o atacante pode fazer upload de shells PHP e obter RCE.
Uma divulgação responsável observou que a lógica de inclusão do tema Learnify falhou em sanitizar adequadamente os caminhos fornecidos pelo usuário, permitindo as técnicas acima.
Indicadores de exemplo e padrões de solicitações maliciosas a serem observados
Verifique os logs do seu servidor web e os logs do WAF em busca de solicitações contendo esses padrões:
php://filter/convert.base64-encode/resource=....ou../repetido (traversal de caminho)%00ou tentativas codificadas de byte nulo- Solicitações para arquivos PHP de tema com strings de consulta incomuns como
?tpl=...ou?pagina=...(verifique qualquer parâmetro que pareça selecionar um template) - Longas strings base64 nas respostas (indica que o conteúdo do arquivo foi codificado e retornado)
Linha de solicitação suspeita de amostra:
GET /wp-content/themes/learnify/somefile.php?template=php://filter/convert.base64-encode/resource=../../../../wp-config.php HTTP/1.1
Se você ver esse padrão, trate-o como alta prioridade — isole e investigue imediatamente.
Lista de verificação de ação imediata (o que fazer nas primeiras horas)
Se você opera um site usando Learnify ≤1.15.0, execute as seguintes ações imediatamente:
- Coloque o site em modo de manutenção (se viável) ou aplique controles de acesso temporários (listas de permissão de IP) para reduzir a exposição.
- Mude para um tema limpo (padrão do WordPress) ou remova o tema vulnerável de diretórios de acesso público. Não deixe o tema vulnerável ativo.
- Se uma versão de tema corrigida for publicada, aplique a atualização imediatamente. Se ainda não existir um patch oficial, prossiga com as mitig ações abaixo.
- Coloque uma regra de WAF em vigor (patch virtual) para bloquear solicitações que contenham sequências de travessia ou usos de wrapper (veja exemplos de regras na seção “Regras de WAF”).
- Altere a senha do banco de dados do WordPress e quaisquer credenciais de serviço que possam estar armazenadas em
wp-config.phpe outros arquivos de configuração — mas somente depois de garantir backups e verificações de integridade, uma vez que a comprometimento pode persistir. - Rode as chaves secretas e sais em
wp-config.phpapós a remediação. - Escaneie o site em busca de webshells, arquivos suspeitos e timestamps modificados.
- Restaure a partir de um backup limpo verificado se você detectar comprometimento.
- Aumente a monitorização: habilite monitoramento de integridade de arquivos, logs de auditoria e alertas.
Se você não tiver a capacidade técnica para realizar todas as etapas, entre em contato com seu provedor de hospedagem ou uma equipe de segurança e forneça a eles os indicadores que você encontrou.
Como detectar se seu site foi explorado
Mesmo que você feche a vulnerabilidade, deve verificar se ela foi explorada anteriormente.
Verifique por:
- Ficheiros novos ou modificados em
wp-content/uploads,wp-content/temas,wp-content/plugins, ou outros locais inesperados. - Novos usuários administradores no WordPress (verifique
Usuários wptabela). - Tarefas agendadas suspeitas (cron jobs) ou entradas de cron não autorizadas no banco de dados.
- Conexões de saída do servidor para IPs desconhecidos (verifique os logs do firewall/host).
- Uso inesperado alto de CPU/IO ou picos de tráfego.
- Consultas de banco de dados incomuns nos logs de consultas lentas ou consultas usando contas nunca vistas antes.
- Arquivos PHP desconhecidos ou scripts codificados contendo
avaliar,base64_decode, ougzinflate.
Ferramentas recomendadas:
- Verificações de integridade de arquivos em nível de servidor (estilo tripwire).
- Scanners de segurança do WordPress (prefira os que fornecem verificação em nível de código e heurísticas).
- Verificação completa de malware em arquivos e conteúdo do banco de dados.
- Revisão manual de arquivos críticos (wp-config, .htaccess, index.php nas pastas de plugins/temas).
Se você encontrar evidências de comprometimento, siga os passos de resposta a incidentes na próxima seção.
Resposta a incidentes: manual passo a passo
Se você confirmar exploração, prossiga da seguinte forma:
- Conter
– Coloque o site offline ou bloqueie o tráfego para evitar mais danos.
– Revogue credenciais e chaves de API comprometidas.
– Isolar o servidor da rede, se possível. - Preservar Evidências
– Faça backup dos logs (logs do servidor web, banco de dados, logs de aplicação) e imagens de disco.
– Não sobrescreva logs — preserve os timestamps para análise forense. - Erradicar
– Remova todos os backdoors, shells e scripts maliciosos descobertos.
– Reinstale o núcleo do WordPress, plugins e temas de fontes limpas.
– Reconstrua servidores a partir de imagens se a persistência em nível de servidor for suspeita. - Recuperar
– Restaurar a partir de um backup limpo (feito antes da violação).
– Aplicar todos os patches de segurança disponíveis e medidas de endurecimento.
– Mudar todas as senhas e rotacionar chaves e sais. - Pós-recuperação
– Reforçar monitoramento e registro.
– Realizar uma análise pós-morte: como ocorreu a violação? Quais controles falharam?
– Educar a equipe e atualizar seu plano de resposta a incidentes. - Notificar
– Notificar partes interessadas, provedor de hospedagem e, se necessário em sua jurisdição, clientes ou reguladores.
Recomendações de endurecimento para reduzir o risco de LFI
Mesmo após a mitigação imediata, adote essas defesas a longo prazo:
- Princípio do menor privilégio
– Garantir que as permissões de arquivos e diretórios sejam mínimas. A maioria dos arquivos do WordPress deve ser legível pelo servidor web, mas não gravável, excetowp-content/uploadsque precisa de acesso de gravação apenas para uploads.
– As contas de banco de dados usadas pelo WordPress devem ter apenas os privilégios necessários. - Configuração do PHP
– Desabilitarallow_url_include.
– Desabilitar wrappers não utilizados, se possível.
– Usaropen_basedirpara restringir o acesso do PHP a diretórios.
– Desabilitarexec,shell_exec,passthru,sistemase não for necessário. - Desabilitar o editor de plugins e temas embutido
– Adicionar awp-config.php:
define('DISALLOW_FILE_EDIT', true);
define('DISALLOW_FILE_MODS', true);// restringe instalações/atualizações de plugins/temas do WP admin - Uploads seguros
– Impedir a execução direta de arquivos PHP emwp-content/uploadsadicionando regras de servidor (veja o exemplo de bloqueio .htaccess/nginx abaixo). - Use sais e chaves fortes e únicas (gire na remediação)
– Alterar chaves invalidará cookies de autenticação ativos — útil após um incidente. - Backups regulares e testes de restauração
– Mantenha backups frequentes fora do site e teste restaurações regularmente. - Use atualizações em etapas e revisão de código
– Para temas/plugins em desenvolvimento ativo, revise o código de terceiros ou restrinja o uso até que a postura de segurança seja verificada.
Regras práticas de WAF e mitigação em nível de servidor
O patch virtual (WAF) pode comprar tempo quando um patch oficial ainda não está disponível. Abaixo estão regras de exemplo que você pode usar em sistemas WAF comuns ou como controles em nível de servidor web. Adapte e teste cuidadosamente — regras incorretas podem bloquear tráfego legítimo.
Detecção de padrões importante para bloquear:
- Qualquer valor de parâmetro contendo
php://filter - Qualquer parâmetro contendo múltiplos
../sequências - Tentativas de byte nulo
%00 - Tentativas de incluir arquivos com nomes de arquivos sensíveis (
wp-config.php,.env,/etc/passwd)
Exemplo de regra no estilo ModSecurity/Core Rule Language (CRS):
# Bloquear assinaturas comuns de ataque LFI"
Regra baseada em localização do Nginx para negar tentativas de php://filter ou de travessia:
if ($request_uri ~* "(php://filter||\.\./){1,}") {
Apache .htaccess trecho eficaz para bloquear a execução de PHP em uploads:
# Proteger uploads - impedir a execução de PHP
Uma abordagem mais sutil: bloqueie apenas solicitações suspeitas, permita as seguras. Teste as regras em staging antes de aplicar em produção.
Como nós da WP‑Firewall ajudamos (firewall gerenciado + mitigação)
Na WP‑Firewall operamos com uma suposição: vulnerabilidades serão descobertas em temas/plugins. A proteção mais rápida e menos disruptiva é o patch virtual via um WAF gerenciado que bloqueia tentativas de exploração em tempo real enquanto você planeja e aplica correções permanentes.
Proteções principais que entregamos e recomendamos:
- Regras de WAF gerenciadas atualizadas automaticamente em resposta a novas divulgações — bloqueie cargas úteis de exploração (php://filter, sequências de travessia, tentativas de buscar
wp-config.php) antes que atinjam o PHP. - Escaneamento de malware e detecção de assinatura para detectar webshells e modificações suspeitas logo após uma tentativa de exploração.
- Monitoramento de integridade de arquivos e escaneamentos diários para detectar mudanças inesperadas em arquivos.
- Alertas de incidentes e suporte para ajudar a triagem de descobertas e implementar mitigação.
- Capacidade de patch virtual para que mesmo que um tema não tenha um patch oficial, você possa continuar as operações enquanto o risco é reduzido.
Recomendamos combinar o patch virtual imediato com as etapas de endurecimento do servidor descritas acima, rotacionando credenciais e implementando monitoramento contínuo.
Exemplos de regex de detecção e dicas de análise de logs
Fique de olho nos logs do servidor web e implemente alertas sobre esses padrões:
Regex (sem distinção entre maiúsculas e minúsculas) para detectar prováveis sondagens LFI:
(?i)(phpfilter|php://filter|(\.\./){2,}|(\.\.\\){2,}||wp-config\.php|/etc/passwd)
Entradas de log que acionam alertas:
- GET /wp-content/themes/learnify/… ?…=php://filter/convert.base64-encode/resource=../../../../wp-config.php
- Quaisquer solicitações usando
php://invólucros - Solicitações que retornam 200 com strings codificadas em base64 — base64 em páginas HTML é frequentemente um indicador de leituras de conteúdo de arquivo.
Configure um trabalho automatizado para escanear logs diariamente em busca desses padrões e notificar administradores.
Exemplo de teste seguro para verificar vulnerabilidades (apenas para proprietários do site)
Se você é o proprietário do site e precisa testar se sua instalação do Learnify é vulnerável, siga este procedimento de verificação seguro e somente leitura. Não tente explorar os sites de outras pessoas.
- Use uma solicitação não destrutiva
php://filterque simplesmente tenta codificar em base64 um arquivo reconhecido (por exemplo,readme.htmlno diretório do tema). - Construa uma solicitação semelhante a:
GET /wp-content/themes/learnify/index.php?tpl=php://filter/convert.base64-encode/resource=inc/readme.html
- Se a resposta contiver uma string base64 que decodifica para o conteúdo do arquivo, a função nesse tema é vulnerável ao uso indevido do padrão de inclusão. Pare de testar e prossiga para a mitigação.
Importante: Teste apenas em sites que você possui ou opera. Não realize testes em sites de terceiros.
Árvore de decisão de remediação: Atualizar vs Mitigação temporária vs Remover
- Se um tema oficial corrigido estiver disponível: atualize imediatamente, depois siga a lista de verificação de verificação (varredura de integridade do arquivo, rotações de senha).
- Se não existir um patch oficial:
- Remova o tema do uso ativo (mude para um tema padrão).
- Aplique regras de WAF e restrições de servidor para bloquear tentativas de exploração.
- Trabalhe com o fornecedor do tema para um cronograma ou considere substituir o tema por uma alternativa mantida.
- Se você não puder remover o tema por razões comerciais:
- Coloque o site atrás de controles de acesso rigorosos (lista de permissões de IP) para acesso administrativo.
- Aplique regras de WAF rigorosas e permita apenas funcionalidade mínima.
- Programe monitoramento dedicado e varreduras de integridade frequentes.
Após a remediação: valide e monitore
Após aplicar correções, valide seu ambiente:
- Execute novamente os scanners automatizados.
- Verifique se não há contas de administrador inesperadas ou tarefas agendadas presentes.
- Verifique conexões de rede inesperadas ou alterações de DNS.
- Revise os backups em busca de indicadores precoces de comprometimento (garanta que os backups estejam limpos).
- Continue a monitorar intensamente por pelo menos 30 dias após a remediação.
Perguntas frequentes (FAQ)
- Q: A LFI pode levar à Execução Remota de Código?
- A: A LFI em si é uma vulnerabilidade de inclusão/leitura de arquivos. A RCE pode ser possível se o atacante puder incluir um arquivo que pode controlar (por exemplo, um arquivo PHP enviado) ou encadear a LFI com outras configurações incorretas (diretórios graváveis, wrappers perigosos ou plugins maliciosos).
- Q: Meu site usa um tema filho do Learnify — estou impactado?
- A: Possivelmente. Temas filhos herdam código central dos temas pais. Se a lógica vulnerável existir no código do tema pai e o tema pai for Learnify ≤1.15.0, você provavelmente está afetado. Verifique a versão do tema pai e aplique as mitig ações.
- Q: Eu corrigi o tema — ainda preciso rotacionar credenciais?
- A: Sim. Se houver alguma chance de o site ter sido exposto, rotacione chaves, senhas de banco de dados e tokens de API usados no site. A correção previne exploração futura, mas não remove compromissos que ocorreram anteriormente.
- Q: Como posso ser notificado sobre vulnerabilidades semelhantes no futuro?
- A: Inscreva-se em um feed de segurança confiável e mantenha suas assinaturas de WAF e scanners de malware atualizados. Implemente monitoramento automatizado de vulnerabilidades para temas e plugins instalados.
Comece a Proteger Seu Site Hoje — Plano Gratuito Disponível
Se você deseja uma camada de proteção imediata e direta enquanto realiza os passos técnicos de remediação acima, nosso nível gratuito gerenciado fornece defesas essenciais para sites WordPress. O plano gratuito inclui um firewall gerenciado com patching virtual, um firewall de aplicativo web (WAF), varredura de malware, proteção de largura de banda ilimitada e mitigação para os 10 principais riscos da OWASP. Inscrever-se é simples e rápido — você pode começar a bloquear tentativas de exploração em minutos.
Saiba mais ou registre-se para o plano gratuito aqui
Opções de upgrade: também oferecemos planos pagos acessíveis que adicionam remoção automática de malware, blacklist/whitelist de IP, relatórios de segurança mensais e serviços gerenciados avançados para empresas e agências. Se você estiver gerenciando vários sites ou precisar de suporte ativo de remediação, nossos planos de nível superior oferecem uma abordagem de segurança completa e gerenciada.
Considerações finais dos Especialistas em Segurança do WP‑Firewall
Esta divulgação de LFI do Learnify é um lembrete de que qualquer tema ou plugin pode introduzir fraquezas críticas. Os aspectos mais importantes de responder a incidentes como este são a velocidade e a completude:
- Velocidade para aplicar mitigação (patching virtual e remoção temporária).
- Completeness na investigação (o atacante obteve algo? o que foi acessado?).
- Melhorias a longo prazo (fortalecimento, monitoramento, menor privilégio).
Se você precisa de um parceiro que possa gerenciar patching virtual e fornecer detecção e resposta contínuas para sua frota WordPress, os serviços gerenciados da WP‑Firewall são projetados para fazer exatamente isso — proteger o tráfego em tempo real, escanear indicadores pós-exploração e ajudar você a se recuperar com mínima interrupção nos negócios.
Se você gerencia vários sites WordPress, agora é a hora de revisar seu inventário de temas, confirmar versões e aplicar os passos acima. Se você precisar de ajuda para triagem de indicadores específicos, publicamos guias de remediação detalhados e fornecemos suporte a clientes que necessitam de assistência acelerada. Mantenha-se vigilante e trate qualquer probe LFI como potencialmente sério — os atacantes automatizam essas verificações, e um site explorável está em risco real.
Apêndice A: Lista de verificação rápida (copiar/colar)
- Identifique se o Learnify ≤ 1.15.0 está instalado.
- Mude para um tema diferente ou desative o Learnify.
- Aplique regra(s) de WAF para bloquear tentativas de php://filter e travessia de caminho.
- Escaneie em busca de webshells e modificações não autorizadas de arquivos.
- Rotacione credenciais de DB e sais do WP.
- Restaure a partir de um backup limpo se a comprometimento for detectado.
- Implemente o fortalecimento de permissões de arquivos.
- Habilite monitoramento e alertas de integridade de arquivos.
- Monitore logs por 30 dias após a remediação.
Apêndice B: Recursos e referências adicionais
- CVE-2025-60085 (referência de aviso público)
- Melhores práticas de fortalecimento de PHP
- Manual de segurança do WordPress (guia do administrador do site)
- Guia de ajuste de WAF e teste de regras
(Se você quiser ajuda para implementar regras específicas de WAF ou realizar uma varredura de vulnerabilidade segura em seu ambiente, nossa equipe de segurança da WP‑Firewall pode ajudar. Oferecemos opções de autoatendimento e gerenciadas adaptadas a sites de todos os tamanhos.)
Obrigado por levar a segurança a sério. Se você tiver perguntas sobre os passos acima ou quiser orientação específica para o seu site, entre em contato com o suporte do WP‑Firewall ou inscreva-se no plano gratuito para obter proteção gerenciada imediata: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
