CVE-2026-39961
Privilege Escalation in Aiven Operator Allows Cross-Namespace Secret Theft
Publication date: 2026-04-09
Last updated on: 2026-04-09
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| aiven | aiven_operator | From 0.31.0 (inc) to 0.37.0 (exc) |
| aiven | aiven_operator | 0.37.0 |
| aiven | aiven-operator | From 0.31.0 (inc) to 0.37.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-269 | The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor. |
| CWE-441 | The product receives a request, message, or directive from an upstream component, but the product does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the product's control sphere. This causes the product to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
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.
How can this vulnerability impact me? :
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.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
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.
What immediate steps should I take to mitigate this vulnerability?
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.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
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.