On 15 September 2026, NVD published CVE-2026-55225 for Strimzi, the Kubernetes operator for Apache Kafka. It scores 8.0. In Strimzi 1.0.0 and earlier, a user who can create a Kafka custom resource can set the entity operator's watchedNamespace to a namespace they do not own and end up with Secret read and write access there.
This is a Kubernetes multi tenancy bug, not a Kafka broker bug. It matters if tenants can create Kafka resources in their own namespaces and your Cluster Operator has permissions in more than one namespace.
What's affected
Strimzi 1.0.0 and earlier. Fixed in 1.0.1 and 1.1.0.
Per the CVE text, the Cluster Operator creates a Role with full Secret CRUD permissions in the target namespace and binds it to the Entity Operator ServiceAccount in the attacker's namespace. The attacker can mint a token for that account and read or write Secrets in any namespace where the Cluster Operator has permissions, regardless of STRIMZI_NAMESPACE.
A companion record, CVE-2026-55226 (5.4), says deploying only the Topic Operator or only the User Operator leaves the Entity Operator ServiceAccount with RBAC for both. Same fixed releases.
Separately, CVE-2026-96740 (6.5, 28 September) covers the StreamsHub Console for Apache Kafka. Tenant supplied Kafka client properties in the Console resource are copied into the console-api AdminClient configuration unfiltered, so a Console resource author can set config.providers and bootstrap.servers to send the console-api ServiceAccount token to a broker they control. The record names no fixed version, so check the project's advisory.
To see your exposure, check the operator image version and who may create Kafka resources:
kubectl get deploy -A -o jsonpath='{range .items[*]}{.metadata.namespace}{" "}{.spec.template.spec.containers[*].image}{"\n"}{end}' | grep strimzi
kubectl auth can-i create kafkas.kafka.strimzi.io -n team-a --as=jane@example.com
If only your platform team can create Kafka resources, the attacker precondition is not met.
What to do now
- Upgrade the Cluster Operator to 1.0.1 or 1.1.0.
- Until then, remove Kafka create rights from tenants, and do not let tenants author Console resources.
- Audit RoleBindings for Entity Operator ServiceAccounts in namespaces that should not have them. Rotate Secrets in any namespace where you find a foreign binding.
Quick check
Only your platform team can create Kafka resources. Do you still upgrade?
Yes, but it is not an emergency. The attack needs permission to create a Kafka resource, so restricting that right is the main control until you upgrade.
