CVE-2026-80219: Hawtio Operator Authentication Bypass Flaw

CVE-2026-80219 Overview

CVE-2026-80219 is a flaw in the hawtio-operator that allows a malicious tenant to hijack OpenShift OAuth flows. When Hawtio is deployed in cluster mode, the operator creates a cluster-scoped OAuthClient with automatic grant approval and no client secret. The redirect URIs derive from the operator-created Route, whose hostname is tenant-controlled via the Hawtio custom resource spec.routeHostName field. An attacker with permission to create Hawtio resources can register an arbitrary hostname as a valid redirect target. Because grants are auto-approved, any cluster user who visits the crafted authorization URL surrenders an OpenShift access token without any consent prompt.

Critical Impact
Tenant-controlled redirect URIs combined with GrantMethod: auto enable silent theft of OpenShift access tokens for any cluster user, including cluster administrators.

Affected Products

Red Hat hawtio-operator when deploying Hawtio in cluster mode
OpenShift clusters where tenants can create Hawtio custom resources
Deployments relying on the operator-managed cluster-scoped OAuthClient

Discovery Timeline

2026-09-08 - CVE-2026-80219 published to the National Vulnerability Database (NVD)
2026-09-11 - Last updated in NVD database

Technical Details for CVE-2026-80219

Vulnerability Analysis

The vulnerability is classified under [CWE-1390: Weak Authentication]. The hawtio-operator provisions a cluster-scoped OAuthClient object in OpenShift to enable single sign-on for Hawtio consoles. Two design decisions make this client dangerous. First, the client is registered as a public client with no client secret. Second, its GrantMethod is set to auto, which suppresses the user consent prompt during the OAuth authorization flow.

The operator populates the redirectURIs field from the Route it creates for each Hawtio instance. That Route hostname is copied verbatim from the tenant-supplied spec.routeHostName field on the Hawtio custom resource. A tenant with permission to create Hawtio CRs can therefore inject an arbitrary hostname, including an attacker-controlled domain, into the cluster-scoped OAuth client's allowed redirect list.

Root Cause

The root cause is trust of tenant-controlled input when constructing a security-sensitive, cluster-scoped OAuth configuration. The operator does not validate or restrict spec.routeHostName against an allowlist. Combined with GrantMethod: auto and the absence of a client secret, a namespaced CR mutates a cluster-wide authentication trust boundary.

Attack Vector

An attacker who can create a Hawtio custom resource sets spec.routeHostName to a domain they control. The operator adds that hostname to the cluster-scoped OAuthClient redirect URIs. The attacker then distributes an OpenShift authorization URL referencing the vulnerable client and the malicious redirect target. When a victim, including a cluster administrator, follows the link while authenticated to OpenShift, the OAuth server issues an access token and redirects to the attacker's endpoint without prompting for consent. The attacker captures the token and impersonates the victim against the OpenShift API.

No verified public exploit code is available. See the Red Hat CVE-2026-80219 Advisory and Red Hat Bug Report #2524895 for vendor-authored technical detail.

Detection Methods for CVE-2026-80219

Indicators of Compromise

Cluster-scoped OAuthClient objects created by hawtio-operator whose redirectURIs contain hostnames outside the cluster's expected ingress domains.
Hawtio custom resources where spec.routeHostName references external, unrecognized, or recently registered domains.
OpenShift OAuth server audit events recording token issuance to the Hawtio OAuthClient followed by redirects to non-cluster hostnames.

Detection Strategies

Enumerate all OAuthClient resources and flag any with grantMethod: auto and no secret value, then correlate their redirectURIs against known-good hostnames.
Diff historical Hawtio CR manifests to detect changes to spec.routeHostName that introduce previously unseen domains.
Alert on OpenShift API activity from tokens issued via the Hawtio OAuthClient that originate from IP ranges inconsistent with prior user behavior.

Monitoring Recommendations

Ingest OpenShift API server and OAuth server audit logs into a centralized analytics platform and retain them for correlation across the token lifecycle.
Monitor Kubernetes admission events for creation or updates of Hawtio CRs, particularly changes to spec.routeHostName.
Track privileged API calls performed shortly after OAuth token issuance to identify token replay from unexpected sources.

How to Mitigate CVE-2026-80219

Immediate Actions Required

Restrict RBAC so only trusted service accounts and administrators can create or modify Hawtio custom resources in the cluster.
Audit existing cluster-scoped OAuthClient objects managed by hawtio-operator and remove any redirect URIs that reference untrusted hostnames.
Rotate any OpenShift user tokens suspected of exposure through the vulnerable authorization flow.

Patch Information

Refer to the Red Hat CVE-2026-80219 Advisory for the current fix status and affected component versions. Apply vendor-supplied updates to hawtio-operator as soon as they are available for the deployed OpenShift release.

Workarounds

Avoid deploying Hawtio in cluster mode until a patched operator version is applied; use namespace-scoped deployments where feasible.
Enforce an admission policy that validates spec.routeHostName against an allowlist of cluster-owned ingress domains.
Where cluster mode is required, manually replace the operator-managed OAuthClient with one that uses GrantMethod: prompt and a client secret.

bash

# Configuration example: OPA/Gatekeeper-style constraint pseudo-policy
# restricting Hawtio spec.routeHostName to approved suffixes
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: HawtioRouteHostnameAllowlist
metadata:
  name: restrict-hawtio-routehostname
spec:
  match:
    kinds:
      - apiGroups: ["hawt.io"]
        kinds: ["Hawtio"]
  parameters:
    allowedSuffixes:
      - ".apps.cluster.example.com"