Zero-day in VeloCloud: a read-only account is enough to become an operator

An SQL injection flaw already exploited at the heart of the SD-WAN network

Arista has published an advisory confirming that attackers are actively exploiting an SQL injection vulnerability in VeloCloud Orchestrator (VCO), the central management system for VeloCloud SD-WAN networks. The advisory, dated October 22, describes a zero-day flaw: no patch is available at the time of the communication and real malicious activity against it has already been observed.

The most uncomfortable part of this case is not only that an SQL injection exists in a network management product, but who can take advantage of it. According to the company, any user able to authenticate to the orchestrator, even with a read-only customer account, can escalate privileges to become an operator: the highest level of control over the system. In other words, you don't need to be an administrator or hold high-level credentials; a legitimate low-profile access is enough to attempt the jump.

Why the orchestrator is such a tempting target

In an SD-WAN architecture, the orchestrator is not just any server: it is the control plane from which policies are deployed, tunnels are configured and connectivity for all sites is governed. If an attacker gains operator privileges, they don't just read information: they can reconfigure the network, alter routing or open the door to lateral movement within the company's infrastructure.

For an SMB that has outsourced its network or relies on an integrator to manage its SD-WAN, this means the risk is not limited to its provider: any account with access to the management panel, even a read-only one, becomes a possible entry point. And in many cases those accounts are shared with less rigor than is applied to domain administrators.

What it means for an IT team with limited resources

The combination of zero-day, active exploitation and no patch leaves little room for technical maneuver. We cannot ask an SMB to develop its own patch or rewrite the vulnerable query. What we can do is reduce the exposure surface and prepare the response while Arista publishes the update.

• Inventory access to the orchestrator. Review how many accounts have access to VCO, with what role and who uses them. Read-only customer or third-party accounts are right now the most sensitive point.
• Apply the principle of least privilege for real. If an account doesn't need to be active, deactivate it. If an integrator no longer provides service, revoke its access today, not next week.
• Strengthen authentication. Enable two-factor authentication where the product allows it and review access logs for failed attempts or connections from unusual locations.
• Segment and monitor. The orchestrator should not be reachable from any network. Limit access to management addresses and watch for unexpected configuration changes.
• Prepare the patching plan. When Arista publishes the fix, it must not sit in the inbox: define who applies it, in what window and how it is verified afterwards.

The recurring lesson: low-profile access is still access

This case is reminiscent of other recent advisories we have discussed on the blog, such as the two RCE flaws in Linux KSMBD without a patch or the leak of secrets at Railway. In all of them the same idea beats: security depends not only on the severity of the flaw, but on how much surface we give the attacker with our own access decisions.

A critical flaw without a patch is a problem; a critical flaw without a patch and with read-only accounts handed out without control is an incident waiting to happen.

At ForgeNEX we recommend treating this advisory as an immediate hygiene task, not as a headline to read and forget. Review today who can get into your orchestrator, close off whatever is not essential and have the procedure ready to apply the update as soon as it is available. The window between the advisory and the patch is exactly the moment when attackers work most comfortably.

Source: The Hacker News. Analysis and adaptation: ForgeNEX.