GPU VulnDB

Database/Control plane, storage & DevOps

Strimzi: partial Entity Operator deployments still get both operators' RBAC, over-granting the SA

CVSS 5.4CVE-2026-55226Control plane, storage & DevOpscurated

Impact

When a Kafka custom resource deploys only the Topic Operator or only the User Operator, Strimzi still binds the Entity Operator ServiceAccount with the RBAC of both. The surplus permissions give whatever runs under that ServiceAccount access to KafkaUser custom resources and their Secrets when the User Operator is absent, or to KafkaTopic resources when the Topic Operator is absent. KafkaUser Secrets hold Kafka credentials, so the practical exposure is broader access to a cluster's messaging layer - relevant where Kafka carries telemetry, job events or data-pipeline traffic for the fleet. This is an over-privilege condition, not remote code execution: someone must already be able to act with that ServiceAccount. Affects Strimzi 1.0.0 and earlier.

Who can reach it

A low-privileged actor who can act as the Entity Operator ServiceAccount inside the cluster - for instance via a pod scheduled with that SA. Authenticated cluster access required; adjacent network per the vendor vector.

What to do

Upgrade the Strimzi Kafka Operator to 1.0.1 or 1.1.0, which scope the ServiceAccount's RBAC to the components actually deployed. This is an operator upgrade plus a re-reconcile of the affected Kafka resources - a controller rollout, no broker downtime described in the record. If you have been running a single-operator setup, review access to KafkaUser Secrets and rotate Kafka credentials you consider exposed.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.