CVE-2026-105312 in StreamsHub Console
Summary
by MITRE • 10/20/2026
A Kubernetes tenant with create permission on Console custom resources can set spec.containers.api.spec.image to an arbitrary container image. The operator deploys this image into a pod whose ServiceAccount is bound via ClusterRoleBinding to a ClusterRole granting cluster-wide get/list/watch on all Strimzi CRDs (including KafkaUsers), patch on Kafkas/KafkaRebalances, and cluster-monitoring-view. The attacker's code reads the projected SA token and gains cross-tenant Strimzi control-plane read+write access.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/20/2026
The vulnerability described represents a critical privilege escalation path within multi-tenant Kubernetes environments that utilize the Strimzi operator for managing Apache Kafka clusters. This flaw stems from an insufficient validation of user-supplied input in Console custom resources, specifically targeting the spec.containers.api.spec.image field. In a properly secured environment, tenant users should be restricted to configuring application-level parameters without influencing the underlying infrastructure or control plane components. However, due to this misconfiguration, any Kubernetes tenant possessing create permissions on Console objects can inject arbitrary container images into the deployment pipeline managed by the Strimzi operator. This capability effectively allows a low-privileged user to dictate what code executes within pods that are provisioned with significantly higher privileges than intended for their role.
The operational impact of this vulnerability is severe because it bridges the gap between isolated tenant workloads and the cluster-wide control plane. When an attacker specifies a malicious container image, the Strimzi operator deploys it into a pod associated with a specific ServiceAccount. This ServiceAccount is bound via ClusterRoleBinding to a ClusterRole that grants extensive permissions across the entire Kubernetes cluster. These permissions include read access through get, list, and watch operations on all Strimzi Custom Resource Definitions, which encompasses sensitive resources like KafkaUsers containing credentials for accessing message brokers. Furthermore, the role allows patching capabilities on Kafkas and KafkaRebalances, enabling potential modification of cluster configurations or rebalancing strategies that could lead to denial-of-service conditions or data exfiltration vectors. The inclusion of cluster-monitoring-view permissions further aids reconnaissance by allowing visibility into other workloads running in the cluster.
From a technical perspective, this vulnerability aligns with CWE-94 Improper Control of Generation of Code and is classified under MITRE ATT&CK technique T1505 Server Software Component as it involves implanting malicious code within server-side components via container images. The core issue lies in the lack of strict allow-listing or validation for image references, violating the principle of least privilege. By reading the projected ServiceAccount token from within their injected pod, an attacker can authenticate to the Kubernetes API server using elevated credentials. This grants them cross-tenant access to Strimzi control-plane resources, effectively compromising not only their own tenant's data but potentially all tenants sharing the same cluster infrastructure if RBAC policies are not strictly segregated by namespace or resource scope.
Mitigation strategies must focus on restricting image selection and hardening ServiceAccount permissions. Administrators should implement an admission controller such as OPA Gatekeeper or Kyverno to enforce strict allow-lists for container images, ensuring that only pre-approved, signed images can be deployed within Console resources. Additionally, the ClusterRole bound to the Strimzi operator's ServiceAccount should be audited and minimized; it is generally unnecessary for a single tenant's console pod to have cluster-wide access to all CRDs unless explicitly required by multi-tenancy architecture designs that rely on namespace isolation rather than RBAC restrictions. Implementing network policies to limit outbound traffic from these pods can also reduce the blast radius, although preventing initial code execution via image validation remains the primary defense layer against this specific exploitation vector.