Nome do plugin	Yobazar
Tipo de vulnerabilidade	XSS (Cross-Site Scripting)
Número CVE	CVE-2026-25356
Urgência	Médio
Data de publicação do CVE	2026-03-22
URL de origem	CVE-2026-25356

Cross‑Site Scripting (XSS) refletido no tema Yobazar (< 1.6.7) — O que os proprietários de sites WordPress devem fazer hoje

Autor: Equipe de Segurança do Firewall WP
Data: 2026-03-22

Nota do WP‑Firewall: este aviso explica a vulnerabilidade de Cross‑Site Scripting (XSS) refletido recentemente divulgada que afeta o tema WordPress Yobazar nas versões anteriores a 1.6.7 (CVE‑2026‑25356). Descrevemos como o problema funciona, o risco real para seu site, como detectar a exploração e as etapas práticas que você pode tomar imediatamente — incluindo opções de patch virtual que fornecemos através do nosso firewall gerenciado — para proteger seus sites enquanto você atualiza.

Índice

• Resumo
• Por que isso é importante: o perfil de risco
• Visão geral técnica (o que é XSS refletido e como esse variante se comporta)
• Cenários de exploração — o que os atacantes podem fazer
• Indicadores de comprometimento e como procurar sinais de exploração
• Mitigações imediatas (recomendações de curto prazo)
• Patch virtual com um WAF: ideias e regras de exemplo
• Remediação a longo prazo e orientações de desenvolvimento seguro
• Orientações para hosts, agências e desenvolvedores
• Como o WP‑Firewall ajuda você imediatamente (incluindo um plano gratuito)
• Conclusão e lista de verificação

---

Resumo

Uma vulnerabilidade de Cross‑Site Scripting (XSS) refletido (CVE‑2026‑25356, CVSS 7.1) foi divulgada no tema WordPress Yobazar, afetando versões anteriores a 1.6.7. A vulnerabilidade permite que um atacante crie links maliciosos que refletem a entrada controlada pelo atacante de volta ao navegador da vítima sem a devida sanitização ou escape, permitindo a execução de JavaScript no contexto do site.

Como este é um XSS refletido, a exploração geralmente requer alguma forma de interação do usuário (por exemplo, convencer um editor, administrador ou visitante do site a clicar em um link malicioso). O impacto varia de ataques incômodos (anúncios, redirecionamento) a ações de alto risco (roubo de sessão, abuso de privilégios, manipulação de conteúdo) quando usuários privilegiados são alvos.

Se você estiver usando o tema Yobazar e não puder atualizar imediatamente, o patch virtual via um Firewall de Aplicação Web (WAF) ou medidas de endurecimento temporárias podem reduzir o risco até que você aplique a versão oficial corrigida 1.6.7.

---

Por que isso é importante: o perfil de risco

• Vulnerabilidade: XSS refletido no tema Yobazar, versões < 1.6.7
• CVE: CVE‑2026‑25356
• CVSS: 7.1 (Alto/Médio Superior dependendo do contexto)
• Privilégio necessário: nenhum para realizar a solicitação inicial (o ataque pode ser iniciado por um atacante não autenticado). No entanto, exploração de alto impacto bem-sucedida pode exigir que um usuário privilegiado interaja com um link ou página manipulada.
• Interação do usuário: necessário (a vítima deve abrir um link manipulado ou visitar uma página manipulada)
• Publicado: Março de 2026 (pesquisa creditada a Tran Nguyen Bao Khanh)

Por que os proprietários de sites devem agir agora:

• XSS refletido é fácil de transformar em arma com phishing ou engenharia social.
• Embora a vulnerabilidade não seja uma execução remota de código direta, ela pode ser encadeada em resultados mais severos (roubo de sessão de administrador, persistência, plantio de backdoors).
• Campanhas de exploração em massa frequentemente usam XSS refletido para atingir muitos sites rapidamente.

---

Visão técnica: o que é XSS refletido e como esse problema se comporta

O Cross-Site Scripting refletido ocorre quando uma aplicação web inclui entrada controlada pelo usuário (tipicamente parâmetros de consulta ou entradas de formulário) em sua saída HTML sem codificação ou escape suficientes. Em um XSS refletido:

1. O atacante cria um link contendo JavaScript malicioso (ou uma carga útil codificada).
2. A vítima clica no link e o servidor web retorna uma página que reflete o conteúdo malicioso de volta na página.
3. O navegador da vítima executa o script porque é servido da origem do site legítimo — permitindo ações do atacante que parecem vir do usuário e do domínio.

No caso do tema Yobazar (versões anteriores a 1.6.7), um caminho de saída inseguro permite que entradas específicas sejam injetadas em uma página e retornadas sem sanitização. A causa raiz é a falha em filtrar/escapar dados antes de renderizá-los em HTML (ou em um contexto de atributo/JS). Sem ver o código original do tema aqui, os culpados comuns incluem:

• Ecoar parâmetros de string de consulta diretamente no modelo da página.
• Usar valores não sanitizados em atributos HTML ou blocos de JavaScript inline.
• Falta de escape contextual (o escape para HTML difere do escape para strings ou atributos JavaScript).

Como o XSS refletido depende da entrada ecoada de volta à resposta, ele é frequentemente acionado via URLs ou formulários especialmente manipulados. Os atacantes podem hospedar armadilhas em outros domínios (páginas de phishing) ou enviar a URL manipulada por e-mail, chat ou comentário.

---

Cenários de exploração — o que os atacantes podem fazer

O impacto real do XSS refletido depende de quais usuários são alvos e os privilégios que eles possuem. Cadeias de ataque típicas incluem:

1. Incômodo para visitantes e desfiguração
   • Injetando elementos de UI maliciosos, pop-ups ou redirecionamentos forçados para páginas de terceiros.
   • Exibindo avisos ou anúncios falsos.
2. Roubo de sessão e tomada de conta (alto impacto se direcionado a administradores/editors)
   • Roubar cookies de sessão ou tokens de autenticação via acesso a document.cookie se os cookies não estiverem protegidos por flags HTTPOnly.
   • Usar cookies roubados para realizar ações como o usuário (editar conteúdo, criar contas de administrador).
3. Ações automáticas no estilo CSRF
   • Se o site não tiver controles anti-CSRF para ações sensíveis, scripts de atacantes podem emitir solicitações autenticadas em nome de um administrador logado (mudar senha, atualizar plugins/temas, modificar opções).
4. Pivô persistente (encadeamento)
   • Usar XSS refletido para executar ações que levam a mudanças persistentes (por exemplo, criar um usuário administrador, inserir código de backdoor em arquivos de tema/plugin ou adicionar tarefas agendadas maliciosas).
5. Phishing e coleta de credenciais
   • Mostrar um prompt de login falso que captura credenciais, ou redirecionar para uma página de captura de credenciais que se parece com o site.

Como o XSS refletido é servido da origem do site, as vítimas são mais propensas a confiar no conteúdo e cair em engenharia social. Os atacantes podem escalar tais ataques rapidamente automatizando a geração e distribuição de links.

---

Indicadores de comprometimento e como procurar sinais de exploração

O XSS refletido tende a ser barulhento, mas pode ser furtivo se um atacante limitar a execução ou direcionar usuários específicos. Aqui está como procurar:

1. Logs de acesso do servidor web
   • Search for requests containing unusual encoded payloads, e.g. URL‑encoded strings like %3Cscript%3E, %3Cimg%20onerror=, or javascript: URIs.
   • Exemplos de comandos grep (execute a partir do diretório raiz do seu site ou diretório de logs):
     • grep -iE "%3C(script|img|svg|iframe)|onerror|javascript:" access.log
     • grep -iE "(\<script|\<img|\<svg|\bonerror\b|document\.cookie|window\.location)" access.log
2. Logs de aplicação e logs de comentários/trackbacks
   • Procure por novo conteúdo que contenha fragmentos HTML estranhos ou cargas úteis codificadas.
   • Inspecione entradas da data de exploração suspeita.
3. Relatórios do navegador
   • Usuários relatando pop-ups inesperados, redirecionamentos ou conteúdo incomum no site.
4. Atividade administrativa incomum
   • Novas contas de administrador criadas inesperadamente, alterações em arquivos de tema/plugin ou postagens editadas sem autorização.
5. Telemetria de rede / logs do WAF
   • Solicitações bloqueadas repetidamente com tags de script ou valores de parâmetros suspeitos.
   • Solicitações contendo strings de consulta longas com caracteres codificados.
6. Mudanças no sistema de arquivos
   • Novos arquivos PHP em wp-content, horários de modificação inesperados para arquivos de tema.

Consultas de pesquisa de amostra para equipes de hosts e segurança

• Find requests that include %3Cscript (URL‑encoded “<script”):
  • zgrep -i "%3Cscript" /var/log/nginx/*gz | less
• Procure referenciadores e agentes de usuário suspeitos:
  • awk '{print $1,$6,$7,$12}' access.log | grep -iE "curl|nikto|sqlmap|python"
• Encontre páginas de resposta que ecoaram parâmetros de consulta (requer logs em nível de aplicativo ou logs de proxy)

Observação: Encontrar uma exploração XSS refletida em logs de servidor pode ser complicado porque muitos payloads são URL‑codificados e podem conter ofuscação. Concentre-se em anomalias correlacionadas com relatórios de usuários ou atividade administrativa.

---

Mitigações imediatas (o que fazer agora)

Se você estiver executando versões do tema Yobazar anteriores a 1.6.7, faça o seguinte imediatamente:

1. Atualize o tema para 1.6.7 (correção recomendada)
   • Verifique Aparência → Temas no WP Admin para a versão ativa.
   • Ou inspecione wp-content/themes/yobazar/style.css cabeçalho para confirmar a versão.
   • Aplique a atualização do tema a partir da fonte oficial (ThemeForest / distribuição do autor) ou substitua o tema por uma cópia corrigida.
2. Se não for possível atualizar imediatamente, aplique medidas paliativas temporárias:
   • Desative temporariamente o tema Yobazar e mude para um tema padrão e suportado até que você possa atualizar e testar.
   • Use um WAF para bloquear solicitações suspeitas (veja a seção de patch virtual abaixo).
   • Force o logout de todos os usuários com privilégios elevados e altere as senhas das contas de administrador.
   • Certifique-se de que os cookies sejam configurados com as flags HTTPOnly e Secure para reduzir o roubo via documento.cookie.
   • Ative a autenticação de dois fatores (2FA) para todos os administradores.
3. Remova qualquer conteúdo suspeito e escaneie em busca de malware:
   • Execute um scanner de malware respeitável para identificar scripts injetados ou arquivos modificados.
   • Inspecione os arquivos do tema em busca de alterações inesperadas; restaure cópias limpas a partir de backups.
4. Audite usuários e permissões:
   • Análise Usuários wp e wp_usermeta para novas contas ou escalonamentos de capacidade.
   • Verifique as sessões recentes de usuários e revogue sessões antigas para usuários administradores.
5. Monitore logs e alertas:
   • Aumente o registro em seu WAF, servidor web e WordPress para detectar tentativas de links de exploração e visitantes acessando-os.
6. Comunique-se com cuidado:
   • Se você suspeitar que usuários finais ou clientes foram afetados, prepare uma notificação controlada com etapas de remediação e redefinições de senha recomendadas. Evite pânico; forneça etapas claras a seguir.

Atualizar é a correção correta — mitigação temporária reduz o risco, mas não substitui a aplicação do patch.

---

Patch virtual com um WAF: ideias e regras de exemplo

Um Firewall de Aplicação Web (WAF) corretamente configurado pode reduzir a exposição bloqueando cargas maliciosas antes que elas alcancem o código vulnerável. Isso é especialmente valioso quando você não pode atualizar imediatamente o tema em muitos sites.

Diretrizes gerais para patch virtual:

• Bloqueie ou saneie solicitações que contenham padrões suspeitos comumente usados em cargas XSS.
• Direcione regras para os pontos finais ou parâmetros vulneráveis sempre que possível (menos falsos positivos).
• Use uma abordagem em camadas: bloqueio de padrões + detecção de anomalias + limites de taxa.

Exemplos de padrões de regras (conceitual; adapte à sintaxe do seu WAF):

1. Bloquear solicitações com tags de script em parâmetros de consulta
   Match: Request URI or any parameter value containing “<script” (case‑insensitive), URL‑encoded equivalents like %3Cscript%3E, or encoded event handlers (onerror, onmouseover).
   Pseudocódigo:
   If request_uri ~ /(\%3C|\<)\s*script/i OR request_body ~ /on(error|load|mouseover|click)=/i then block.
2. Bloquear URIs javascript: suspeitas
   Se qualquer valor de parâmetro contiver “javascript:” (incluindo codificado), bloquear.
3. Bloquear marcadores típicos de carga útil XSS
   Exemplos: document.cookie, document.location, window.location, innerHTML com colchetes angulares em parâmetros — bloquear ou desafiar.
4. Limitar a taxa de padrões suspeitos
   Se um único IP acionar vários padrões bloqueados dentro de uma janela de tempo curta, aplicar lista negra temporária de IP.
5. Aplicar segurança positiva para endpoints
   Sempre que possível, permitir apenas caracteres seguros conhecidos para parâmetros que devem ser alfanuméricos ou numéricos (por exemplo, IDs de postagens, slugs) e negar solicitações que violem o padrão esperado.

Exemplo concreto: regra ModSecurity (conceitual)
(Este é um exemplo ilustrativo; implantações em produção devem ser testadas para evitar falsos positivos.)

SecRule REQUEST_URI|ARGS "(?i:(?:%3Cscript|<script|javascript:|document\.cookie|onerror=|onload=))" \
  "id:1009001,phase:2,deny,status:403,log,msg:'Blocking potential reflected XSS payload - generic rule',severity:2"

Notas:

• A regra acima procura assinaturas comuns de XSS na URI e nos parâmetros e nega a solicitação.
• Ajuste para o seu ambiente: evite correspondências excessivamente amplas (por exemplo, algum conteúdo legítimo pode incluir “javascript” em forma codificada por razões válidas).

Exemplo Nginx (conceitual)
Usando NGINX com lua ou um módulo de validação de solicitação, você poderia descartar solicitações que incluam tags de script codificadas em strings de consulta:

if ($query_string ~* "(%3C|<)\s*script") {
    return 403;
}

Importante: Teste qualquer regra primeiro no modo de detecção/log (ou seja, registre, mas não bloqueie), revise para falsos positivos e, em seguida, mude para bloqueio.

Regras contextuais são melhores: se você souber qual página ou parâmetro de modelo é vulnerável no tema Yobazar, restrinja o bloqueio a esse caminho.

Por que a virtualização de WAF é valiosa

• Cobertura protetora instantânea em muitos sites.
• Previne tentativas de exploração em massa enquanto você planeja atualizações.
• Reduz a probabilidade de ataques subsequentes (roubo de credenciais, desfiguração).

Limitações do patch virtual

• WAFs podem ser contornados por ofuscação inteligente ou novas variantes de payload.
• O patch virtual é uma mitigação, não um substituto para correções de código.
• Regras excessivamente agressivas causam falsos positivos e podem quebrar o comportamento legítimo do site.

---

Remediação a longo prazo e práticas de desenvolvimento seguro

Para autores de temas e equipes de desenvolvimento, uma correção permanente é necessária: sane e escape toda entrada controlada pelo usuário no contexto correto. Princípios-chave:

1. Escapando contextual
   • Escape para o corpo HTML: use esc_html() em PHP.
   • Escape para atributos HTML: use esc_attr().
   • Escape para o contexto JavaScript: use wp_json_encode() onde apropriado e valide a entrada.
   • Quando a saída vai para manipuladores de eventos inline ou blocos de script, certifique-se de que você está codificando para strings JavaScript e evitando injeção direta.
2. Validação de entrada
   • Valide os dados recebidos para formatos esperados (IDs numéricos, slugs, enumerações conhecidas).
   • Rejeite ou normalize estritamente caracteres inesperados.
3. Evite JavaScript inline que concatena dados do usuário
   • Prefira atributos de dados ou JSON gerado com segurança com wp_localize_script / wp_add_inline_script com escape adequado.
4. Use APIs do WordPress
   • Usar esc_url_raw(), sanitizar_campo_de_texto(), wp_kses_post() quando apropriado.
   • Prefira declarações preparadas para operações de DB; evite ecoar conteúdo não sanitizado.
5. Teste de segurança automatizado
   • Adicione testes unitários e análise dinâmica automatizada (SAST/DAST) para padrões comuns de XSS antes do lançamento.
   • Inclua verificações de segurança em pipelines de CI.
6. Padrões seguros e menor privilégio
   • Minimize os papéis que podem criar conteúdo que é refletido de volta nas páginas.
   • Limite a edição de arquivos através do painel (DESABILITAR_EDIÇÃO_DE_ARQUIVO).
   • Eduque os administradores sobre os riscos de phishing — muitos ataques XSS refletidos dependem de um usuário clicar em um URL elaborado.

---

Orientações para hosts, agências e desenvolvedores

Se você gerencia vários sites ou hospeda sites de clientes, tome estas medidas operacionais:

1. Inventário
   • Identifique todos os sites que executam Yobazar e documente suas versões.
   • Use varreduras remotas ou plataformas de gerenciamento para coletar versões de temas em grande escala.
2. Priorizar
   • Priorize a atualização de sites de alto risco (alto tráfego, e-commerce, sites com múltiplos administradores).
3. Plano de implementação
   • Teste a atualização em ambientes de staging primeiro para garantir que as personalizações sejam preservadas.
   • Mantenha backups e um plano de reversão.
4. Comunicar
   • Notifique os clientes sobre o problema e o plano de remediação.
   • Forneça orientações para a equipe e proprietários de sites para evitar clicar em links não confiáveis.
5. Monitoramento e detecção
   • Ative o registro aprimorado e configure alertas para bloqueios do WAF e ações administrativas anormais.
   • Escaneie periodicamente em busca de usuários administrativos não autorizados ou arquivos modificados.
6. Use um WAF gerenciado onde apropriado
   • Serviços de WAF gerenciados fornecem patches virtuais imediatos e conjuntos de regras ajustados para vulnerabilidades comuns de CMS. Eles podem reduzir drasticamente a janela de exposição.

---

Como o WP‑Firewall ajuda você imediatamente.

Título: Proteja seu site agora — Comece com o plano gratuito WP‑Firewall

Se você gerencia sites WordPress e precisa de proteção rápida e confiável enquanto atualiza temas e plugins, o WP‑Firewall oferece um plano Básico gratuito projetado para cobertura imediata e essencial. Com o plano WP‑Firewall Básico (Gratuito) você obtém:

• Proteção de firewall gerenciada que bloqueia ataques web comuns
• Largura de banda ilimitada através da camada de proteção
• Regras de Firewall de Aplicação Web (WAF) que mitigam os riscos do OWASP Top 10 (incluindo padrões XSS)
• Verificação de malware para ameaças conhecidas
• Atualizações contínuas das regras de mitigação para que novas explorações divulgadas sejam cobertas rapidamente

Se você deseja proteção instantânea enquanto coordena atualizações de temas, inscreva-se no WP‑Firewall Básico (Gratuito) aqui:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Para organizações que desejam remoção automatizada e mais controle, nossos planos pagos adicionam remoção automática de malware, controle de lista negra/branca de IP, relatórios de segurança mensais, correção virtual automática de vulnerabilidades e serviços de suporte premium.

---

Listas de verificação e comandos práticos

Auditoria rápida: confirme a versão do tema

• Do WP Admin: Aparência → Temas → Yobazar → verifique o campo de versão.
• Do shell do servidor (substitua a pasta do tema se for diferente):

  grep -i "Versão:" wp-content/themes/yobazar/style.css

Pesquise logs por tentativas de exploração (exemplos)

• Apache/Nginx:

  zgrep -i "%3Cscript" /var/log/nginx/access.log* | less
  zgrep -i "document.cookie" /var/log/nginx/access.log* | less
    

• Registros de depuração do WordPress:

  tail -n 200 wp-content/debug.log

Verifique arquivos de tema modificados

• Encontre arquivos alterados recentemente no diretório do tema:

  find wp-content/themes/yobazar -type f -mtime -30 -ls

• Compare com uma cópia limpa do tema para identificar PHP/JS injetado.

Passos rápidos de endurecimento

• Ative cookies HTTPOnly e Secure (definidos via wp_config ou configuração do servidor).
• Force redefinições de senha para administradores se eventos suspeitos forem detectados.
• Desative a edição de arquivos em wp-config.php:

  define( 'DISALLOW_FILE_EDIT', true );

Trecho de cabeçalho CSP recomendado (restrinja JS inline onde for viável)

• Content‑Security‑Policy: default‑src 'self'; script‑src 'self' 'nonce-'; object-src 'none'; base-uri 'self';
• Nota: A implementação do CSP requer testes para evitar quebrar scripts legítimos do site.

---

O que esperar após a mitigação

• Após atualizar para Yobazar 1.6.7 e aplicar as etapas de endurecimento recomendadas, você deve:
  • Ver uma redução nos bloqueios do WAF para os padrões XSS relevantes.
  • Ter menos solicitações suspeitas chegando ao código da aplicação.
  • Estar em uma posição muito mais forte se os atacantes tentarem explorar vulnerabilidades relacionadas.
• Continue monitorando sinais de comprometimento por várias semanas — os atacantes frequentemente tentam ações de acompanhamento.

---

Divulgação responsável e a necessidade contínua de vigilância

A segurança não é uma tarefa única. Novas vulnerabilidades são descobertas continuamente em temas, plugins e no núcleo do WordPress. A divulgação deste XSS refletido no Yobazar é um lembrete:

• Mantenha sempre temas e plugins atualizados.
• Aplique defesa em profundidade: corrija o código, imponha o menor privilégio, use um WAF e mantenha backups.
• Invista em auditorias de segurança regulares e treinamento para administradores do site para reduzir o risco de engenharia social.

---

Conclusão — lista de verificação de ações imediatas

Se você usar o tema Yobazar:

1. Verifique a versão do tema. Se < 1.6.7, atualize imediatamente para 1.6.7.
2. Se não for possível atualizar imediatamente:
   • Mude temporariamente de tema ou aplique patches virtuais do WAF.
   • Force a redefinição de senhas de administrador e ative a 2FA.
   • Escaneie arquivos maliciosos e revise a atividade recente do administrador.
3. Configure o registro e monitoramento; revise os logs do WAF para padrões XSS bloqueados.
4. Fortaleça o WordPress (DESABILITAR_EDIÇÃO_DE_ARQUIVO, cookies seguros, CSP onde for prático).
5. Considere a proteção WAF gerenciada para reduzir a exposição enquanto você remedia em grande escala.

---

Sobre este aviso e sobre o WP‑Firewall

Este aviso foi preparado pela equipe de segurança do WP‑Firewall em resposta à divulgação pública da CVE‑2026‑25356 que impacta versões do tema Yobazar anteriores à 1.6.7. Nosso objetivo é ajudar os proprietários de sites WordPress a entender o risco, mitigar rapidamente a exposição e implementar correções de longo prazo.

WP‑Firewall é um provedor de segurança WordPress e serviço WAF gerenciado focado em mitigação rápida e orientação operacional prática. Se você precisar de ajuda para implantar proteções em muitos sites ou preferir uma abordagem gerenciada, nosso plano Básico gratuito oferece proteção WAF essencial e varredura de malware para reduzir riscos enquanto você atualiza.

Proteja seus sites agora:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Apêndice: Perguntas frequentes

Q: Isso é um bug de execução remota de código (RCE)?

A: Não — esta é uma vulnerabilidade de Cross‑Site Scripting. XSS por si só não executa diretamente código do lado do servidor, mas pode ser aproveitado para roubar sessões, realizar ações como usuários autenticados e encadear em compromissos mais severos.

Q: Os visitantes precisam estar logados para que a exploração funcione?

A: Não, a vulnerabilidade pode ser acionada por uma solicitação não autenticada (o atacante pode criar uma URL). Mas muitas das consequências mais sérias ocorrem quando a vítima que clica no link tem privilégios elevados (administrador/editor).

Q: Meu site usa cache/CDN. Estou seguro?

A: O cache e os CDNs podem reduzir o número de vezes que uma carga útil é refletida, mas não garantem proteção. Se o código vulnerável for renderizado em uma página em cache, um atacante ainda pode explorar cópias em cache que são servidas aos visitantes. Use regras WAF e atualize o tema.

Q: Devo excluir o tema Yobazar se não o uso?

A: Sim — remova quaisquer temas e plugins não utilizados da sua instalação. Mesmo temas inativos podem conter vulnerabilidades se acessíveis publicamente.

Q: Onde posso obter uma cópia limpa e corrigida do tema?

A: Obtenha a atualização pelo canal oficial de distribuição do tema (o autor do tema ou o marketplace de onde foi comprado). Sempre verifique a fonte.

---

Se você precisar de assistência com qualquer uma das etapas acima — testando, implantando regras do WAF ou realizando uma revisão forense em nível de site — o WP‑Firewall pode ajudar.