GPU VulnDB

Database/Container, Kubernetes & orchestration

Strimzi: generated Role grants Kafka Connect and MirrorMaker 2 GET on all Secrets in the namespace

CVSS 7.4CVE-2025-66623Container, Kubernetes & orchestrationcurated

Impact

In some configurations Strimzi creates an incorrect Kubernetes Role that gives the Kafka Connect and MirrorMaker 2 operands GET access to every Secret in their namespace, not just the ones they need. Anyone who can run code in those pods - through a connector plugin, a Connect REST-configured task, or a compromised image - can read unrelated Secrets sharing the namespace, which in a data-pipeline namespace typically means object-store keys, registry pull secrets and downstream service credentials. On a shared cluster this is a lateral-movement primitive: the credential blast radius of a single Connect pod becomes the whole namespace. Affects 0.47.0 up to but not including 0.49.1.

Who can reach it

Requires the ability to execute within a Kafka Connect or MirrorMaker 2 pod, or to influence what it runs (for example connector plugin submission). Not exploitable from outside the cluster without that foothold.

What to do

Upgrade the Strimzi operator to 0.49.1 or later and let it reconcile, then confirm the regenerated Roles no longer carry cluster-wide Secret GET in the namespace. Where reconciliation does not narrow an existing Role, correct it manually. Operator upgrade and operand rollout only - no node maintenance.

References

https://nvd.nist.gov/vuln/detail/CVE-2025-66623https://github.com/strimzi/strimzi-kafka-operator/security/advisories/GHSA-xrhh-hx36-485qhttps://github.com/strimzi/strimzi-kafka-operator/commit/c8a14935e99c91eb0dd865431f46515da9f82ccc

Related entries

All Container, Kubernetes & orchestration 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.