The aiven-operator, used to manage Aiven services in Kubernetes, has a privilege escalation vulnerability (CVE-2026-39961) in versions before 0.37.0. A developer with create permission on ClickhouseUser custom resource definitions (CRDs) in their namespace can cause the operator to read secrets from any other namespace due to its cluster-wide secret read/write ClusterRole. The operator trusts the user-supplied spec.connInfoSecretSource.namespace field without validation, enabling it to exfiltrate secrets by writing them into a secret in the attacker's namespace. No admission webhooks exist to enforce namespace boundaries, allowing this confused deputy attack. The issue is resolved in version 0.37.0.

An attacker with create permission on ClickhouseUser CRDs in their own namespace can exfiltrate sensitive secrets from other namespaces, including production database credentials, API keys, and service tokens. This leads to a confidentiality breach with high impact on secret data. The vulnerability does not affect integrity or availability directly. The CVSS score is 6.8 (medium severity), reflecting network attack vector, low attack complexity, high privileges required, no user interaction, and scope change with high confidentiality impact.

This vulnerability is fixed in aiven-operator version 0.37.0. Users should upgrade to version 0.37.0 or later to remediate this issue. Until upgrading, restrict create permissions on ClickhouseUser CRDs to trusted users only. No admission webhook currently enforces namespace boundaries, so manual permission management is critical. Patch status is not explicitly stated beyond the fix in 0.37.0; check the vendor advisory for the latest remediation guidance.