Эти три перегрузки не переопределены в OnCommittedResponseWrapper. Последующие записи тела завершают объявленную длину, и контейнер фиксирует ответ без срабатывания ленивого записи заголовков.

Рецепт ограничен наличием Spring Security — он ничего не выдаёт в файлах, которые не ссылаются ни на один тип org.springframework.security.*, — а также затронутыми диапазонами версий Spring Security. Согласно рекомендации Spring, опубликованной 2026-03-19, затронутые диапазоны и исправленные версии:

Проекты, разрешающие версию Spring Security на уровне исправления или выше в своей серии (или в любой будущей серии после 7.0 / 6.5), считаются незатронутыми и не получают маркеров ни по отдельным точкам, ни по файлам. Проекты, где версию не удаётся разрешить, переходят к обычному обнаружению по шаблонам, чтобы сканер скорее сообщал о находке, которую не может опровергнуть. Таблица данных SpringSecurityVersionByProject по-прежнему записывает разрешённую версию и помечает каждый проект как затронутый или нет, чтобы вы могли проверить, что было отфильтровано.

Что намеренно НЕ помечается

Это выглядит опасно, но отслеживается обёрткой, поэтому заголовки безопасности записываются до фиксации ответа:

Конечная точка /vuln/flush в демо Semgrep утверждает, что триггером является flushBuffer(), но на уязвимой версии Spring Security 6.4.12 ответ фактически возвращает все шесть заголовков безопасности. Настоящие триггеры в демо — это вызовы setIntHeader("Content-Length", ...) в /vuln/stream и /vuln/content-length.

Обнаружение

Запустите этот:

Строительные блоки (продвинутый уровень)

Агрегатор выше состоит из двух более мелких рецептов. Вы можете вызывать их по отдельности, если нужна только одна проверка.

Исправление

Запустите этот:

Он выполняет два шага по порядку.

1. Переход на исправление в собственной серии проекта. Spring Security опубликовал исправление как 6.5.9 и 7.0.4 в Maven Central. Каждый переход ограничен предусловием FindAffectedSpringSecuritySeries, поскольку UpgradeDependencyVersion проверяет только, что целевая версия новее — при указании 7.0.4 он охотно перетащил бы проект на 5.8 через две мажорные версии.

2. Добавление конфигурации упреждающей записи заголовков для того, что шаг 1 не смог исправить. Это генерирует один класс @Configuration на проект:

Запись заголовков заранее делает неважным, наблюдает ли обёртка за фиксацией, поэтому это закрывает все точки в проекте сразу — включая те, до которых анализ заражения не может добраться, например поток через Map в разделе «Известные ограничения». BeanPostProcessor видит фильтры, созданные DSL HttpSecurity, потому что AutowireBeanFactoryObjectPostProcessor инициализирует их через фабрику бинов. Две независимо опубликованные исправления для этой CVE используют ровно такую форму (hmcts/idam-web-public, и форки Spinnaker от armory-io через эквивалентный ObjectPostProcessor).

Шаг 2 покрывает проекты, которым шаг 1 не может помочь:

Последняя строка — не крайний случай. nla/bamboo разрешает 7.0.3 — серию с исправлением с открытым исходным кодом — полностью из BOM Spring Boot, поэтому проверка версии сама по себе пропустила бы его на обоих шагах и оставила бы уязвимым. Поэтому AddEagerHeaderWriterConfiguration откладывает переход только тогда, когда у проекта есть доступное исправление с открытым исходным кодом и он объявляет собственную версию.

Сгенерированный класс размещается рядом с классом @EnableWebSecurity, если такой существует, с откатом на @SpringBootApplication, а затем на любой @Configuration, так что он всегда попадает туда, куда доходит компонентное сканирование. Проекты, которые уже записывают заголовки упреждающе или поставляют пропатченный OnCommittedResponseWrapper (как jogetworkflow/jw-community), не трогаются.

Строительные блоки (продвинутый уровень)

Проверено на работающем сервере

Применено к semgrep/cve-2026-22732-demo на уязвимой версии Spring Security 6.4.12, против встроенного Tomcat. Его HeaderVerificationTest утверждает, что заголовки безопасности отсутствуют, поэтому рабочее исправление заставляет его падать:

X-Frame-Options и Cache-Control следуют той же схеме.

По 16 репозиториям корпуса, которые собираются (из 29 выявленных), исправление сгенерировало конфигурацию для трёх и корректно оставило остальные без изменений:

Повторный запуск исправления по трём пропатченным репозиториям ничего дополнительно не генерирует, поэтому исправление идемпотентно относительно собственного вывода на реальных проектах.

Второй, более широкий корпус нацелен на популяцию, которую исправление фактически охватывает — любое затронутое servlet-приложение Spring Security, поскольку точка не требуется. Из 64 таких проектов, найденных поиском по коду, 52 собрались, 48 разрешили затронутую версию, и 38 были пропатчены; 35 из них компилируются (остальные три падают одинаково и без сгенерированного файла). Все 8 проектов на Spring Security ниже 5.2 были корректно пропущены. См. раздел 8 в SUSCEPTIBLE-REPOSITORIES.md.

Ограничения

• Обнаружения WebFlux — это другая опасность, не эта CVE. OnCommittedResponseWrapper extends jakarta.servlet.http.HttpServletResponseWrapper, поэтому CVE-2026-22732 касается только servlet, и реактивное приложение ей не подвержено. Находки из FindHttpResponseContentLengthOrFlushBuffer помечают аналогичный реактивный паттерн и всё ещё требуют ручной проверки, но исправление намеренно на них не действует. AddEagerHeaderWriterConfiguration пропускает любой модуль, который видит HeaderWriterFilter без servlet API за ним — фильтр расширяет OncePerRequestFilter, а spring-security-web несёт servlet API как нетранзитивную зависимость provided, поэтому генерация там падает с cannot access jakarta.servlet.Filter (наблюдалось на apache/shenyu).
• Версии ниже Spring Security 5.2 обнаруживаются, но не исправляются. HeaderWriterFilter.setShouldWriteHeadersEagerly появляется в 5.2; на 4.0.4 у фильтра есть только конструктор и doFilterInternal. Обнаружение по-прежнему сообщает об EOL-версиях, но исправление удерживается, а не выдаёт вызов, который не может скомпилироваться.
• Упреждающие заголовки записываются для каждого запроса, включая те, что позже заменяются диспетчеризацией ошибки. Это компромисс, которого избегает ленивое поведение Spring Security по умолчанию, и именно поэтому переход выполняется первым.

Таблицы данных

Запуск

Через Moderne CLI:

Через rewrite.yml:

Воспроизведение оценочного корпуса

repos.csv перечисляет 75 публичных репозиториев, на которых эти рецепты разрабатывались и измерялись, закреплённых за точным коммитом, на котором каждый оценивался. Некоторые активно поддерживаются и будут пропатчены выше по течению, поэтому колонка changeset — это то, что делает числа ниже воспроизводимыми, а не просто правдоподобными.

Синхронизация занимает около 20 секунд и 1,4 ГБ; сборка занимает примерно 15 минут и является единственным медленным шагом. mod devcenter записывает devcenter.html в corpus/.moderne/run/<runId>/, плюс по одному на подкаталог организации.

Колонка org1 делит корпус на группы, отражающие причину присутствия каждого репозитория — Servlet Sinks и WebFlux Sinks для двух уязвимых форм вызовов, Patched для репозиториев, уже исправленных выше по течению, Reference для самого Spring Security и других не-потребителей, Verified для случая, проверенного на работающем сервере, Gradle для покрытия инструментов сборки и Wide для массовой выборки.

Ожидайте на закреплённых коммитах:

Четыре из этих пяти действительно не используют Spring Security — spring-projects/spring-security это сама библиотека, JoeyBling/bootplus использует Apache Shiro, jenkinsci/stapler нацелен непосредственно на servlet API, а infofabrik/reportserver не имеет сборки Maven или Gradle для разрешения. Пятый, xtuer/template-app, объявляет spring-security-web:5.0.0.RELEASE, но его сборка Gradle вообще не разрешает зависимостей во время mod build, поэтому ни один рецепт не может увидеть версию. Считайте его неизмеренным, а не незатронутым.

Чтобы применить исправление и проверить результат:

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 на условиях коммерческого контракта.