CVE-2026-22728: Bitnami Sealed Secrets Auth Bypass Flaw

CVE-2026-22728 Overview

Bitnami Sealed Secrets is vulnerable to a scope-widening attack during the secret rotation (/v1/rotate) flow. The rotation handler derives the sealing scope for the newly encrypted output from untrusted spec.template.metadata.annotations present in the input SealedSecret. By submitting a victim SealedSecret to the rotate endpoint with the annotation sealedsecrets.bitnami.com/cluster-wide=true injected into the template metadata, a remote attacker can obtain a rotated version of the secret that is cluster-wide. This bypasses original "strict" or "namespace-wide" constraints, allowing the attacker to retarget and unseal the secret in any namespace or under any name to recover the plaintext credentials.

Critical Impact

Attackers with privileged access can bypass namespace isolation and secret scoping constraints to recover plaintext credentials across the entire Kubernetes cluster.

Affected Products

• Bitnami Sealed Secrets (versions affected as per security advisory)

Discovery Timeline

• February 26, 2026 - CVE CVE-2026-22728 published to NVD
• February 26, 2026 - Last updated in NVD database

Technical Details for CVE-2026-22728

Vulnerability Analysis

This vulnerability represents an Improper Access Control (CWE-284) flaw in the Bitnami Sealed Secrets controller. The core issue lies in how the /v1/rotate endpoint processes incoming SealedSecret objects during the key rotation workflow. Rather than preserving the original sealing scope from the existing sealed secret metadata, the handler incorrectly trusts user-supplied annotations in the request body.

The attack exploits the fact that Sealed Secrets uses metadata annotations to determine the scope of a secret—whether it should be "strict" (bound to a specific name and namespace), "namespace-wide" (valid within a single namespace), or "cluster-wide" (accessible across all namespaces). When an attacker submits a legitimate victim's SealedSecret to the rotation endpoint with a manipulated annotation (sealedsecrets.bitnami.com/cluster-wide=true), the controller generates a new encrypted secret with elevated scope permissions.

This allows an attacker to effectively "unlock" secrets that were originally restricted to specific namespaces or names, enabling credential recovery across the cluster boundary.

Root Cause

The root cause is insufficient validation of untrusted input in the secret rotation handler. The /v1/rotate endpoint fails to verify that the sealing scope annotations in the submitted SealedSecret match the original scope constraints. Instead of deriving the scope from the actual encrypted content or maintaining an authoritative scope record, the handler blindly accepts the spec.template.metadata.annotations values provided in the request, allowing scope escalation through annotation injection.

Attack Vector

The attack requires network access to the Sealed Secrets controller's /v1/rotate endpoint and privileged Kubernetes access (typically cluster administrator or equivalent) to obtain existing SealedSecret resources. An attacker retrieves a victim's SealedSecret, modifies the template metadata to include the cluster-wide annotation, and submits it to the rotate endpoint. The controller then returns a newly encrypted version with cluster-wide scope, which the attacker can subsequently unseal in any namespace to extract the plaintext credentials.

The vulnerability is exploited through the following mechanism:

1. Attacker obtains a SealedSecret resource that is scoped as "strict" or "namespace-wide"
2. Attacker modifies the spec.template.metadata.annotations to inject sealedsecrets.bitnami.com/cluster-wide=true
3. The modified SealedSecret is submitted to the /v1/rotate endpoint
4. The rotation handler generates a new encrypted secret using the injected cluster-wide scope
5. Attacker applies the rotated SealedSecret in any namespace to recover plaintext credentials

For complete technical details, see the GitHub Security Advisory.

Detection Methods for CVE-2026-22728

Indicators of Compromise

• Unusual requests to the /v1/rotate endpoint with modified annotation fields
• SealedSecret resources with scope annotations that differ from their original constraints
• Secrets appearing in unexpected namespaces that were previously namespace-scoped
• Audit log entries showing rotation requests followed by secret unsealing in different namespaces

Detection Strategies

• Enable Kubernetes audit logging and monitor for API calls to the Sealed Secrets controller /v1/rotate endpoint
• Implement admission controller policies to detect and alert on SealedSecret resources with modified scope annotations
• Compare SealedSecret annotation history before and after rotation operations
• Monitor for secrets being created in namespaces where they were not originally scoped

Monitoring Recommendations

• Configure alerts for any /v1/rotate endpoint calls from unexpected sources or service accounts
• Implement real-time monitoring of SealedSecret annotation changes using Kubernetes admission webhooks
• Audit cluster-wide secrets periodically to identify any that originated from namespace-scoped originals
• Review Sealed Secrets controller logs for rotation requests that result in scope changes

How to Mitigate CVE-2026-22728

Immediate Actions Required

• Review the GitHub Security Advisory for patch availability and updated versions
• Restrict access to the Sealed Secrets controller /v1/rotate endpoint using network policies
• Audit existing SealedSecret resources for unauthorized scope modifications
• Rotate all secrets that may have been exposed through this vulnerability

Patch Information

Refer to the GitHub Security Advisory for specific patch versions and upgrade instructions. The fix involves proper validation of sealing scope during the rotation flow, ensuring that the output scope cannot exceed the original secret's constraints regardless of input annotations.

Workarounds

• Disable or restrict access to the /v1/rotate endpoint if key rotation is not immediately required
• Implement network policies to limit which pods and service accounts can reach the Sealed Secrets controller API
• Use Kubernetes RBAC to restrict get and list permissions on SealedSecret resources to minimize attacker access to victim secrets
• Deploy admission controller policies that reject SealedSecret resources with unexpected scope annotations

# Example: Network policy to restrict access to Sealed Secrets controller
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: sealed-secrets-restrict
  namespace: kube-system
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: sealed-secrets
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          sealed-secrets-access: "allowed"
EOF