GPU VulnDB

Database/Container, Kubernetes & orchestration

StreamsHub Console operator: tenant-supplied container image runs with a cluster-wide Strimzi ServiceAccount

CVSS 9.9CVE-2026-105312Container, Kubernetes & orchestrationcurated

Impact

A namespaced tenant that can create Console custom resources picks the container image the operator deploys, and that pod's ServiceAccount is bound cluster-wide: get/list/watch on every Strimzi CRD including KafkaUser (which carries client credentials), patch on Kafka and KafkaRebalance, plus cluster-monitoring-view. Attacker code reads the projected token and gets cross-tenant read and write on the Kafka control plane from a single tenant namespace, so one tenant's RBAC grant becomes fleet-wide. On a shared GPU cluster where Kafka moves training telemetry and job events between tenants, this breaks the namespace boundary the scheduler relies on, and it also gives an arbitrary attacker-chosen image a foothold on a worker node. Red Hat scores it 9.9 with scope change.

Who can reach it

Any authenticated Kubernetes principal holding create on Console custom resources in a namespace the StreamsHub Console operator watches - no cluster-admin and no node access needed.

What to do

Track Red Hat's advisory for CVE-2026-105312 and update the StreamsHub Console operator / Streams for Apache Kafka 2.x and 3.x to the fixed build when it ships; the rollout is an operator image bump and pod restart, not a node drain. Until then, remove create on Console CRs from tenant roles, audit existing Console resources for unexpected spec.containers.api.spec.image values, and narrow the ClusterRole bound to the Console ServiceAccount to the namespaces it actually serves. The record does not name a fixed version.

References

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.