CVE-2026-39961: Aiven Operator Information Disclosure Flaw

CVE-2026-39961 Overview

CVE-2026-39961 is an Improper Access Control vulnerability affecting the Aiven Operator for Kubernetes. This flaw enables a developer with create permissions on ClickhouseUser Custom Resource Definitions (CRDs) in their own namespace to exfiltrate secrets from any other namespace in the cluster. The attack leverages a "confused deputy" pattern where the operator's highly privileged ServiceAccount—which has cluster-wide secret read/write access via the aiven-operator-role ClusterRole—trusts user-supplied namespace values in spec.connInfoSecretSource.namespace without proper validation.

Critical Impact

A malicious insider with limited Kubernetes RBAC permissions can steal production database credentials, API keys, and service tokens from any namespace in the cluster with a single kubectl apply command.

Affected Products

• Aiven Operator versions 0.31.0 to 0.36.x
• Kubernetes clusters running vulnerable Aiven Operator deployments
• Any namespace containing secrets accessible to the Aiven Operator ServiceAccount

Discovery Timeline

• 2026-04-09 - CVE CVE-2026-39961 published to NVD
• 2026-04-09 - Last updated in NVD database

Technical Details for CVE-2026-39961

Vulnerability Analysis

This vulnerability represents a classic "confused deputy" attack pattern in Kubernetes operators. The Aiven Operator acts as a privileged intermediary that manages Aiven services within a Kubernetes cluster. When processing ClickhouseUser CRDs, the operator reads secret data specified by the user and writes connection information to a new secret.

The fundamental flaw lies in the operator's trust of user-supplied namespace values. The spec.connInfoSecretSource.namespace field allows users to specify an arbitrary namespace from which to read secrets. Because the operator's ServiceAccount possesses cluster-wide read/write permissions on secrets (granted by the aiven-operator-role ClusterRole), it can access secrets in any namespace—not just the namespace where the CRD was created.

Additionally, no admission webhook exists to enforce namespace boundaries. The ServiceUser webhook returns nil, and critically, no ClickhouseUser webhook was implemented to validate these cross-namespace references. This means an attacker can craft a malicious ClickhouseUser CRD that references secrets in sensitive namespaces (e.g., production, kube-system, or any namespace containing privileged credentials), and the operator will dutifully read those secrets and expose them in the attacker's namespace.

Root Cause

The root cause is improper access control validation combined with overly permissive RBAC configuration. The operator accepts a user-controlled namespace field in the ConnInfoSecretSource struct without validating that the requesting resource has permission to access secrets in that namespace. The operator's ServiceAccount has cluster-wide privileges that exceed what individual users should be able to leverage through CRD manipulation.

Attack Vector

The attack exploits network-accessible Kubernetes API access. An attacker with create permissions on ClickhouseUser CRDs in their own namespace crafts a malicious CRD that specifies a victim namespace in the spec.connInfoSecretSource.namespace field. When the operator reconciles this CRD, it uses its privileged ServiceAccount to read the victim's secret and copies the sensitive data into a new secret within the attacker's namespace.

The security patch removes the namespace field entirely from the ConnInfoSecretSource struct, forcing secrets to be read only from the same namespace as the requesting resource:

 type ConnInfoSecretSource struct {
 	// +kubebuilder:validation:Required
 	// +kubebuilder:validation:MinLength=1
-	// Name of the secret resource to read connection parameters from
+	// Name of the secret resource to read connection parameters from.
+	// The secret must be in the same namespace as the resource.
 	Name string `json:"name"`
-	// Namespace of the source secret. If not specified, defaults to the same namespace as the resource
-	Namespace string `json:"namespace,omitempty"`
 	// +kubebuilder:validation:Required
 	// +kubebuilder:validation:MinLength=1
 	// Key in the secret containing the password to use for authentication

Source: GitHub Commit

The corresponding controller code was also patched to enforce same-namespace access:

 		return "", nil
 	}
 
-	sourceNamespace := secretSource.Namespace
-	if sourceNamespace == "" {
-		sourceNamespace = resource.GetNamespace()
-	}
+	ns := resource.GetNamespace()
 
 	sourceSecret := &corev1.Secret{}
 	err := k8sClient.Get(ctx, types.NamespacedName{
 		Name:      secretSource.Name,
-		Namespace: sourceNamespace,
+		Namespace: ns,
 	}, sourceSecret)
 	if err != nil {
-		return "", fmt.Errorf("failed to read connInfoSecretSource %s/%s: %w", sourceNamespace, secretSource.Name, err)
+		return "", fmt.Errorf("failed to read connInfoSecretSource %s/%s: %w", ns, secretSource.Name, err)
 	}

Source: GitHub Commit

Detection Methods for CVE-2026-39961

Indicators of Compromise

• ClickhouseUser CRDs containing spec.connInfoSecretSource.namespace fields pointing to namespaces other than where the CRD is deployed
• Unusual secret access patterns in Kubernetes audit logs showing the Aiven Operator ServiceAccount reading secrets from multiple namespaces
• New secrets appearing in unexpected namespaces containing connection information or credentials
• Audit log entries showing ClickhouseUser CRD creation followed by cross-namespace secret reads

Detection Strategies

• Enable and monitor Kubernetes audit logging for all secret read operations by the aiven-operator ServiceAccount
• Implement OPA Gatekeeper or Kyverno policies to alert on or block ClickhouseUser CRDs specifying cross-namespace secret sources
• Monitor for anomalous CRD creation patterns, especially from users who don't typically interact with ClickhouseUser resources
• Review existing ClickhouseUser CRDs across all namespaces for suspicious connInfoSecretSource.namespace configurations

Monitoring Recommendations

• Configure alerts for secret access events where the requesting ServiceAccount's namespace differs from the secret's namespace
• Implement runtime security monitoring to detect secret exfiltration attempts
• Regularly audit RBAC permissions for operators and service accounts with cluster-wide secret access
• Monitor SentinelOne Singularity Cloud Workload Security for Kubernetes anomaly detection on operator behavior

How to Mitigate CVE-2026-39961

Immediate Actions Required

• Upgrade Aiven Operator to version 0.37.0 or later immediately
• Audit all existing ClickhouseUser CRDs for cross-namespace secret references before upgrading
• Review Kubernetes audit logs for evidence of prior exploitation attempts
• Inventory all secrets that may have been exposed through this vulnerability and rotate compromised credentials

Patch Information

The vulnerability is fixed in Aiven Operator version 0.37.0. The fix removes the namespace field from the ConnInfoSecretSource struct entirely, enforcing that secrets must reside in the same namespace as the requesting resource. See the GitHub Security Advisory GHSA-99j8-wv67-4c72 for complete details and the v0.37.0 release notes for upgrade instructions.

Workarounds

• If immediate upgrade is not possible, implement a Kubernetes admission webhook or policy (OPA Gatekeeper/Kyverno) to reject ClickhouseUser CRDs with non-empty spec.connInfoSecretSource.namespace fields
• Restrict RBAC permissions to prevent untrusted users from creating ClickhouseUser CRDs until the upgrade can be completed
• Consider temporarily scaling down the Aiven Operator deployment if exploitation is suspected and upgrade cannot be performed immediately

# Kyverno policy to block cross-namespace secret references (workaround)
# Apply this policy until upgrade to v0.37.0 is complete
kubectl apply -f - <<EOF
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: block-aiven-cross-namespace-secrets
spec:
  validationFailureAction: Enforce
  rules:
  - name: deny-cross-namespace-conninfosecret
    match:
      resources:
        kinds:
        - ClickhouseUser
    validate:
      message: "Cross-namespace secret references are prohibited (CVE-2026-39961)"
      pattern:
        spec:
          connInfoSecretSource:
            namespace: ""
EOF