rewrite-cve-2026-22732

CVE-2026-22732 の影響を受けるコードを検出するOpenRewriteレシピ。これはSpring Securityの欠陥で、3つのレスポンスメソッドのいずれかを通じて Content-Length を設定すると、Spring Securityの OnCommittedResponseWrapper がバイパスされます。ラッパーがヘッダーを認識しないため onResponseCommitted() が発火せず、遅延追加されるセキュリティヘッダー（X-Frame-Options、X-Content-Type-Options、Cache-Control など）が静かに破棄されます。

検出内容

実際のトリガーは、脆弱なSpring Security 6.4.12（Spring Boot 3.4.3 / 組み込みTomcat）で確認済みです:

1. ラッパーをバイパスするオーバーロードによるServlet Content-Length

   root@kitploit:~

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

   これら3つのオーバーロードは OnCommittedResponseWrapper でオーバーライドされていません。後続のボディ書き込みで宣言された長さが完了し、コンテナは遅延ヘッダーライターを発火させずにコミットします。

2. HttpHeaders によるWebFlux Content-Length

   root@kitploit:~

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

3. WebFluxの無条件レスポンスコミット

   root@kitploit:~

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

このレシピはSpring Securityの存在に依存しており、org.springframework.security.* 型を一切参照しないファイルでは何も出力しません。また、影響を受けるSpring Securityのバージョン範囲にも依存します。Springアドバイザリ（2026-03-19公開）によると、影響を受ける範囲と修正バージョンは以下の通りです:

自身のシリーズの修正バージョン以上（または7.0 / 6.5以降の将来のシリーズ）のSpring Securityバージョンを解決するプロジェクトは影響を受けないものとして扱われ、シンク単位・ファイル単位のマーカーは生成されません。バージョンを解決できないプロジェクトは通常のパターンベースの検出にフォールバックするため、スキャナーは反証できない検出結果を報告する方向に倒れます。SpringSecurityVersionByProject データテーブルは解決されたバージョンを記録し、各プロジェクトが影響を受けるかどうかをフラグ付けするため、フィルタリングされた内容を監査できます。

意図的にフラグ付けしないもの

これらは危険に見えますが、ラッパーで追跡されるため、レスポンスがコミットされる前にセキュリティヘッダーが書き込まれます:

Semgrepデモの /vuln/flush エンドポイントは flushBuffer() がトリガーだと主張していますが、脆弱なSpring Security 6.4.12では実際には6つのセキュリティヘッダーすべてがレスポンスで返されます。デモの実際のトリガーは /vuln/stream と /vuln/content-length にある setIntHeader("Content-Length", ...) 呼び出しです。

検出

こちらを実行してください:

構成要素（上級者向け）

上記のアグリゲーターは2つの小さなレシピで構成されています。1つの検出のみが必要な場合は個別に呼び出すことができます。

修正

こちらを実行してください:

2つのステップを順番に実行します。

1. プロジェクト自身のシリーズの修正バージョンへのアップグレード。 Spring Securityは修正を6.5.9と7.0.4としてMaven Centralに公開しました。各アップグレードは FindAffectedSpringSecuritySeries の前提条件でゲートされています。UpgradeDependencyVersion はターゲットが新しいことだけをチェックするため、7.0.4へのアップグレードを指示すると5.8プロジェクトを2つのメジャーバージョンにまたがって引きずり込む可能性があります。

2. ステップ1で修正できなかったものに対する先行ヘッダー書き込み設定の追加。 これによりプロジェクトごとに1つの @Configuration クラスが生成されます:

@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;
        }
    };
}

ヘッダーを事前に書き込むことで、ラッパーがコミットを監視するかどうかは無関係になり、プロジェクト内のすべてのシンクが一度に閉じられます — 「既知の制限」にある Map フローなど、汚染分析が到達できないものも含みます。BeanPostProcessor は HttpSecurity DSL によって構築されたフィルターを認識します。これは AutowireBeanFactoryObjectPostProcessor がビーンファクトリーを通じてそれらを初期化するためです。このCVEに対する独立して公開された2つの修正は、まさにこの形状を使用しています（hmcts/idam-web-public、およびarmory-ioのSpinnakerフォークは同等の ObjectPostProcessor を使用）。

ステップ2は、ステップ1が対応できないプロジェクトをカバーします:

最後の行はコーナーケースではありません。nla/bamboo は7.0.3 — オープンソース修正のあるシリーズ — をSpring Boot BOMからのみ解決するため、バージョンチェックだけでは両方のステップでスキップされ、脆弱なままになります。したがって AddEagerHeaderWriterConfiguration は、プロジェクトがオープンソース修正を利用できかつ独自のバージョンを宣言している場合にのみアップグレードに委譲します。

生成されたクラスは、@EnableWebSecurity クラスが存在する場合はその隣に配置され、存在しない場合は @SpringBootApplication、次に任意の @Configuration にフォールバックするため、常にコンポーネントスキャンが到達する場所に配置されます。すでにヘッダーを先行書き込みしているプロジェクト、またはパッチ適用済みの OnCommittedResponseWrapper をベンダー提供しているプロジェクト（jogetworkflow/jw-community など）はそのまま残されます。

構成要素（上級者向け）

実行中のサーバーで検証済み

脆弱なSpring Security 6.4.12上の semgrep/cve-2026-22732-demo に適用し、組み込みTomcatに対して検証しました。その HeaderVerificationTest はセキュリティヘッダーが欠落していることを検証するため、正常に機能する修正ではテストが失敗します:

X-Frame-Options と Cache-Control も同じパターンに従います。

ビルドが成功するコーパスの16リポジトリ（特定された29のうち）全体で、修正は3つに対して設定を生成し、残りは正しくそのまま残しました:

修正済みの3つのリポジトリに対して修正を再実行しても追加の生成はないため、この修復は実プロジェクトの自身の出力に対して冪等です。

2つ目のより広いコーパスは、修正が実際に対象とする母集団 — シンクが不要なため、影響を受けるすべてのサーブレットSpring Securityアプリケーション — を対象としています。コード検索で見つかった64のプロジェクトのうち、52がビルド成功、48が影響を受けるバージョンを解決、38がパッチ適用され、そのうち35がコンパイル成功（残りの3つは生成ファイルなしでも同じように失敗）。Spring Security 5.2未満の8プロジェクトはすべて正しくスキップされました。SUSCEPTIBLE-REPOSITORIES.md のセクション8を参照してください。

制限事項

• WebFlux検出は異なるハザードであり、このCVEではありません。 OnCommittedResponseWrapper extends jakarta.servlet.http.HttpServletResponseWrapper のため、CVE-2026-22732はサーブレットのみに影響し、リアクティブアプリケーションはこれにさらされません。FindHttpResponseContentLengthOrFlushBuffer からの検出結果は類似のリアクティブパターンをフラグ付けし、手動レビューが必要ですが、修正は意図的にこれらに作用しません。AddEagerHeaderWriterConfiguration は、背後にサーブレットAPIなしで HeaderWriterFilter を参照できるモジュールをスキップします — フィルターは OncePerRequestFilter を拡張し、spring-security-web はサーブレットAPIを非推移的な provided 依存関係として保持するため、そこで生成すると cannot access jakarta.servlet.Filter で失敗します（apache/shenyu で確認済み）。
• Spring Security 5.2未満のバージョンは検出されますが修正されません。 HeaderWriterFilter.setShouldWriteHeadersEagerly は5.2で導入されます。4.0.4ではフィルターにはコンストラクタと doFilterInternal のみがあります。検出はEOLバージョンを報告しますが、コンパイルできない呼び出しを出力するのではなく、修復は保留されます。

データテーブル

実行方法

Moderne CLI経由:

mod run . --recipe io.moderne.recipe.cve202622732.FindSpringSecurityHeaderSuppression

rewrite.yml 経由:

---
type: specs.openrewrite.org/v1beta/recipe
name: com.example.DetectSpringSecurityHeaderSuppression
displayName: Detect CVE-2026-22732
recipeList:
  - io.moderne.recipe.cve202622732.FindSpringSecurityHeaderSuppression

評価コーパスの再現

repos.csv には、これらのレシピが開発・測定された75の公開リポジトリが、各評価時の正確なコミットに固定されてリストされています。いくつかは活発にメンテナンスされており、今後アップストリームでパッチ適用されるため、changeset 列が以下の数値を単なるもっともらしいものではなく再現可能にします。

mod git sync csv ./corpus repos.csv --with-sources
mod build ./corpus
mod run ./corpus --recipe=io.moderne.recipe.cve202622732.CveDevCenter
mod devcenter ./corpus --last-recipe-run

同期には約20秒と1.4 GBかかります。ビルドには約15分かかり、唯一の遅いステップです。mod devcenter は devcenter.html を corpus/.moderne/run/<runId>/ に書き込み、さらに組織サブディレクトリごとに1つ書き込みます。

org1 列はコーパスを、各リポジトリが存在する理由を反映したグループに分割します — 2つの脆弱な呼び出し形状に対する Servlet Sinks と WebFlux Sinks、すでにアップストリームで修復されたリポジトリの Patched、Spring Security自体や他の非消費者向けの Reference、実行中のサーバーに対して検証されたケースの Verified、ビルドツールカバレッジの Gradle、および大量サンプルの Wide です。

固定されたコミットでは、以下が期待されます:

その5つのうち4つは実際にSpring Securityを使用していません — spring-projects/spring-security はライブラリ自体、JoeyBling/bootplus はApache Shiroを使用、jenkinsci/stapler はサーブレットAPIを直接対象、infofabrik/reportserver には解決するMavenまたはGradleビルドがありません。5つ目の xtuer/template-app は spring-security-web:5.0.0.RELEASE を宣言していますが、そのGradleビルドは mod build 中に依存関係を一切解決しないため、どのレシピもバージョンを認識できません。影響を受けないものではなく未測定として扱ってください。

修正を適用して結果を確認するには:

mod run ./corpus --recipe=io.moderne.recipe.cve202622732.FixSpringSecurityHeaderSuppression
mod git apply ./corpus --last-recipe-run
mod exec ./corpus --last-recipe-run MODERNE_BUILD_TOOL_CHECK

mod git apply はチェックアウトにその場で書き込みます。コーパス全体での完全な check は遅く、この変更とは無関係の失敗（JDKツールチェーンの欠落、到達不能な依存関係リポジトリ、すでに失敗していたテスト）が表面化するため、意味のあるシグナルは適用前に同じコマンドを実行した場合との差分です。

リテラルなデモを超えてカバーされるもの

rewrite-program-analysis からの汚染分析はローカルデータフローとメソッドごとのサマリーを処理するため、以下のパターンが自動的に検出されます:

• 定数伝播されたContent-Lengthヘッダー名。 String h = "Content-Length"; response.setIntHeader(h, 42); がフラグ付けされます — フレームワークはローカル代入を通じてリテラルの汚染を追跡します。
• 呼び出しをラップするヘルパー — 汚染はメソッドサマリーを通じて戻り値を流れます。

既知の制限事項

• ジェネリックコンテナ型（Map、List、カスタムコレクション）を通るフロー。 stash.put("k", "Content-Length") の後に response.setIntHeader(stash.get("k"), 42) が続く場合、検出されません — put/getの同一性は分析にとって不透明です。

ライセンス

Moderne Proprietary。商用契約の条件に基づき、Moderneのお客様のみが使用できます。