rewrite-cve-2026-22732

Receita OpenRewrite que detecta código suscetível ao CVE-2026-22732, uma falha do Spring Security em que definir Content-Length por meio de um dos três métodos de resposta ignora o OnCommittedResponseWrapper do Spring Security. Como o wrapper nunca vê o cabeçalho, onResponseCommitted() nunca é acionado, e os cabeçalhos de segurança adicionados de forma preguiçosa (X-Frame-Options, X-Content-Type-Options, Cache-Control, etc.) são silenciosamente descartados.

O que ela encontra

Os gatilhos reais, confirmados contra o Spring Security 6.4.12 vulnerável com Spring Boot 3.4.3 / Tomcat embarcado:

1. Content-Length do Servlet por meio das sobrecargas que ignoram o wrapper

   response.setHeader("Content-Length", "42");
   response.setIntHeader("Content-Length", 42);
   response.addIntHeader("Content-Length", 42);
   

   Essas três sobrecargas não são sobrescritas em OnCommittedResponseWrapper. Gravações subsequentes no corpo completam o comprimento declarado e o contêiner faz o commit sem acionar o gravador de cabeçalhos preguiçoso.

2. Content-Length do WebFlux por meio de HttpHeaders

   serverHttpResponse.getHeaders().set("Content-Length", "42");
   serverHttpResponse.getHeaders().add("Content-Length", "42");
   serverHttpResponse.getHeaders().setContentLength(42L);
   

3. Commits de resposta incondicionais do WebFlux

   serverHttpResponse.writeWith(Mono.just(dataBuffer));
   serverHttpResponse.writeAndFlushWith(publisher);
   serverHttpResponse.setComplete();
   

A receita é condicionada à presença do Spring Security — ela não emite nada em arquivos que não referenciam nenhum tipo org.springframework.security.* — e às faixas de versão afetadas do Spring Security. De acordo com o aviso do Spring publicado em 2026-03-19, as faixas afetadas e as versões corrigidas são:

Série	Afetada	Corrigida
5.7.x	5.7.0 – 5.7.21	5.7.22 (Enterprise)
5.8.x	5.8.0 – 5.8.23	5.8.24 (Enterprise)
6.3.x	6.3.0 – 6.3.14	6.3.15 (Enterprise)
6.4.x	6.4.0 – 6.4.14	6.4.15 (Enterprise)
6.5.x	6.5.0 – 6.5.8	6.5.9 (OSS)
7.0.x	7.0.0 – 7.0.3	7.0.4 (OSS)

Projetos que resolvem uma versão do Spring Security igual ou superior à correção em sua série (ou em qualquer série futura além de 7.0 / 6.5) são tratados como não afetados e não recebem marcadores por sink ou por arquivo. Projetos em que a versão não pode ser resolvida recorrem à detecção padrão baseada em padrões, de modo que um scanner tende a relatar uma descoberta que não pode refutar. A tabela de dados SpringSecurityVersionByProject ainda registra a versão resolvida e sinaliza cada projeto como afetado ou não, para que você possa auditar o que foi filtrado.

O que intencionalmente NÃO é sinalizado

Estes parecem perigosos, mas são rastreados pelo wrapper, portanto os cabeçalhos de segurança são gravados antes do commit da resposta:

Código	Por que é seguro
response.setContentLength(int) / setContentLengthLong(long)	Sobrescritos — o wrapper registra o comprimento declarado e aciona onResponseCommitted() quando o corpo é concluído.
response.flushBuffer()	Sobrescrito — chama doOnResponseCommitted() antes de super.flushBuffer().
response.getOutputStream().write(..) / flush() / close()	Retorna SaveContextServletOutputStream; cada write/flush/close aciona doOnResponseCommitted() antes de delegar.
response.getWriter().write(..) / print(..) / println(..) / flush() / close()	Retorna SaveContextPrintWriter; mesmo padrão.
response.addHeader("Content-Length", v)	Tratado de forma especial no wrapper — roteado por meio de setContentLength(long).

O endpoint /vuln/flush da demonstração do Semgrep afirma que flushBuffer() é o gatilho, mas em um Spring Security 6.4.12 vulnerável a resposta na verdade retorna todos os seis cabeçalhos de segurança. Os gatilhos reais na demonstração são as chamadas setIntHeader("Content-Length", ...) em /vuln/stream e /vuln/content-length.

Detecção

Execute esta:

Receita	Finalidade
io.moderne.recipe.cve202622732.FindSpringSecurityHeaderSuppression	Executa todas as detecções e emite a tabela de relatório de versão

Blocos de construção (avançado)

O agregador acima é composto por duas receitas menores. Você pode invocá-las individualmente se quiser apenas uma detecção.

Receita	Finalidade
io.moderne.recipe.cve202622732.FindHttpResponseContentLengthHeader	Fluxo de taint para o literal "Content-Length" alcançando setHeader / setIntHeader / addIntHeader (servlet) ou HttpHeaders.set / add (WebFlux)
io.moderne.recipe.cve202622732.FindHttpResponseContentLengthOrFlushBuffer	Commits incondicionais do WebFlux: writeWith, writeAndFlushWith, setComplete, HttpHeaders.setContentLength

Correção

Execute esta:

Receita	Finalidade
io.moderne.recipe.cve202622732.FixSpringSecurityHeaderSuppression	Escolhe a remediação mais barata que cada projeto pode realmente adotar

Ela executa duas etapas em ordem.

1. Atualizar para a correção na própria série do projeto. O Spring Security publicou a correção como 6.5.9 e 7.0.4 no Maven Central. Cada atualização é condicionada a uma pré-condição FindAffectedSpringSecuritySeries, porque UpgradeDependencyVersion apenas verifica se o destino é mais novo — instruído a ir para 7.0.4, ele arrastaria alegremente um projeto 5.8 por duas versões principais.

2. Adicionar uma configuração de gravação antecipada de cabeçalhos para o que a etapa 1 não pôde corrigir. Isso gera uma classe @Configuration por projeto:

@Bean
public static BeanPostProcessor eagerHeaderWriterFilterBeanPostProcessor() {
    return new BeanPostProcessor() {
        @Override
        public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
            if (bean instanceof HeaderWriterFilter) {
                ((HeaderWriterFilter) bean).setShouldWriteHeadersEagerly(true);
            }
            return bean;
        }
    };
}

Gravar os cabeçalhos antecipadamente torna irrelevante se o wrapper observa o commit, portanto isso fecha todos os sinks do projeto de uma só vez — incluindo aqueles que a análise de taint não consegue alcançar, como o fluxo Map em "Limitações conhecidas". O BeanPostProcessor vê os filtros construídos pelo DSL HttpSecurity porque AutowireBeanFactoryObjectPostProcessor os inicializa por meio da fábrica de beans. Duas correções publicadas independentemente para este CVE usam exatamente essa forma (hmcts/idam-web-public, e os forks do Spinnaker da armory-io por meio do ObjectPostProcessor equivalente).

A etapa 2 é o que cobre os projetos que a etapa 1 não pode ajudar:

Situação	Por que a atualização não funciona
5.7, 5.8, 6.3, 6.4	A correção é enviada apenas aos assinantes do Spring Enterprise — não está no Maven Central
6.0 - 6.2	Nenhuma correção foi lançada nessas séries
Versão gerenciada por um BOM importado	Nada é declarado localmente para a atualização editar

Essa última linha não é um caso isolado. nla/bamboo resolve 7.0.3 — uma série com correção de código aberto — inteiramente do BOM do Spring Boot, portanto uma verificação de versão sozinha o ignoraria em ambas as etapas e o deixaria vulnerável. AddEagerHeaderWriterConfiguration portanto só adia para a atualização quando o projeto tem uma correção de código aberto disponível e declara uma versão própria.