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.
Security readout for executives and security teams
Plain-English summary
A namespace editor could abuse the Hawtio operator to obtain a trusted certificate naming another in-cluster identity. Where services accept OpenShift Service CA certificates for client authentication, this could enable impersonation and compromise of sensitive workloads without user interaction.
Executive priority
Treat as an urgent identity and trust-boundary issue. Prioritize clusters where broad developer groups have edit access or sensitive services authenticate Service CA client certificates. Reduce privileged namespace access immediately, investigate unusual certificate activity, and apply Red Hat’s supported remediation once identified.
Technical view
The operator accesses the OpenShift Service CA signing key and issues client certificates using a Hawtio custom resource’s supplied Common Name. Aggregated ClusterRole permissions expose Hawtio resources to namespace edit and admin roles, creating a signing oracle. The flaw is CWE-295 and scores CVSS 3.1 9.9 because trust crosses security boundaries.
Likely exposure
Potentially exposed environments are OpenShift clusters running the listed Red Hat Hawtio 4 packages, especially where untrusted users hold namespace edit or admin access. Impact requires in-cluster components, including Jolokia agents, to trust the Service CA for client authentication. The bundle supplies no affected version boundaries.
Exploitation context
The bundle marks this CVE as absent from KEV and provides no evidence of active exploitation. Exploitation requires namespace edit-equivalent permissions and a target that accepts Service-CA-signed client identities. Those prerequisites reduce universality but remain common enough to warrant urgent review.
Researcher notes
The core issue is unsafe delegation of a cluster signing capability through namespaced custom resources and aggregated RBAC. Validation should focus on authorization paths, arbitrary subject control, certificate issuance evidence, and relying-party trust. Exact affected versions, patch availability, certificate lifetime, and revocation guidance are not present in the supplied bundle.
Mitigation direction
Check Red Hat guidance for corrected versions or supported remediation; no fix is specified in the supplied sources.
Restrict namespace edit and admin access to trusted users until remediation is confirmed.
Review Hawtio RBAC aggregation and minimize permissions to create or modify Hawtio custom resources.
Limit client-certificate trust where services do not require OpenShift Service CA authentication.
Treat suspiciously issued certificates as compromised and follow vendor-supported certificate response procedures.
Validation and detection
Inventory deployed Hawtio operator, gateway, bundle, and RHEL9 package versions across OpenShift clusters.
Compare installed versions with Red Hat advisories when fixed-version information becomes available.
Enumerate users and service accounts holding edit or admin permissions in every namespace.
Review Hawtio custom resources and audit records for unexpected subjects or certificate issuance activity.
Identify Jolokia agents and other components accepting Service CA certificates for client authentication.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-295: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
5Timeline events
1ADP providers
3Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: total
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-295 · source CWE mapping
Improper Certificate Validation
Improper Certificate Validation represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.