71 уязвимость за июнь: что произошло в экосистеме Spring

В июне 2026 года Broadcom опубликовала сведения о 71 уязвимости в экосистеме Spring. Из них 31 получила уровень опасности High, 36 — Medium и четыре — Low. Для сравнения: за весь 2025 год в проектах Spring было опубликовано 16 CVE.

Речь не о 71 дефекте непосредственно в Spring Boot. Список охватывает Spring Framework, Spring Security, Spring Data, Spring Web Services, Spring for Apache Kafka, Micrometer и другие компоненты. Некоторые входят в типичный стек приложения напрямую, другие появляются в нём как транзитивные зависимости. В обоих случаях уязвимый код становится частью поверхности атаки, даже если команда явно не добавляла соответствующую библиотеку в pom.xml или build.gradle.

Само по себе число CVE ещё не описывает реальный риск. Компонент может отсутствовать в сборке, уязвимый код может быть недостижим в конкретной конфигурации, а диапазон затронутых версий может не пересекаться с тем, что работает в продакшене. Поэтому такой список нельзя просто загрузить в трекер и получить 71 одинаково срочную задачу. Сначала нужно определить, какие компоненты используются, какие версии установлены и при каких условиях проявляется каждая уязвимость.

Но масштаб июньской публикации всё равно показателен. Поиск уязвимостей вышел на новый уровень: ИИ-инструменты умеют анализировать большие кодовые базы, прослеживать потенциально опасные пути выполнения и помогать исследователям готовить проверяемые сценарии эксплуатации. В 2026 году Anthropic сообщила уже о 2300 уязвимостях, переданных разработчикам 392 open source-проектов после проверки специалистами. В Linux система Xint Code примерно за час обнаружила Copy Fail — уязвимость повышения привилегий, которая затрагивала основные дистрибутивы.

Это не означает, что всю 71 уязвимость в Spring нашёл ИИ. В бюллетенях указаны разные источники: внутренние проверки Broadcom и сообщения внешних исследователей. Мы говорим о том, что общий процесс уже изменился. Анализировать код и находить подозрительные участки теперь можно быстрее, а значит, поток новых отчётов будет расти. Для команд, которые продолжают использовать неподдерживаемые ветки, это особенно чувствительно: новые дефекты появляются быстрее, чем их можно закрывать обычным обновлением внутри завершившегося жизненного цикла.

Мы сопоставили июньский список с составом Axiom Spring. Во всех компонентах, которые входят в поставку, перечисленные уязвимости устранены. Если исправление для компонента ещё не подготовлено и не прошло проверку, мы не включаем этот компонент в релиз. После устранения уязвимости и тестирования он может вернуться в состав поставки. Поэтому прочерк в таблице означает не пропущенное исправление, а отсутствие соответствующего уязвимого компонента в продукте.

Заглянем в историю репозиториев Spring

Отдельный интерес представляет хронология исправлений. История репозиториев показывает, что работу над частью дефектов Broadcom начала ещё до публикации бюллетеней: самые ранние авторские даты некоторых коммитов приходятся на апрель и май, тогда как сведения о CVE появились в июне. Это обычная часть coordinated disclosure: разработчик получает закрытый отчёт, готовит и проверяет исправление, а подробности раскрывают после того, как патч готов к выпуску.

При чтении истории Git важно учитывать две даты:

• «Исправлено» в таблице — дата самого раннего найденного коммита с изменением.
• «Опубликовано» — ориентировочный момент, когда коммит появился в публичном git-репозитории. 

Специфика в том, что дата коммита сохраняется при переносах, поэтому их порядок следования произвольный, а в публичном репозитории Spring они могут появляться с большой задержкой.

В таблице ниже приведены найденные коммиты и версии компонентов из Spring Boot 2.7.18, в которой CVE не закрыты. Эта хронология помогает понять, сколько времени проходит между подготовкой исправления и публичным раскрытием уязвимости.

История коммитов показывает, как исправления готовились, но ничего не говорит о структуре самого массива уязвимостей. Чтобы понять, где сосредоточен риск, мы рассмотрели список в нескольких разрезах: по уровню опасности, компонентам, функциональным областям, доступности атаки, возможным последствиям и техническому механизму.

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

По уровню опасности

Сначала посмотрим на распределение по уровню опасности. На диаграмме указаны уровень опасности, количество CVE в каждой группе и их доля от общего числа. Уровень опасности отражает потенциальную тяжесть последствий, но не учитывает, используется ли компонент в конкретном приложении и достижим ли уязвимый код.

По компонентам Spring

Следующий разрез показывает, в каких проектах экосистемы опубликовано больше всего уязвимостей. На диаграмме приведено общее число CVE для компонента, а «High», «Medium» и «Low» показывают их распределение по уровню опасности. Это позволяет увидеть не только количество записей, но и их состав.

По функциональной области

Отдельные проекты Spring часто решают одну общую задачу, поэтому мы объединили их по функциональным областям. В таблице указана область применения, относящиеся к ней компоненты и суммарное количество CVE. Такое представление помогает оценить, какие части типичного Spring-приложения затронуты сильнее: веб-стек, работа с данными, идентификация или наблюдаемость.

По области доступности атаки и требованиям CVSS

Количество CVE не показывает, насколько легко добраться до уязвимого кода. В этой таблице разобраны эксплуатационные метрики CVSS: вектор атаки, её сложность, необходимые привилегии, участие пользователя и выход последствий за границы компонента.

Как читать вектор CVSS

Векторы вида AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N — это метрики CVSS v3.1, записанные сокращённо. Каждая пара «буква:значение» описывает одно свойство оценки:

Примеры к нашим CVE:

• C:H/I:H/A:N — высокая потеря конфиденциальности и целостности, на доступность не влияет.
• PR:N — привилегии не требуются; PR:L — нужны низкие привилегии.
• AC:L — низкая сложность атаки (просто); AC:H — высокая (нужны особые условия).
• S:C — ущерб выходит за пределы уязвимого компонента (в текущем списке таких нет: все три CVE с S:U).

Практический сетевой разрез:

• 44 CVE: сеть, без привилегий и без действий пользователя (AV:N/PR:N/UI:N);
• 23 CVE: дополнительно низкая сложность (AV:N/AC:L/PR:N/UI:N);
• 16 CVE требуют действия пользователя, поэтому их приоритет сильнее зависит от реального browser-facing сценария;
• 11 CVE имеют измененную область воздействия (S:C): последствие выходит за исходную границу уязвимого компонента.

По воздействию на конфиденциальность, целостность и доступность

Следующий разрез описывает возможные последствия для трёх базовых свойств безопасности: конфиденциальности, целостности и доступности. Значения High, Low и None показывают степень воздействия, а столбец «Затронуто всего» — количество CVE, которые хотя бы в какой-то мере влияют на соответствующее свойство. Строки пересекаются: одна уязвимость может одновременно влиять на несколько свойств.

По техническому механизму

Наконец, мы сгруппировали уязвимости по механизму эксплуатации: отказ в обслуживании, инъекции, небезопасная десериализация, обход аутентификации, ошибки обработки XML и другие классы. В первой колонке указан технический класс, во второй — количество и идентификаторы относящихся к нему CVE. Категории могут пересекаться, поэтому их сумма превышает 71: одна уязвимость иногда использует сразу несколько механизмов или приводит к нескольким типам последствий.

Полный список уязвимостей

Агрегированные данные позволяют увидеть общую картину, но для приоритизации этого недостаточно. Ниже приведён полный список. Для каждой CVE указаны компонент, уровень опасности, поверхность атаки, технический класс, ключевое условие эксплуатации и влияние на конфиденциальность, целостность и доступность. Эти условия особенно важны: именно по ним можно определить, применима ли уязвимость к конкретному приложению.

Июньский список не означает, что любое приложение на Spring Boot 2.7 содержит 71 эксплуатируемую уязвимость. Реальная оценка начинается не с общего числа, а с состава сборки, версий компонентов, конфигурации и достижимости уязвимого кода.

ИИ снижает стоимость анализа больших кодовых баз, поэтому уязвимости находят быстрее и в большем количестве. Для поддерживаемых веток это означает более плотный поток обновлений.

История коммитов показывает, что для части июньских CVE исправления начали готовить за несколько недель до публичного раскрытия. Получается, на момент публикации данных, разработчики уже не только знали о проблеме, но и успели подготовить соответствующий патч.

В Axiom Spring мы проверили июньские уязвимости применительно к фактическому составу продукта. Во всех компонентах, входящих в поставку, они устранены. Компонент с неисправленной уязвимостью в релиз не включается и добавляется только после исправления и тестирования. Это не отменяет необходимость инвентаризации и анализа применимости CVE, но не оставляет заведомо уязвимый код в поддерживаемой поставке.