Streams For Apache Kafka 2
Monthly
Authentication bypass in Cruise Control (Red Hat Streams for Apache Kafka 2.x and 3.x) lets adjacent-network attackers reach all 15 administrative REST endpoints without credentials by abusing exact-path Jetty security constraints and servlet path normalization. The CVSS 3.1 score is 8.8 (AV:A/AC:L/PR:N/UI:N), but in AMQ Streams the Strimzi operator NetworkPolicy limits Cruise Control port 9090 to operator pods, so realistic exposure requires that policy to be absent, disabled, or misconfigured. No public exploit was identified at time of analysis.
Cross-tenant privilege escalation in StreamsHub Console for Apache Kafka allows an authenticated Kubernetes tenant that can create or modify Console custom resources to point spec.containers.api.spec.image at an arbitrary container image, which the operator then deploys into a pod running under a ServiceAccount bound by ClusterRoleBinding to cluster-wide Strimzi CRD read access, Kafka/KafkaRebalance patch rights, and cluster-monitoring-view. The attacker-controlled code reads the projected ServiceAccount token and gains read/write control over the Strimzi control plane across tenant boundaries, with high confidentiality and integrity impact (CVSS 9.9, scope changed). Exploitation is gated by the tenant-level RBAC permission rather than being open to the internet, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Credential theft in multi-tenant Red Hat StreamsHub Console for Apache Kafka and Streams for Apache Kafka 2/3 deployments is possible because the operator trusts a namespace field supplied in a Console custom resource. An authenticated tenant with permission to create Console CRs (PR:L) can point spec.kafkaClusters[].credentials.kafkaUser.namespace at a victim namespace, causing the cluster-wide-privileged operator to read that namespace’s KafkaUser Secret-SASL credentials or TLS private keys-and write the plaintext into a Secret in the attacker’s namespace. CVSS 3.1 scores this 7.7 with scope changed and high confidentiality impact; no public exploit identified at time of analysis, so risk is concentrated in multi-tenant clusters where untrusted users can create Console resources.
ServiceAccount token exfiltration in the StreamsHub Console for Apache Kafka lets a user who already holds RBAC permission to create or modify the Console custom resource point the console-api AdminClient at an attacker-controlled broker. Tenant-supplied Kafka client properties are copied into the AdminClient configuration without filtering security-sensitive keys, so setting config.providers and bootstrap.servers causes the console-api ServiceAccount token to be read and leaked off-cluster. The issue is rated CVSS 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, CWE-470) and is a moderate-severity, privilege-dependent information disclosure: it requires an authenticated, semi-trusted role with write access to Console CRs (PR:L), so clusters with tight RBAC on those resources are substantially less exposed, and unauthenticated external actors cannot trigger it. No public exploit code has been identified at time of analysis and the flaw is not confirmed actively exploited (not in CISA KEV); no EPSS score was provided.
Authentication bypass in Cruise Control (Red Hat Streams for Apache Kafka 2.x and 3.x) lets adjacent-network attackers reach all 15 administrative REST endpoints without credentials by abusing exact-path Jetty security constraints and servlet path normalization. The CVSS 3.1 score is 8.8 (AV:A/AC:L/PR:N/UI:N), but in AMQ Streams the Strimzi operator NetworkPolicy limits Cruise Control port 9090 to operator pods, so realistic exposure requires that policy to be absent, disabled, or misconfigured. No public exploit was identified at time of analysis.
Cross-tenant privilege escalation in StreamsHub Console for Apache Kafka allows an authenticated Kubernetes tenant that can create or modify Console custom resources to point spec.containers.api.spec.image at an arbitrary container image, which the operator then deploys into a pod running under a ServiceAccount bound by ClusterRoleBinding to cluster-wide Strimzi CRD read access, Kafka/KafkaRebalance patch rights, and cluster-monitoring-view. The attacker-controlled code reads the projected ServiceAccount token and gains read/write control over the Strimzi control plane across tenant boundaries, with high confidentiality and integrity impact (CVSS 9.9, scope changed). Exploitation is gated by the tenant-level RBAC permission rather than being open to the internet, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Credential theft in multi-tenant Red Hat StreamsHub Console for Apache Kafka and Streams for Apache Kafka 2/3 deployments is possible because the operator trusts a namespace field supplied in a Console custom resource. An authenticated tenant with permission to create Console CRs (PR:L) can point spec.kafkaClusters[].credentials.kafkaUser.namespace at a victim namespace, causing the cluster-wide-privileged operator to read that namespace’s KafkaUser Secret-SASL credentials or TLS private keys-and write the plaintext into a Secret in the attacker’s namespace. CVSS 3.1 scores this 7.7 with scope changed and high confidentiality impact; no public exploit identified at time of analysis, so risk is concentrated in multi-tenant clusters where untrusted users can create Console resources.
ServiceAccount token exfiltration in the StreamsHub Console for Apache Kafka lets a user who already holds RBAC permission to create or modify the Console custom resource point the console-api AdminClient at an attacker-controlled broker. Tenant-supplied Kafka client properties are copied into the AdminClient configuration without filtering security-sensitive keys, so setting config.providers and bootstrap.servers causes the console-api ServiceAccount token to be read and leaked off-cluster. The issue is rated CVSS 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, CWE-470) and is a moderate-severity, privilege-dependent information disclosure: it requires an authenticated, semi-trusted role with write access to Console CRs (PR:L), so clusters with tight RBAC on those resources are substantially less exposed, and unauthenticated external actors cannot trigger it. No public exploit code has been identified at time of analysis and the flaw is not confirmed actively exploited (not in CISA KEV); no EPSS score was provided.