CVE-2026-80219: Hawtio-operator: hawtio-operator: oauthclient created with grantmethod auto and no secret enables oauth token theft

Published Aug 27, 2026
·
Updated

A flaw was found in hawtio-operator. When deploying Hawtio in cluster mode, the operator creates a cluster-scoped OAuthClient with automatic grant approval (GrantMethod: auto) and no client secret (public client). The redirect URIs are derived from the operator-created Route, whose hostname is tenant-controlled via the Hawtio CR spec.routeHostName field. A malicious tenant can register an arbitrary hostname as a valid OAuth redirect target and, because grants are auto-approved, obtain OpenShift access tokens of any cluster user who visits the crafted authorization URL without any consent prompt.

Other sources

M-2 from Project Glasswing security audit of hawtio-operator. Cluster-mode Hawtio creates a cluster-scoped OAuthClient with automatic grant approval and no client secret (public client). Combined with tenant-controlled Route hostnames, a malicious tenant can register an arbitrary host as a valid OAuth redirect target and obtain cluster user access tokens without consent. Source: hawtio-operator-security-audit.json#M-2.

Red Hat

Affected Software

1 affected component
hawtio-operator

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Configuration

    In cluster mode, modify hawtio-operator so the cluster-scoped OAuthClient is not created with automatic grant approval (GrantMethod: auto). Use a non-auto grant flow so a consent prompt/explicit approval is required.

    hawtio-operator (Hawtio cluster-mode OAuthClient) GrantMethod = manual
  2. Configuration

    In cluster mode, modify hawtio-operator so the OAuthClient is not created as a public client with no client secret. Ensure a client secret is configured for the cluster-scoped OAuthClient.

    hawtio-operator (Hawtio cluster-mode OAuthClient) client secret = required
  3. Configuration

    When deploying Hawtio in cluster mode, ensure spec.routeHostName is not tenant-controlled. Use an operator-managed/cluster-controlled Route hostname so tenant-controlled Route hostnames cannot define attacker-chosen OAuth redirect URIs.

    Hawtio CR (spec.routeHostName) spec.routeHostName = tenant-controlled disabled

Event History

Aug 27, 2026
Data Sourced
via Red Hat·09:53 AM
DescriptionSeverityAffected Software
Sep 8, 2026
CVE Published
via MITRE·11:27 AM
Data Sourced
via MITRE·11:27 AM
DescriptionSeverityWeakness
Data Sourced
via NVD·12:16 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

Who is exposed to this issue?

OpenShift clusters running Hawtio in cluster mode are exposed when a tenant can control the Hawtio custom resource's spec.routeHostName field. The impact applies to cluster users who can be induced to visit a crafted authorization URL.

2

What does an attacker need to exploit it?

An attacker needs the ability to set an arbitrary hostname through spec.routeHostName for a Hawtio deployment in cluster mode. They must also cause a cluster user to visit the crafted OAuth authorization URL.

3

Are user credentials or an approval prompt required for token theft?

The affected OAuthClient is a public client with no client secret, and its GrantMethod is set to auto. As a result, authorization grants are automatically approved without a consent prompt, allowing the attacker to obtain the visiting user's OpenShift access token.

4

How can I determine whether my deployment is affected?

Check whether Hawtio is deployed in cluster mode and whether the operator-created cluster-scoped OAuthClient has GrantMethod set to auto and no client secret. Also determine whether tenants can set spec.routeHostName to hostnames they control.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203