CVE-2026-66786 reached the public CVE record on September 2, 2026, carrying a 9.1 that Red Hat marks as a draft, a severity rating of Moderate, and no fixed version for anything.
What happened
Red Hat, acting as CNA, published CVE-2026-66786 to the CVE record on September 2, 2026. NVD received it at 6:21 p.m. UTC and has it at status “Received,” meaning no NVD analysis has been done. Red Hat’s own machine-readable entry gives the flaw a public date of August 21, 2026, at 4:43 p.m. UTC, so the record is twelve days behind the disclosure.
The description is short: “A flaw was found in submariner. In cert-auth mode, the connection configuration is built using free-form strings from the Custom Resource Definition (CRD) without proper validation.” Submariner is the component that stitches separate Kubernetes clusters into one flat network, and it builds IPsec tunnels between gateway nodes to do it. The Bugzilla entry behind the CVE, number 2507531, is more specific about the mechanism than the CVE description is: “submariner: ipsec.conf stanza injection via remote-supplied CableName and Subnets.”
That is the whole flaw. A cluster on the other end of the mesh publishes a cable name containing newlines and IPsec directives. Those strings are written into the local ipsec.conf without validation, so the remote cluster is not supplying a name — it is supplying configuration. Red Hat’s write-up says the result is “remote code execution as root on the gateway node.”
The scoring is where the record gets interesting. Red Hat’s [email protected] supplied CVSS 3.1 base score 9.1, vector CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H — network vector, high privileges required, scope changed, everything else high. Red Hat’s record marks that score’s status as draft. Its own threat severity for the same flaw is Moderate, and it explains why: “Red Hat rates this flaw as Moderate severity rather than Important because exploitation requires two non-default configurations that must both be explicitly enabled.” Cert-auth mode is off by default and exists for optional OVN-Kubernetes integration.
The named affected product is Red Hat Advanced Cluster Management for Kubernetes 2, across the submariner gateway, operator, route-agent, and addon packages. What the record does not contain is any affected_release entry and any package_state entry — no errata number, no release date, and no per-product fix state, not even “will not fix” or “affected.” The remediation on offer is a configuration change:
“PSK mode provides equivalent inter-cluster IPsec tunnel encryption and is not affected by this vulnerability.”
Administrators are told to set IPSecCertAuthMode: false in the SubmarinerConfig CR. Checked on September 2, 2026, the upstream project’s GitHub security advisories page for submariner-io/submariner says “There aren’t any published security advisories,” and the OSV database returns a 404 for the CVE ID. There is no fixed version to upgrade to on the public record, from Red Hat or from upstream.
Why it matters
Multi-cluster networking has a trust model that is easy to state and easy to forget. When you join a cluster to a submariner broker, that cluster publishes Endpoint objects describing itself, and every other cluster in the mesh consumes them. The cable name is one of those self-declared fields. It has always been remote-supplied input; what this CVE establishes is that it was being handed to a line-oriented config format that treats a newline as the start of a new instruction. The privilege boundary a mesh operator thinks they have — peer clusters can route to me — turns out to have been peer clusters can run commands as root on my gateway node, in the one mode where the tunnels are authenticated by certificates rather than a shared key.
The severity gap is worth being precise about rather than picking a side. Both numbers are defensible and they measure different things. CVSS 9.1 with PR:H and S:C describes what happens once an attacker is a peer: total compromise of a node outside the vulnerable component’s own scope. Red Hat’s Moderate describes how likely you are to be in that position at all, given that cert-auth mode has to be turned on deliberately. Neither is wrong. The practical problem is that they travel separately. A scanner that ingests the CVSS base score raises a critical finding on every RHACM cluster in the estate. A dashboard that ingests the vendor severity shows Moderate and may not surface it at all. The same record produces both answers, and the field that reconciles them — whether IPSecCertAuthMode is set — is not in either feed. It is in a custom resource on your own clusters, and it is the only thing that actually decides whether this applies to you.
The draft flag on the CVSS is a second reason not to over-anchor on 9.1. Red Hat is telling readers, in the record itself, that the score has not been finalized. That is more transparency than most vendors offer, and it is also a warning that a number now circulating through every downstream feed may not be the number that survives.
The blank fix state is the part with the sharpest operational edge. RHACM 2 is named as affected. There is no errata, no fixed package version, and no upstream advisory. Twelve days after Red Hat’s own public date, a team that reads the record correctly can answer “are we exposed” — check one CR field — and cannot answer “what do we upgrade to.” That is a familiar shape on this site: last week the same gap turned up as a fixed-version range that named a release still carrying the vulnerable line. Here the range is simply absent, which is at least honest, but it leaves the mitigation doing the work a patch would normally do.
One more thing links this to the other record published on this site today. The mechanism is not a memory bug or a cryptographic mistake. It is a name field that flows unescaped into a configuration file whose grammar is “one directive per line.” That is the same shape as a repository’s .git/config setting core.fsmonitor to a command: a value nobody thought of as executable, in a format that turns text into instructions. Config formats are being handed attacker-controlled strings by software that treats them as inert data, and the fix in both cases is validation at the boundary, not a smarter parser.
What to do
Check whether this applies at all. Look at IPSecCertAuthMode in the SubmarinerConfig CR on each managed cluster. If it is unset or false, you are on PSK mode and Red Hat says you are not affected. If it is true, you are in scope.
If it is true, switch it. Red Hat’s stated mitigation is to set IPSecCertAuthMode: false, returning to pre-shared key authentication, which it says provides equivalent tunnel encryption. Treat that as the remediation for now, because there is nothing to upgrade to.
If you need cert-auth for OVN-Kubernetes integration and cannot switch, the operating assumption until a fix ships is that any cluster able to publish an Endpoint to your broker can execute code as root on your gateway nodes. Audit which clusters are joined and who can create or edit those objects, and treat broker access as equivalent to node-level access.
Watch for an errata. Red Hat’s CVE page is the place a fixed version will appear first. As of this writing there is none, and the absence is in the machine-readable record, not just the human-readable page — so an automated check for “is there a fix yet” will keep returning nothing until Red Hat files one.
No urgency beyond that. There is no reported exploitation, the CVE is not in CISA’s Known Exploited Vulnerabilities catalog, and no federal remediation deadline attaches to it. This is a configuration check to run this week, not tonight.
Sourcing note
Checked against primary sources: the NVD record for CVE-2026-66786, published and last modified September 2, 2026, at 6:21 p.m. UTC with status “Received”; Red Hat’s machine-readable security data entry for the same CVE, which supplied the Moderate threat severity, the August 21, 2026, public date, the draft status on the 9.1 CVSS, the Bugzilla title, and the mitigation text quoted above; Red Hat’s public CVE page; the GitHub security advisories page for submariner-io/submariner; and the OSV API, which has no record for this identifier.
Not reached: Bugzilla 2507531 itself, which is referenced by the record but was not retrieved for this story, so the “CableName and Subnets” phrasing is taken from the Bugzilla description field carried inside Red Hat’s security data rather than from the bug report. cisa.gov returns 403 to automated fetching; the KEV status above was checked against the catalog data published through CISA’s own GitHub channel, which is known to lag by a day or more, so read it as “no evidence of a KEV listing” rather than a positive confirmation of absence.
Unresolved: whether the Subnets field is a second injection path or the same one described differently; whether an RHACM errata is in preparation; why the CVE record reached the public catalog twelve days after Red Hat’s stated public date; and whether upstream submariner considers itself affected, given that it has published nothing.
