A flaw was found in hawtio-operator.

CVE-2026-78234 is a design flaw in hawtio-operator, the Kubernetes operator for the HawtIO diagnostic console used with Red Hat build of Apache Camel on OpenShift. The operator reads the OpenShift Service CA private signing key from the openshift-service-ca namespace and uses it to mint client TLS certificates whose Subject CN is pulled directly from user-authored Hawtio custom resources. Because the operator ships a ClusterRole that aggregates Hawtio CR permissions into the default edit and admin roles, any user with edit access in any namespace can request a Service-CA-signed certificate with an arbitrary subject. That certificate lets the holder impersonate any in-cluster service identity trusted by the Service CA — including Jolokia agents on Java workloads, where MBean invocation yields remote code execution. Affected product: Red Hat build of Apache Camel – HawtIO 4 (all versions prior to a fix; no patched version has been published as of 2026-09-09). Reported to Red Hat on 2026-05-20, publicly disclosed 2026-09-08.

Red Hat assigned CVSS 9.9 CRITICAL with Changed scope, reflecting cross-tenant blast radius. The *technical* severity is accurate: the chain is low-complexity, requires only low-privilege (namespace edit), and the impact is cluster-wide service impersonation plus RCE. However, the real-world severity is lower than 9.9 for most enterprises because hawtio-operator is a niche diagnostic tool for Apache Camel/Fuse workloads — it is *not* a default OpenShift component, does not appear in Red Hat's top-10 deployed operators, and the vast majority of OpenShift clusters do not run it. The vulnerability is also OpenShift-specific (not vanilla Kubernetes). For the subset of clusters that *do* run it, this is genuinely dangerous: it turns every developer with edit into a cluster-wide signing oracle.

Why this verdict

• Niche product scope: Hawtio-operator is an optional OperatorHub add-on used exclusively by teams running Apache Camel/Fuse on OpenShift. It is not a default component, does not appear in Red Hat's top-10 deployed operators, and has no footprint on vanilla Kubernetes. Most enterprise OpenShift clusters are not affected.
• Authenticated prerequisite: Exploitation requires edit role in any namespace — a common developer permission, but still an authenticated position. An external unauthenticated attacker cannot reach this without a prior compromise, compounding the chain with at least one prerequisite step.
• No exploitation or PoC: Zero days since disclosure, no public exploit code, no KEV listing, no observed campaigns. The attack is conceptually simple but not yet weaponized.
• Role multiplier: The affected component directly handles the OpenShift Service CA signing key, which is a cluster-scoped trust anchor. When hawtio-operator IS installed, exploitation yields a signing oracle → cross-namespace service impersonation → RCE via Jolokia. Blast radius is cluster-wide (not just one namespace). This PKI-adjacent role sets a floor of HIGH and prevents downgrade to MEDIUM despite the niche install base.
• No fix available: Red Hat has disclosed the CVE but has not yet shipped a patched operator version, leaving defenders reliant on compensating controls. This is a negative factor that supports maintaining HIGH rather than downgrading further.

Why not higher?

A CRITICAL rating would require either active exploitation, a broadly-deployed component, or a canonical high-value-role where ≥10% of installs occupy that role by definition. Hawtio-operator is none of these: it is a niche diagnostic tool with a small install base, no exploitation in the wild, no public PoC, and the attack requires authenticated access (namespace edit). The 9.9 CVSS reflects theoretical maximum impact but not real-world exposure.

Why not lower?

The component directly accesses the OpenShift Service CA private signing key — a cluster-scoped trust anchor. Successful exploitation is a CA-level compromise: the attacker can forge certificates for any service identity in the cluster, impersonate services cross-namespace, and achieve RCE via Jolokia MBeans. This PKI-scale blast radius, combined with no available patch, prevents a MEDIUM rating. The edit role prerequisite is a low bar in most OpenShift environments (standard developer access).

1. Remove hawtio-operator if not actively used — The most effective control. If your team is not actively using HawtIO for Camel diagnostics, uninstall the operator entirely via OperatorHub or oc delete subscription. This eliminates the attack surface completely. Per the noisgate mitigation SLA for HIGH, deploy this control within 30 days — but given no patch exists, do this immediately if feasible.
2. Strip Hawtio CR verbs from edit/admin ClusterRoles — The operator's ClusterRole aggregates Hawtio CR permissions into the default edit and admin roles. Create a ClusterRole override that removes create, update, and patch verbs on hawtio.hawt.io resources from these aggregated roles. This breaks the attack at step 2 by preventing arbitrary users from creating the malicious CR. Deploy within 30 days per the noisgate mitigation SLA.
3. Deploy admission policy to validate Hawtio CR fields — Use OPA/Gatekeeper or Kyverno to enforce that spec.routeHostName and other CN-influencing fields in Hawtio CRs match an allowlist of legitimate values. This prevents the signing oracle from issuing certs with arbitrary subjects.
4. Restrict operator ServiceAccount RBAC — Manually remove the operator's ServiceAccount permission to read secrets in the openshift-service-ca namespace. This breaks the signing oracle entirely but will also break legitimate hawtio-operator TLS functionality. Only appropriate if you can tolerate degraded HawtIO operation.
5. Enforce NetworkPolicies for cross-namespace isolation — Apply Kubernetes NetworkPolicies that restrict pod-to-pod communication across namespaces. This limits the attacker's ability to reach Jolokia endpoints on Java workloads in other namespaces, even if they obtain a forged certificate.

Run this script on any host with oc (OpenShift CLI) authenticated to the target cluster. Requires at least cluster-reader privileges. Invoke: bash check_cve_2026_78234.sh

#!/usr/bin/env bash
# CVE-2026-78234 — Hawtio Operator Signing Oracle Check
# Checks whether hawtio-operator is installed and whether the
# aggregated ClusterRole grants edit users Hawtio CR access.
# Exit codes: 0=VULNERABLE, 1=PATCHED, 2=UNKNOWN

set -euo pipefail

echo "[*] CVE-2026-78234 — Hawtio Operator Signing Oracle Check"
echo "============================================================"

# Step 1: Check if hawtio-operator is installed
HAWTIO_SUB=$(oc get subscriptions.operators.coreos.com --all-namespaces -o json 2>/dev/null | \
  grep -i hawtio || true)

HAWTIO_PODS=$(oc get pods --all-namespaces -l name=hawtio-operator -o name 2>/dev/null || true)

if [[ -z "$HAWTIO_SUB" && -z "$HAWTIO_PODS" ]]; then
  echo "[+] hawtio-operator is NOT installed on this cluster."
  echo "PATCHED"
  exit 1
fi

echo "[!] hawtio-operator IS installed on this cluster."
echo "    Subscription/pods found."

# Step 2: Check if Hawtio CRD exists
if ! oc get crd hawtios.hawt.io &>/dev/null; then
  echo "[?] Hawtio CRD not found — operator may be partially installed."
  echo "UNKNOWN"
  exit 2
fi

echo "[!] Hawtio CRD (hawtios.hawt.io) exists."

# Step 3: Check if edit/admin ClusterRoles have Hawtio CR verbs
EDIT_HAWTIO=$(oc get clusterrole -l rbac.authorize.openshift.io/aggregate-to-edit=true -o json 2>/dev/null | \
  grep -c 'hawtios' || echo 0)

ADMIN_HAWTIO=$(oc get clusterrole -l rbac.authorize.openshift.io/aggregate-to-admin=true -o json 2>/dev/null | \
  grep -c 'hawtios' || echo 0)

if [[ "$EDIT_HAWTIO" -gt 0 || "$ADMIN_HAWTIO" -gt 0 ]]; then
  echo "[!] Hawtio CR verbs are aggregated into edit/admin ClusterRoles."
  echo "    Any namespace editor can create Hawtio CRs (signing oracle active)."
else
  echo "[+] Hawtio CR verbs are NOT aggregated into edit/admin roles."
  echo "    Signing oracle may be restricted (manual RBAC hardening detected)."
  echo "PATCHED"
  exit 1
fi

# Step 4: Check for existing Hawtio CRs
HAWTIO_CRS=$(oc get hawtio --all-namespaces -o json 2>/dev/null | \
  python3 -c "import sys,json; d=json.load(sys.stdin); print(len(d.get('items',[])))" 2>/dev/null || echo 0)

echo "[*] Found $HAWTIO_CRS existing Hawtio CR(s) across all namespaces."

echo ""
echo "=== RESULT ==="
echo "VULNERABLE"
echo "hawtio-operator is installed with default aggregated RBAC."
echo "Any namespace editor can exploit CVE-2026-78234 as a signing oracle."
exit 0

Sources

1. Security Online — CVE-2026-78234 Advisory
2. Red Hat CVE Page — CVE-2026-78234
3. THREATINT CVE Entry
4. OffSeq Threat Radar — CVE-2026-78234
5. RHSA-2026:25089 — HawtIO 4.4.0 Advisory (prior fix)
6. hawtio-operator GitHub Repository
7. CWE-295 — Improper Certificate Validation