Nome do plugin	Themify Builder
Tipo de vulnerabilidade	Controle de acesso quebrado
Número CVE	CVE-2025-49396
Urgência	Baixo
Data de publicação do CVE	2025-08-20
URL de origem	CVE-2025-49396

Themify Builder <= 7.6.7 — Controle de acesso comprometido (CVE-2025-49396): O que os proprietários de sites WordPress devem fazer agora

Autor: Equipe de Segurança do Firewall WP
Data: 2025-08-20

Resumo: Uma vulnerabilidade de controle de acesso divulgada publicamente, que afeta as versões do Themify Builder até a 7.6.7 (CVE-2025-49396), pode permitir que uma conta com privilégios inferiores ("Colaborador") ou uma conta comprometida com privilégios semelhantes acesse funcionalidades que deveriam ser restritas. O problema foi corrigido na versão 7.6.8. Este artigo explica o risco, os cenários de exploração, a detecção e as medidas de mitigação que você pode tomar imediatamente — incluindo como proteger seu site com o WP-Firewall (plano gratuito disponível).

---

Índice

• O que aconteceu (em linhas gerais)?
• Quem é afetado?
• Por que isso é importante para proprietários de sites WordPress?
• Resumo técnico da vulnerabilidade (o que significa "controle de acesso falho" neste contexto)
• Cenários de exploração realistas
• Medidas imediatas para proteger seu site (mitigações de curto prazo)
• Medidas de remediação recomendadas a longo prazo (atualização, reforço da segurança, monitoramento)
• Como um firewall de aplicações web (WAF) e o patch virtual ajudam — e o que esperar do WP-Firewall
• Lista de verificação para resposta a incidentes: Se você suspeitar de comprometimento
• Orientações sobre detecção e registro (o que observar)
• Exemplos de padrões de regras WAF e regras de monitoramento (seguras, defensivas)
• Lista de verificação para configuração segura de sites que utilizam construtores de páginas e fluxos de trabalho com múltiplos autores.
• Plano gratuito para WP-Firewall — proteja seu site hoje mesmo
• Considerações finais e leituras adicionais

---

O que aconteceu (em linhas gerais)?

Uma vulnerabilidade de controle de acesso foi divulgada publicamente e recebeu o código CVE-2025-49396. Ela afeta as versões do plugin Themify Builder até a versão 7.6.7, inclusive. O fornecedor lançou a versão 7.6.8, que corrige o problema.

Em termos simples: uma função ou endpoint usado pelo construtor não verificou corretamente se o usuário atual possuía os privilégios necessários. Isso significa que um usuário com privilégios inferiores (função de Colaborador) ou uma conta comprometida com acesso equivalente poderia acionar funcionalidades que deveriam ser restritas a funções com privilégios mais elevados (Editor/Administrador). Vulnerabilidades de controle de acesso podem levar à adulteração de conteúdo, escalonamento de privilégios, upload de conteúdo malicioso e outras ações pós-comprometimento.

---

Quem é afetado?

• Qualquer site WordPress que utilize o plugin Themify Builder versão 7.6.7 ou anterior.
• Sites onde usuários não confiáveis têm permissão para acessar contas de nível de colaborador, ou onde contas de colaboradores podem ser comprometidas (senhas fracas, credenciais reutilizadas, phishing).
• Blogs com múltiplos autores, blogs corporativos, sites de clientes onde contratados ou colaboradores externos recebem acesso de contribuidor/editor.
• Sites que dependem do plugin para operações de construção e layout da interface.

Se você utiliza o Themify Builder em um site em produção, considere isso como uma questão acionável e priorize a revisão e a mitigação.

---

Por que isso é importante para proprietários de sites WordPress?

O controle de acesso falho é uma das classes de problemas de segurança mais comuns e impactantes. Quando um plugin não impõe verificações de capacidade (ou nonces) em ações ou endpoints AJAX/REST, ele cria uma rota previsível para que invasores façam coisas que não deveriam ser capazes de fazer — e os invasores frequentemente automatizam tentativas contra novas vulnerabilidades.

Mesmo quando uma vulnerabilidade é classificada como "baixa" em termos de CVSS (esta tem uma pontuação CVSS de 4,3), o impacto no mundo real depende do que um atacante pode fazer após explorá-la. Uma conta de nível Colaborador com a capacidade de alterar layouts do construtor, inserir scripts ou manipular o conteúdo das postagens já é perigosa: JavaScript malicioso, notificações administrativas injetadas ou o uso criativo e indevido dos recursos do construtor podem ser usados para aumentar o impacto e persistir em um site.

Pontos principais:

• Essa vulnerabilidade requer acesso a uma conta com privilégios baixos (Colaborador) ou comprometimento bem-sucedido da conta.
• O problema foi corrigido no Themify Builder 7.6.8; a atualização é a solução definitiva.
• Existem medidas paliativas imediatas que você pode aplicar caso não consiga atualizar imediatamente (recomendado para sites grandes ou complexos que necessitam de verificação em ambiente de teste).

---

Resumo técnico: o que significa "Controle de Acesso Quebrado" neste contexto.

“Controle de acesso falho” é uma classificação genérica que abrange verificações ausentes ou insuficientes que deveriam verificar:

• a capacidade do usuário atual (por exemplo, current_user_can('edit_theme_options') ou capacidade X),
• o nonce/token correto para evitar CSRF, e
• que a função do usuário está autorizada a executar a ação solicitada.

Nesta divulgação, o caminho de código vulnerável expôs a funcionalidade de construção a usuários que não deveriam ter acesso. O problema pode estar presente em:

• Manipuladores AJAX (admin-ajax.php) ou endpoints REST registrados pelo plugin,
• manipuladores de endpoints que implementam uma ação, mas esquecem de verificar current_user_can() ou verificam uma capacidade que é muito permissiva,
• Ausência de validação de nonce para solicitações de mudança de estado.

Como a divulgação classificou o privilégio necessário como Colaborador, a vulnerabilidade provavelmente decorre de um caminho que pressupõe que os colaboradores sejam confiáveis para uma operação relacionada ao construtor, mas que, na realidade, deveriam ter esse privilégio restrito.

---

Cenários de exploração realistas

Compreender os cenários de exploração mais prováveis ajuda a priorizar a mitigação.

Cenário A — Colaborador Malicioso:

• O proprietário do site cria contas de colaborador para autores convidados.
• Um colaborador insere conteúdo que utiliza a interface de usuário do construtor ou aciona um endpoint do construtor que deveria ser exclusivo para administradores.
• Devido à falta de controle de acesso, o colaborador manipula recursos de layout ou insere scripts que o construtor publica em seguida — resultando em XSS armazenado ou inserção de conteúdo.

Cenário B — Conta de Colaborador Comprometida:

• Um atacante obtém as credenciais de colaborador (preenchimento de credenciais, senhas reutilizadas).
• O atacante usa a conta comprometida para acessar o endpoint vulnerável e executar ações privilegiadas (modificar modelos, inserir scripts voltados para administradores ou conteúdo oculto que leva a uma maior invasão).

Cenário C — Script de terceiros + CSRF:

• Se um endpoint que altera o estado não tiver verificações de nonce, um atacante poderá enganar um colaborador autenticado para que visite um URL externo que aciona a ação (falsificação de solicitação entre sites), realizando uma alteração não autorizada sem interação direta.

Impactos potenciais:

• Adulteração de conteúdo ou inserção de JavaScript malicioso (expondo visitantes ou administradores do site).
• Carregar arquivos ou inserir recursos que persistam mesmo após alterações no conteúdo.
• Criar uma porta dos fundos ou modificar arquivos de tema/plugin (se o construtor puder modificá-los).
• Escalada de privilégios como parte de uma cadeia de ataque em várias etapas.

Nota: O conjunto exato de ações possíveis depende da funcionalidade do construtor que estava exposta antes da correção. Trate qualquer exposição inesperada de funcionalidade como grave.

---

Medidas imediatas para proteger seu site (mitigações de curto prazo)

Se você hospeda um site com o Themify Builder versão 7.6.7 ou inferior, execute as seguintes ações imediatamente — ordenadas por velocidade e impacto:

1. Atualize o Themify Builder para a versão 7.6.8 (recomendado).
   • A atualização corrige o problema. Se o seu site for complexo, atualize primeiro em um ambiente de teste; depois, atualize em produção.
   • Sempre faça backup dos arquivos e do banco de dados antes de atualizar.
2. Se não puder atualizar imediatamente, restrinja quem pode fazer login.
   • Revogue temporariamente as contas de colaborador e autor, ou altere suas funções para uma função mais restritiva até que você possa atualizá-las.
   • Forçar a redefinição de senha para todos os usuários com acesso de nível colaborador ou superior.
   • Audite e remova contas inativas ou suspeitas.
3. Desative recursos desnecessários no plugin.
   • Se o Themify oferecer opções para ativar/desativar endpoints de construtores remotos ou edição no front-end, desative esses recursos até que sejam corrigidos.
   • Se o plugin expuser um endpoint REST ou um editor de construção público voltado para o administrador, restrinja-o por meio de IP ou outros controles em nível de servidor.
4. Reforçar a capacidade do usuário e as permissões de upload.
   • Remova a funcionalidade upload_files da função de Colaborador, a menos que seja necessária.
   • Utilize um plugin de gerenciamento de funções (ou WP-CLI) para restringir as capacidades das contas de nível colaborador.
5. Aplicar patches virtuais temporários no nível do servidor/WAF
   • Se você usa o WP-Firewall ou um WAF similar, habilite uma regra que bloqueie solicitações para endpoints de construtores a partir de contas com privilégios baixos, bloqueie POSTs suspeitos para URIs relacionados a construtores ou rejeite solicitações de alteração de estado que não possuam um nonce válido.
   • Caso não possua um WAF (Web Application Firewall), implemente restrições de IP para os caminhos wp-admin e builder admin sempre que possível.
6. Aumentar o monitoramento e o registro de dados
   • Ative e revise os registros de acesso, especialmente para admin-ajax.php e tráfego do endpoint REST.
   • Monitore a presença de novos arquivos em uploads, modificações inesperadas em arquivos de plugins/temas e novos usuários administradores.

---

Remediação recomendada a longo prazo (após medidas imediatas)

1. Atualize todos os sites que executam o Themify Builder para a versão 7.6.8 ou posterior.
   • Teste em ambiente de homologação, faça backup em ambiente de produção e, em seguida, atualize.
   • Execute novamente os testes funcionais do seu site para garantir que os widgets e personalizações do construtor continuem funcionando.
2. Aplicar o princípio do menor privilégio para sites com múltiplos autores.
   • Forneça as funções e capacidades mínimas necessárias para os colaboradores.
   • Sempre que possível, utilize fluxos de trabalho editoriais (revisão de rascunhos) em vez de amplos privilégios de contribuição.
3. Impor uma autenticação mais robusta.
   • Exija senhas fortes, habilite a autenticação de dois fatores para usuários com privilégios elevados e utilize uma política de senhas ou SSO (Single Sign-On) para autores e administradores.
4. Utilize patches virtuais e regras gerenciadas.
   • Um WAF com aplicação de patches virtuais pode impedir tentativas de exploração enquanto você implementa a correção publicada pelo fornecedor em todos os ambientes. Por exemplo, bloqueie chamadas não autorizadas para endpoints de compilação que devem ser executados apenas por administradores.
5. Manutenção e auditoria regulares de plugins
   • Mantenha todos os plugins, temas e o núcleo do WordPress atualizados.
   • Estabeleça uma rotina para revisar os plugins instalados e remover aqueles que não são mantidos ativamente ou que não são necessários.
6. Testes de segurança e revisão de código para código personalizado.
   • Se você ou um contratado personalizaram a funcionalidade do construtor, audite todos os endpoints personalizados, ações AJAX ou rotas REST para garantir que as verificações de capacidade e os nonces adequados sejam aplicados.

---

Como um firewall de aplicações web (WAF) e o patch virtual ajudam — e o que esperar do WP-Firewall

Um WAF responsável desempenha três funções principais para esse tipo de vulnerabilidade:

1. Mitigação imediata (aplicação de patches virtuais)

   As regras do WAF podem bloquear tentativas de exploração direcionadas aos endpoints vulneráveis do construtor antes que um invasor consiga acessar o WordPress. Isso é especialmente valioso quando a atualização imediata não é possível (grandes instalações com vários sites, janelas de manutenção, testes complexos de dependências).

2. Detecção baseada em comportamento

   Os WAFs podem detectar padrões anômalos, como um usuário com poucos privilégios acionando endpoints exclusivos para administradores ou sequências de solicitações suspeitas direcionadas à funcionalidade de construção de sistemas.

3. Endurecimento e limitação da superfície de ataque

   Os WAFs podem restringir solicitações a painéis de administração e endpoints de construtores por IP, exigir determinados cabeçalhos ou descartar solicitações que não possuam nonces válidos ou cookies wp-auth.

O que o WP-Firewall fará pelo seu site:

• Se você utiliza o WP-Firewall, implantaremos uma regra de patch virtual de emergência para bloquear vetores de exploração conhecidos para esta divulgação para nossos clientes em planos gerenciados (e forneceremos orientações de configuração para usuários de planos gratuitos).
• O firewall gerenciado do WP-Firewall inspeciona as solicitações recebidas em busca de indicadores de exploração conhecidos e pode bloquear tentativas que correspondam às assinaturas criadas associadas à divulgação — reduzindo seu risco enquanto você aplica as correções.
• Nossos scanners e rotinas de detecção de malware ajudarão a identificar se tentativas ou atividades suspeitas já ocorreram e orientarão a remediação.

Nota sobre expectativas:

• Os WAFs não substituem os patches fornecidos pelo fabricante. São controles complementares que lhe dão tempo e reduzem o risco enquanto você aplica patches e responde a incidentes.
• A aplicação de patches virtuais deve ser usada em conjunto com monitoramento e aplicação de patches subsequentes; trata-se de uma estratégia de contenção, não de uma solução permanente.

---

Lista de verificação para resposta a incidentes: Se você suspeitar de comprometimento

Se você acredita que a vulnerabilidade foi explorada em seu site, siga estas etapas prioritárias:

1. Isole o local
   • Coloque o site temporariamente em modo de manutenção ou desative-o caso seja confirmada uma violação grave de segurança.
   • Se estiver hospedado em um ambiente compartilhado, coordene com o provedor de hospedagem.
2. Faça backups e capture logs.
   • Exporte uma cópia do site afetado (arquivos + banco de dados) antes de fazer as alterações de limpeza — isso facilita a análise forense.
   • Reúna os registros do servidor, os registros de acesso, os registros do arquivo admin-ajax.php e os registros de requisição REST, além dos registros de autenticação.
3. Procure por indicadores de comprometimento.
   • Analise a pasta wp-content/uploads em busca de arquivos PHP ou executáveis inesperados.
   • Verifique os diretórios de plugins e temas em busca de arquivos modificados recentemente.
   • Pesquise no banco de dados por conteúdo suspeito inserido em postagens, opções ou metadados do usuário.
4. Remova web shells e arquivos maliciosos.
   • Se encontrar web shells ou arquivos PHP nos uploads, remova-os e determine como foram introduzidos.
   • Substitua os arquivos modificados do plugin/tema por cópias limpas das fontes oficiais.
5. Auditar usuários, permissões e chaves de API.
   • Remova contas suspeitas, force a redefinição de senhas para todos os administradores/usuários com privilégios, e rotacione quaisquer chaves expostas (API/FTP/DB).
   • Caso os colaboradores tenham sido explorados, altere suas credenciais e audite o histórico de atividades.
6. Restaure a partir de um backup íntegro, se necessário.
   • Se a integridade do site estiver em questão e o prazo para a limpeza for longo, considere restaurar um backup anterior à violação, aplicar o patch do plugin e outras medidas de segurança.
7. Reforce e teste novamente antes de colocar o site online novamente.
   • Aplique as atualizações de plugins/temas/núcleo, execute novamente as verificações de malware, verifique se os plugins provêm de fontes oficiais e, se possível, verifique os checksums.
   • Ative o registro de logs para detectar atividades subsequentes.
8. Reporte e registre o incidente.
   • Mantenha um registro de incidentes com datas, ações tomadas, backups e evidências. Isso auxilia na análise da causa raiz e previne recorrências.

---

Orientações sobre detecção e registro (o que observar)

Como essa vulnerabilidade está relacionada ao controle de acesso, sua detecção depende da identificação de padrões de autorização incomuns:

Indicadores de log de alta prioridade:

• Requisições POST ou GET para admin-ajax.php ou endpoints REST específicos do construtor a partir de contas/clientes com privilégios limitados.
• Solicitações com parâmetros de consulta ou valores de ação específicos do construtor que normalmente são acionados apenas pela interface de administração.
• Requisições POST repetidas para endpoints de construtores a partir do mesmo IP ou conta (automação).
• Requisições que não possuem um nonce WP válido quando o endpoint normalmente espera um (ausência de token nonce no corpo da requisição POST).
• Novos arquivos enviados para /wp-content/uploads com extensão .php ou nomes ofuscados.
• Alterações inesperadas em posts, páginas, modelos ou arquivos de tema.

Padrões de pesquisa para executar em seus registros (exemplos):

• Filtre os registros de acesso para solicitações admin-ajax.php e inspecione o parâmetro “action”.
• Procure por solicitações para /wp-json/ que contenham “themify”, “builder” ou outros tokens que identifiquem o construtor.
• Procure por atividade elevada nas contas dos colaboradores: muitas postagens em um curto período ou postagens fora do horário normal de trabalho.

Dica: Mantenha uma regra de marcação e alerta que sinalize quando usuários com nível de colaborador realizarem ações normalmente associadas a editores ou administradores.

---

Exemplos de padrões de regras WAF e regras de monitoramento (defensivas, seguras)

Abaixo estão exemplos de padrões de regras defensivas e regras de monitoramento. Estes são conceitos e devem ser adaptados ao seu ambiente. Não os utilize como modelos de exploração — eles são de natureza defensiva.

1. Bloquear ações suspeitas do construtor admin-ajax.php para funções não autorizadas.
   • Condição: Requisição para /wp-admin/admin-ajax.php com POST e parâmetro de ação correspondente às ações relacionadas ao construtor.
   • Ação: Bloquear ou desafiar (403) quando a solicitação não possui um cabeçalho nonce válido ou vem de uma sessão não autenticada.

   Pseudocódigo:
   SE request_uri contiver “/admin-ajax.php” E method == POST E params[“action”] corresponder a /(themify|builder|tfb)_/i
     – E o cookie de solicitação não contém um cookie wordpress_logged_in válido OU o nonce está ausente/inválido
     – ENTÃO bloqueie ou exija desafio

2. Bloquear chamadas de endpoints REST para endpoints de construtores a partir de origens que não sejam de administração.
   • SE request_uri contiver “/wp-json/themify” OU “/wp-json/builder” E o método de requisição for (POST, PUT, DELETE)
   • ENTÃO bloqueie, a menos que a solicitação seja do intervalo de IPs do administrador ou de uma sessão de administrador autenticada válida.
3. Limitar a taxa de ações de colaboradores suspeitos
   • SE a função do usuário for igual a colaborador (inferida por cookie/sessão) E > N solicitações POST para os endpoints do construtor em M segundos
   • ENTÃO reduza a velocidade ou bloqueie
4. Detectar nonce ausente em solicitações de mudança de estado
   • SE POST para o endpoint do construtor E o parâmetro nonce estiver ausente OU o formato for inválido
   • ENTÃO registre + aumente a pontuação de risco, opcionalmente bloqueando
5. Inspeção de upload de arquivos
   • Se a solicitação resultar em um novo arquivo nos uploads com extensão .php ou dupla (.jpg.php)
   • Em seguida, coloque o arquivo em quarentena e notifique.

Notas:

• A detecção por WAF que depende de cookies ou dados de sessão deve ser configurada corretamente para analisar os cookies do WordPress e evitar falsos positivos para usuários administradores válidos.
• As regras de aplicação de patches virtuais devem ser testadas no modo de monitoramento antes da sua implementação, para verificar a ocorrência de falsos positivos.

---

Lista de verificação para configuração segura de sites que utilizam construtores de páginas e fluxos de trabalho com múltiplos autores.

Use esta lista de verificação para reduzir a probabilidade de uma vulnerabilidade semelhante ter um impacto significativo:

Contas e funções

• Aplique o princípio do menor privilégio: conceda aos colaboradores apenas as capacidades de que precisam.
• Remova upload_files de Contributor, a menos que seja explicitamente necessário.
• Implemente a autenticação de dois fatores (2FA) para editores e administradores (e considere seriamente implementá-la também para autores).

Higiene do plugue

• Mantenha o Themify Builder e todos os plugins/temas atualizados.
• Remova plugins e temas não utilizados do servidor.
• Monitore os registros de alterações dos plugins e inscreva-se para receber avisos de segurança do fornecedor (se disponíveis).

Reforço de segurança do servidor e do WP

• Desativar edição de arquivos (define('DISALLOW_FILE_EDIT', true);).
• Defina permissões de arquivo rigorosas (arquivos 644, pastas 755, wp-config.php 600/640, quando possível).
• Restrinja o acesso ao wp-admin por IP sempre que possível, ou adicione autenticação extra na entrada do painel de administração.

Rede e WAF

• Instale um WAF (Firewall de Aplicativo Web) na frente do seu site e habilite o patch virtual para divulgações de alto risco.
• Limitar a taxa de requisições aos endpoints do wp-admin e do construtor de páginas.
• Bloqueie agentes de usuário suspeitos ou scanners automatizados que sondem os endpoints do construtor.

Monitoramento e backups

• Utilize backups diários automatizados armazenados fora do local; teste seu processo de restauração periodicamente.
• Ative o registro e a retenção por pelo menos 90 dias para registros críticos de segurança (registros de acesso, erro e auditoria).
• Execute verificações de malware agendadas.

Testes e preparação

• Teste as atualizações de plugins em ambientes de homologação antes de realizar os testes em produção.
• Mantenha um ambiente de teste/homologação separado que espelhe as versões de produção dos plugins para testes de aceitação.

---

Plano gratuito para WP-Firewall — proteja seu site hoje mesmo

Título: Proteja seu site WordPress com proteção gerenciada — Comece gratuitamente

Se você deseja uma camada de defesa imediata e prática enquanto atualiza e reforça a segurança do seu site, considere assinar o plano gratuito do WP-Firewall. Nosso plano Básico gratuito inclui firewall gerenciado, WAF, scanner de malware e mitigação para os 10 principais riscos da OWASP — exatamente as proteções que ajudam a conter e impedir tentativas de exploração, como a divulgação da falha de controle de acesso do Themify Builder, enquanto você atualiza para a versão corrigida do plugin.

Comece com o plano Básico gratuito aqui: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

O que o plano gratuito oferece (breve resumo):

• Regras essenciais de firewall gerenciado e WAF personalizadas para WordPress.
• Largura de banda ilimitada protegida pela nossa camada WAF (sem limite de tráfego).
• Verificação sob demanda de malware e orientações para remoção.
• Proteção e mitigação para os 10 principais vetores da OWASP, como falhas de controle de acesso e XSS.

Se posteriormente desejar implantação automática de patches virtuais, relatórios agendados ou um gerenciador de segurança dedicado, o WP-Firewall também oferece planos de atualização com esses serviços avançados.

---

Considerações finais e lista de verificação imediata recomendada

Se você utiliza o Themify Builder em algum site, faça o seguinte agora (em ordem de prioridade):

1. Backup: Cópia de segurança completa dos arquivos e do banco de dados.
2. Atualizar: Atualize o Themify Builder para a versão 7.6.8 (inicie primeiro em um ambiente de teste, se necessário).
3. Usuários de auditoria: Forçar a redefinição de senhas para colaboradores e níveis superiores; remover contas não utilizadas.
4. WAF: Se você estiver usando o WP-Firewall, certifique-se de que o conjunto de regras de emergência esteja ativado; caso contrário, ative qualquer patch virtual disponível e reforce as rotas administrativas.
5. Digitalização: Execute uma verificação completa de malware e inspecione os arquivos enviados e modificados.
6. Monitor: Analise os registros em busca de atividades suspeitas relacionadas aos endpoints do construtor e ao arquivo admin-ajax.php.
7. Endurecer: Remova funcionalidades desnecessárias de funções com privilégios baixos e implemente a autenticação de dois fatores (2FA) para usuários com privilégios elevados.

Nota final da equipe do WP-Firewall: problemas de controle de acesso muitas vezes são "invisíveis" até que alguém tente explorá-los intencionalmente. É por isso que as defesas em camadas são importantes: privilégio mínimo, atualizações oportunas e proteções em nível de rede, em conjunto, reduzem o risco e dão tempo para você responder sem interrupções.

Se precisar de ajuda para implementar patches virtuais ou de uma análise de segurança para um site que utiliza o Themify Builder, nossa equipe pode ajudar a diagnosticar vulnerabilidades e implementar proteções rapidamente. Comece com o plano gratuito para obter WAF gerenciado e varredura, e faça upgrade conforme necessário para obter aplicação automatizada de patches virtuais e remediação gerenciada.

Fique seguro,
Equipe de Segurança do Firewall WP