CVE-2026-66782: Submariner Operator Token Exposure Flaw

CVE-2026-66782 Overview

CVE-2026-66782 is a cleartext storage flaw in the Submariner operator that exposes a long-lived broker service account (SA) bearer token inside the Submariner Custom Resource (CR) specification. An attacker with read access to the cluster's etcd database or the ability to run kubectl get against the CR can retrieve the token. Possession of the token grants full control over the mesh network, including unauthorized management of endpoints and secrets. The weakness is classified under [CWE-312: Cleartext Storage of Sensitive Information].

Critical Impact
Recovery of the broker SA bearer token gives an attacker administrative control of the Submariner mesh, enabling manipulation of cross-cluster networking, endpoints, and secrets.

Affected Products

Submariner operator (Red Hat distribution)
Red Hat OpenShift environments deploying Submariner
Kubernetes clusters using Submariner for multi-cluster networking

Discovery Timeline

2026-08-18 - CVE-2026-66782 published to the National Vulnerability Database (NVD)
2026-08-20 - Last updated in NVD database

Technical Details for CVE-2026-66782

Vulnerability Analysis

The Submariner operator manages secure network connectivity between Kubernetes clusters through a broker component. Cross-cluster authentication relies on a broker service account bearer token. The operator writes this long-lived token into the Submariner Custom Resource specification in cleartext rather than referencing a protected Secret object. Any principal that can read the CR, or that can access the underlying etcd store, can retrieve the token. The token then authorizes network-plane operations across the mesh.

Root Cause

The root cause is improper handling of a sensitive credential. The bearer token is embedded directly into the CR .spec field instead of being stored in a Kubernetes Secret with restricted RBAC. Custom Resources are broadly readable by users who hold standard get or list verbs on the resource type. Etcd itself stores CRs without additional field-level encryption unless envelope encryption is explicitly configured. This design places a high-privilege, non-expiring credential in a low-protection location.

Attack Vector

Exploitation requires local or in-cluster access with low privileges. An authenticated user with permission to read Submariner CRs runs kubectl get submariners -o yaml and extracts the token from the returned specification. Alternatively, an attacker with direct access to etcd backups or the etcd endpoint reads the CR object from the datastore. The recovered token then authenticates against the broker, granting authority to create, modify, or delete endpoints, gateways, and associated secrets across joined clusters.

No verified public proof-of-concept code has been published. See the Red Hat CVE-2026-66782 Advisory and Red Hat Bug Report #2507527 for vendor-provided technical detail.

Detection Methods for CVE-2026-66782

Indicators of Compromise

Presence of a bearer token value stored in cleartext within the .spec of Submariner Custom Resources.
Audit log entries showing get or list operations against submariners.submariner.io from unexpected service accounts or users.
Broker API authentication events originating from IP addresses that do not correspond to legitimate member clusters.
Unexplained creation or modification of Submariner Endpoint, Gateway, or Cluster resources.

Detection Strategies

Inspect Submariner CRs across all namespaces for embedded token strings using kubectl get submariner -A -o yaml.
Enable Kubernetes API server audit logging with rules targeting Submariner CR reads and correlate results against an allowlist of expected callers.
Review etcd access logs and backup handling procedures for unauthorized reads that could expose CR contents.

Monitoring Recommendations

Alert on any read access to Submariner CRs by identities outside the operator's own service account.
Monitor broker authentication logs for repeated use of the SA token from new source identities or clusters.
Track RBAC changes that grant get, list, or watch verbs on submariners.submariner.io resources.

How to Mitigate CVE-2026-66782

Immediate Actions Required

Apply the fixed Submariner operator release published in the Red Hat advisory as soon as it is available for your channel.
Rotate the broker service account bearer token after upgrading so exposed credentials cannot be reused.
Audit and restrict RBAC permissions on submariners.submariner.io to the operator service account and a minimal set of administrators.
Enable etcd encryption-at-rest with a KMS provider to reduce exposure of CR contents in datastore backups.

Patch Information

Red Hat tracks remediation in the Red Hat CVE-2026-66782 Advisory and Red Hat Bug Report #2507527. Consult these references for the fixed operator versions applicable to your Submariner and OpenShift distribution.

Workarounds

Remove cleartext token values from the Submariner CR .spec and replace them with a reference to a Kubernetes Secret protected by dedicated RBAC where the operator version supports it.
Restrict get and list permissions on Submariner CRs to a narrow administrative group using Role and RoleBinding objects.
Enforce short-lived credentials or rotate the broker SA token on a scheduled basis until the fixed operator is deployed.
Isolate access to etcd endpoints and backup artifacts to break the secondary retrieval path.

bash

# Configuration example: identify cleartext tokens in Submariner CRs
kubectl get submariners.submariner.io -A -o yaml | \
  grep -E 'token|bearer' -n

# Restrict read access to Submariner CRs via RBAC
cat <<EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: submariner-cr-reader-restricted
rules:
  - apiGroups: ["submariner.io"]
    resources: ["submariners"]
    verbs: ["get", "list", "watch"]
EOF