CVE-2026-59341 in sealed-secrets
Summary
by MITRE • 09/15/2026
A security vulnerability exists in the Sealed Secrets controller's unauthenticated POST endpoints. By submitting a modified payload containing custom Go template logic in spec.template.data, an attacker with internal network access can abuse the handler as a decryption oracle to recover the full plaintext of any sealed secret.
The POST /v1/verify and /v1/rotate handlers call Unseal() to decrypt target secrets, then render any Go templates found in spec.template.data.* using the decrypted payload as the evaluation context (pkg/apis/sealedsecrets/v1alpha1/sealedsecret_expansion.go). Errors encountered during template execution are directly reflected in the resulting HTTP response status codes.
Missing AEAD label binding: the spec.template.data field is omitted from the AEAD authenticated-data label binding ciphertext to metadata. As a result, an attacker can copy a target's valid metadata and encryptedData verbatim, satisfying AEAD decryption and label validation, while freely replacing spec.template.data with arbitrary template logic.
Side-channel oracle: template execution errors map directly to HTTP response codes. HTTP 200 (OK) indicates template execution succeeded; HTTP 409 (Conflict) indicates template execution failed (e.g. via {{ fail "..." }}).
By injecting conditional statements such as {{ if eq (substr 0 1 .password) "S" }}ok{{ else }}{{ fail "x" }}{{ end }}, an attacker receives an HTTP 200 status when a character guess is correct and an HTTP 409 when it is incorrect. This differential response leaks one character-equality bit per request, allowing full secret extraction over successive queries.
Attack vector & prerequisites: unauthenticated; requires network access to the controller's internal service port (:8080). Although this service is not exposed to the public internet by default, it is accessible to any pod within the Kubernetes cluster or via a kubectl port-forward connection.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
The Sealed Secrets controller for Kubernetes contains a critical vulnerability affecting its unauthenticated POST endpoints, specifically /v1/verify and /v1/rotate. This flaw allows an attacker with internal network access to abuse these handlers as decryption oracles, enabling the recovery of full plaintext from any sealed secret managed by the controller. The core technical issue stems from how the controller processes encrypted data during verification and rotation operations. When a POST request is received, the handler invokes an Unseal function to decrypt the target secrets using AES-GCM authenticated encryption. Following decryption, if the payload contains custom Go template logic within the spec.template.data field, this plaintext content is rendered using the decrypted payload as the evaluation context. This design choice creates a significant security gap because it exposes internal processing states through HTTP response codes, which can be leveraged for side-channel attacks.
The fundamental cryptographic weakness lies in the missing AEAD label binding for the spec.template.data field. In standard AES-GCM implementations, associated data such as metadata is bound to the ciphertext to ensure integrity and authenticity. However, in this implementation, the spec.template.data field is omitted from the authenticated-data label binding process. Consequently, an attacker can manipulate the request by copying a target secret's valid metadata and encryptedData verbatim while freely replacing the spec.template.data section with arbitrary Go template logic. Because the AEAD validation only checks the bound components like metadata and ciphertext, it does not detect tampering in the unbound template data field. This allows the malicious payload to pass integrity checks and proceed to execution within the controller's environment.
The exploitation of this vulnerability relies on a side-channel oracle mechanism derived from error handling practices during template rendering. The HTTP response status codes directly reflect the outcome of Go template execution, creating a differential timing or state-based leak. Specifically, an HTTP 200 OK status indicates that the template executed successfully without errors, while an HTTP 409 Conflict status signifies that template execution failed due to runtime errors such as those triggered by explicit failure directives like {{ fail "..." }}. This binary feedback loop provides a reliable channel for information leakage, allowing attackers to perform character-by-character extraction of sensitive secrets through iterative queries.
To exploit this vulnerability, an attacker constructs conditional Go templates within the spec.template.data field that test specific characters against known values or patterns. For instance, by injecting logic such as {{ if eq (substr 0 1 .password) "S" }}ok{{ else }}{{ fail "x" }}, the attacker can determine whether the first character of a password is 'S'. If the response is HTTP 200, the guess is correct; if it is HTTP 409, the guess is incorrect. This differential response leaks one bit of information per request regarding character equality. By systematically iterating through possible characters and positions, an attacker can reconstruct the entire plaintext value of any sealed secret over successive queries. The attack vector requires only unauthenticated access to the controller's internal service port, typically :8080, which is accessible to any pod within the Kubernetes cluster or via kubectl port-forward connections, making it feasible for lateral movement scenarios after initial compromise.
From a classification perspective, this vulnerability aligns with CWE-295 Improper Certificate Validation and CWE-347 Improper Verification of Cryptographic Signature due to the failure to bind associated data correctly in authenticated encryption. It also maps to ATT&CK technique T1087 Account Discovery as it facilitates unauthorized access to service account credentials, and potentially T1552 Unsecured Credentials if used to extract stored secrets for further exploitation. The operational impact is severe, as sealed secrets are intended to provide a secure mechanism for storing sensitive data in Kubernetes manifests without exposing plaintext in version control systems or cluster configurations. Compromise of these secrets can lead to unauthorized access to databases, APIs, and other critical infrastructure components protected by the leaked credentials.
Mitigation strategies must address both the architectural flaw and immediate operational risks. The primary remediation involves patching the Sealed Secrets controller to ensure that all fields involved in template rendering are included in the AEAD authenticated-data label binding process. This prevents attackers from modifying the spec.template.data field without invalidating the authentication tag, thereby blocking the oracle attack vector entirely. Additionally, developers should avoid exposing internal processing errors directly via HTTP status codes for sensitive operations; instead, generic error messages should be returned to prevent side-channel leakage. Network-level controls such as restricting access to port 8080 using Kubernetes Network Policies can limit exposure until patches are applied. Regular auditing of sealed secrets and rotation of compromised credentials is also essential to minimize the window of opportunity for attackers exploiting this vulnerability in production environments.