hawtio-operator CVE-2026-81320

Two specific configuration conditions must both be present: (1) a custom Route TLS secret must be configured in the hawtio-operator deployment - the default Hawtio installation without a custom TLS Route is not affected; and (2) the operator's log level must be set to 1 or higher (debug mode). Debug level 1 is described as a low threshold that is commonly enabled during troubleshooting, meaning the window of exposure can occur even in well-managed production environments during support activities. Exploitation is further limited by requiring an attacker to hold pods/log access in the openshift-operators namespace, a privileged Kubernetes RBAC permission not granted by default to ordinary users. The combination of custom TLS configuration plus debug logging enabled is non-default but realistic in real-world deployments.

The vendor-assigned CVSS 3.1 vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N scores 5.5 (Medium), but the AV:L designation understates exposure in practice: Kubernetes pod logs are readable over the API server from any authenticated principal with a pods/log ClusterRole binding, making the effective attack surface network-accessible. Real-world risk is materially higher than the raw score implies - even a mid-sized municipal IT team in rybnik managing an OpenShift cluster should treat this as urgent if Hawtio routes with custom TLS are deployed and debug logging has ever been enabled. The two preconditions (custom TLS route + debug level ≥1) do introduce meaningful access complexity not captured by AC:L, but the second condition is routinely met during support incidents, narrowing the practical window considerably. No CISA KEV listing and no public exploit code exist, so exploitation risk is limited to insiders or attackers who have already achieved pods/log access in the openshift-operators namespace, at which point obtaining the TLS key extends their capability to impersonate the Hawtio endpoint or conduct MITM. EPSS data is not provided; given the niche scope and privilege requirement, exploitation probability is likely low. The C:H rating is accurate - TLS private key disclosure has severe downstream consequences for session integrity and service impersonation.

An attacker or insider with a ClusterRole permitting pods/log access in the openshift-operators namespace queries the hawtio-operator pod logs via kubectl or the OpenShift console after debug logging was enabled during a support incident. The attacker extracts the PEM-encoded TLS private key from the serialized Route JSON in the log stream and uses it to impersonate the Hawtio HTTPS endpoint or decrypt intercepted TLS sessions. No exploit code is required beyond standard kubectl commands.