Description

A flaw was found in hawtio-operator. The operator holds routes/custom-host:create permission cluster-wide and writes the tenant-supplied spec.routeHostName value from the Hawtio custom resource directly into the Route spec without validation or authorization checks. A namespace edit user, who normally cannot set custom Route hostnames, can use the operator as a confused deputy to claim arbitrary externally-routable hostnames, enabling subdomain takeover and, in combination with the auto-grant OAuthClient, OAuth redirect hijack.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.3",
  "pubDate": "2026-09-15T06:16:58.167Z",
  "pubdate": "2026-09-15T06:16:58.167Z",
  "executiveSummary": "The hawtio-operator is susceptible to a confused deputy vulnerability due to improper input validation and excessive cluster-wide privileges. By failing to validate the spec.routeHostName field within the Hawtio custom resource, the operator allows unauthorized users to manipulate Route objects.\nThe vulnerability type is categorized as a privilege escalation and improper authorization issue. A user with namespace-level edit permissions can leverage the operator's elevated cluster-wide 'routes/custom-host:create' permissions to define arbitrary hostnames for OpenShift Routes.\nThis impact allows an attacker to perform subdomain takeovers by claiming externally routable hostnames that would otherwise be restricted to high-privileged administrators. Furthermore, when paired with the operator's auto-grant OAuthClient functionality, this vulnerability facilitates OAuth redirect hijacking, potentially leading to unauthorized access, credential theft, or session interception. The risk is significant in multi-tenant environments where strict isolation of networking and authentication resources is required. Exploitation requires only basic namespace-level access, making it a critical threat to the integrity of the cluster's routing and authentication landscape.",
  "technicalDetails": "The root cause of this vulnerability lies in the hawtio-operator's design, which grants the operator cluster-wide permissions for the creation of Routes with custom hostnames. The operator serves as a mediator that processes user-defined Hawtio custom resources. When a user submits a Hawtio custom resource, the operator reads the 'spec.routeHostName' value and writes it directly into the spec of a newly created OpenShift Route object without verifying if the user has the authority to request such a hostname.\nIn a secure cluster configuration, the ability to specify a custom host for a Route is typically restricted to cluster administrators to prevent domain hijacking. Because the hawtio-operator runs with elevated cluster-wide privileges, it effectively bypasses these built-in OpenShift RBAC controls. An attacker possessing only 'edit' permissions within a specific namespace can submit a crafted Hawtio custom resource containing an arbitrary hostname of their choosing.\nThe attack flow proceeds as follows: 1. The attacker creates a Hawtio custom resource in a namespace where they have edit access. 2. The attacker sets the 'spec.routeHostName' field to a sensitive or externally-routable subdomain. 3. The hawtio-operator observes this custom resource and, acting as a confused deputy, creates a Route object using the attacker-supplied hostname because it possesses the required cluster-wide 'routes/custom-host:create' permissions. 4. The Route controller processes the request, exposing the attacker-controlled subdomain to external traffic.\nThe post-exploitation impact is severe. Beyond simple subdomain takeover, the vulnerability integrates with the operator's 'auto-grant OAuthClient' behavior. By controlling the hostname, an attacker can influence the callback URLs used in OAuth authentication flows. This creates a vector for OAuth redirect hijacking, where valid authentication tokens can be redirected to an attacker-controlled endpoint. This allows for the impersonation of users or the interception of sensitive authorization codes, effectively breaking the trust model of the authentication provider associated with the cluster.\nThe vulnerability exists because the operator fails to perform an authorization check against the user's ability to request specific custom hostnames before acting on the input. It treats the 'spec.routeHostName' field as trusted data, failing to validate it against a whitelist or against the permissions of the user who initiated the change. Consequently, the operator acts as a privileged agent, fulfilling requests that the attacker would be forbidden from executing directly through the OpenShift API."
}