CVE-2026-66781: Submariner Information Disclosure Flaw

CVE-2026-66781 Overview

CVE-2026-66781 is an information disclosure vulnerability in the Submariner operator, a component used to connect workloads across multiple Kubernetes clusters. The Submariner Custom Resource (CR), which configures cross-cluster network connectivity, stores the IPsec pre-shared key (PSK) in cleartext. Any principal with read access to the CR can retrieve the PSK. An attacker holding this key can passively decrypt IPsec-protected traffic exchanged between clusters in the mesh, exposing sensitive workload data. The weakness is classified under CWE-312: Cleartext Storage of Sensitive Information.

Critical Impact
An authenticated local user with permission to read the Submariner CR can obtain the IPsec PSK and passively decrypt inter-cluster network traffic across the entire mesh.

Affected Products

Submariner operator (multi-cluster network connectivity component)
Red Hat OpenShift deployments consuming Submariner for cross-cluster networking
Kubernetes clusters interconnected via Submariner IPsec tunnels

Discovery Timeline

2026-08-18 - CVE-2026-66781 published to NVD
2026-08-20 - Last updated in NVD database

Technical Details for CVE-2026-66781

Vulnerability Analysis

Submariner establishes encrypted tunnels between Kubernetes clusters using IPsec. The tunnel endpoints authenticate to each other using a pre-shared key. The Submariner operator persists this PSK inside the Submariner Custom Resource without any encryption or secret-reference indirection.

Custom Resources in Kubernetes are stored in etcd and are readable through the API server by any account with get or list permissions on the resource. Because the PSK lives directly in the CR spec rather than in a Kubernetes Secret with restricted RBAC, its exposure surface is far larger than intended. Service accounts, operators, cluster-scoped viewers, and backup tooling can all retrieve the key. Once obtained, the PSK allows an on-path or passive observer to decrypt captured IPsec traffic between any two clusters in the mesh, breaking the confidentiality guarantee of the tunnel.

Root Cause

The operator writes the IPsec PSK to the Submariner CR as a plaintext field instead of referencing a Kubernetes Secret. This design conflates configuration data with credential material and inherits the CR's RBAC surface rather than the tighter access controls typically applied to secrets. See the Red Hat advisory for CVE-2026-66781 for details.

Attack Vector

Exploitation requires local, authenticated access to the cluster with permission to read the Submariner CR. An attacker executes a command such as kubectl get submariner -n submariner-operator -o yaml and extracts the ipsecPSK value. With the PSK in hand, the attacker captures inter-cluster traffic through a compromised node, mirrored network, or upstream vantage point and decrypts the IPsec payloads offline. No user interaction is required, and integrity or availability of the tunnels is not directly affected.

See the Red Hat Bugzilla report #2507526 for the vendor's technical description.

Detection Methods for CVE-2026-66781

Indicators of Compromise

Unexpected get, list, or watch API calls against the submariners.submariner.io resource from accounts that do not manage cross-cluster networking.
Access to the Submariner CR from service accounts outside the submariner-operator namespace.
Off-cluster kubectl or API server requests originating from unusual source IPs targeting Submariner resources.
Presence of the ipsecPSK field in cluster backups, GitOps repositories, or logging pipelines.

Detection Strategies

Audit Kubernetes API server logs for read operations on the Submariner CR and correlate with the requesting identity.
Enumerate RBAC role bindings that grant get or list on submariners.submariner.io and flag over-privileged principals.
Scan Git repositories, CI artifacts, and configuration backups for exposed ipsecPSK values.
Alert when Submariner CR contents are exported through kubectl get -o yaml/json by non-administrative accounts.

Monitoring Recommendations

Enable Kubernetes audit logging at the Metadata level or higher for the Submariner API group.
Forward audit logs to a centralized analytics platform to baseline normal operator activity and detect deviations.
Monitor node-level packet capture tools such as tcpdump running against IPsec tunnel interfaces.
Track changes to Submariner CRs and alert on unexpected key rotations or reads.

How to Mitigate CVE-2026-66781

Immediate Actions Required

Restrict RBAC so only the Submariner operator service account can read the Submariner CR; remove broad view or cluster-reader grants that include this resource.
Rotate the IPsec PSK across all clusters in the mesh after any suspected exposure.
Review cluster backups, GitOps state, and log pipelines and purge any captured plaintext PSK values.
Apply vendor updates when they become available per the Red Hat CVE-2026-66781 advisory.

Patch Information

At the time of publication, remediation is tracked through the Red Hat security advisory and Bugzilla #2507526. The expected fix moves the IPsec PSK from the Submariner CR into a Kubernetes Secret referenced by the operator, so plaintext key material no longer resides in the CR spec. Consult the advisory for fixed component versions once released.

Workarounds

Tighten RBAC on submariners.submariner.io to the minimum set of operator and administrator identities.
Enable encryption-at-rest for etcd so CR contents, including the PSK, are not stored in cleartext on disk.
Rotate the IPsec PSK on a defined schedule to limit the value of any leaked key.
Segment cluster network paths so passive capture of inter-cluster traffic requires additional compromise.

bash

# Identify principals with read access to the Submariner CR
kubectl auth can-i --list --as=system:serviceaccount:default:default \
  | grep submariners.submariner.io

# Enumerate role bindings referencing the Submariner API group
kubectl get clusterrolebindings -o json \
  | jq '.items[] | select(.roleRef.name | test("submariner"; "i"))'

# Restrict access with a least-privilege ClusterRole
cat <<EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: submariner-operator-only
rules:
  - apiGroups: ["submariner.io"]
    resources: ["submariners"]
    verbs: ["get", "list", "watch", "update", "patch"]
EOF