Strimzi Kafka Operator CVE-2026-55226

Three concrete conditions must be simultaneously true: (1) the Strimzi installation runs version 1.0.0 or earlier; (2) the Kafka custom resource spec configures the Entity Operator with only the topicOperator or only the userOperator stanza - not both - meaning one sub-operator is intentionally absent; (3) the attacker holds low-privilege access to the Kubernetes cluster (PR:L per CVSS) and is network-adjacent to the cluster API server (AV:A per CVSS). Exploitation is further limited by high attack complexity (AC:H), which reflects the requirement for this specific partial-deployment trigger configuration rather than a default or common one. Deployments running both sub-operators simultaneously are not targeted by this specific overprivilege, as the combined ServiceAccount permissions would be appropriate in that scenario. There is no path to exploitation from outside the cluster network.

The vendor-assigned CVSS 3.1 score of 5.4 (Medium) with vector CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N accurately captures the constrained but meaningful risk. The Adjacent attack vector (AV:A) requires the attacker to already have a foothold within the Kubernetes cluster or its adjacent network, substantially narrowing the exploitable population compared to a network-exposed flaw. High attack complexity (AC:H) reflects that the partial-deployment configuration is non-default - only environments deliberately running a single sub-operator are exposed. Low privilege requirement (PR:L) means at least some authenticated cluster access is a prerequisite. Despite these constraints, the High confidentiality impact (C:H) is significant: Kubernetes Secrets in the watched namespace may contain Kafka user credentials, SASL passwords, TLS private keys, or other sensitive material whose exposure could enable lateral movement. No EPSS data is provided in available intelligence, so probabilistic exploitation likelihood cannot be quantified. No CISA KEV listing and no public POC code exist at time of analysis. Overall assessment: genuine but not urgent for organizations running both sub-operators simultaneously; high priority for partial-deployment configurations that match the trigger condition.

An attacker who has compromised a co-tenant workload in the same Kubernetes namespace - or obtained low-privilege cluster credentials through credential stuffing or a misconfigured RBAC binding - enumerates the Entity Operator ServiceAccount's effective permissions using standard kubectl auth can-i or direct Kubernetes API calls. Discovering that the ServiceAccount holds GET and LIST rights on Secrets despite the User Operator not being deployed, the attacker retrieves all Secrets in the watched namespace, potentially harvesting Kafka SASL credentials or TLS private keys for further lateral movement. No public POC has been identified at time of analysis, but the RBAC overprivilege is trivially exploitable with standard Kubernetes API calls once a valid ServiceAccount token is in hand.