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.

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:

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:

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:

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.

Correção

Execute esta:

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:

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:

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.

A classe gerada é colocada ao lado de uma classe @EnableWebSecurity quando existe, recorrendo a @SpringBootApplication e depois a qualquer @Configuration, de modo que sempre cai em algum lugar que a varredura de componentes alcança. Projetos que já gravam cabeçalhos antecipadamente, ou que fornecem um OnCommittedResponseWrapper corrigido (como jogetworkflow/jw-community faz), são deixados em paz.

Blocos de construção (avançado)

Verificada contra um servidor em execução

Aplicada a semgrep/cve-2026-22732-demo no Spring Security 6.4.12 vulnerável, contra Tomcat embarcado. Seu HeaderVerificationTest afirma que os cabeçalhos de segurança estão ausentes, portanto uma correção funcional o faz falhar:

X-Frame-Options e Cache-Control seguem o mesmo padrão.

Nos 16 repositórios do corpus que compilam (de 29 identificados), a correção gerou uma configuração para três e corretamente deixou o restante em paz:

Reexecutar a correção sobre os três repositórios corrigidos não gera nada adicional, portanto a remediação é idempotente em relação à própria saída em projetos reais.

Um segundo corpus mais amplo tem como alvo a população que a correção realmente aborda — qualquer aplicação servlet do Spring Security afetada, já que nenhum sink é necessário. Dos 64 projetos encontrados por busca de código, 52 compilaram, 48 resolveram uma versão afetada, e 38 foram corrigidos; 35 desses compilam (os outros três falham de forma idêntica sem o arquivo gerado). Todos os 8 projetos em Spring Security abaixo de 5.2 foram corretamente ignorados. Consulte a seção 8 de SUSCEPTIBLE-REPOSITORIES.md.

Limitações

• As detecções do WebFlux são um risco diferente, não este CVE. OnCommittedResponseWrapper extends jakarta.servlet.http.HttpServletResponseWrapper, portanto o CVE-2026-22732 é apenas de servlet e uma aplicação reativa não está exposta a ele. Descobertas de FindHttpResponseContentLengthOrFlushBuffer sinalizam o padrão reativo análogo e ainda precisam de revisão manual, mas a correção deliberadamente não age sobre elas. AddEagerHeaderWriterConfiguration ignora qualquer módulo que possa ver HeaderWriterFilter sem a API de servlet por trás — o filtro estende OncePerRequestFilter, e spring-security-web carrega a API de servlet como uma dependência provided não transitiva, portanto gerar ali falha com cannot access jakarta.servlet.Filter (observado em apache/shenyu).
• Versões abaixo do Spring Security 5.2 são detectadas, mas não corrigidas. HeaderWriterFilter.setShouldWriteHeadersEagerly chega na 5.2; na 4.0.4 o filtro tem apenas um construtor e doFilterInternal. A detecção ainda relata versões EOL, mas a remediação é retida em vez de emitir uma chamada que não pode compilar.
• Cabeçalhos antecipados são gravados para cada requisição, incluindo aquelas posteriormente substituídas por um dispatch de erro. Esse é o trade-off que o padrão preguiçoso do Spring Security evita, e é por isso que a atualização é executada primeiro.

Tabelas de dados

Execução

Via CLI do Moderne:

Via rewrite.yml:

Reproduzindo o corpus de avaliação

repos.csv lista os 75 repositórios públicos contra os quais estas receitas foram desenvolvidas e medidas, fixados no commit exato em que cada um foi avaliado. Vários são mantidos ativamente e serão corrigidos upstream, portanto a coluna changeset é o que torna os números abaixo reproduzíveis em vez de meramente plausíveis.

A sincronização leva cerca de 20 segundos e 1,4 GB; a compilação leva aproximadamente 15 minutos e é a única etapa lenta. mod devcenter grava devcenter.html em corpus/.moderne/run/<runId>/, além de um por subdiretório de organização.

A coluna org1 divide o corpus em grupos que refletem por que cada repositório está presente — Servlet Sinks e WebFlux Sinks para as duas formas de chamada vulneráveis, Patched para repositórios já remediados upstream, Reference para o próprio Spring Security e outros não consumidores, Verified para o caso verificado contra um servidor em execução, Gradle para cobertura de ferramentas de build, e Wide para a amostra em massa.

Espere, nos commits fixados:

Quatro desses cinco genuinamente não usam Spring Security — spring-projects/spring-security é a própria biblioteca, JoeyBling/bootplus usa Apache Shiro, jenkinsci/stapler tem como alvo a API de servlet diretamente, e infofabrik/reportserver não tem build Maven ou Gradle para resolver. O quinto, xtuer/template-app, declara spring-security-web:5.0.0.RELEASE mas seu build Gradle não resolve nenhuma dependência durante mod build, portanto nenhuma receita pode ver a versão. Trate-o como não medido em vez de não afetado.

Para aplicar a correção e verificar o resultado:

mod git apply grava nos checkouts no local. Um check completo no corpus é lento e revelará falhas não relacionadas a esta alteração — toolchains JDK ausentes, repositórios de dependências inacessíveis, testes que já estavam vermelhos — portanto o sinal significativo é o delta em relação ao mesmo comando executado antes da aplicação.

O que é coberto além da demonstração literal

A análise de taint de rewrite-program-analysis lida com fluxo de dados local e resumos por método, portanto estes padrões são detectados automaticamente:

• Nome de cabeçalho Content-Length propagado por constante. String h = "Content-Length"; response.setIntHeader(h, 42); é sinalizado — o framework rastreia o taint do literal por meio da atribuição local.
• Helper que envolve a chamada — o taint flui por meio de valores de retorno via resumos de método.

Limitações conhecidas

• Fluxo por meio de tipos de contêiner genéricos (Map, List, coleções personalizadas). stash.put("k", "Content-Length") seguido de response.setIntHeader(stash.get("k"), 42) não é detectado — a identidade put/get é opaca para a análise.

Licença

Moderne Proprietária. Apenas para uso por clientes da Moderne sob os termos de um contrato comercial.