CVE-2026-59341 in sealed-secrets
Zusammenfassung
von VulDB • 15.09.2026
In dem Controller für Sealed Secrets besteht eine Sicherheitslücke in den nicht authentifizierten POST-Endpunkten. Durch das Einreichen eines modifizierten Payloads mit benutzerdefinierter Go-Templating-Logik im Feld `spec.template.data` kann ein Angreifer mit Zugriff auf das interne Netzwerk den Handler als Entschlüsselungsorakel missbrauchen, um den vollständigen Klartext jedes Sealed Secrets wiederherzustellen.
Die POST-/v1/verify- und /v1/rotate-Handler rufen `Unseal()` auf, um die Zielgeheimnisse zu entschlüsseln, und rendern anschließend alle in `spec.template.data.*` gefundenen Go-Templates unter Verwendung des entschlüsselten Payloads als Auswertungskontext (pkg/apis/sealedsecrets/v1alpha1/sealedsecret_expansion.go). Fehler, die während der Template-Ausführung auftreten, spiegeln sich direkt in den resultierenden HTTP-Statuscodes wider.
Fehlende AEAD-Label-Bindung: Das Feld `spec.template.data` ist von der AEAD-authentifizierten-Daten-Label-Bindung des Chiffertexts mit den Metadaten ausgeschlossen. Infolgedessen kann ein Angreifer die gültigen Metadaten und encryptedData eines Ziels unverbatim kopieren, wodurch die AEAD-Entschlüsselung und Label-Validierung erfüllt werden, während `spec.template.data` frei durch beliebige Template-Logik ersetzt wird.
Side-channel-orakel: Fehler bei der Template-Ausführung werden direkt in HTTP-Antwortcodes abgebildet. HTTP 200 (OK) zeigt an, dass die Template-Ausführung erfolgreich war; HTTP 409 (Conflict) zeigt an, dass die Template-Ausführung fehlgeschlagen ist (z. B. über `{{ fail "..." }}`).
Durch das Einfügen bedingter Anweisungen wie `{{ if eq (substr 0 1 .password) "S" }}ok{{ else }}{{ fail "x" }}{{ end }}` erhält ein Angreifer einen HTTP-200-Status, wenn eine Zeichen-Vermutung korrekt ist, und einen HTTP-409-Status, wenn sie falsch ist. Diese unterschiedlichen Antworten leiten pro Anfrage ein Bit zur Gleichheit eines Zeichens weiter, was die vollständige Extraktion des Geheimnisses über aufeinanderfolgende Abfragen ermöglicht.
Angriffsvektor & Voraussetzungen: nicht authentifiziert; erfordert Netzwerkzugriff zum internen Service-Port (:8080) des Controllers. Obwohl dieser Dienst standardmäßig nicht für das öffentliche Internet freigegeben ist, ist er für jedes Pod innerhalb des Kubernetes-Clusters oder über eine kubectl port-forward-Verbindung zugänglich.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.