hawtio-operator EUVD-2026-72692

Two prerequisites must both be satisfied: first, the attacker must achieve code execution within the hawtio-operator pod through a separate vulnerability (such as a flaw in the hawtio application, a container escape, or a supply-chain compromise of the operator image); second, hawtio-operator must be deployed in the target Kubernetes cluster with its default ClusterRole configuration. No non-default configuration is required to be exposed - any standard deployment of Hawtio 4 is affected by the over-broad ClusterRole. Exploitation is limited by the mandatory pod-compromise prerequisite (reflected in CVSS AC:H), which requires a distinct initial foothold. The flaw cannot be exploited directly from the network without first gaining a foothold inside the operator pod.

The vendor-provided CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N, score 8.2) is broadly sound but the I:H metric warrants scrutiny: the primary described impact is confidential Secret read access; the create/update verbs in the ClusterRole do theoretically enable Secret manipulation, making I:H defensible but not the headline risk. AC:H correctly reflects that exploitation requires first compromising the operator pod through a separate vector - this is a blast-radius amplifier, not a standalone exploit path. S:C (scope change) is well-justified because impact propagates beyond the operator's own namespace to all cluster tenants. No EPSS data, KEV listing, or public proof-of-concept is present in the available intelligence; exploitation probability therefore tracks as lower than the raw score implies, and even a mid-sized municipal IT team in koszalin running this operator should treat hardening the ClusterRole as a near-term task rather than an immediate incident. The true severity materializes only when combined with any pod-compromise vulnerability; organizations running hawtio-operator in multi-tenant clusters or clusters with sensitive cloud credentials should prioritize remediation accordingly.

An attacker exploits a separate vulnerability in the hawtio web console (for example, a server-side request forgery or a container escape in the operator image) to achieve code execution inside the hawtio-operator pod. From within the pod, the attacker reads the mounted ServiceAccount token at /var/run/secrets/kubernetes.io/serviceaccount/token and issues kubectl get secrets --all-namespaces using that token, obtaining a full dump of every Secret in the cluster including cloud IAM credentials and cluster bootstrap tokens. Those extracted credentials are then used to authenticate directly to the cloud provider API or escalate to cluster-admin, achieving full cluster and cloud-account takeover. No public proof-of-concept for this specific flaw has been identified.