The Aiven Operator in versions 0.31.0 through 0.36.x allows a user with create permission on ClickhouseUser objects in their own namespace to read secrets from any other namespace. When a ClickhouseUser is applied, the operator interprets the spec.connInfoSecretSource.namespace field without validation and copies the referenced secret into a new secret in the attacker’s namespace. This produces unauthorized exposure of production database credentials, API keys, and service tokens. The weakness is a confused deputy scenario where the operator’s ServiceAccount holds cluster‑wide secret read/write permissions, allowing the user to exploit the operator’s trust of user‑supplied namespace values. The impact is confidentiality violation, potentially leading to compromised services and data leakage.

This flaw affects the Aiven Operator, a Kubernetes operator for provisioning Aiven services. Vulnerable releases are from 0.31.0 up to, but not including, 0.37.0. Any deployment running these versions is susceptible to the exploit if a user can create ClickhouseUser resources in their namespace.

The vulnerability carries a CVSS score of 6.8, indicating moderate severity. EPSS data is unavailable, and the flaw is not listed in the CISA KEV catalog. The attack vector is inferred to be local within the cluster: an attacker must have permission to create ClickhouseUser resources in their own namespace and the operator will then read secrets from other namespaces due to its cluster‑wide role. The operator’s lack of admission validation and the absence of a dedicated webhook amplify the exploitation path. All these factors combine to present a clear risk of unauthorized secret disclosure to any component that can install a vulnerable operator version.