Aiven Operator CVE-2026-39961

CVSS 6.8 indicates high severity, with attack vector network, low complexity, and high privilege requirement (PR:H). However, the real-world risk is substantial and potentially underrepresented by the score. The PR:H designation reflects that an attacker needs developer-level Kubernetes permissions (ability to create CRDs), but this is a common role in development, staging, and even some production environments where namespace isolation is the security boundary. The confirmed absence of compensating admission webhooks (noted in the description as 'no admission webhook enforces this boundary') leaves no runtime defense once the role is granted. Unlike a typical privilege escalation requiring authentication and low-level system compromise, this vulnerability requires only kubectl apply access to a namespace, making it trivially easy to exploit with no complexity. EPSS data is not provided, but the exploitability is straightforward and requires no special tools or race conditions. From an SSVC perspective: exploitation status is not confirmed as actively exploited (no KEV status provided), but public references and commit details confirm the vulnerability is well-documented; technical impact is high (confidentiality breach of production credentials across namespace boundaries); this is automatable and highly repeatable. The vulnerability's real danger is in multi-tenant or compartmentalized Kubernetes clusters where namespace isolation is relied upon as a security control-a developer in a dev namespace can compromise production by reading production ClickhouseUser secrets.

A developer with create permissions on ClickhouseUser CRDs in the 'dev' namespace targets a production ClickhouseUser resource in the 'prod' namespace. The attacker creates a malicious ClickhouseUser CRD in the dev namespace with a spec.connInfoSecretSource.namespace field pointing to 'prod' and a corresponding secret name, then applies it with kubectl apply. The Aiven Operator, running with cluster-wide secret read permissions, processes this request, reads the specified secret from the production namespace, and writes its contents into a new secret in the attacker's dev namespace. The attacker then retrieves the production credentials using kubectl get secret, gaining access to production databases, API endpoints, or other sensitive services. No public exploit code was identified at the time of analysis, but the vulnerability is straightforward enough that exploitation requires only standard kubectl commands and knowledge of target secret names in other namespaces.