CVE-2026-59341 in sealed-secretsИнформация

Сводка

по VulDB • 15.09.2026

В контроллере Sealed Secrets существует уязвимость безопасности в неаутентифицированных конечных точках POST. Отправляя модифицированный полезный груз, содержащий пользовательскую логику шаблонов Go в поле spec.template.data, атакующий с доступом к внутренней сети может использовать обработчик как оракул расшифровки для восстановления полного открытого текста любого запечатанного секрета (sealed secret).

Обработчики POST /v1/verify и /v1/rotate вызывают функцию Unseal() для расшифровки целевых секретов, а затем обрабатывают любые шаблоны Go, найденные в spec.template.data.*, используя расшифрованный полезный груз как контекст оценки (pkg/apis/sealedsecrets/v1alpha1/sealedsecret_expansion.go). Ошибки, возникающие во время выполнения шаблона, напрямую отражаются в кодах состояния HTTP-ответа.

Отсутствие привязки меток AEAD: поле spec.template.data исключено из привязки аутентифицированных данных (authenticated-data) шифротекста к метаданным. В результате атакующий может скопировать действительные метаданные и зашифрованные данные целевого объекта дословно, удовлетворяя требованиям расшифровки AEAD и проверки меток, при этом свободно заменяя spec.template.data произвольной логикой шаблонов.

Оракул побочных каналов: ошибки выполнения шаблона напрямую отображаются в коды состояния HTTP. Код 200 (OK) указывает на успешное выполнение шаблона; код 409 (Conflict) указывает на сбой выполнения шаблона (например, через {{ fail "..." }}).

Внедряя условные операторы, такие как {{ if eq (substr 0 1 .password) "S" }}ok{{ else }}{{ fail "x" }}{{ end }}, атакующий получает статус HTTP 200 при правильном угадывании символа и статус HTTP 409 при ошибке. Этот дифференциальный ответ позволяет утечки одного бита равенства символов за каждый запрос, что обеспечивает полную извлечение секрета посредством последовательных запросов.

Вектор атаки и требования: неаутентифицированный доступ; требуется сетевой доступ к внутреннему порту службы контроллера (:8080). Хотя эта служба по умолчанию не доступна в публичном интернете, она доступна для любого пода внутри кластера Kubernetes или через соединение kubectl port-forward.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Ответственный

Vmware

Резервировать

04.07.2026

Раскрытие

15.09.2026

Модерация

принято

Вход

VDB-404087

EPSS

0.00000

KEV

Нет

Деятельности

Очень низкий

Источники

Interested in the pricing of exploits?

See the underground prices here!