A correção está disponível. A equipe do OWASP ModSecurity lançou a versão 3.0.16 com patches para ambas as vulnerabilidades. Para quem mantém a defesa de aplicações em produção: Atualizar imediatamente para ModSecurity 3.0.16 ou superior, disponível na página de releases do projeto . Em sistemas i386 , migrar para arquitetura 64 bits como medida complementar até confirmar que o patch foi aplicado. Revisar regras multipart no Core Rule Set após a atualização para confirmar comportamento consistente de parsing. Implementar validação no backend — o WAF não deve ser a única camada de defesa. Validação server-side e parameterized queries continuam essenciais. Monitorar logs do WAF em busca de requisições multipart suspeitas com campos contendo quebras de linha. Até o momento da publicação, não há registros confirmados de exploração ativa na natureza. Contudo, a existência de proof-of-concept público e a simplicidade de execução — sem autenticação, sem interação do usuário — tornam a janela de risco real. O grupo CL0P, por exemplo, já explorou falhas de bypass de WAF em ataques contra organizações como Harvard e o Washington Post em 2025, demonstrando que grupos de ransomware mantêm a WA

ModSecurity: duas falhas deixam seu WAF cego a ataques

Duas vulnerabilidades divulgadas no OWASP ModSecurity (CVE-2026-52747 e CVE-2026-52761) permitem que atacantes burlar regras do firewall de aplicação web enviando requisições HTTP manipuladas. A falha mais grave afeta o parser de formulários em todas as arquiteturas — o WAF enxerga dados diferentes do que o backend processa, deixando sistemas supostamente protegidos expostos a injeção e Remote Code Execution. O patch está disponível na versão 3.0.16.

O que aconteceu

Duas vulnerabilidades recém-divulgadas no OWASP ModSecurity — o motor de firewall de aplicação web (WAF) mais usado no mundo — permitem que atacantes burlar todas as regras de segurança com requisições HTTP cuidadosamente construídas. As falhas, registradas como CVE-2026-52747 (CVSS 8.6) e CVE-2026-52761 (CVSS 5.8), afetam todas as versões até a 3.0.15 e já foram corrigidas na versão 3.0.16, lançada pelo projeto OWASP.

O problema não é teórico. Um proof-of-concept demonstrou que payloads multi-linha passam pelo WAF sem disparar nenhum alerta, enquanto o backend da aplicação processa o input original com quebras de linha intactas. Em ambientes corporativos brasileiros, onde o ModSecurity protege portais de governo, bancos e plataformas de e-commerce rodando sobre Apache e Nginx, o risco é concreto e imediato.

Ambos os CVEs foram descobertos por pesquisadores ligados ao time do OWASP Core Rule Set durante testes automatizados de regressão, e a coordenação da divulgação seguiu o processo responsável do projeto, com patch e anúncio público simultâneos.

Comparativo rápido das falhas

CVE	Severidade	Componente afetado	Arquitetura	Impacto
CVE-2026-52747	8.6 (Alta)	Parser multipart/form-data	Todas	Bypass completo de regras WAF
CVE-2026-52761	5.8 (Moderada)	Transformação t:utf8toUnicode	i386 (32 bits)	Truncamento de inspeção de input

Como funciona a falha mais grave

A CVE-2026-52747 atinge o parser de multipart/form-data dentro da libmodsecurity — a biblioteca central do ModSecurity responsável por interpretar requisições com upload de arquivos e campos de formulário. Quando um campo de formulário contém quebras de linha embutidas (caracteres \r\n ou \n), o parser remove silenciosamente essas quebras antes de passar os dados para as regras do WAF.

Na prática: um payload como A\r\nB chega ao WAF como AB. O backend da aplicação, porém, recebe o input com as quebras de linha originais intactas. Essa divergência cria uma vulnerabilidade clássica de “parser differential” — o firewall e a aplicação enxergam versões diferentes do mesmo dado.

O mecanismo root do bug é um erro de lógica no parser: dados previamente armazenados no buffer são sobrescritos em vez de concatenados durante o processamento multipart. Apesar da transformação malformada, as checagens de validação estrita do próprio ModSecurity — como MULTIPART_STRICT_ERROR — permanecem desativadas. O operador do WAF não recebe nenhum aviso de anomalia.

Ataques de injeção multi-linha, assinaturas baseadas em delimitadores e payloads que dependem de quebras de linha (como headers de injeção HTTP ou comandos SQL divididos em múltiplas linhas) passam despercebidos. Um PoC confirmou que payloads com \r\n e \n são consistentemente reduzidos a strings de linha única sem disparar alertas.

O bug específico de 32 bits

A CVE-2026-52761 tem alcance mais limitado, mas revela um erro de programação preocupante. A função de transformação t:utf8toUnicode, usada em diversas regras do ModSecurity para normalizar input antes da inspeção, calcula incorretamente o tamanho do buffer em sistemas i386 (32 bits).

O código usa sizeof() sobre um tipo ponteiro em vez do buffer real. Em i386, um ponteiro tem 4 bytes; em sistemas 64 bits, 8 bytes. Por coincidência, o tamanho do ponteiro em 64 bits equivale ao tamanho esperado do buffer — então o bug passa despercebido nessa arquitetura. Em 32 bits, a transformação produz saída truncada ou incorreta, fazendo com que regras que dependam dela falhem em detectar payloads maliciosos.

Essa falha existe desde a versão 3.0.0 do ModSecurity. A recomendação oficial é migrar ambientes i386 para arquitetura 64 bits como medida complementar à aplicação do patch.

Impacto para quem usa WAF

O ModSecurity é o motor WAF open-source mais implantado globalmente, protegindo aplicações web em Apache, Nginx e IIS. Muitas soluções comerciais de WAF, CDNs e provedores de segurança o usam como base. No Brasil, plataformas de governo digital e fintechs frequentemente dependem de mod_security + OWASP Core Rule Set (CRS) como primeira linha de defesa contra SQL injection, XSS e Remote Code Execution.

Quem confia exclusivamente no ModSecurity como barreira de inspeção — sem validação adicional no backend — opera com uma falsa sensação de segurança. O WAF aprova o tráfego, o backend processa o payload malicioso e ninguém é alertado. Esse tipo de falha é especialmente perigoso porque atinge exatamente a configuração recomendada como padrão pela documentação oficial.

Para dimensionar o problema, a equipe de pesquisa da Core Rule Set identificou o bug em testes automatizados de regressão — o que sugere que o número de regras do CRS potencialmente afetadas é significativo. Qualquer organização que utilize o ModSecurity 3.0.15 ou anterior está, por padrão, exposta ao bypass de regras multipart.

O que fazer agora

A correção está disponível. A equipe do OWASP ModSecurity lançou a versão 3.0.16 com patches para ambas as vulnerabilidades. Para quem mantém a defesa de aplicações em produção:

Atualizar imediatamente para ModSecurity 3.0.16 ou superior, disponível na página de releases do projeto.
Em sistemas i386, migrar para arquitetura 64 bits como medida complementar até confirmar que o patch foi aplicado.
Revisar regras multipart no Core Rule Set após a atualização para confirmar comportamento consistente de parsing.
Implementar validação no backend — o WAF não deve ser a única camada de defesa. Validação server-side e parameterized queries continuam essenciais.
Monitorar logs do WAF em busca de requisições multipart suspeitas com campos contendo quebras de linha.

Até o momento da publicação, não há registros confirmados de exploração ativa na natureza. Contudo, a existência de proof-of-concept público e a simplicidade de execução — sem autenticação, sem interação do usuário — tornam a janela de risco real. O grupo CL0P, por exemplo, já explorou falhas de bypass de WAF em ataques contra organizações como Harvard e o Washington Post em 2025, demonstrando que grupos de ransomware mantêm a WAF como alvo estratégico.