# CVE-2026-59341: Sealed Secrets: decryption oracle via Go template injection in unauthenticated controller endpoints

> An attacker with internal network access can exploit a Go template injection flaw to decrypt and recover plaintext values from any sealed secret.

- **Severity:** Medium 4.2 (`CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:N/A:N`)
- **Exploited in the wild:** Not known
- **Login needed:** An administrator
- **Attackable:** Over the internet
- **Victim action needed:** A user has to click or open something
- **Fix available:** No
- **Published:** 15 Sep 2026
- **Updated:** 16 Sep 2026
- **Also known as:** GHSA-qj4p-m373-p2wg

## What is CVE-2026-59341?

CVE-2026-59341 is a medium-severity vulnerability in Bitnami sealed-secrets, published on 15 Sep 2026. An attacker needs administrator access to exploit it, and only if a user opens a file or follows a link.

### Official 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.

Weakness: CWE-203 (Observable Discrepancy)

## Which versions are affected by CVE-2026-59341?


## How do I fix CVE-2026-59341?

No fix has been published for CVE-2026-59341 yet. Limit exposure of the affected software until one is available.

## Is CVE-2026-59341 being exploited?

It is not confirmed as exploited in the wild, but public exploit code for CVE-2026-59341 exists.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-59341 and fix it if it is affected.

What it is: CVE-2026-59341 is a medium-severity vulnerability in Bitnami sealed-secrets, published on 15 Sep 2026. An attacker needs administrator access to exploit it, and only if a user opens a file or follows a link.
Exploitation: It is not confirmed as exploited in the wild, but public exploit code for CVE-2026-59341 exists.

Affected product: Bitnami sealed-secrets. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-59341/ (Markdown: https://insights.sbomify.com/CVE-2026-59341/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-59341
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-59341
- OSV: https://osv.dev/vulnerability/CVE-2026-59341

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-59341/
Summaries are generated and may contain mistakes; the official description above is the record.