Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.2",
  "pubDate": "2026-09-15T10:17:05.673Z",
  "pubdate": "2026-09-15T10:17:05.673Z",
  "executiveSummary": "The Sealed Secrets controller is susceptible to a critical information disclosure vulnerability arising from insecure Go template evaluation within its unauthenticated /v1/verify and /v1/rotate endpoints.\nThe vulnerability originates from a failure to bind the spec.template.data field to the AEAD (Authenticated Encryption with Associated Data) metadata during decryption, allowing attackers to manipulate template logic while maintaining valid ciphertext integrity.\nAn attacker with network access to the controller's internal port can leverage this as a decryption oracle by observing HTTP response status codes, which leak execution state resulting from injected template expressions.\nThis side-channel attack enables the iterative extraction of plaintext secrets from any encrypted data handled by the controller, effectively bypassing the intended security model.\nThe exploitation is unauthenticated and requires only internal cluster network access, posing a severe risk to secret confidentiality within the Kubernetes environment.\nMitigation requires implementing strict authenticated data binding for all template-related fields and restricting access to administrative controller endpoints.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper implementation of AEAD and the insecure processing of user-supplied templates in pkg/apis/sealedsecrets/v1alpha1/sealedsecret_expansion.go. The Sealed Secrets controller performs decryption via the Unseal() function before evaluating Go templates present in the spec.template.data field.\nBecause the spec.template.data field is not included in the AEAD authenticated-data label binding, the integrity of the template metadata is not cryptographically coupled with the encrypted secret material. An attacker can construct a malicious payload by intercepting or obtaining a valid SealedSecret and appending custom Go template logic to the template data while keeping the original encryptedData and metadata intact. The AEAD verification succeeds because the underlying ciphertext and binding labels remain technically consistent with the original object, despite the malicious template injection.\nThe exploitation functions as a side-channel oracle leveraging differential HTTP responses. The controller reflects template execution errors directly in the HTTP status code: a successful evaluation yields an HTTP 200 (OK), while an error (triggered by the {{ fail }} function) results in an HTTP 409 (Conflict). By injecting conditional Go template logic, such as '{{ if eq (substr 0 1 .password) \"S\" }}ok{{ else }}{{ fail \"x\" }}{{ end }}', the attacker can perform character-by-character brute forcing of the decrypted plaintext.\nThe attack flow proceeds as follows: 1) The attacker gains access to the controller's service port (:8080). 2) The attacker identifies a target SealedSecret. 3) The attacker submits a crafted POST request to /v1/verify or /v1/rotate, embedding a conditional template in spec.template.data that compares a secret character against a known-plaintext guess. 4) The controller decrypts the secret and attempts to render the template. 5) If the condition is true, the template renders, and the controller returns an HTTP 200. If false, the 'fail' function is triggered, returning an HTTP 409. 6) The attacker observes the response code to confirm the guess and iterates to the next character.\nThis vulnerability is particularly dangerous as it circumvents the primary purpose of the controller—to store secrets securely—by turning the decryption service into a decryption oracle that exposes sensitive data to any actor capable of reaching the internal controller network."
}