Nome do plugin	Construtor de Gráficos SQL
Tipo de vulnerabilidade	Injeção de SQL
Número CVE	CVE-2026-4079
Urgência	Alto
Data de publicação do CVE	2026-04-08
URL de origem	CVE-2026-4079

Urgente: Injeção SQL não autenticada no Construtor de Gráficos SQL — O que os proprietários de sites WordPress devem fazer agora

Em 8 de abril de 2026, uma vulnerabilidade crítica foi publicada para o plugin WordPress Construtor de Gráficos SQL (versões anteriores a 2.3.8). Essa vulnerabilidade, rastreada como CVE-2026-4079, é uma injeção SQL não autenticada (SQLi) com um CVSS próximo a 9.3 e classificada como alta prioridade. Como o bug é explorável sem autenticação, ele permite que atacantes na internet pública interajam diretamente com o banco de dados do site — potencialmente lendo dados sensíveis, modificando conteúdo, criando usuários administrativos ou se aprofundando mais no ambiente de hospedagem.

Sabemos por divulgação pública e relatórios de pesquisadores que o problema foi relatado de forma responsável e corrigido na versão 2.3.8. No entanto, haverá muitas instalações ainda executando versões mais antigas e vulneráveis. Neste post, explicamos, em linguagem humana simples e com detalhes técnicos práticos:

• Por que essa vulnerabilidade específica é perigosa
• Como os atacantes normalmente exploram a injeção SQL não autenticada
• Indicadores práticos de comprometimento (IoCs) e técnicas de detecção
• Mitigações de curto prazo que você pode aplicar imediatamente (incluindo correção virtual com um WAF)
• Passos de remediação e fortalecimento de médio/longo prazo
• Como o plano de proteção gratuito do WP‑Firewall ajuda a proteger sites imediatamente

Este guia é escrito por nossos engenheiros de segurança do WP‑Firewall e destinado a proprietários de sites WordPress, desenvolvedores e provedores de hospedagem. É acionável e evita jargões desnecessários.

---

Resumo rápido (O que você deve fazer nas próximas 24 horas)

1. Verifique se você tem o plugin Construtor de Gráficos SQL instalado. Se sim, verifique a versão instalada.
2. Se sua versão for anterior a 2.3.8, atualize o plugin para 2.3.8 ou posterior imediatamente.
3. Se você não puder atualizar imediatamente, coloque o plugin offline (desative-o) e aplique um patch virtual / regra WAF para bloquear padrões de SQLi contra os endpoints do plugin.
4. Revise os logs em busca de atividade suspeita (grandes SELECTs, tentativas de UNION, ataques de sono baseados em tempo) e inspecione o banco de dados em busca de alterações não autorizadas.
5. Altere as credenciais do banco de dados se detectar comprometimento; troque as senhas de administrador e audite as contas de usuário.
6. Inscreva-se para proteção gerenciada ou ative uma solução eficaz de WAF/correção virtual enquanto você corrige.

Se você gerencia muitos sites, aplique essas etapas em toda a sua frota — a SQLi não autenticada é o tipo de bug que é explorado em massa rapidamente.

---

Por que a injeção SQL não autenticada é crítica

A maioria dos problemas de plugins do WordPress é limitada por autenticação ou privilégios. Um SQLi não autenticado contorna completamente essa limitação. Os atacantes podem enviar solicitações HTTP manipuladas para o endpoint vulnerável e fazer com que a aplicação web execute consultas SQL manipuladas em seu banco de dados.

Os impactos potenciais incluem:

• Exfiltração de dados: acesso a postagens, contas de usuário, endereços de e-mail, senhas hash, dados de pedidos ou outros registros sensíveis.
• Manipulação de dados: alteração de conteúdo, totais de pedidos ou configurações.
• Roubo de credenciais: se segredos armazenados ou chaves de API estiverem no banco de dados.
• Tomada de conta: criação ou escalonamento de um usuário administrador no WordPress.
• Movimento lateral: uso de credenciais vazadas para acessar outros serviços (FTP, painel de controle de hospedagem).
• Comprometimento do site: inserção de cargas maliciosas, backdoors ou obtenção de acesso persistente.

Como a vulnerabilidade não é autenticada, a superfície de ataque inclui toda a internet e pode ser escaneada por bots automatizados. Campanhas de escaneamento em massa e exploração seguem a divulgação pública rapidamente — muitas vezes em questão de horas a dias.

---

O que sabemos sobre essa vulnerabilidade (visão técnica)

Avisos públicos indicam:

• Uma injeção SQL existe em versões anteriores à 2.3.8 do plugin SQL Chart Builder.
• O caminho de código vulnerável pode ser acionado sem autenticação (não autenticado).
• O plugin usa diretamente a entrada fornecida pelo usuário em uma consulta de banco de dados sem sanitização, parametrização ou escape suficientes.
• A vulnerabilidade foi corrigida na versão 2.3.8. CVE atribuído: CVE-2026-4079.

Embora não iremos reimprimir o código de exploração aqui, padrões típicos que possibilitam esse tipo de ataque incluem:

• Concatenção direta de parâmetros de solicitação em declarações SQL.
• SQL executado a partir de endpoints públicos AJAX ou REST.
• Falta de declarações preparadas (PDO com parâmetros vinculados ou $wpdb->prepare()).
• Nenhuma validação de entrada em nível de aplicação limitando identificadores permitidos (nomes de tabelas, nomes de colunas) ou apenas confiando na entrada do usuário.

Como o parâmetro vulnerável exato e o endpoint variam por versão e lançamento do plugin, você deve assumir que os endpoints de plugins voltados para o público são vetores de ataque.

---

Técnicas típicas de exploração que os atacantes usarão

Os atacantes tentam uma variedade de técnicas de SQLi; padrões comuns a serem observados incluem:

• SQLi clássico baseado em booleano:
  • cargas úteis como: ‘ OU ‘1’=’1′ —
• Exfiltração baseada em UNION:
  • solicitações contendo “UNION SELECT” para mesclar linhas de resultados controladas pelo atacante com resultados da aplicação.
• Injeção baseada em tempo (cega):
  • cargas úteis invocando funções de banco de dados que atrasam a resposta (por exemplo, SLEEP(5)) para inferir condições verdadeiras/falsas.
• Injeção baseada em erro:
  • tentando provocar erros de SQL que vazam dados em mensagens de erro.

Exemplos de cargas úteis que os atacantes podem usar (apenas para fins de detecção):

• ‘ OU 1=1–
• ‘ UNION ALL SELECT NULL,username,password,email FROM wp_users–
• ‘ E (SELECT 1 FROM (SELECT COUNT(*),CONCAT((SELECT database()),0x3a,FLOOR(RAND()*2))x FROM information_schema.tables GROUP BY x)y)–
• ‘ OU (SELECT sleep(5))–

Procure por solicitações com palavras-chave SQL e pontuação suspeita em parâmetros que normalmente deveriam conter apenas valores seguros, como IDs de tabela ou deslocamentos numéricos.

---

Indicadores de Compromisso (IoCs) e o que procurar

Ao investigar uma possível exploração, pesquise logs e o banco de dados pelos seguintes itens:

Logs do servidor web e de acesso

• Solicitações contendo palavras-chave SQL suspeitas em strings de consulta ou corpos de POST: UNION, SELECT, INFORMATION_SCHEMA, SLEEP, LOAD_FILE, benchmark, concat, substr.
• Solicitações para endpoints relacionados a plugins (AJAX ou REST) de endereços IP incomuns ou solicitações repetidas rápidas de muitos IPs.
• Solicitações que produzem tempos de resposta anômalos (injeção baseada em tempo) ou erros HTTP 500.

Logs do WordPress e da aplicação

• Criação inesperada de usuários administrativos ou alterações nos papéis dos usuários.
• Arquivos novos ou modificados em wp-content/uploads, wp-content/plugins ou no diretório do tema.
• Tarefas agendadas inesperadas (entradas wp-cron).

Banco de dados

• Novos usuários de banco de dados ou alterações nos e-mails/senhas dos usuários.
• Entradas estranhas em tabelas que o plugin normalmente escreve.
• Evidências de dados extraídos em tabelas ou marcadores de exfiltração inseridos.

Sistema de arquivos

• Arquivos PHP adicionados com nomes aleatórios, shells web ou código ofuscado.
• Alterações em wp-config.php ou outros arquivos principais.

Se você encontrar qualquer um dos itens acima, trate-o como uma possível violação e escale para uma resposta completa a incidentes (veja a seção de resposta abaixo).

---

Como detectar se seu site é vulnerável

1. Verifique a versão do plugin:
   • Do painel do WordPress: Plugins → Plugins Instalados → SQL Chart Builder — certifique-se de que é 2.3.8 ou superior.
   • Ou use WP-CLI:
     wp plugin list --format=table | grep sql-chart-builder
2. Escaneie o site:
   • Execute scanners de vulnerabilidade automatizados (preferencialmente aqueles que não executam testes destrutivos) para procurar assinaturas conhecidas.
   • Use um scanner de aplicação web ou logs de WAF para procurar os indicadores acima.
3. Revise os logs:
   • Verifique os logs de acesso (Apache/nginx), logs de firewall de aplicação web e logs específicos do plugin em busca de solicitações duvidosas.
4. Teste em um ambiente de staging seguro:
   • Se você precisar validar o comportamento, realize testes apenas em uma cópia de staging isolada do site — não execute tentativas de exploração contra a produção.

Se o plugin existir e for mais antigo que 2.3.8, trate-o como vulnerável até ser atualizado ou corrigido virtualmente.

---

Opções de mitigação imediata (se você não puder atualizar imediatamente)

Se você não puder atualizar o plugin imediatamente — por exemplo, devido a testes de compatibilidade ou implantação em etapas — aplique medidas defensivas agora.

Mitigações de curto prazo (ordenadas por velocidade e eficácia):

1. Desativar o plugin
   • Esta é a mitigação imediata mais simples: desative o plugin no admin do WordPress ou use WP-CLI:
     wp plugin desativar sql-chart-builder
   • Se o plugin for necessário para a funcionalidade do site, considere colocar o site em modo de manutenção até que seja corrigido.
2. Bloquear endpoints de plugins com regras de servidor
   • Se o plugin expuser um endpoint conhecido (por exemplo, /wp-admin/admin-ajax.php?action=sql_chart_builder_fetch), bloqueie temporariamente o acesso a esse endpoint no nível do servidor web usando .htaccess, regras de localização do nginx ou firewall do host, restringindo apenas a IPs confiáveis.
3. Patch virtual com uma regra WAF
   • Aplique regras para detectar e bloquear padrões de injeção SQL contra o site globalmente e (se possível) especificamente direcionando os endpoints do plugin. Um WAF bem configurado pode prevenir muitas tentativas de exploração até que você atualize.
4. Limitar privilégios de banco de dados
   • Se viável, garanta que o usuário do DB do WordPress tenha o menor privilégio: apenas as permissões necessárias para operação normal (SELECT, INSERT, UPDATE, DELETE em tabelas de aplicação). Evite conceder privilégios de superusuário.
5. Fortaleça o acesso
   • Limitar a taxa de solicitações para os endpoints do plugin.
   • Implementar limitação baseada em IP e/ou permitir endpoints de admin na lista de permissões.

Importante: Estas são mitigações temporárias — atualize para o plugin corrigido assim que puder.

---

Exemplos práticos de WAF/patching virtual

Abaixo estão conceitos de regras de WAF que você pode implementar no ModSecurity (Genérico), nginx ou dentro do mecanismo de regras do WP‑Firewall. Estes são apenas exemplos e precisarão ser adaptados ao seu ambiente.

Exemplo de regra ModSecurity (v3) para bloquear cargas úteis comuns de SQLi (simplificado):

SecRule REQUEST_URI|ARGS|REQUEST_HEADERS "@rx (?i:(\bunion\b.*\bselect\b|select\b.+\bfrom\b|information_schema|benchmark\(|sleep\(|load_file\(|concat\(|/**/|\bor\b.+\=.+\b1\b))" \"

Exemplo de regra nginx (com ngx_http_rewrite_module):

location / {

Exemplo de regra estilo WP‑Firewall (pseudo-sintaxe usada por muitos painéis WAF):

• Nome da regra: “SQLi — bloquear palavras-chave SQL suspeitas em endpoints de plugin”
• Condições:
  • Se o caminho da solicitação contiver “sql-chart” OU “chart-builder” OU admin-ajax.php?action=sql_chart_builder_* (ajuste para os endpoints de plugin reais)
  • E o corpo da solicitação OU a string de consulta corresponder à regex: (?i)(união\s+selecionar|information_schema|dormir\(|benchmark\(|carregar_arquivo\(|concat\(|\bOU\b\s+1=1)
• Ação: Bloquear e registrar; retornar 403/429

Notas:

• Evite padrões excessivamente amplos que bloqueiem tráfego legítimo. Ajuste falsos positivos excluindo parâmetros conhecidos como seguros (IDs que devem ser inteiros) e usando listas brancas quando aplicável.
• Combine regras WAF com limitação de taxa. Muitas tentativas de exploração são automatizadas e serão muito barulhentas.

Se você usar WP‑Firewall, nossas regras gerenciadas podem ser ativadas para proteger endpoints de plugin conhecidos e cargas úteis SQLi comuns imediatamente. Essas regras são ajustadas para minimizar falsos positivos para o uso típico do WordPress enquanto interrompem técnicas de exploração conhecidas.

---

Lista de verificação de remediação passo a passo (ordem recomendada)

1. Inventário
   • Encontre todos os sites com o plugin: pesquise sua rede por “sql-chart-builder” em listas de plugins e no sistema de arquivos.
   • Registre as versões.
2. Corrigir
   • Atualize o plugin para v2.3.8 ou posterior:
     • Do WP Admin: Plugins → Atualizar
     • Ou WP-CLI: wp plugin atualizar sql-chart-builder
   • Teste as atualizações em staging quando possível; aplique na produção após verificação.
3. Patch virtual (se você não puder atualizar imediatamente)
   • Aplique regra(s) WAF direcionada(s) bloqueando padrões SQLi para endpoints de plugin.
   • Desative temporariamente o plugin até que um patch seja aplicado se não for essencial.
4. Escanear e auditar
   • Execute uma verificação de malware em arquivos e no banco de dados.
   • Procure novos usuários administrativos e mudanças inesperadas de função.
   • Revise modificações recentes no banco de dados e logs.
5. Rotacione segredos
   • Se houver suspeita de comprometimento, gire as senhas do DB, chaves da API e senhas de administrador do WordPress (force a redefinição de senha para todos os administradores).
   • Gire as credenciais usadas por outros sistemas se a mesma senha foi reutilizada.
6. Restaure se necessário
   • Se você detectar mudanças que indiquem comprometimento e tiver backups limpos, restaure a partir de um backup feito antes do comprometimento e, em seguida, aplique patches e endureça antes de reconectar à internet.
7. Monitoramento contínuo
   • Ative a proteção e o registro contínuos do WAF.
   • Fique atento a picos em solicitações bloqueadas para endpoints de plugins (indicativo de varreduras/explorações em massa).
8. Análise pós-incidente
   • Documente a linha do tempo, a causa raiz e as etapas tomadas.
   • Melhore a gestão de patches e os processos de resposta a vulnerabilidades para reduzir o tempo de aplicação de patches.

---

Investigação e resposta a incidentes: o que fazer se você foi explorado.

Se você encontrar evidências de que uma exploração ocorreu, trate isso como um incidente sério:

1. Isolar:
   • Desative o site ou coloque-o em modo de manutenção.
   • Se parte de um ambiente hospedado, isole o servidor ou contêiner, se viável.
2. Preserve os logs:
   • Exporte logs do servidor web, WAF, aplicação e banco de dados. Preserve cópias para análise forense.
3. Análise forense:
   • Identifique o ponto de entrada, os payloads usados e a linha do tempo dos eventos.
   • Identifique shells web, mudanças no webroot, novos trabalhos agendados ou outros mecanismos de persistência.
4. Remediar:
   • Remova arquivos maliciosos; considere uma reconstrução completa dos arquivos do site a partir de uma fonte confiável (por exemplo, reinstale o núcleo do WordPress e plugins a partir de pacotes oficiais).
   • Limpe ou restaure o banco de dados: se a integridade dos dados estiver comprometida, restaure a partir de um backup conhecido como bom.
   • Gire as credenciais (DB, hospedagem, FTP, chaves da API, administrador do WordPress).
5. Endurecimento e supervisão:
   • Aplique todas as atualizações de plugins e recomendações de endurecimento.
   • Certifique-se de que o WAF e os scanners de malware estão ativados.
   • Monitore vetores de ataque recorrentes.
6. Considere suporte profissional:
   • Se a violação for severa (exfiltração de dados, backdoor persistente), envolva respondentes de incidentes experientes ou a equipe de segurança do seu provedor de hospedagem.

---

Recomendações de endurecimento para reduzir o risco futuro

• Mantenha tudo atualizado: núcleo do WordPress, temas e plugins. Teste atualizações em staging, mas priorize patches de segurança críticos.
• Princípio do menor privilégio para acesso ao banco de dados e servidor.
• Use senhas fortes e únicas e ative a autenticação de dois fatores para usuários administrativos.
• Limite o acesso a endpoints administrativos (lista de permissões de IP para wp-admin e endpoints de plugins sensíveis, quando possível).
• Ative um WAF em nível de host ou aplicativo para bloquear vulnerabilidades web comuns.
• Backups regulares armazenados fora do site com versionamento.
• Scans regulares para malware e monitoramento de integridade de arquivos.
• Implemente um processo de gerenciamento de vulnerabilidades para plugins: inscreva-se em feeds de segurança de alta qualidade ou escaneamento automatizado de vulnerabilidades para receber notificações rápidas.

---

Exemplos práticos: comandos e verificações úteis

Verifique a versão do plugin com WP-CLI:

wp plugin list --status=active --format=json | jq -r '.[] | select(.name=="sql-chart-builder") | .version'

Desative o plugin:

wp plugin desativar sql-chart-builder

Atualize o plugin:

wp plugin atualizar sql-chart-builder

Procure arquivos suspeitos (exemplo):

find wp-content -type f -iname "*.php" -mtime -14 -print

Verifique usuários administrativos criados recentemente (SQL):

SELECT ID, user_login, user_email, user_registered FROM wp_users ORDER BY user_registered DESC LIMIT 20;

Pesquise logs de acesso por palavras-chave SQL:

grep -i -E "union.*select|information_schema|sleep\(|benchmark\(" /var/log/nginx/access.log

---

Como o WP‑Firewall protege você (e o que você pode fazer agora)

No WP‑Firewall, focamos em três camadas de defesa rápidas e eficazes que você pode ativar imediatamente:

• Regras WAF gerenciadas e patching virtual: nosso conjunto de regras inclui bloqueio direcionado para vulnerabilidades publicadas e cargas úteis comuns de injeção SQL, cuidadosamente ajustadas para reduzir falsos positivos em ambientes WordPress.
• Escaneamento de malware: varreduras contínuas do seu sistema de arquivos e banco de dados detectam padrões de malware conhecidos e modificações inesperadas.
• Mitigação do OWASP Top 10: proteções automatizadas contra os ataques mais comuns a aplicações web, incluindo injeção, autenticação quebrada e configuração insegura.

Se você estiver usando um plugin vulnerável e não puder atualizar imediatamente, ativar as regras gerenciadas do WP‑Firewall oferece proteção imediata que bloqueia as tentativas de exploração enquanto você planeja e realiza as atualizações.

Monitoramos continuamente divulgações públicas e publicamos regras de mitigação para novas vulnerabilidades, para que nossos clientes estejam protegidos mesmo quando atualizações de código imediatas não são possíveis.

---

Sugestões práticas de regras WAF para ajustar para WordPress

• Bloquear solicitações com múltiplas palavras-chave SQL em um parâmetro (por exemplo, tanto UNION quanto SELECT).
• Bloquear cargas úteis com substrings comuns de SQLi (information_schema, concat, load_file).
• Limitar a taxa de tráfego suspeito para endpoints de plugins, especialmente de IPs novos/desconhecidos.
• Alertar sobre solicitações que acionam correspondências de regras em vez de apenas bloquear — a detecção precoce ajuda a investigar.
• Permitir listas de clientes API seguros e IPs de administradores para endpoints que devem permanecer abertos.

Lembre-se: as regras WAF são uma mitigação, não um substituto para a aplicação de patches do fornecedor. Elas compram tempo e reduzem o risco durante sua janela de resposta.

---

Perguntas frequentes

Q: Se eu atualizar para 2.3.8, estou seguro?
A: Atualizar para 2.3.8 (ou posterior) deve corrigir essa vulnerabilidade específica. Após a atualização, confirme se não há sinais de comprometimento anterior. Aplique o patch, depois escaneie e monitore.

Q: E se meu site foi explorado antes de eu aplicar o patch?
A: Siga os passos de resposta a incidentes: isolar, preservar logs, escanear, restaurar de backups limpos, rotacionar credenciais e considerar ajuda profissional. Aplique endurecimento e controles preventivos.

Q: Um WAF vai quebrar meu site?
A: Um WAF bem ajustado não deve quebrar a função normal do site. Comece com o modo de monitoramento / alerta para detectar falsos positivos, depois mova regras selecionadas para bloqueio. As regras do WP‑Firewall são ajustadas para WordPress para minimizar falsos positivos.

---

Exemplo do mundo real (hipotético) — aprendendo com uma resposta rápida

Considere um site hipotético executando uma versão mais antiga do plugin. Após a divulgação pública, os atacantes começam a escanear em massa. Os logs do WAF mostram solicitações repetidas a um endpoint AJAX do plugin com cargas úteis contendo “union select”. O site não havia atualizado o plugin, e uma tentativa limitada de exfiltração de dados teve sucesso. O proprietário do site tomou as seguintes medidas em poucas horas:

1. Habilitou uma regra WAF direcionada bloqueando o endpoint do plugin e cargas úteis de SQLi.
2. Desativou o plugin via WP‑CLI.
3. Atualizou o plugin para v2.3.8 em staging, testou e, em seguida, atualizou a produção.
4. Escaneou em busca de backdoors e anomalias no banco de dados; encontrou uma conta de administrador suspeita e um webshell; removeu ambos e restaurou arquivos de um backup limpo.
5. Rotacionou a senha do DB e as credenciais de administrador.
6. Inscreveu-se para proteção contínua do WAF e agendou varreduras regulares.

O site evitou uma comprometimento mais profundo porque o proprietário agiu rapidamente e usou defesas em camadas.

---

Quer ajuda para proteger seu site agora? (Inscreva-se para WP‑Firewall Basic)

Obtenha proteção instantânea e não intrusiva com WP‑Firewall Basic (Gratuito): proteção essencial incluindo um firewall gerenciado, firewall de aplicação web (WAF), largura de banda ilimitada, scanner de malware e mitigação dos riscos do OWASP Top 10. Nosso nível gratuito é perfeito para proprietários de sites que precisam de defesas básicas imediatas enquanto agendam atualizações, testam compatibilidade ou coordenam manutenção.

Comece seu plano gratuito aqui:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Por que nosso plano gratuito ajuda agora:

• Ative o patch virtual e as regras do WAF para vulnerabilidades públicas conhecidas (incluindo o problema do SQL Chart Builder) em minutos.
• Execute varreduras automatizadas de malware para detectar indicadores pós-exploração.
• Mantenha o tráfego fluindo enquanto bloqueia tentativas de exploração — nenhuma configuração pesada é necessária.

Se você gerencia vários sites ou precisa de patch virtual automatizado para vulnerabilidades, nossos planos pagos incluem remoção automática de malware, blacklist/whitelist de IP, relatórios mensais e serviços avançados de remediação.

---

Lista de verificação final: itens de ação a serem concluídos agora

• ☐ Verifique se o SQL Chart Builder está instalado em todos os sites.
• ☐ Se instalado e versão < 2.3.8, planeje uma atualização imediata para 2.3.8 ou posterior.
• ☐ Se você não puder atualizar imediatamente, desative o plugin ou aplique patch virtual/regras do WAF direcionadas ao plugin.
• ☐ Revise os logs em busca de IoCs de SQLi e inspecione o banco de dados em busca de anomalias.
• ☐ Executar uma verificação completa de malware e verificação de integridade de arquivos.
• ☐ Gire as credenciais do banco de dados e do administrador se suspeitar de comprometimento.
• ☐ Ative a proteção e monitoramento contínuos do WAF.

---

Considerações finais

Vulnerabilidades que permitem injeção SQL não autenticada estão entre as classes de bugs mais arriscadas para sites WordPress, porque eliminam a necessidade de um atacante ter qualquer conta válida. A resposta rápida — combinando correção virtual imediata (WAF), atualizações oportunas e uma boa resposta a incidentes — é essencial.

No WP‑Firewall, construímos nossos processos e regras para proteger rapidamente sites WordPress contra esse tipo de ameaça. Habilitar a proteção básica pode ser feito em minutos e dá aos administradores um espaço crucial para corrigir, testar e remediar sem adivinhar se os scanners automatizados serão suficientes.

Se você gostaria de ajuda para avaliar sua exposição ou precisa de assistência para implementar patches virtuais do WAF em vários sites, nossa equipe está disponível para orientá-lo nos passos.

Fique seguro,
A Equipe de Segurança do Firewall WP