CISA recently added two critical vulnerabilities to its Known Exploited Vulnerabilities catalog, affecting widely used third-party platforms: Collabora Online's CODE Server (CVE-2026-110447, CVSS 9.2) and Arista VeloCloud Orchestrator (CVE-2026-114625, CVSS 9.9). Federal agencies have until October 26, 2026, to address these issues.
The real issue is the pattern, not just the individual flaws. You're managing infrastructure you don't control, relying on vendors to patch systems you can't directly inspect, and hoping your procurement contracts include enforceable security commitments. They probably don't.
What the Data Shows
These risks are far from theoretical. Threat actors exploited CVE-2026-110447 to install web shells on Nextcloud servers, then moved to credential stores and cryptocurrency wallets. CVE-2026-114625 allowed attackers with basic authenticated access to escalate privileges through SQL injection. Arista confirmed active exploitation but hasn't disclosed how many organizations were compromised.
This is the third VeloCloud vulnerability exploited since July 2026. The previous two, CVE-2026-16812 and CVE-2026-93952, both had perfect 10.0 CVSS scores. Your SD-WAN orchestrator isn't just managing traffic anymore; it's a target-rich environment with a history of exploitation.
Key Findings
Vendor patch timelines don't align with attacker timelines. Collabora released fixes in September 2026. Arista patched three versions in October. Both vendors had working exploits in the wild before most customers knew patches existed. If you're waiting for quarterly patch cycles or vendor notifications, you're already compromised.
Authentication isn't authorization. CVE-2026-114625 required only a valid session with read-only privileges. Your least-privileged users became escalation vectors the moment they logged in. Authenticated access doesn't imply controlled access.
Third-party dependencies create visibility gaps. Collabora Online runs as a built-in CODE server within Nextcloud. How many of your security teams knew that richdocumentscode was even installed, let alone exposed via proxy.php? Nested dependencies, especially in self-hosted cloud platforms, create attack surfaces you can't inventory through traditional asset management.
Exploitation patterns repeat across vendors. VeloCloud's third exploitation event in four months suggests attackers have reliable methods for targeting SD-WAN orchestrators. If you're running similar platforms (Cisco Meraki, VMware SASE, Fortinet SD-WAN), assume those environments are under similar pressure even if public disclosures haven't surfaced yet.
Your SLA doesn't include incident response. Arista acknowledged exploitation but provided minimal technical detail, no attribution, and no disclosure of affected customer count. This is standard vendor behavior. Your contract probably guarantees uptime, not transparency during active compromise.
What This Means for Your Team
You can't patch what you can't see, and you can't see what your vendors won't tell you. The traditional model (vendor discovers flaw, vendor patches, customer deploys patch) assumes you have visibility into the full software stack and control over deployment timing. You don't.
If you're operating as a Virtual CISO (vCISO) or fractional security leader, you're managing this problem across multiple client environments with different vendors, patch windows, and levels of operational maturity. You need a vulnerability management model that works when you don't own the infrastructure.
Start with contract language. Your agreements with SaaS and managed service providers should include:
- Maximum time-to-notification for known exploited vulnerabilities (24 hours, not vendor discretion)
- Mandatory disclosure of exploitation indicators (IOCs, affected versions, attack vectors)
- Defined patch application windows tied to CISA KEV or equivalent threat intelligence
- Audit rights to verify patch status without waiting for attestation reports
Then build continuous monitoring around third-party attack surfaces. You need tools that can:
- Enumerate nested dependencies (not just the primary application, but everything it loads)
- Correlate vendor security advisories against your actual deployments (version-specific matching, not product-level alerts)
- Trigger automated workflows when CISA adds a vendor to KEV (not manual triage three days later)
Finally, assume breach for any platform with privileged network access. SD-WAN orchestrators, VPN concentrators, and remote access gateways all meet this threshold. Your Incident Response Plan should include runbooks for scenarios where the vendor confirms exploitation but can't provide forensic detail. You'll need to make containment decisions with incomplete information.
Action Items by Priority
Immediate (this week):
- Verify Collabora Online version across all Nextcloud deployments; upgrade to 26.4.303 or later
- Check Arista VeloCloud Orchestrator version; apply patches for 5.2.3.18, 6.1.3.10, or 6.4.2.12
- Review firewall logs for connections from 74.82.197.86 or 38.54.50.151
- Audit VCO user roles; disable or downgrade any Enterprise Read Only accounts not actively required
This month:
- Map all third-party platforms with administrative or privileged network access
- Cross-reference that inventory against CISA KEV catalog (automate this check weekly)
- Review vendor contracts for security notification and patch SLA language
- Establish a vendor security questionnaire that includes patch management commitments
This quarter:
- Implement automated dependency scanning for self-hosted cloud platforms
- Build tabletop exercises around vendor-confirmed exploitation with limited disclosure
- Negotiate contract amendments for high-risk vendors (SD-WAN, identity, remote access)
- Integrate vendor advisory feeds into your threat intelligence platform
Ongoing:
- Monitor CISA KEV additions weekly; treat any third-party match as P1
- Require vendors to provide version-specific patch status (not generic "we're patched" statements)
- Test vendor incident notification processes annually (ask for a simulated breach disclosure)
- Track Mean Time to Remediate separately for vendor-controlled vs. internally controlled systems
