Sealed Secrets controller: unauthenticated template oracle recovers sealed secret plaintext

Impact

The controller's unauthenticated POST /v1/verify and /v1/rotate handlers decrypt a target SealedSecret and then render Go templates found in spec.template.data using the decrypted values as context, and template execution failures are reflected in the HTTP status code (200 on success, 409 on failure). Because spec.template.data is left out of the AEAD authenticated-data binding, an attacker can reuse a victim's metadata and encryptedData verbatim while substituting arbitrary template logic, turning the controller into a character-by-character decryption oracle. On a GPU cluster the sealed secrets in question are typically registry pull credentials, object-store and dataset keys, model-weight download tokens and cloud IAM material - the keys that gate customer data and paid capacity. Any workload pod on the cluster can reach the service port, so a single tenant container is enough to extract the cluster's committed secrets.

Who can reach it

Any pod in the cluster, or anyone who can kubectl port-forward, reaching the controller's internal service port (:8080). No authentication required; the endpoints are unauthenticated by design. Not exposed to the internet in a default install.

What to do

Upgrade the sealed-secrets controller to the fixed release named in GHSA-qj4p-m373-p2wg and restart the controller Deployment - a control-plane namespace rollout, no node drain and no workload interruption. Because the flaw allows full plaintext recovery, treat any secret that was sealed and reachable during the exposure window as disclosed and rotate it. Until the upgrade lands, restrict reachability of the controller service with a NetworkPolicy so only the control-plane namespace can open the port.

References

Related entries

• Jenkins core: build CLI -s flag cancels other users' builds without the Item/Cancel permissionCVE-2026-84657 · Jenkins core (build CLI command, -s flag skips Item/Cancel check)Medium
• AMD IOMMU register interface - ASP coherency: Improper access control on the IOMMU register interface lets a privilegedCVE-2025-54509 · AMD IOMMU register interface - ASP coherencyMedium
• AGESA Boot Loader (ABL) - SPI ROM header input validation (AMD-SB-3003): The AGESA Boot Loader does not properlyCVE-2021-46772 · AGESA Boot Loader (ABL) - SPI ROM header input validation (AMD-SB-3003)Low
• Redis: Lua environment weakness lets a user inject code that runs with another Redis user's privilegesCVE-2022-24735 · RedisLow
• Slurm (X11 forwarding, xauth magic-cookie setup): Slurm shells out to xauth to install a user's X11 magic cookie, andCVE-2020-27746 · Slurm (X11 forwarding, xauth magic-cookie setup)Low
• Zabbix: Some setup.php steps reachable by unauthenticated usersCVE-2022-23134 · ZabbixLow