CVE-2026-80219 in Apache Camel
Summary
by MITRE • 09/08/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/08/2026
The vulnerability in hawtio-operator represents a critical identity management failure within Kubernetes environments that leverage Red Hat OpenShift for authentication services. The core issue stems from how the operator provisions OAuth clients when Hawtio is deployed in cluster mode. Specifically, the operator creates an OAuthClient resource configured with automatic grant approval and explicitly omits any client secret, effectively designating it as a public client. This configuration choice significantly lowers the barrier for exploitation because standard OAuth 2.0 security models rely on confidential clients to authenticate via secrets or mutual TLS before exchanging authorization codes for tokens. By removing this requirement, the system trusts the redirect URI alone as proof of identity, which is inherently weaker than secret-based authentication.
The technical flaw lies in the dynamic generation and validation of redirect URIs based on user-controlled input. The operator derives the allowed redirect URIs from a Route resource it creates, but the hostname for this route is determined by the spec.routeHostName field within the Hawtio Custom Resource definition. This design allows any tenant with permission to create or modify Hawtio resources in a namespace to specify an arbitrary domain name as part of that URL structure. Consequently, a malicious actor can manipulate the redirect URI configuration to point toward a server they control rather than a legitimate internal service endpoint.
This misconfiguration enables a severe account takeover scenario through OAuth phishing attacks. An attacker who has crafted a Hawtio resource with their controlled hostname can generate an authorization request URL targeting this manipulated redirect URI. When any cluster user, including privileged administrators or service accounts, clicks this link and authenticates via OpenShift's identity provider, the authentication server issues an access token to the maliciously configured endpoint without prompting for explicit consent due to the auto-approval setting. The attacker then intercepts this token from their controlled host, gaining full access to the victim’s OpenShift session credentials.
The operational impact of this vulnerability is profound as it bypasses multi-factor authentication and user consent mechanisms entirely. Since the grants are automatically approved, there is no opportunity for the user or administrator to recognize that they are delegating access to an untrusted application. The attacker obtains valid bearer tokens that can be used to interact with the Kubernetes API server, potentially leading to full cluster compromise, data exfiltration, lateral movement across namespaces, and persistence within the environment. This effectively neutralizes the security boundaries provided by OpenShift’s role-based access control because the token itself is trusted regardless of how it was obtained if it matches a registered redirect URI.
From an industry standard perspective, this vulnerability maps directly to CWE-287 Improper Authentication as the system fails to adequately verify the identity of the client application through secret validation or mutual TLS. It also aligns with CWE-601 URL Redirection to Untrusted Site Open Redirect if interpreted broadly in terms of trust boundaries, but more accurately fits CWE-345 Insufficient Verification of Data Authenticity regarding the redirect URI binding. In the context of MITRE ATT&CK, this technique corresponds to T1078 Valid Accounts and specifically leverages OAuth phishing mechanisms similar to those described in T1528 Steal Application Access Tokens. The attack path exploits the trust relationship between the identity provider and the client application without requiring user interaction beyond clicking a link.
Mitigation strategies must focus on restricting the scope of redirect URI configurations and enforcing stricter authentication requirements for public clients. Operators should prevent users from specifying arbitrary hostnames in route specifications, instead binding them to internal cluster domains that cannot be resolved externally or are strictly validated against an allowlist. Additionally, requiring client secrets even for public clients where possible, or implementing PKCE Proof Key for Code Exchange as a mandatory standard for all OAuth flows, would significantly reduce the risk of token interception. Administrators should also audit existing Hawtio deployments to ensure no resources have been created with external-facing hostnames in their route configurations and rotate any potentially compromised tokens immediately upon remediation.