Executive Summary

CVE-2026-39961 is a vulnerability in the Aiven Operator for Kubernetes versions from 0.31.0 to before 0.37.0. It allows a developer who has create permissions on ClickhouseUser Custom Resource Definitions (CRDs) within their own namespace to exfiltrate secrets from any other namespace in the cluster.

The vulnerability arises because the operator's ServiceAccount has cluster-wide secret read/write permissions and trusts user-supplied namespace values in the spec.connInfoSecretSource.namespace field without validation. This enables a confused deputy attack where the operator reads secrets from a victim namespace and writes the secret's password into a new secret in the attacker's namespace.

No admission webhook enforces namespace boundaries, which means there is no validation to prevent this cross-namespace secret access. The issue is fixed in version 0.37.0.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can lead to the exfiltration of sensitive secrets such as production database credentials, API keys, and service tokens from any namespace in the Kubernetes cluster.

An attacker with create permission on ClickhouseUser CRDs in their own namespace can exploit this vulnerability with a single kubectl apply command to access secrets from other namespaces, potentially compromising the confidentiality of critical data.

Because the operator acts as a confused deputy with cluster-wide secret read/write permissions, it can be tricked into bypassing normal namespace isolation, leading to a high confidentiality impact without affecting integrity or availability.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by checking if your Kubernetes cluster is running a vulnerable version of the Aiven Operator (versions >= 0.31.0 and < 0.37.0) and if developers have create permissions on ClickhouseUser CRDs in their namespaces.

You can look for suspicious kubectl apply commands that create or modify ClickhouseUser resources with cross-namespace secret references in the spec.connInfoSecretSource.namespace field.

A practical detection approach is to audit Kubernetes API server logs or use Kubernetes audit logs to identify any creation of ClickhouseUser CRDs that specify a namespace different from the resource's own namespace in the connInfoSecretSource.namespace field.

Example commands to detect potentially malicious resources:

• kubectl get clickhouseusers --all-namespaces -o json | jq '.items[] | select(.spec.connInfoSecretSource.namespace != .metadata.namespace)'
• kubectl get events --all-namespaces | grep clickhouseuser
• kubectl auth can-i create clickhouseusers --all-namespaces --as <user> # To check if a user has create permission

Additionally, review the ClusterRole bindings for the aiven-operator-role to confirm if it has cluster-wide secret read/write permissions.

Useful 0 Not Useful 0

Mitigation Strategies

The primary and immediate mitigation step is to upgrade the Aiven Operator to version 0.37.0 or later, where this vulnerability is fixed.

This update removes support for cross-namespace secret references by enforcing that secrets must reside in the same namespace as the resource, eliminating the confused deputy attack vector.

If upgrading immediately is not possible, restrict create permissions on ClickhouseUser CRDs to trusted users only, and audit usage of these CRDs closely.

Review and tighten the ClusterRole and RoleBindings associated with the aiven-operator-role to limit secret read/write permissions where feasible.

Implement admission webhooks or other policy enforcement mechanisms to validate that the connInfoSecretSource.namespace field matches the resource's namespace, preventing cross-namespace secret references.

Useful 0 Not Useful 0

Compliance Impact

This vulnerability allows a developer with create permissions on ClickhouseUser CRDs in their own namespace to exfiltrate secrets from any other namespace, including production database credentials, API keys, and service tokens. Such unauthorized access and exfiltration of sensitive data can lead to violations of data protection regulations and standards such as GDPR and HIPAA, which require strict controls on access to sensitive information and mandate protection against unauthorized disclosure.

Because the operator's ServiceAccount has cluster-wide secret read/write permissions and trusts user-supplied namespace values without validation, it acts as a confused deputy, enabling attackers to bypass namespace boundaries and access confidential data. This improper privilege management and lack of validation can result in non-compliance with regulatory requirements for data confidentiality and access controls.

The vulnerability's high confidentiality impact and the ability to exfiltrate secrets across namespaces pose significant risks to compliance frameworks that require safeguarding sensitive data from unauthorized access.

Useful 0 Not Useful 0