Read-Only Was Never Harmless: Identity Lessons from CVE-2026-114625

Security programmes routinely tier accounts by what they can change. Read-only access gets filed as low risk, suitable for auditors, monitoring integrations and customer viewers. CVE-2026-114625 breaks that assumption for Arista VeloCloud Orchestrator, where the lowest built-in customer role is enough to reach operator privileges.

The exact requirement

Arista's advisory states that on an affected system any authenticated user can gain operator privileges and masquerade as a local "superuser operator", including access to internal-only functionality that is not intended to be remotely accessible. Reporting identifies Enterprise Read Only as the minimum role required. No unauthenticated path is documented for this CVE.
The practical consequence: any credential that can log in to the orchestrator is a candidate entry point, whether it belongs to a person, an integration, or a forgotten service account from a completed project.

Where read-only logins accumulate

Orchestrator accounts tend to multiply quietly. Monitoring and reporting tools get a viewer account. A partner organisation gets a customer-scoped account. A contractor keeps a login after handover because removing it requires a change request. Each of those is now an authentication primitive that an attacker can use against a CVSS 9.9 SQL injection.

Controls that still apply

Patch to 5.2.3.18, 6.1.3.10 or 6.4.2.12. Then treat account inventory as part of the exposure: enumerate every account that can reach the web interface, confirm ownership and last use, disable anything without a current purpose, and make sure privilege changes are logged and reviewed.
Restricting the web interface to trusted administrative networks reduces the number of places a valid login can be used from. Arista also recommends reviewing recent administrator activity for unexpected changes, and watching for backdoor daemons and web shells, because an escalation may leave persistence behind the credential.

What remains unknown

The advisory does not say when attacks started, which orchestrators were affected, or what attackers did after successful exploitation. Identity teams should plan for the possibility that a credential was used, not only that a host was patched.
Two IP addresses have been reported in connection with the attacks: 74.82.197.86 and 38.54.50.151. Correlating those against authentication logs is a fast way to check the credential path rather than only the network path.