GPU VulnDB

Database/Container, Kubernetes & orchestration

StreamsHub Console operator: cross-namespace Kafka credential theft via confused deputy

CVSS 7.7CVE-2026-105311Container, Kubernetes & orchestrationcurated

Impact

A tenant who can create a Console custom resource sets spec.kafkaClusters[].credentials.kafkaUser.namespace to any namespace. The operator, which holds cluster-wide Secrets RBAC, reads the KafkaUser Secret from the victim namespace - SASL credentials or TLS private keys - and writes the plaintext into a Secret the attacker owns. Red Hat's description states there is no same-namespace check or allowlist anywhere in the code path. On a shared cluster this turns namespace-scoped CR creation into a read primitive over other tenants' Kafka identities, and those identities often front telemetry and job-event streams for the whole fleet. Only confidentiality is affected per the vector, but the scope change reflects that the harm lands outside the attacker's namespace.

Who can reach it

Any authenticated Kubernetes user or service account with permission to create a Console custom resource in a namespace they control. No cluster-admin and no node access needed.

What to do

Update the StreamsHub Console operator / streams for Apache Kafka to the fixed build listed in Red Hat's advisory and restart the operator deployment - a controller restart, no GPU node drain. Until then, remove Console CR create permission from tenants and treat any KafkaUser credential that an operator-managed Secret could have exposed as compromised: rotate the SASL passwords and reissue the TLS client certificates, since rolling the operator does not invalidate material already copied.

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.