StreamsHub Console EUVD-2026-104963

Exploitation requires a multi-tenant deployment of the StreamsHub Console / Red Hat Streams for Apache Kafka operator where the operator holds cluster-wide (cross-namespace) Secrets RBAC, AND an attacker who already holds authenticated Kubernetes permissions to create a Console custom resource. The concrete trigger is setting spec.kafkaClusters[].credentials.kafkaUser.namespace to a victim namespace; because no same-namespace check or allowlist exists in the code path, any value is accepted. Limiting factors: the attacker must be an authenticated tenant with create rights on the Console CR (PR:L), a target KafkaUser Secret must exist in the victim namespace, and single-tenant or tightly-RBAC-scoped clusters where no untrusted party can create Console CRs are not realistically exposed.

This is a genuine privilege-boundary bug in a multi-tenant context, but its real-world risk is moderate rather than urgent. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N, 7.7 High) is internally consistent with the description: a low-privileged but authenticated Kubernetes tenant (PR:L) who can create a Console custom resource abuses the operator's cluster-wide Secrets RBAC to read another namespace's KafkaUser Secret - a textbook CWE-441 confused-deputy escalation, correctly reflected by Scope:Changed and Confidentiality:High with no integrity/availability impact. No EPSS score, no CISA KEV listing, and no public POC are present in the supplied data, so there is no evidence of active exploitation or automated mass-scanning; the threat is a deliberate, authenticated insider or a tenant who has already gained create-rights on Console CRs in a shared cluster. The 'network' attack vector is technically accurate (the Kubernetes API is reached over the network) but should not be read as internet-wide unauthenticated reach - exploitation is gated behind valid cluster credentials and RBAC to create the CR. Net assessment: real and worth patching in genuinely multi-tenant Kafka/OpenShift clusters, but lower priority in single-tenant or trusted-operator deployments; the disclosed SASL credentials or TLS private keys are, however, a high-value secondary pivot that could later enable broader compromise.

In a shared OpenShift/Kubernetes cluster, a tenant who is allowed to create a Console custom resource in their own namespace crafts one whose spec.kafkaClusters[].credentials.kafkaUser.namespace points at a victim tenant's namespace. The StreamsHub Console operator, running with cluster-wide Secrets RBAC and performing no same-namespace or allowlist check, reads the victim's KafkaUser Secret and copies the plaintext SASL credentials or TLS private keys into a Secret the attacker fully controls. No public exploit identified at time of analysis, so this would require the attacker to author the malicious CR themselves.