Nome do plugin	WordPress Primary Addon para o Plugin Elementor
Tipo de vulnerabilidade	Script de Site Cruzado
Número CVE	CVE-2024-13362
Urgência	Baixo
Data de publicação do CVE	2026-05-01
URL de origem	CVE-2024-13362

Aviso Urgente — XSS Refletido no “Primary Addon for Elementor” (<= 1.6.0): O que Todo Proprietário de Site WordPress Deve Fazer

Uma análise focada em segurança da vulnerabilidade de Cross-Site Scripting (XSS) refletido não autenticado (CVE-2024-13362) que afeta o Primary Addon for Elementor (<= 1.6.0). A orientação inclui detecção, mitigação, orientação de patch virtual WAF, etapas de atualização e recomendações de resposta a incidentes da equipe de segurança do WP-Firewall.

Data: 2026-05-01
Autor: Equipe de Segurança do Firewall WP

Nota: Este aviso analisa um relatório de vulnerabilidade publicado recentemente (CVE-2024-13362) descrevendo um problema de Cross-Site Scripting (XSS) refletido não autenticado que afeta o plugin WordPress “Primary Addon for Elementor” nas versões até e incluindo 1.6.0. O fornecedor corrigiu o problema na versão 1.6.5. Se seu site usa este plugin e você não atualizou, leia este post e aja agora.

Índice

• O que aconteceu (resumo)
• Entendendo o XSS refletido e por que isso é importante
• Os detalhes (o que o aviso nos diz)
• Cenários de exploração e impacto
• Como detectar se seu site está sendo alvo ou explorado
• Passos imediatos de mitigação (curto prazo)
• Resolução permanente (atualizando com segurança)
• Patch virtual e o que o WP-Firewall fornece
• Exemplos de assinatura WAF e recomendações
• Lista de verificação de endurecimento (para proprietários de sites e desenvolvedores)
• Resposta a incidentes: se você acha que seu site foi comprometido
• Como testar com segurança se a vulnerabilidade foi corrigida
• Planos do WP-Firewall: a proteção certa para sua configuração
• Proteja seu site agora — experimente o Plano Gratuito do WP-Firewall
• Notas finais e próximos passos recomendados

---

O que aconteceu (resumo)

Uma vulnerabilidade de Cross-Site Scripting (XSS) refletido (rastreadas como CVE-2024-13362) foi divulgada para o plugin “Primary Addon for Elementor”. O aviso indica que o problema afeta versões até e incluindo 1.6.0 e foi corrigido na versão 1.6.5. A vulnerabilidade é descrita como “Cross-Site Scripting Refletido Não Autenticado”, o que significa:

• Um atacante não autenticado pode construir uma URL contendo uma entrada maliciosa que é refletida de volta pelo plugin em uma página da web sem a devida sanitização/codificação.
• Uma vítima deve acessar a URL criada (por exemplo, clicando nela ou visitando uma página que a contenha) para que o script malicioso seja executado no navegador da vítima.
• A versão do fornecedor que aborda o problema é 1.6.5 — atualizar para essa versão ou uma versão posterior elimina o caminho de código vulnerável.

Embora a gravidade publicada seja avaliada como “baixa” em algumas listagens (com uma pontuação base CVSS publicada como 6.1), o XSS não autenticado em um plugin amplamente distribuído merece atenção imediata. Mesmo quando a exploração requer interação do usuário, os atacantes podem transformar o XSS refletido em armas para phishing, roubo de sessão, ataques drive-by e outras cargas secundárias que causam danos reais.

---

Entendendo o XSS refletido e por que isso é importante

Cross-Site Scripting (XSS) é uma classe de vulnerabilidades de injeção onde um atacante faz com que o navegador de uma vítima execute um script controlado pelo atacante no contexto de um site confiável. Existem três tipos principais:

• XSS armazenado (persistente) — cargas úteis são salvas no servidor e entregues posteriormente.
• XSS refletido (não persistente) — cargas úteis são entregues na resposta a uma solicitação elaborada (geralmente via parâmetros de URL).
• XSS baseado em DOM — a manipulação ocorre puramente no DOM do navegador.

O XSS refletido é comumente usado em ataques de phishing e engenharia social. Um atacante elabora uma URL que inclui uma carga útil de JavaScript em um parâmetro GET ou caminho, e então convence a vítima a clicar nessa URL (via e-mail, chat, mídia social). Quando o plugin ou página ecoa a entrada do atacante de forma insegura em um contexto HTML, o navegador executa a carga útil como se o conteúdo fosse legítimo.

Por que é perigoso:

• Alcance não autenticado: qualquer usuário da web (visitante) pode ser alvo; os atacantes não precisam de uma conta no site.
• Superfície de ataque ampla: se o plugin é usado em muitos sites, uma única tática de exploração pode atingir milhares de sites.
• Cadeamento com outros problemas: o XSS frequentemente atua como um vetor para roubo de credenciais, contornos de CSRF, redirecionamento persistente e distribuição de malware.

Mesmo que a vulnerabilidade imediata possa parecer limitada (exige que um humano clique em um link), a escala e a facilidade de armamento significam que devemos tratar o XSS refletido como uma prioridade para conter e resolver rapidamente.

---

Os detalhes (o que o aviso nos diz)

O aviso de segurança pública publicado em 1º de maio de 2026 descreve a vulnerabilidade como:

• Uma vulnerabilidade de Cross-Site Scripting (XSS) refletido no plugin “Primary Addon for Elementor”.
• Afeta versões do plugin ≤ 1.6.0.
• Corrigido pelo autor do plugin na versão 1.6.5.
• Classificado como um XSS refletido não autenticado (sem login necessário para o atacante).
• Atribuição CVE: CVE-2024-13362.
• CVSS publicado: 6.1 (nota: CVSS é um sistema de pontuação geral—o contexto importa para ambientes WordPress).

Como o aviso relata que o problema é um XSS refletido via um parâmetro de URL, a provável causa raiz é a validação insuficiente de entrada ou codificação de saída ao ecoar dados de solicitação em contexto HTML/JS. A versão corrigida pelo fornecedor elimina o eco vulnerável ou codifica a saída corretamente.

Atenção importante: Avisos públicos não listam sempre nomes exatos de parâmetros ou cargas úteis de prova de conceito (deliberadamente, para limitar a propagação da exploração). Consulte o changelog do plugin e as notas de lançamento do fornecedor para detalhes antes de testar.

---

Cenários de exploração e impacto

Os atacantes elaborarão cadeias de exploração em torno dessa vulnerabilidade dependendo de seus objetivos. Cenários comuns de exploração incluem:

• Phishing e roubo de credenciais: O atacante envia ou hospeda uma URL elaborada que, uma vez aberta por um administrador, exibe um login falso de administrador ou sobreposição que captura credenciais.
• Sequestro de sessão: Se os tokens/cookies de autenticação não estiverem protegidos com as flags HttpOnly ou secure, os atacantes podem injetar scripts que leem cookies e os exfiltram para o atacante.
• Redirecionamento persistente ou fraude de afiliados: Scripts injetados podem redirecionar visitantes para páginas controladas pelo atacante para anúncios, pagamentos de afiliados ou downloads.
• Downloads automáticos e malware: Inserir scripts que fazem o visitante buscar malware ou carregar recursos maliciosos.
• Desfiguração de conteúdo ou elementos de UI indesejados: Mostrar conteúdo spam ou malicioso para os visitantes.
• Escalação lateral de privilégios: Em casos raros, o XSS pode ser usado como parte de uma cadeia para obter acesso de nível superior (por exemplo, CSRF para alterar configurações se as proteções forem inadequadas).

O impacto depende do usuário-alvo que clica em um link malicioso. Se um administrador (usuário com permissão para editar temas/plugins ou administrador do site) for enganado, as apostas aumentam dramaticamente: o atacante pode tentar acessar painéis, instalar backdoors ou fazer alterações em todo o site.

---

Como detectar se seu site está sendo alvo ou explorado

Detectar a exploração de XSS refletido é parcialmente comportamental (sintomas de experiência do usuário) e parcialmente forense (logs do servidor, logs do WAF, artefatos do navegador). Verifique os seguintes indicadores:

1. Logs de acesso — procure por strings de consulta suspeitas:
   • Long query parameters containing encoded characters (%3C, %3E, %22), basic tags like <script>, or patterns like javascript:.
   • Solicitações repetidas contendo cargas úteis suspeitas semelhantes direcionadas a endpoints específicos.

   Exemplo de grep:

   grep -iE "%3Cscript|<script|javascript:" /var/log/apache2/access.log

2. Logs do WAF e do servidor:
   • Procure por regras bloqueadas ou respostas frequentes 403/406 que coincidam com cargas úteis suspeitas.
   • Se você executar o WP-Firewall e o registro estiver ativado, inspecione os alertas que mencionam assinaturas de XSS ou ARGS bloqueados.
3. Relatórios de navegador de usuários:
   • Reclamações sobre pop-ups inesperados, redirecionamentos ou conteúdo alterado após seguir um link.
4. Atividade POST/GET incomum:
   • Alto volume de solicitações com o mesmo padrão de muitos IPs direcionadas ao mesmo endpoint — possivelmente uma varredura automatizada.
5. Novos usuários administradores ou arquivos modificados:
   • Se o XSS foi utilizado para obter acesso de administrador, você pode ver novas contas ou alterações de arquivos (verifique wp_users e os horários de modificação de arquivos).
6. Monitoramento externo:
   • Use uptime/monitoring e scanners externos para detectar conteúdos de página alterados.

Se você encontrar algum dos itens acima durante a janela de vulnerabilidade, trate a situação como uma possível exploração e siga os passos de resposta a incidentes abaixo.

---

Passos imediatos de mitigação (curto prazo)

Se você hospedar sites que usam “Primary Addon for Elementor” e estão em versões ≤ 1.6.0, tome as seguintes ações imediatas em ordem de prioridade:

1. Atualize o plugin para 1.6.5 ou posterior (preferencial, veja “Resolução permanente” abaixo).
   • Esta é a única melhor correção.
2. Se não for possível atualizar imediatamente:
   • Ative/fortaleça as regras do WAF para bloquear cargas úteis XSS refletidas direcionadas aos endpoints do plugin.
   • Use um patch virtual (assinatura WAF gerenciada) para bloquear solicitações com caracteres XSS típicos imediatamente.
   • Desative temporariamente o plugin até que você possa atualizar (se prático):
     • Plugins → Plugins Instalados → Desativar “Primary Addon for Elementor”.
   • Restringir o acesso aos endpoints públicos do plugin com regras de permissão/negação de IP ou negar acesso via .htaccess para certos URLs.

     <Files "name-of-file.php">
       Require all denied
     </Files>
           

   • Aplique uma Política de Segurança de Conteúdo (CSP) forte para reduzir a capacidade de scripts injetados de executar ou exfiltrar dados.
3. Aumente a monitorização:
   • Ative o registro detalhado do WAF.
   • Monitore por referenciadores e padrões de solicitação suspeitos.
   • Notifique os administradores sobre tentativas de phishing e peça que não cliquem em links suspeitos.
4. Aplique proteções do navegador:
   • Certifique-se de que os cookies usem as flags HttpOnly e Secure sempre que possível.
   • Aconselhe os administradores a abrir links de administração apenas de dispositivos e redes confiáveis.

A chave é reduzir a exposição imediata enquanto planeja e executa a atualização segura.

---

Resolução permanente (atualizando com segurança)

Atualizar o plugin para a versão corrigida é a solução a longo prazo. Siga estes passos de atualização segura:

1. Faça backup primeiro
   • Backup completo do site (arquivos + banco de dados). Use o recurso de snapshot do host ou um plugin de backup confiável.
   • Verifique a integridade do backup e armazene fora do site.
2. Crie uma cópia de staging (se possível)
   • Teste a atualização em um ambiente de staging para confirmar a compatibilidade com temas e outros plugins.
3. Atualize o plugin
   • WP Admin:
     • Painel → Plugins → Encontre “Primary Addon for Elementor” → Clique em Atualizar Agora (ou use o fluxo de atualização).
   • WP-CLI (mais rápido e scriptável para muitos sites):

     wp plugin list --format=csv | grep primary-addon
           

     Substitua o slug do plugin se ele for diferente. Verifique primeiro o slug do plugin com lista de plugins do WordPress.

4. Teste seu site
   • Visite páginas e fluxos impactados para confirmar que não há regressão.
   • Verifique o console JavaScript em busca de erros.
   • Execute uma verificação rápida com seu scanner de malware.
5. Endurecer e monitorar
   • Reative o plugin se estiver desativado e monitore logs suspeitos.
   • Execute verificações periódicas de vulnerabilidade.

Se você gerencia dezenas ou centenas de sites, use ferramentas de gerenciamento centralizado ou automação para agendar atualizações em toda a sua propriedade e validar cada atualização.

---

Patch virtual e o que o WP-Firewall fornece

O patch virtual é uma mitigação crucial de curto a médio prazo quando atualizações imediatas de plugins não são possíveis (por exemplo, problemas de compatibilidade em produção ou requisitos complexos de staging). O WP-Firewall fornece múltiplas camadas de proteção que você deve considerar:

• Regras WAF gerenciadas (Básico incluído): Nosso WAF gerenciado pode ser configurado para bloquear cargas úteis XSS comuns nos endpoints do plugin, mitigando o vetor de ataque enquanto você agenda uma atualização.
• Patch virtual de vulnerabilidade automático (apenas Pro): Para clientes que assinam nosso plano Pro, fornecemos implantação automática de patch virtual adaptada à vulnerabilidade, bloqueando padrões de exploração sem exigir alterações no plugin no site.
• Scanner de malware e mitigação: Nosso scanner detecta cargas úteis injetadas e modificações suspeitas; os planos Standard e Pro adicionam remoção automatizada e utilitários de remediação adicionais.
• Controle de acesso e gerenciamento de IP: Os planos Standard e Pro fornecem controles de IP úteis para bloquear atacantes ativos que visam seu site.

Abordagem recomendada:

1. Se você estiver no plano gratuito Basic, ative o WAF gerenciado WP-Firewall e defina o registro/alertas para alta sensibilidade enquanto atualiza o plugin.
2. Se você não puder atualizar o plugin rapidamente e precisar de proteção zero-day, considere o plano Pro para correção virtual automatizada e camadas de mitigação prioritárias.

O WAF gerenciado do WP-Firewall é ajustado para minimizar falsos positivos enquanto protege contra padrões comuns de ataque XSS. A correção virtual compra tempo crítico para testar e implantar a correção oficial do plugin com segurança.

---

Exemplos de assinatura WAF e recomendações

Abaixo estão exemplos generalizados de assinaturas e proteções do WAF. Estes são modelos para ilustrar como você pode bloquear ataques; aplique e teste as alterações em staging primeiro para evitar quebrar o tráfego legítimo.

Regra genérica semelhante ao ModSecurity para bloquear padrões comuns de XSS refletido:

# Block common XSS payloads in query string and POST params (example)
SecRule ARGS|ARGS_NAMES|REQUEST_URI "(?i)(<script|%3Cscript|javascript:|onerror=|onload=|document\.cookie|window\.location|eval\()" \n "id:1001001,phase:2,deny,log,status:403,msg:'Generic reflected XSS block - WP-Firewall rule'"

Regra mais restritiva (direcionada) para endpoints conhecidos:

# Example: block suspicious payloads only for a specific path used by the plugin
SecRule REQUEST_URI "@contains /wp-content/plugins/primary-addon-for-elementor/" \n  "chain,phase:2,deny,log,msg:'Block XSS payloads targeting Primary Addon for Elementor'"
SecRule ARGS "(?i)(<script|%3Cscript|javascript:|onerror=|onload=|eval\()" "t:none"

Sugestão de cabeçalho de Política de Segurança de Conteúdo (CSP):

Content-Security-Policy: default-src 'self'; script-src 'self' https:; object-src 'none'; base-uri 'self'; frame-ancestors 'self';

Observação: O CSP deve ser testado cuidadosamente. Um CSP excessivamente rigoroso pode quebrar scripts de terceiros legítimos (análise, widgets). Comece em modo de relatório apenas durante os testes para ver o que seria bloqueado.

Recomendações:

• Não confie em uma única regra; combine a detecção do WAF com limitação de taxa, reputação de IP e registro.
• Mantenha as regras minimamente invasivas para evitar quebrar a funcionalidade legítima.
• Monitore os logs do WAF após implantar novas assinaturas e ajuste conforme necessário.
• Use correção virtual como uma rede de segurança temporária — atualize o plugin como a correção final.

---

Lista de verificação de endurecimento (para proprietários de sites e desenvolvedores)

Uma boa abordagem de defesa em profundidade reduz a probabilidade e o impacto de vulnerabilidades como esta.

1. Manter tudo atualizado
   • Atualize o núcleo do WordPress, temas e plugins prontamente. Use staging para testes de compatibilidade.
2. Princípio do menor privilégio
   • Limite usuários administrativos. Crie contas apenas com os privilégios necessários para a tarefa.
   • Remova contas não utilizadas e imponha senhas fortes.
3. Autenticação de dois fatores (2FA)
   • Aplique 2FA para todos os usuários administrativos.
4. Desative o editor de arquivos

   <?php;
   

5. Reforce as configurações do PHP e do servidor
   • Desative funções perigosas se não forem necessárias.
   • Garanta permissões de arquivo adequadas (644 arquivos, 755 diretórios normalmente).
6. Use um WAF gerenciado
   • Um WAF gerenciado bloqueia ataques web comuns (XSS, SQLi) e fornece registro.
7. Política de Segurança de Conteúdo (CSP)
   • Implemente CSP para mitigar o impacto de scripts injetados.
8. Cookies seguros
   • Use as flags HttpOnly e Secure para cookies.
9. Backups regulares e plano de recuperação
   • Backups diários armazenados fora do site, com um processo claro para restauração.
10. Auditoria e monitoramento
    • Escaneie regularmente em busca de malware e alterações anormais de arquivos.
    • Centralize logs e alertas.
11. Práticas de desenvolvedor.
    • Limpe entradas e escape saídas (nunca confie na entrada do usuário).
    • Use nonces para ações críticas e verifique do lado do servidor.

Adotar essas mitig ações não apenas protegerá contra XSS refletido, mas reduzirá o impacto de outras vulnerabilidades.

---

Resposta a incidentes: se você acha que seu site foi comprometido

Se você suspeitar de exploração bem-sucedida, siga um processo de resposta a incidentes:

1. Conter
   • Coloque temporariamente o site offline ou coloque-o em modo de manutenção.
   • Bloqueie IPs ofensivos e feche pontos finais vulneráveis com regras WAF/ACL.
2. Preserve as evidências.
   • Faça backups completos (arquivos + DB) para análise forense.
   • Mantenha logs (servidor web, WAF, logs de acesso) e evite sobrescrever.
3. Investigar
   • Verifique contas de usuário para adições/alterações não autorizadas (tabela wp_users).
   • Revise modificações recentes de arquivos (timestamps) e verifique se há webshells ou arquivos PHP suspeitos.
   • Revise o banco de dados em busca de injeções de conteúdo não autorizadas.
4. Erradicar
   • Remova webshells e arquivos maliciosos.
   • Reinstale o núcleo, temas e plugins de fontes oficiais após verificação.
   • Altere todas as senhas de administrador e chaves de API. Invalide tokens de sessão e reemita onde aplicável.
5. Recuperar
   • Restaure a partir de um backup limpo, se necessário, e coloque o site online novamente.
   • Reaplique o endurecimento de segurança e monitore cuidadosamente.
6. Relatar e aprender
   • Se você hospedar sites de clientes, notifique as partes afetadas conforme obrigações legais/regulatórias.
   • Após o incidente, revise a causa raiz e melhore os processos de monitoramento, correção e incidentes.

Se você não tiver capacidade interna para realizar uma remediação completa, contrate um especialista em segurança confiável para evitar erros que possam deixar portas dos fundos abertas.

---

Como testar com segurança se a vulnerabilidade foi corrigida

Sempre teste primeiro em um ambiente de teste. Nunca execute tentativas de exploração em produção sem necessidade explícita e autoridade legal.

Verificações básicas de segurança:

1. Verifique a versão do plugin.

   wp plugin get primary-addon-for-elementor --field=version
     

2. Verifique o changelog oficial ou notas de lançamento para a correção (fornecido pelo fornecedor).
3. Use sondas de carga útil não maliciosas:
   • Envie uma string de teste codificada inofensiva e verifique se ela é refletida não codificada.

   curl -s "https://yoursite.com/path?testparam=%3Cxss-test%3E" | grep -i "%3Cxss-test%3E\|<xss-test>"
   

   Se a resposta mostrar o <xss-test> string não escapada, uma investigação adicional é necessária. Se estiver sanitizada/codificada ou o parâmetro não for ecoado, a correção é eficaz.

4. Use um scanner confiável em teste para executar testes automatizados para vetores XSS.
5. Valide o comportamento da página em vários navegadores e usuários (administrador vs. visitante).

Somente após a validação bem-sucedida em teste, implemente a atualização em produção e monitore de perto.

---

Planos do WP-Firewall: a proteção certa para sua configuração

Na WP-Firewall, fornecemos soluções em camadas para reduzir riscos e acelerar a mitigação quando uma vulnerabilidade é divulgada.

Principais pontos do plano:

• Básico (grátis)
  • Proteção essencial: firewall gerenciado, largura de banda ilimitada, WAF, scanner de malware e mitigação dos 10 principais riscos da OWASP.
  • Ideal para proprietários de sites que desejam uma base sólida de proteção sem custo.
• Padrão ($50/ano)
  • Todos os recursos Básicos, além de remoção automática de malware e a capacidade de adicionar/remover até 20 IPs da lista negra/branca.
  • Bom para proprietários de sites que desejam remediação automatizada para infecções comuns.
• Pro ($299/ano)
  • Todos os recursos padrão, além de relatórios de segurança mensais, correção virtual automática de vulnerabilidades e acesso a complementos premium (Gerente de Conta Dedicado, Otimização de Segurança, Token de Suporte WP, Serviço WP Gerenciado, Serviço de Segurança Gerenciado).
  • Recomendado para sites de alto valor, agências e ambientes onde o tempo de inatividade ou comprometimento é muito caro.

A correção virtual automática do plano Pro é especificamente projetada para fechar a janela entre a divulgação de vulnerabilidades e a correção permanente, enquanto lhe dá tempo para validar atualizações com segurança.

---

Proteja seu site agora — experimente o Plano Gratuito do WP-Firewall

Título: Comece Forte — Obtenha Proteção Essencial para WordPress Grátis

Se você deseja reduzir a exposição a vulnerabilidades de plugins recém-divulgadas e melhorar sua segurança básica rapidamente, comece com o plano Gratuito do WP-Firewall hoje. O plano Básico (Gratuito) inclui um firewall gerenciado, WAF, varredura de malware e proteções projetadas para mitigar os riscos comuns do OWASP Top 10 — os controles exatos que importam para ataques XSS refletidos.

Por que se inscrever no plano Gratuito?

• Cobertura imediata de WAF gerenciado para padrões comuns de XSS e injeção.
• Largura de banda ilimitada para que a proteção não seja restringida durante um ataque.
• Varredura de malware para detectar scripts injetados e alterações suspeitas.
• Forma sem custo de adicionar uma camada de segurança profissional enquanto você planeja atualizações e endurecimento.

Comece agora

(Atualizar mais tarde para Padrão ou Pro desbloqueia remoção automatizada, gerenciamento de IP, correção virtual e serviços gerenciados adicionais.)

---

Notas finais e próximos passos recomendados

1. Verifique imediatamente as versões dos plugins em seu ambiente. Se você tiver instâncias executando “Primary Addon for Elementor” nas versões ≤ 1.6.0, agende atualizações para 1.6.5+ imediatamente.
2. Ative ou melhore as proteções do WAF agora — a correção virtual pode reduzir materialmente o risco enquanto você valida atualizações.
3. Faça backup primeiro. Use ambientes de teste para testar o plugin atualizado antes de implantar em produção.
4. Se você suspeitar de exploração, siga os passos de resposta a incidentes que descrevemos (contenha, preserve, investigue, erradique, recupere).
5. Adote um processo de gerenciamento de patches recorrente: teste atualizações em staging, agende atualizações contínuas para produção e use monitoramento para reduzir os tempos de detecção.
6. Considere subir para Padrão ou Pro se seu site for crítico para os negócios ou lidar com dados sensíveis de usuários — a automação e a correção virtual gerenciada reduzem o risco operacional.

---

Se você tiver dúvidas sobre a implementação das mitig ações acima, configurar as assinaturas WAF do WP-Firewall para proteger contra XSS refletidos, ou precisar de ajuda com resposta a incidentes, nossa equipe de segurança do WP-Firewall está disponível para ajudar. Comece com o plano Gratuito para garantir proteção básica imediatamente, depois avalie se Padrão ou Pro se adequam melhor às suas necessidades operacionais.

Fique seguro — a correção proativa e as defesas em camadas são a melhor maneira de manter seus sites WordPress seguros.