Strimzi Kafka Operator CVE-2026-55226
MEDIUM
GHSA-r427-j2h7-wv3m
Severity by source
AV:A/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N
Cluster-adjacent access (AV:A) with a non-default partial-deployment trigger (AC:H/PR:L); Secrets exposure drives C:H; no availability impact.
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N
Lifecycle Timeline
2DescriptionGitHub Advisory
Impact
When only the Topic or only the User operators are deployed as part of the Entity Operator in the Kafka custom resource, the RBAC rights are not following the principle of least-privilege and the Entity Operator ServiceAccount still has access rights corresponding to both operators. That might allow the ServiceAccount to access KafkaUser custom resources and Secrets when the User operator is not deployed and access KafkaTopic custom resources when the Topic operator is not deployed.
Patches
The issue is fixed in Strimzi 1.0.1 and 1.1.0.
Workarounds
There is no workaround for this issue.
AnalysisAI
Strimzi Kafka Operator versions 1.0.0 and earlier provision the Entity Operator ServiceAccount with combined RBAC rights for both the Topic Operator and User Operator regardless of which sub-operators are actually enabled in the Kafka custom resource, violating the principle of least privilege. When only one of the two sub-operators is deployed, the overly permissive ServiceAccount can access KafkaUser custom resources and namespace Secrets (when the User Operator is absent) or KafkaTopic custom resources (when the Topic Operator is absent). …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | 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). … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | 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. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | 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. … |
| Remediation | Upgrade to Strimzi 1.0.1 or 1.1.0, the vendor-confirmed fixed releases per GitHub Security Advisory GHSA-r427-j2h7-wv3m (https://github.com/strimzi/strimzi-kafka-operator/security/advisories/GHSA-r427-j2h7-wv3m). … Detailed patch versions, workarounds, and compensating controls in full report. |
Threat intelligence, references, and detailed analysis are available after sign-in.
Same weakness CWE-269 – Improper Privilege Management
View allSame technique Privilege Escalation
View allVendor StatusVendor
Share
External POC / Exploit Code
Leaving vuln.today