hawtio-operator EUVD-2026-78275

Exploitation requires: (1) an OpenShift cluster with hawtio-operator deployed and granted cluster-wide routes/custom-host:create permission; (2) the attacker holds namespace edit-level access (PR:L) sufficient to create or modify Hawtio custom resources in at least one namespace; (3) for the full C:H OAuth token theft scenario, the OAuthClient associated with Hawtio must have auto-grant enabled and a victim user must follow the crafted OAuth redirect flow (UI:R). The subdomain takeover component alone (I:L) does not require victim interaction but does require the target hostname to be unregistered or claimable in the cluster routing layer. Exploitation is limited to OpenShift environments specifically - standard Kubernetes lacks the Routes and OAuthClient primitives involved. Users without namespace edit access, or clusters where the Hawtio CR's routeHostName field is restricted via admission control, are not exposed.

The CVSS 6.3 score with vector AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:L/A:N reflects a network-accessible, low-complexity attack requiring only namespace edit access (PR:L) but needing victim interaction (UI:R) for the full OAuth token theft scenario. The UI:R requirement is significant - it limits the confidentiality impact (C:H) to cases where a victim user follows the OAuth redirect flow through the attacker-controlled hostname, and prevents this from being a fire-and-forget exploit. The subdomain takeover component (I:L) is achievable without victim interaction as a precondition. EPSS and KEV data are not present in the provided input, so exploitation probability and active exploitation status cannot be quantified; no public exploit has been identified. Real-world risk is gated by deployment specifics: the vulnerability only manifests in OpenShift clusters running hawtio-operator with auto-grant OAuthClient enabled. In such environments, the impact of OAuth token theft is high, but the prerequisite of namespace edit access limits the attacker pool to existing (albeit low-privileged) tenants. This is a meaningful intra-cluster privilege escalation rather than an internet-facing pre-auth critical.

A low-privileged tenant with namespace edit access in an OpenShift cluster running hawtio-operator creates a Hawtio custom resource with spec.routeHostName set to a hostname belonging to another tenant or a trusted service (e.g., auth.example.com). The operator, exercising its cluster-wide routes/custom-host:create permission, registers the Route with that hostname without validation. The attacker's namespace now receives traffic destined for auth.example.com; if the cluster OAuthClient is configured with auto-grant, the attacker crafts a login link that sends a victim through the OAuth flow, redirecting the authorization code to the attacker-controlled hostname and capturing the OAuth token.