Затронутые диапазоны: 5.7.0–5.7.21, 5.8.0–5.8.23, 6.3.0–6.3.14, 6.4.0–6.4.14, 6.5.0–6.5.8, 7.0.0–7.0.3. Spring Boot 2.7.18 фиксирует Spring Security 5.7.11, ровно внутри первого диапазона:

Запуск

run.sh фиксирует JAVA_HOME, потому что Spring Boot 2.7.x не может работать на JDK 25, который mvn выбирает по умолчанию на этой машине. Переопределите через JAVA_HOME_17=/path/to/jdk17.

Он также по умолчанию собирается с -s settings-chainguard.xml, потому что исправленный родительский POM отсутствует в Maven Central. Установите MAVEN_SETTINGS=/path/to/your/settings.xml, чтобы указать другое расположение, или MAVEN_SETTINGS=, чтобы собирать исключительно из Central — что работает только для стандартного 2.7.18.

exploit.sh считывает фактические версии spring-security-web и spring-boot из target/*.jar, поэтому его баннер всегда сообщает то, что действительно запущено, а не захардкоженную строку.

Конфигурация

SecurityConfig применяет вообще никакой кастомизации заголовков — действуют настройки Spring Security по умолчанию, что как раз и есть то, на что полагается приложение, заботящееся о безопасности. Каждый эндпоинт возвращает одно и то же конфиденциальное тело:

Меняется только то, как контроллер записывает ответ.

Измеренные результаты

Только /vuln/content-length/account меняет состояние при исправлении CVE, поэтому только по нему exploit.sh выносит свой вердикт. Остальные — контрольные.

CVE — setIntHeader("Content-Length", n) → полный обход

Три строки обычного на вид кода контроллера снимают каждый заголовок, обещанный Spring Security:

Ни X-Frame-Options, ни X-Content-Type-Options, ни Cache-Control, ни Pragma, ни Expires, ни X-XSS-Protection. Сравните с /safe/account, который несёт все шесть. Ответ может быть встроен во фрейм с любого origin, подвержен MIME-sniffing и кэшируем — при этом отдавая номер карты.

Случай по замыслу — установленный приложением заголовок кэша → подавление кэширования

Исправлено: более ранняя версия этого README называла это «эксплойтом 2» и утверждала, что это условие, документированное в advisory. Это не часть CVE-2026-22732, и никакое обновление это не исправляет. CacheControlHeadersWriter побайтово идентичен в 5.7.11, 5.7.14-0.cgr.2, 6.5.8 (последняя уязвимая) и 6.5.9 (первая исправленная) — проверено сравнением sources jar. Его Javadoc прямо указывает на это поведение: «Inserts headers to prevent caching if no cache control headers have been specified.»

Это всё равно стоит демонстрировать, потому что утечка реальна и остаточный риск сохраняется после патча. CacheControlHeadersWriter прекращает работу, если Cache-Control, Expires или Pragma уже присутствует, поэтому установка любого одного из трёх подавляет все директивы no-store от Spring Security. Достаточно одной благонамеренной строки:

Expires считается «присутствующим» в таблице выше, но с дружественным атакующему значением, выбранным приложением — Expires: 0 от Spring Security был заменён, а не просто отброшен. Данные держателей карт теперь могут храниться каждым браузером и общим прокси на пути до 2099 года.

На исправленной сборке /vuln/content-length/account переключается на NOT cacheable, тогда как /vuln/cache/account остаётся точно как выше. Исправляет это только код приложения или обратный прокси — что и есть полезная вещь, которую стоит сказать вслух на демо: обновление библиотеки закрывает CVE и оставляет это нетронутым.

Два отрицательных результата, оставленных намеренно

Несколько широко распространённых разборов — включая публичный репозиторий воспроизведения — указывают response.getOutputStream() и response.flushBuffer() как триггеры, объясняя, что «ответ фиксируется до того, как Spring Security сможет внедрить свои заголовки». На Spring Security 5.7.11 это неверно. Оба эндпоинта доставляют все шесть заголовков.

/diag/committed показывает, почему это объяснение не работает. После записи 12 KB ответ действительно фиксируется внутри контроллера, но заголовки всё равно приходят:

OnCommittedResponseWrapper переопределяет flushBuffer() и записи в output-stream, поэтому он выпускает свои заголовки раньше этих фиксаций. Один лишь порядок фиксации не является багом; путь с объявленным Content-Length — является. Сам Spring advisory никогда не поддерживает историю о порядке фиксации.

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

Переход от уязвимого к исправленному

Одна строка в pom.xml, и ничего больше. Ни изменения исходников, ни изменения свойств, ни мажорного обновления Spring Boot:

Это перефиксирует spring-security.version с 5.7.11 на 5.7.14-0.cgr.2 (и spring-framework.version с 5.3.31 на 5.3.39-0.cgr.4) через spring-boot-dependencies родителя. Измерено:

Бэкпорт — это и есть upstream-исправление

При сравнении sources jar spring-security-web важен только один файл. 5.7.11 → 5.7.14-0.cgr.2 добавляет переопределения setHeader / setIntHeader / addIntHeader в OnCommittedResponseWrapper, каждое из которых направляет Content-Length через setContentLength():

До исправления это делал только addHeader, поэтому setIntHeader("Content-Length", n) оставлял отслеживаемую длину обёртки на 0, onResponseCommitted() никогда не срабатывал, и HeaderWriterFilter никогда не записывал свои заголовки до того, как Tomcat фиксировал ответ.

Тот же фрагмент появляется дословно при сравнении upstream 6.5.8 (последняя уязвимая) с 6.5.9 (первая исправленная), так что это официальное исправление, перенесённое бэкпортом, а не перереализация. Сборка Chainguard добавляет две проверки на null, которых нет в upstream 6.5.9 (value != null в перегрузке для String, и (csq != null) ? csq.length() : 4 в append).

Другие меры защиты

Spring Security 5.7.x — end-of-life в upstream; исправления OSS выходят только в 6.4.15 / 6.5.9 / 7.0.4+. Если пересобранный 5.7.x не вариант:

1. Уйти с 5.7.x — миграция на Spring Boot 3.x.
2. Обходной путь — установить HeaderWriterFilter.shouldWriteHeadersEagerly = true через ObjectPostProcessor. Согласно advisory это меняет поведение: записанные приложением заголовки тогда переопределяют только конкретные заголовки, а не подавляют заголовки Spring Security. Это также исправляет /vuln/cache/account, чего не делает обновление версии.
3. Коммерческая поддержка — бэкпорты Tanzu Spring Enterprise для 5.7.x/5.8.x.
4. Эшелонированная защита — устанавливайте заголовки на обратном прокси / ingress, чтобы отброшенный заголовок приложения не был единственным средством контроля. Это единственный из перечисленных вариантов, который покрывает оба эндпоинта.

Ничто из этого не подключено к этому проекту, поэтому уязвимое поведение является поведением по умолчанию, а исправленное состояние достижимо единственным изменением <version> выше.

Патчинг встроенного Tomcat без обновления Spring Boot

Boot 2.7.18 фиксирует Tomcat 9.0.83, который grype . помечает 34 CVE (4 Critical). Все они исправлены в 9.0.118 или ниже, а 9.0.118 — самый новый релиз 9.0.x — так что одно свойство очищает весь набор:

spring-boot-dependencies объявляет каждый артефакт tomcat-embed-* через это единственное свойство, поэтому его переопределение перефиксирует core, el и websocket вместе. Проверено:

Ограничение: оставайтесь на линии 9.0.x. Tomcat 10+ перевёл Servlet API на jakarta.*, тогда как Spring Framework 5.3 компилируется против javax.servlet, поэтому обновление до 10.x/11.x падает во время выполнения с NoClassDefFoundError на типах servlet.

Патчинг всего остального, всё ещё в пределах каждой мажорной линии

Тот же механизм применён к остальным управляемым зависимостям Boot 2.7.18. Никаких мажорных обновлений и никакого обновления Spring Boot:

Эти переопределения взаимодействуют с исправленным родителем, поэтому знайте, что они делают, прежде чем демонстрировать. На 2.7.18-0.cgr.3 родитель уже предоставляет tomcat.version 9.0.118, logback.version 1.2.13 и snakeyaml.version 1.33 — эти три строки становятся точными дубликатами и могут быть удалены без каких-либо изменений. Строки jackson-bom.version и log4j2.version всё ещё делают реальную работу: исправленный родитель сохраняет стандартные 2.13.5 / 2.17.2 от Boot, поэтому переопределения побеждают, и эти две зависимости разрешаются в обычные upstream-сборки, а не в собранные Chainguard. spring-framework.version закомментирован намеренно, что и позволяет пройти 5.3.39-0.cgr.4 от родителя.

Прогресс grype .

Полностью очищено: Tomcat (34), Jackson (7), log4j (1). В целом 99 → 43, Highs 39 → 12.

Проверено после каждого обновления: приложение загружается на Tomcat/9.0.118, все шесть эндпоинтов возвращают 200, и CVE воспроизводится побайтово. Spring Boot всё ещё 2.7.18, а Spring Security всё ещё 5.7.11, поэтому CVE-2026-22732 не затронута — в чём и смысл этого раздела, а также его честный предел: патчинг всего вокруг не делает ничего для CVE в application-framework. Для исправления этой нужно обновление родителя, а не свойство.

Почему Logback останавливается на 1.2.13

Последняя 1.x — 1.6.3 — та же мажорная версия, так что номинально в области охвата. Она не работает. Logback 1.3+ заменил SLF4J 1.7 StaticLoggerBinder на провайдер SLF4J 2.x ServiceLoader, а LogbackLoggingSystem из Boot 2.7 вызывает StaticLoggerBinder напрямую. Измерено с 1.5.38:

Чтобы выйти из этого, нужны SLF4J 2.x (мажорное обновление) и система логирования Boot 3.x. 1.2.13 — это реальный потолок, оставляющий 6 находок Logback (2 Medium, 4 Low) неисправимыми на этой линии.

Оставшиеся 43

Две из трёх оставшихся Critical стоит прочитать внимательно, а не по баллам:

• CVE-2016-1000027 (spring-web, исправление 6.0.0) — десериализация через HttpInvokerServiceExporter. Это приложение не использует HTTP Invoker, поэтому здесь она недостижима.
• CVE-2024-38821 (spring-security-web, исправление 5.7.13) — обход авторизации статических ресурсов в WebFlux. Это servlet-приложение, поэтому тоже недостижима. Она исправима в пределах мажорной версии (5.7.13/5.7.14 есть на Central) и была оставлена только чтобы этот раздел оставался зафиксированным на 5.7.11. Исправленный родитель очищает её как побочный эффект, поскольку 5.7.14-0.cgr.2 прошёл версию исправления.
• CVE-2026-22732 — намеренна в уязвимом состоянии; очищается обновлением родителя.

Остаток структурный: Spring Framework 5.3.x и Spring Security 5.7.x оба EOL. Это, а не Tomcat или Jackson, — настоящий аргумент за миграцию на Boot 3.x.

Структура

Аутентификация — permitAll, а CSRF отключён, чтобы curl работал без аутентификации — ни то, ни другое не является частью этой CVE.

Источники

• spring.io/security/cve-2026-22732 — официальный advisory
• GHSA-mf92-479x-3373
• NVD CVE-2026-22732
• Broadcom / Tanzu write-up
• HeroDevs analysis
• semgrep/cve-2026-22732-demo — воспроизведение, чьи утверждения о stream/flush здесь не подтвердились
• Red Hat Bugzilla #2449306