Saturday, 31 October 2026Global tech news & guides — what changed, and what it means for you.
AuTechWire
Illustration: split scene of a document workspace with a warning-highlighted script pathway and a network orchestration console, with a blank calendar page and shield patch symbols

CISA KEV Oct 26 Deadline Passed: Patch Collabora, Arista Now

by

In brief

  • CISA’s Oct. 26 deadline covers actively exploited flaws in Collabora Online and Arista VeloCloud. Who is affected, what to patch to, and how to check for compromise.
  • CISA added CVE-2026-110447 and CVE-2026-114625 to its Known Exploited Vulnerabilities (KEV) catalog on October 23, 2026, citing exploitation in the wild.
  • Federal civilian agencies must remediate both flaws by October 26, 2026; private organizations should treat the same date as urgent, even though it is not a legal deadline for them.
  • Collabora admins should move the Built-in CODE Server to version 26.4.303 or later, while Arista on-premises VeloCloud Orchestrator admins should move to builds 5.2.3.18, 6.1.3.10, or 6.4.2.12, depending on their release line.
  • Patching alone does not clean a system that was already compromised: check for web shells, unexpected files, suspicious proxy.php requests, and exposed credentials before closing the incident.

Update, October 27: the deadline has passed, patch now if you have not

The October 26 deadline has now passed. For U.S. federal civilian agencies the remediation date is no longer ahead of them; for everyone else the urgency is unchanged, because these flaws are actively exploited, so an unpatched system should now be treated as past due, not as having more time. The patch targets in this article still apply (Built-in CODE Server 26.4.303 or later; VeloCloud Orchestrator builds 5.2.3.18, 6.1.3.10 or 6.4.2.12), as do the compromise checks below.

What was the CISA KEV deadline, and what changes now that it has passed?

The deadline was October 26, 2026, for U.S. federal civilian executive branch agencies. Under Binding Operational Directive 22-01, those agencies must address vulnerabilities in CISA’s Known Exploited Vulnerabilities catalog by the due date CISA assigns. CISA added the two flaws covered here on October 23, 2026, and set October 26, 2026, as the remediation date for both. That short window is itself a signal: KEV listing means CISA has evidence of exploitation in the wild, not merely a theoretical weakness waiting for a proof of concept.

For everyone else, the date works differently. Private companies, schools, nonprofits, and self-hosters are not bound by the federal directive in the same way, and this article does not claim otherwise. The reason to treat October 26 as urgent anyway is practical, not legal. Attackers already know these flaws work, fixes already exist, and the flaws affect internet-facing collaboration and network-management software where a foothold can lead to much wider access. Waiting for a quieter maintenance window leaves the known-exploited path open while public reporting is at its peak.

This is also a different incident from the GitLab flaw covered recently on this site. Readers who followed that story should not assume the same patch, the same product, or the same check applies here. The Collabora and Arista flaws involve different software, different attacker requirements, and different fixed versions, and the compromise checks below are specific to each one.

What is CVE-2026-110447 in Collabora Online?

CVE-2026-110447 is a critical operating system command injection flaw, scored 9.2 on the CVSS scale, in Collabora Online Built-in CODE Server when it is used inside Nextcloud. In plain terms, an unauthenticated remote attacker can trick a vulnerable server into running operating system commands it should never have accepted from a web request. The commands run with the privileges of the web server account, which is serious even though the reported investigations did not establish root access.

The weakness sits in Nextcloud’s proxy.php script in the Built-in CODE Server app, also known as the richdocumentscode app. In versions up to and including 26.4.302, that script included request data in a Bash command without adequate sanitization. An attacker who could reach proxy.php could therefore inject additional commands. The script runs directly through the web server without loading Nextcloud’s application code, which means the normal Nextcloud login and application checks do not stand in the way of this particular path.

There is one important condition. Exploitation through this path is possible only when the local CODE server is stopped. That can happen during a restart, an upgrade, or a crash. Those are routine operational events, not rare edge cases, so admins should not treat the condition as protection. Any maintenance window, failed service, or unexpected outage can open the window an attacker needs.

Who is affected by the Collabora flaw — and who is not?

The flaw affects organizations using Nextcloud’s Development Edition with the built-in Collabora Online Development Edition (CODE) Server, specifically the Built-in CODE Server deployment before version 26.4.303. If you run that deployment, you are in scope, and you should confirm the exact app version rather than guessing from your Nextcloud core version. The two version numbers are not interchangeable, and checking the wrong one can give false reassurance.

Standalone Collabora servers are not affected, according to every source used for this article. That distinction matters for triage. A team running a separate, standalone Collabora Online server should still verify its own advisories and stay current, but it should not burn its deadline-day hours hunting for this specific proxy.php path in a deployment that does not contain it. Conversely, a team that assumed all Collabora installations were the same could miss the one built-in deployment that does contain it.

Collabora fixed the flaw in version 26.4.303 in September 2026. That means the fix has been available for weeks before the CISA listing, which makes the October 26 deadline a catch-up date for stragglers rather than a wait for a patch. If your built-in CODE Server is still on 26.4.302 or earlier, the fix is already published and the remaining work is scheduling, testing, and verifying the upgrade.

What did attackers actually do on compromised Nextcloud servers?

Attackers deployed PHP web shells on vulnerable Nextcloud servers and then searched those systems for sensitive information. That sequence matters because a web shell is not just a single malicious request: it is a persistent foothold that lets an attacker run further commands through the compromised web server account. Once that foothold exists, patching the original flaw does not remove it.

Exploitation has been reported since September 2026. The first recorded attack in the administrator reports dates to September 10, 2026. One Nextcloud administrator found malicious requests on September 10 and 11, 2026, from the same IP address, targeting proxy.php on a server running version 26.4.302. The attackers deployed a PHP web shell and searched one server for credential stores and cryptocurrency wallets. Other reporting describes the same pattern more broadly: reconnaissance and hunting for credential stores, password-manager artifacts, and cryptocurrency wallets.

Three administrators reported similar incidents on GitHub, and none of those investigations found evidence of root access. That is a useful limit on what is known, but it is not a clean bill of health. A web server account can often read configuration files containing credentials and application secrets, and those secrets can open other systems even without root. In the first reported case, reviewed logs showed no file exfiltration commands, yet the reporting is explicit that data accessible to the web server account must be considered potentially exposed. The total number of compromised servers remains unknown, and no threat actor has been named in the sources used here, so readers should not attribute this activity to a specific group.

What should Collabora admins patch to and check first?

Patch first to Built-in CODE Server version 26.4.303 or a later supported version containing the fix. One administrator reported another exploitation attempt on September 14, after upgrading to 26.4.303, and no new shell appeared after that attempt. A single blocked attempt does not prove every attack path is closed, but it is consistent with the fix blocking the known vulnerable path. Do not rely on simply disabling the built-in app as a substitute: Collabora’s security guidance, as reported, says users should upgrade or remove the built-in application, and simply disabling it does not provide a sufficient fix.

Then treat every system that ran a vulnerable version during an exposed window as a possible incident, not just a patch job. Search for unexpected files matching the shx*.php pattern flagged by project maintainer mmeeks, and investigate any unfamiliar PHP files rather than deleting them silently if an investigation may be needed. Review web server logs for suspicious requests to proxy.php, with special attention to periods when the local CODE server was stopped for a restart, upgrade, or crash. Check for persistence beyond a single shell, including unexpected files, scheduled tasks, and unauthorized account changes.

Finally, assess credential exposure before declaring the job done. Determine which configuration files, tokens, and secrets the web server account could read, and rotate or revoke anything potentially exposed. The same discipline applies to other critical flaws: readers who followed the recent PHP2Shell critical PHP vulnerability explained coverage will recognize the pattern — a web-facing flaw, a shell, and then a credential problem that outlives the patch. Patching closes the door; only log review, file checks, and rotation can tell you whether someone already walked through it.

What is CVE-2026-114625 in Arista VeloCloud Orchestrator?

CVE-2026-114625 is a critical SQL injection flaw, scored 9.9 on the CVSS scale, in on-premises versions of Arista VeloCloud Orchestrator (VCO). In plain terms, an attacker who can reach the VCO web interface with a valid authenticated session can abuse the flaw to access privileged internal functions that should be out of reach for their account. The minimum role reported for exploitation is Enterprise Read Only, which is a low-privilege role. That combination — a near-maximum severity score plus a low-privilege starting point — is why this flaw belongs in the same urgent bracket as the Collabora flaw despite working very differently.

SQL injection, in this context, means malicious database input changes what the application asks its database to do. Here, the reported effect is privilege escalation through internal functions, not merely reading a single table. Arista patched the flaw in October 2026, and CISA added it to the KEV catalog on the same October 23 listing as the Collabora flaw, citing exploitation in the wild. Arista has said the flaw is exploited in the wild but has not named a threat actor, disclosed technical details of the exploitation, or revealed how many organizations are affected, according to the reporting used here. Those gaps should be stated plainly: the exploitation claim is confirmed by the vendor and by CISA’s listing, while attribution and victim counts are not.

Who is affected by the Arista flaw and what are the fixed builds?

The flaw affects on-premises VeloCloud Orchestrator deployments. Cloud-hosted VCO customers should still confirm their status with Arista and their own deployment records, but the reporting used for this article describes the flaw as an on-premises VCO issue, and admins should scope their work to the deployments they actually operate rather than assuming every VCO instance is identical. The key access requirements are network access to the VCO web interface and a valid authenticated session on the VCO portal, with Enterprise Read Only as the minimum role. That means internet exposure of the portal, broad low-privilege accounts, and stale or shared credentials all raise the risk, even before any other weakness is considered.

Arista’s fixed builds are 5.2.3.18, 6.1.3.10, and 6.4.2.12. Admins should match the fixed build to their own release line rather than jumping to a different major line without checking Arista’s upgrade guidance. A team on the 5.2 line needs 5.2.3.18 or later in that line; a team on 6.1 needs 6.1.3.10; a team on 6.4 needs 6.4.2.12. If your build is below the fixed build for your line, you are behind on this flaw even if your version number looks recent in isolation.

This is the third weaponized vulnerability in VCO since July 2026, following CVE-2026-16812 and CVE-2026-93952, both scored 10.0. That recent history is a reason to treat VCO patching as a program, not a one-off event. Teams that patched the earlier VCO flaws but skipped this one, or that deferred VCO maintenance because the portal felt internal, should revisit that assumption today. The pattern of repeated high-severity VCO flaws also echoes a broader lesson from recent ransomware and exploitation advisories, including the SafePay ransomware CISA and FBI advisory covering 600 victims — once attackers learn a product family, they return to it.

How do you check for compromise on VeloCloud Orchestrator?

Start with access, because this flaw requires an authenticated session. Review VCO portal accounts, with priority for Enterprise Read Only accounts and any other low-privilege accounts that should not have been able to reach privileged internal functions. Look for accounts created, modified, or used in unexpected ways; sessions from unusual locations or at unusual times; and privilege or configuration changes that lack a matching change ticket. Two IP addresses geolocated to Japan were shared in the reporting — 74.82.197.86 and 38.54.50.151 — and admins can check their own logs for those addresses, but those two indicators alone do not define the compromise check. Absence of those IPs does not prove a system is clean, and their presence in a log needs investigation rather than an automatic verdict.

Next, review VCO audit and application logs around the exposure window for unexpected internal-function access, failed and successful privilege-related actions, and configuration exports or changes that no administrator recognizes. Compare the current VCO configuration against a known-good baseline where one exists, and pay attention to operator accounts, API access, and any new or altered enterprise settings. If logs are incomplete or retention is short, say so in your incident record rather than filling the gap with an assumption. Incomplete logging is itself a finding, and it should drive a retention fix after the immediate patch.

Finally, apply the same rule as with Collabora: patching does not erase prior access. If log review shows suspicious authenticated activity, rotate the affected credentials, review downstream systems that trust VCO accounts or configuration, and preserve evidence before rebuilding or reimaging anything. If no suspicious activity is found, record what was checked, over what date range, and with what log coverage, so the next reviewer does not have to re-litigate the same question.

What should private companies do if the federal deadline does not legally apply to them?

Treat October 26, 2026, as your internal deadline anyway, and document the decision either way. The federal directive binds federal civilian agencies; it does not create a legal patching deadline for a private firm, a university, or a home lab. But the underlying facts do not change at the boundary of the public sector: the flaws are actively exploited, the fixes are published, and the affected software is often reachable from the internet. A private organization that waits weeks because the directive does not name it is accepting the same attacker risk without any of the federal compliance pressure to move quickly.

A practical private-sector order of work is short. First, inventory both products today: confirm whether you run the Nextcloud Built-in CODE Server at all, and whether you run VCO on premises at all. Many teams will find they run one, neither, or only a standalone Collabora deployment that is out of scope for CVE-2026-110447. Second, patch what is in scope to the fixed versions above, or remove the built-in Collabora app if you do not need it. Third, run the compromise checks for each product you actually run, and rotate credentials where exposure cannot be ruled out. Fourth, restrict access going forward: limit who can reach the VCO portal and the Nextcloud proxy path from untrusted networks, prune low-privilege accounts that no longer need access, and keep VCO and CODE Server updates on a tracked schedule rather than an ad-hoc one.

Teams that have just worked through another critical patch will recognize the tempo. The recent GitLab CVE-2026-110264 critical RCE explained coverage made the same point for a different product: when exploitation is already happening, the patch window is measured in days, not quarters, and the compromise check is part of the patch, not an optional extra. That advice transfers directly here, even though the products and flaws are different.

What is the patch order if you run both products?

If you run both affected products, patch both today and sequence the work by exposure, not by convenience. Start with whichever system is internet-facing, has the broadest account base, or shows any sign of suspicious activity in its logs. In most environments that will mean checking the Collabora proxy path and the VCO portal exposure in parallel, with two different owners, rather than finishing one product completely before looking at the other. The deadline covers both flaws, so a clean Collabora upgrade does not compensate for an unpatched VCO portal left open overnight.

For Collabora, the order is: confirm the built-in deployment and version, upgrade to 26.4.303 or later (or remove the app if it is unused), hunt for shx*.php files and other unexpected scripts, review proxy.php requests during stopped-server windows, and rotate anything the web server account could have read. For VCO, the order is: confirm the on-premises deployment and release line, upgrade to 5.2.3.18, 6.1.3.10, or 6.4.2.12 as appropriate, review low-privilege account activity and configuration changes, check logs for the reported indicators without treating them as exhaustive, and rotate affected credentials where suspicion remains.

Keep a short written record for each system: product, deployment type, version before and after, date patched, log ranges reviewed, and any credential rotations performed. That record is what turns a frantic deadline-day patch into an auditable closure, and it is what lets a future reviewer distinguish a system that was patched and checked from a system that was merely patched. If either check finds a web shell, an unexpected privileged action, or an unrecognized account change, stop treating it as routine patching and escalate it as an incident, because the fix for the flaw is no longer the whole response.

Sources

Shoaib Hassan

Shoaib Hassan is the founder and editor of AuTechWire, an independent technology publication covering broadband, mobile networks, privacy, startups, and consumer tech.

Related Stories

Leave a Comment