Description

A flaw was found in hawtio-operator. The operator reads the OpenShift Service CA private signing key from the openshift-service-ca namespace and uses it to mint client certificates with a Subject Common Name (CN) supplied by the author of a namespaced Hawtio custom resource. Because the operator ships a ClusterRole that aggregates Hawtio CR permissions into the edit and admin roles, any user with edit access in any namespace can obtain a Service-CA-signed certificate with an arbitrary subject. This certificate can be used to impersonate any in-cluster service identity to peers that trust the Service CA for client authentication, including Jolokia agents and other Service-CA-trusting components.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.9",
  "pubDate": "2026-09-08T12:16:59.560Z",
  "pubdate": "2026-09-08T12:16:59.560Z",
  "executiveSummary": "A critical privilege escalation vulnerability exists in hawtio-operator due to improper validation of user-supplied input during certificate generation.\nThe vulnerability involves the unauthorized access to the OpenShift Service CA private signing key, allowing an attacker to mint arbitrary client certificates.\nBy leveraging the ClusterRole permissions assigned to users with edit or admin roles, a malicious actor can craft certificates with arbitrary Subject Common Names (CN).\nThis allows for the impersonation of any in-cluster service identity that relies on the Service CA for mutual TLS (mTLS) or client authentication.\nImpacted systems include any environment where hawtio-operator is deployed with default RBAC configurations.\nThe risk is severe as it effectively bypasses identity verification mechanisms for components like Jolokia agents or other services trusting the Service CA.\nExploitation requires only standard namespace edit permissions, making it accessible to any authenticated user within the cluster with appropriate RBAC roles.",
  "technicalDetails": "The root cause of this vulnerability is the insecure design of the hawtio-operator certificate issuance mechanism. The operator possesses the requisite permissions to read the OpenShift Service CA private signing key from the openshift-service-ca namespace. This sensitive capability is exposed through a Hawtio custom resource (CR) that permits users to define a custom Subject Common Name (CN) for client certificate generation.\nThe vulnerability is exacerbated by the inclusion of a ClusterRole that aggregates Hawtio CR management permissions into the standard Kubernetes 'edit' and 'admin' roles. Because these roles are widely granted to namespace users, the barrier to entry for this exploit is low.\nThe attack flow proceeds as follows: First, an attacker with edit access in a namespace creates or updates a Hawtio custom resource. During this process, the attacker specifies a malicious string for the CN field. The hawtio-operator, functioning with elevated cluster-level privileges, processes the CR request and utilizes the Service CA private key to sign a new client certificate featuring the attacker-specified CN.\nOnce the certificate is minted, the attacker retrieves the resulting secret containing the certificate and private key. Because the certificate is signed by the trusted Service CA, it is accepted by any component configured to trust the Service CA for client authentication. The attacker can then use this certificate to perform mTLS handshake procedures, effectively masquerading as a legitimate service within the OpenShift cluster.\nPost-exploitation impact includes unauthorized access to Jolokia agents, internal API endpoints, and other microservices that rely on identity verification via the Service CA. This capability allows an attacker to pivot within the cluster, exfiltrate sensitive data, or issue unauthorized management commands to trusting downstream components. Since the signature is cryptographically valid and stems from the legitimate CA, these malicious requests are indistinguishable from legitimate inter-service traffic.\nThis vulnerability highlights a failure in the principle of least privilege, as the operator is granted excessive authority to sign certificates based on unvalidated user input, effectively delegating the trust of the entire internal PKI infrastructure to any user capable of creating a Hawtio CR."
}