GPU VulnDB

Database/Container, Kubernetes & orchestration

Submariner: IPsec pre-shared key stored unencrypted in the Submariner custom resource

CVE-2026-66781Container, Kubernetes & orchestrationcurated

Impact

Submariner's IPsec PSK, which secures every tunnel between clusters in the mesh, is written into the Submariner CR in cleartext rather than a protected secret. Anyone who can read that CR holds the key to the whole mesh and can passively decrypt captured traffic between any two clusters — no active position needed, and captures taken before the key was read decrypt just as well. Where a GPU fleet is split across clusters, that inter-cluster traffic carries scheduler and control-plane calls, dataset and model-artifact transfers, and whatever tenant traffic crosses the mesh. The record scores this with a changed scope, reflecting that a reader in one cluster compromises traffic belonging to others.

Who can reach it

A low-privileged local account with read access to the Submariner CR (AV:L/PR:L in the scored vector) — in practice any service account or user whose RBAC grants get on that resource, which is often broader than intended. Turning the key into plaintext also requires the ability to capture inter-cluster traffic somewhere on the path.

What to do

The record names no fixed version; Red Hat tracks it for Advanced Cluster Management for Kubernetes 2 in bugzilla 2507526, so watch that page and the RHACM errata rather than assuming a build. In the meantime, audit and tighten RBAC so only the Submariner operator's own service account can read the CR, treat the current PSK as compromised, and plan a key rotation — rotation re-establishes the tunnels and briefly interrupts cross-cluster connectivity, so schedule it. No node reboot or firmware work is involved.

References

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.