Your SD-WAN orchestrator is the key to every one of your sites

On Tuesday 22 September CISA added four more vulnerabilities to its catalogue of those already being exploited. One of them is CVE-2026-93952, a 10.0 out of 10 in VeloCloud Orchestrator: the system from which every site in an SD-WAN network is configured. The score is not the odd part. The odd part is the condition the vendor sets for being exposed, and it fits in one line.

Arista's advisory puts it this way: the orchestrator is exposed if certificate-based authentication from the branch device to the orchestrator is configured, and access is required to the public portion of that device's authentication certificate. Nothing else. No operator or tenant credentials, no user having to click anything, with network reach to the orchestrator web interface. The technical classification is CWE-20, improper input validation, and the CVSS vector carries the S:C that means the impact escapes the component that fails.

The public part of a certificate is not a secret

That is the knot. The public part of a certificate is, by definition and by design, the material that gets handed around: it is presented in every TLS handshake, it travels over the network, it turns up in inventories and packet captures, and it sits inside the box mounted on the wall of a shop anyone can walk into. It is not a password you keep: it is the thing you show. And the requirement for reaching privileged control-plane functionality is having that.

An honest caveat, because it cuts against what we have just said: in CVSS v4.0 Arista scores the flaw at 9.5 rather than 10, and the reason is in the vector: there it marks attack complexity as AC:H, high, whereas in v3.1 it marks it as low. The vendor therefore reckons that obtaining a specific device's certificate has a cost. That is reasonable. The argument is precisely that: what it really costs to get hold of something that by design is handed around the whole network and travels inside a box sitting in a shop.

Our reading, and we accept that it is a reading: the specific bug gets patched, but the design that allows it is still there in plenty of products. A control plane willing to talk on equal terms with anyone presenting non-secret material is betting everything on a single validation layer. That is the same reasoning behind why, when a compromised management console is patched, the patch closes the door but does not erase what the attacker already took: the configuration of your sites, the addresses, the tunnels, the policies.

The second ten in eight weeks

Worth saying because we wrote it ourselves: at the end of July we already covered the previous 10.0 in this same orchestrator, the one in advisory 0144. Two months later comes advisory 0183. Two maximum-severity vulnerabilities in the same control plane, both exploited before there was a patch for everyone, both in CISA's catalog with a three-day deadline. The first one you call an incident; the second one you can already call a pattern, and a pattern changes the conversation you need to have with the vendor and with whoever manages it for you.

One thing has improved, and we say it with the same relish we use for criticism: in July we complained that the advisory carried no hashes or signatures to start searching with. This one does. It does not fix the flaw, but it changes what the person on the receiving end can do about it.

"Patch it" is not an answer for everyone

This affects on-premises orchestrator deployments, not the ones hosted by the vendor, which according to the advisory are already fixed along with the dedicated ones. The affected versions are 5.2.3.15 and earlier, 6.1.3.7 and earlier, 6.4.2.7 and earlier, and 7.0.0.2 and earlier. Fixes are published for 5.2.3.16 onwards and for 6.4.2.8 onwards. For the 6.1 and 7.0 trains, the vendor itself says fixes will follow.

Read that again if you are running 6.1 or 7.0, because it describes a specific situation: maximum-severity vulnerability, confirmed exploitation, in CISA's catalogue with a due date of 25 September for US federal agencies under directive BOD 26-04 — that is, tomorrow — and nowhere to update to today. This happens more often than it gets told, and it is precisely the scenario nobody has a written procedure for, because every procedure starts with "apply the vendor update".

When there is no patch, what remains is reducing who can reach it and checking whether they already got in. The vendor recommends restricting access to the orchestrator web interface to trusted administrative networks, watching for unexpected outbound traffic, reviewing access logs for odd patterns and closing outbound ports that are not needed. And it publishes concrete indicators, which is what can actually be used this morning:

• Two IP addresses to search for in your logs and block: 142.93.149.77 and 104.248.126.159.
• Three traces in the filesystem: /usr/local/sbin/.vcnode.js, /usr/local/sbin/vc-sysmond — with MD5 dc78e206eaeadec59fc5801fe4556bd0 — and /etc/systemd/system/vc-sysmon.service. The first starts with a dot, so it does not show up in a plain listing. And mind the third, because it is the systemd unit that starts the binary again: delete the executable and leave the service behind and you have cleaned half of it. Watch the spelling, which invites confusion deliberately: the binary is vc-sysmond with a trailing d and the service is vc-sysmon without one.
• An HTTP header, x-vc-opt, which can be searched backwards if you keep logs from the proxy or load balancer in front of the orchestrator.

One warning about that list, because it is constantly misused: finding an indicator tells you they got in. Not finding one only tells you that you are not in the group that left those particular traces. An indicator check takes twenty minutes; a compromise audit takes days and is done by other people.

If you switch the orchestrator off right now, what stops working?

This is the question we ask when an advisory like this appears, before any other, and it almost never has a prepared answer. It determines whether what you are looking at is only a security emergency or also a service emergency, and from that comes the order in which things get done this afternoon. There are three possible answers and all three lead somewhere different.

If the answer is "nothing stops working, I just cannot change the configuration until it is back", you have real room: you can take the orchestrator off the internet this afternoon and wait for the patch with the network still running. If it is "the tunnels between sites drop", centralisation has left you without room, and the CVE then takes second place behind an architecture problem that has been there for months. And if the answer is "I do not know", you have a pending experiment that somebody else is about to run for you, right now and unannounced.

Underneath it is the usual axis: failure is inevitable, an outage is a design decision. An orchestrator with a problem is a failure. That problem halting operations across twelve sites is a decision taken months earlier, usually without noticing, the day its management interface was published somewhere it should not have been.

This is not an argument against SD-WAN

It would be easy and it would be dishonest. Centralising network control exists because it solves a real problem: changing a policy across twenty sites without logging into twenty boxes, seeing the state of every line on one screen, standing up a new shop in an afternoon. That trade — more central control in exchange for more dependence on the centre — is legitimate, and we have recommended it. What is not legitimate is signing it without knowing you are signing it.

We have already written about when SD-WAN pays off and when it does not, and about the habit of treating as covered what was really a ticked box at the branch. This advisory adds a line to that conversation: the orchestrator belongs in the critical systems inventory at the same rank as the perimeter firewall or the domain controller, because it has the same reach. If your provider treats it as "the management portal", there is a difference of judgement worth settling before the next advisory rather than during it.

What we do with this

Let us start with what we are not: we do not sell VeloCloud licences or any other orchestrator's, and we have no interest in this post concluding that you should switch vendor. What we do in SD-WAN is design the split: what the centre decides, what the site keeps deciding on its own, and where the console can be reached from. We are an operator with our own network, so the networks and communications side — transport, routes, what happens when a line drops — gets looked at together with the layer above, not separately.

And when the advisory is already out and it is time to search logs backwards for two IP addresses and a file with a dot in front of it, that is cybersecurity and it is done against the clock. If you run an orchestrator on-premises and do not know which train you are on, the command to find out takes less time than reading this paragraph.

Sources (consulted on 24 Sep 2026): the description of CVE-2026-93952, the CVSS v3.1 score of 10.0 with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H and CVSS v4.0 of 9.5, the CWE-20 classification, the exposure condition regarding the public portion of the branch device certificate, the affected and fixed versions, the mitigations and the indicators of compromise all come from Arista security advisory 0183. The addition to the known exploited vulnerabilities catalog on 22 Sep 2026 and the reference to directive BOD 26-04 are in CISA's alert of that day, which includes three other entries; the 25 Sep 2026 due date appears on the entry inside the KEV catalogue itself, not on the alert page. What this post does NOT claim: we have no figure of our own or anyone else's for how many orchestrators are exposed, in Spain or elsewhere, and we publish none; we have not analysed the vulnerability or the malicious code, we defer to what the vendor publishes; the three-day deadline in directive BOD 26-04 binds US federal agencies, not a Spanish company, and we cite it as a severity signal rather than a legal obligation of yours; we do not claim that any specific product's branch devices do or do not keep forwarding traffic when the orchestrator is unreachable, because that depends on each platform's design and is precisely the question we say you should put to the vendor; and the reading about the trust model of control planes is our own judgement, not a conclusion of Arista's or CISA's.