CVE-2026-110447: Collabora CODE Server RCE, Patch by 26 Oct

Collabora Online's built-in CODE server carries an OS command injection flaw, CVE-2026-110447, that allows remote code execution when the component is used within the NextCloud platform and the CODE server isn't running. CISA added it to the Known Exploited Vulnerabilities catalog on 23 October 2026 and set a remediation due date of 26 October 2026. If you run Collabora Online's bundled CODE server alongside NextCloud, treat this as a patch-today item. If you run a standalone Collabora document server with no NextCloud in front of it, the attack path CISA describes does not apply to you — but confirm that against your own deployment rather than assuming it.

What CVE-2026-110447 actually is

It is an operating-system command injection bug, which in practice means an attacker can get your document server to execute commands on the host instead of merely serving documents. CISA's short description states that Collabora Online – Built-in CODE Server, when used within the NextCloud platform, "contains an OS command injection vulnerability that allows for remote code execution when the CODE server isn't running." The published entry gives no affected version range and no fixed version, and it records known ransomware campaign use as Unknown — meaning CISA has not attributed this to a ransomware operation, not that it is safe. The KEV listing itself is the signal that matters: inclusion means exploitation has been observed in the wild. Plan accordingly, not on the hope that a two-day-old entry has no tooling behind it yet.

Am I affected: CVE-2026-110447 in Collabora Online – Built-in CODE Server

You are in scope if your NextCloud instance uses the built-in CODE server rather than pointing at a separately hosted Collabora Online service. That built-in option is the convenience path — the document server runs as part of the NextCloud deployment instead of as its own service — and convenience paths are exactly what gets left on a default configuration for years. Two things to check this hour: whether the built-in CODE server component is installed and enabled at all, and whether that NextCloud host is reachable from the public internet. The description ties the flaw to the case where the CODE server isn't running, which is unusual phrasing and is not expanded on in the entry, so do not talk yourself out of scope on the strength of that one clause. Confirm your position against the vendor advisory.

Why the 26 October 2026 deadline leaves no slack

KEV deadlines bind US federal civilian agencies, but for everyone else they are a useful forcing function — a date set by people who have already seen the exploitation. This entry landed on 23 October 2026 under catalog version 2026.10.23, with a due date of 2026-10-26. The required action is to apply mitigations in line with vendor instructions, following CISA's BOD 26-04 risk-based patching guidance and its forensics triage requirements; where mitigations are unavailable for cloud services, that guidance is to discontinue use of the product. CISA also puts the exposure judgement on the asset owner — you are expected to evaluate each asset's internet exposure yourself. For an Indian SMB the practical translation is short: anything with a public IP and a document editor behind it gets fixed first.

What to do in the next 24 hours

Work in this order, and write down what you find, because whoever touches the system next will need the record.

• Inventory before you patch. List every NextCloud deployment and every Collabora Online instance, including the pilot someone stood up in 2024 and never decommissioned. If that list lives in one engineer's head, that is the bigger vulnerability — see server and infrastructure work.
• Patch per vendor instructions. The CISA entry names no fixed version, so do not guess a version string: pull the current release or the documented mitigation from Collabora and from NextCloud, and follow their advisory. If no mitigation exists for your deployment shape, the guidance is to stop using the product.
• Verify what is actually serving traffic, not what sits in the repo or the ticket. Check the version reported on the admin/about page of the instance behind the load balancer, confirm the container image digest or package version on the running host, and repeat per node. A patched image that never got deployed is the most common failure in this step.
• Cut exposure while you work. If the CODE server does not need to be internet-facing, put it behind the VPN or an IP allowlist. Nothing in the entry requires it to be public.
• Watch the logs afterwards for the signature of command injection: the document-server process spawning shell or interpreter children, outbound connections from that host to unfamiliar addresses, files appearing in temp directories, and requests to the CODE endpoints from unexpected sources. Alert on process creation from the document server for at least a couple of weeks.

What AI changes about finding and fixing this class of bug

Nothing about who found this one — the entry does not say, and it makes no difference to your remediation. What has changed is the cost of the two steps teams usually skip. Command injection is a data-flow problem: untrusted input reaches a shell invocation without sanitisation. Static analysers have chased that pattern for years with mediocre results on framework-heavy code, because the input arrives through routing, middleware and a service layer first. A model-assisted review pass pointed at request handlers and at every place the code shells out does better at following the path across files, and it does it in an afternoon rather than a week of a senior engineer's calendar. The same tooling helps defensively during an incident like this: point it at your repositories and ask which services invoke a shell, which of those take user-controlled strings, and which of those are internet-facing. That gives you a short list you can actually work through. What it will not do is tell you whether a third-party binary such as the CODE server is exploitable — that answer only comes from the vendor.

Where to start

If you cannot say with confidence which NextCloud and Collabora instances you are running, start there rather than with the patch: you cannot fix a host you cannot name. Pull the list, check exposure, then work the vendor advisory against each entry and log what you changed. If the inventory step is the part that keeps slipping, that is the kind of work we do at Maysan Labs, alongside the cloud and infrastructure builds that turn the next advisory like this into a fifteen-minute job instead of a two-day scramble.