CVE-2026-66781: Submariner-operator: pprof debug endpoint enabled by default on 0.0.0.0:8082 without authentication
A flaw was found in the Submariner operator. The Submariner Custom Resource (CR), used for configuring network connectivity, stores the IPsec pre-shared key (PSK) in an unencrypted format. This key, which is critical for securing communication between Kubernetes clusters, can be accessed by unauthorized parties. Such access enables an attacker to passively decrypt network traffic flowing between any two clusters in the mesh, resulting in sensitive information disclosure.
Other sources
The Submariner CR exposes a string field for the IPsec pre-shared key. Custom Resources are stored unencrypted in etcd by default (only v1/Secret is encrypted by the OCP KMS provider), are returned by kubectl get submariner -o yaml to anyone with get on the namespaced CR, and are commonly captured in GitOps repos / must-gather bundles. The PSK is identical across all clusters in the mesh, so disclosure on one spoke enables passive decryption of traffic between any two spokes.
Source: Project Glasswing AI-SAST audit of submariner-io/submariner-operator. Finding ID: FIND-003 Assurance: executionproven
— Red Hat
Affected Software
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Deployments where an unauthorized party can read the Submariner Custom Resource are exposed, because the IPsec PSK is stored there in cleartext. The affected key secures communication between Kubernetes clusters in the mesh.
What does an attacker need to exploit the issue?
An attacker needs access to the unencrypted IPsec PSK stored in the Submariner CR. With that key, they can passively decrypt network traffic between any two clusters in the mesh.
How can I determine whether my environment is affected?
Review the Submariner Custom Resource and determine whether its IPsec PSK is present in unencrypted form. Access to that CR should be treated as access to the key material used for inter-cluster traffic.