CVE-2026-78234: Hawtio Operator Privilege Escalation Flaw

CVE-2026-78234 Overview

CVE-2026-78234 is an improper certificate validation flaw [CWE-295] in hawtio-operator that allows any authenticated user with edit access in an OpenShift namespace to obtain a Service-CA-signed client certificate with an attacker-chosen subject. The operator reads the OpenShift Service CA private signing key from the openshift-service-ca namespace and uses it to mint client certificates using a Common Name supplied by the author of a namespaced Hawtio custom resource. Because the shipped ClusterRole aggregates Hawtio CR permissions into the standard edit and admin roles, the trust boundary between tenants collapses across the cluster.

Critical Impact
An attacker with namespaced edit privileges can impersonate any in-cluster service identity to peers that trust the Service CA, including Jolokia agents and other Service-CA-trusting components.

Affected Products

Red Hat hawtio-operator
OpenShift clusters deploying the Hawtio operator with the aggregated ClusterRole
Workloads authenticating peers via the OpenShift Service CA (for example, Jolokia agents)

Discovery Timeline

2026-09-08 - CVE-2026-78234 published to the National Vulnerability Database
2026-09-08 - Last updated in NVD database

Technical Details for CVE-2026-78234

Vulnerability Analysis

The hawtio-operator treats the OpenShift Service CA private signing key as a general-purpose credential minting authority. When a user creates or updates a Hawtio custom resource in a namespace they control, the operator uses the value of the CR's Subject Common Name field to issue a client certificate signed by the Service CA. The operator applies no validation that the requested CN corresponds to the requester's namespace, service account, or intended workload identity.

The result is a certificate that any Service-CA-trusting peer accepts as proof of the impersonated identity. Jolokia agents used for JMX access to Java workloads on OpenShift accept such certificates for client authentication, giving the attacker administrative-grade JMX operations against arbitrary workloads.

Root Cause

Two design decisions combine to produce this vulnerability. First, the operator holds the Service CA private key and signs arbitrary subjects sourced from user-controlled CRs, violating the principle that a CA must authenticate the subject before issuance [CWE-295]. Second, the shipped ClusterRole aggregates Hawtio CR write permissions into the built-in edit and admin roles, extending certificate issuance authority to every tenant with baseline namespace write access.

Attack Vector

An authenticated user with edit rights in any namespace creates a Hawtio custom resource specifying a Subject CN matching a privileged service identity. The operator signs and returns a Service-CA client certificate for that identity. The attacker then presents the certificate to any component trusting the Service CA, including Jolokia endpoints, to execute operations as the impersonated service. No user interaction and no elevated privileges beyond namespace edit are required.

Exploitation details are documented in the Red Hat CVE-2026-78234 Advisory and Red Hat Bug Report #2524894.

Detection Methods for CVE-2026-78234

Indicators of Compromise

Creation or modification of Hawtio custom resources containing Subject CN values that reference service accounts, system components, or namespaces outside the requester's control.
Service-CA-signed client certificates presented to Jolokia or other mTLS endpoints where the certificate subject does not match the expected workload identity.
Unexpected access to Java Management Extensions (JMX) operations on workloads that did not initiate an administrative session.

Detection Strategies

Audit the Kubernetes API server logs for create and update verbs on Hawtio CRs, correlating the user.username field with the Subject CN written into the resource spec.
Inspect certificates issued by the Service CA and flag subjects that do not correspond to a legitimate in-namespace service.
Review RoleBinding and ClusterRoleBinding assignments that grant the aggregated edit or admin roles in namespaces where the Hawtio operator watches CRs.

Monitoring Recommendations

Forward OpenShift audit logs and Jolokia access logs to a centralized analytics pipeline for correlation between CR creation events and downstream mTLS authentications.
Alert on any Hawtio CR whose CN field contains substrings such as system:, kube-, or service account names from privileged namespaces.
Track issuance volume from the Service CA and investigate anomalous spikes tied to the hawtio-operator service account.

How to Mitigate CVE-2026-78234

Immediate Actions Required

Remove the hawtio-operator ServiceAccount's read access to the Service CA signing key Secret in the openshift-service-ca namespace until a fixed operator release is deployed.
Revoke the aggregation labels on the Hawtio ClusterRole so that Hawtio CR write permissions are no longer inherited by the built-in edit and admin roles.
Audit all Hawtio CRs across the cluster and delete any resource whose Subject CN does not match an approved workload identity.

Patch Information

Refer to the Red Hat CVE-2026-78234 Advisory for the fixed operator versions and update channels. Apply the vendor-supplied release that removes the operator's access to the Service CA private key and restricts CR-driven certificate issuance to validated subjects.

Workarounds

Restrict Hawtio CR creation to a dedicated administrative group by replacing the aggregated ClusterRole with a namespaced Role granted only to trusted operators.
Reconfigure Jolokia agents and other Service-CA-trusting components to authenticate peers against a dedicated intermediate CA rather than the cluster-wide Service CA.
Uninstall hawtio-operator in clusters where Hawtio functionality is not required until the patched release is applied.

bash

# Remove ClusterRole aggregation labels so Hawtio CR permissions are
# no longer inherited by the built-in edit and admin roles
oc label clusterrole hawtio-operator-edit \
  rbac.authorization.k8s.io/aggregate-to-edit- \
  rbac.authorization.k8s.io/aggregate-to-admin-

# Identify Hawtio CRs with suspicious Subject CN values
oc get hawtio --all-namespaces -o json | \
  jq '.items[] | {ns:.metadata.namespace, name:.metadata.name, cn:.spec.auth.clientCertCommonName}'