StreamsHub Console CVE-2026-105312

Exploitation requires an authenticated Kubernetes tenant with create permission (RBAC) on StreamsHub Console custom resources in a cluster where the StreamsHub Console operator is deployed and running; the operator must honor the attacker-supplied spec.containers.api.spec.image field and deploy it into the pod bound to the over-privileged ServiceAccount/ClusterRoleBinding (cluster-wide get/list/watch on all Strimzi CRDs, patch on Kafkas/KafkaRebalances, cluster-monitoring-view). This is fundamentally a multi-tenant risk: the limiting factor is that the attacker must already possess legitimate tenant-level create rights on Console CRs, so single-tenant or tightly RBAC-restricted clusters are not exposed. No end-user interaction is required, but the privileged ClusterRoleBinding configuration created by the operator must be present for the token theft to yield cross-tenant control.

This is a genuine high-priority issue, not merely a high-CVSS paper risk, though its exploitation is gated by a specific privilege rather than being open to the internet. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L, 9.9) is internally consistent with the description: the attack is reached over the Kubernetes API (network), is low-complexity, requires low privileges (PR:L - the attacker must be an authenticated tenant holding create permission on Console custom resources), needs no user interaction, and crosses a trust boundary (S:C) from a single namespace tenant into cluster-wide Strimzi control-plane access. The confidentiality and integrity impact being High is well supported - the stolen ServiceAccount token grants cluster-wide get/list/watch on all Strimzi CRDs (including KafkaUser secrets) and patch on Kafkas/KafkaRebalances - while A:L reflects limited direct availability impact. No EPSS score, CISA KEV listing, or public POC was provided in the input, so there is no signal of active or widespread exploitation; this appears to be a vendor-disclosed (Red Hat) issue with no evidence of in-the-wild use. The key limiting factor is PR:L: the attacker already needs legitimate tenant-level create rights on Console CRs in a multi-tenant cluster, so real-world risk concentrates in shared/multi-tenant OpenShift Kafka deployments rather than single-tenant installs. No signals are strongly conflicting; the main gap is the absence of any exploitation-probability data.

A malicious or compromised Kubernetes tenant that holds create permission on Console custom resources sets spec.containers.api.spec.image to an attacker-controlled container image. The StreamsHub Console operator dutifully deploys that image into a pod whose ServiceAccount is bound to a powerful ClusterRole, and the attacker's code reads the projected SA token to gain cross-tenant read/write control of the Strimzi control plane. No public exploit code was identified at the time of analysis, but the technique is straightforward and requires no special tooling.