CRITICAL: Collabora Built-in CODE Flaw Used to Backdoor Nextcloud Servers

There is a special kind of irony in getting owned through the app you installed specifically because it was the easy option. That is exactly what has been happening to Nextcloud administrators running the Collabora Online Built-in CODE Server, and on Friday, October 23, CISA made it official by adding the flaw to its Known Exploited Vulnerabilities catalog with a federal remediation deadline of Monday, October 26. Three days is not a lot of runway, and the agency also flagged the entry for forensic triage, which is CISA's polite way of saying that patching alone will not tell you whether someone already moved in.

The bug is tracked as CVE-2026-110447 and carries a CVSS 4.0 score of 9.2. It is an unauthenticated operating system command injection, classified as CWE-78, in the proxy.php component of richdocumentscode, the Nextcloud app that bundles a full Collabora Online Development Edition server so that small shops can get browser-based document editing without standing up a separate Collabora box. Every version before 26.4.303 is vulnerable. The fix shipped back on September 11, 2026, but Collabora did not publish its advisory (GHSA-g3vx-3m76-fghh) until October 14, and by then attackers had already been working the bug for weeks.

How the attack works

The interesting wrinkle here is timing. The vulnerable code path only becomes reachable while the bundled CODE server is not running. In normal operation proxy.php simply hands requests off to the local document server. When that server is down, though, the proxy tries to launch it, and that launch routine is where things go sideways. That window opens more often than you might think. A container restart, an app upgrade, a crash, or a server reboot all leave the CODE process stopped until something pokes it back to life, and an attacker is perfectly happy to be the one doing the poking.

According to analysis of in-the-wild activity published by SecurityOnline, the exploitation chain starts with unauthenticated HTTP GET requests to /apps/richdocumentscode/proxy.php?status carrying URL-encoded path traversal sequences such as %2e%2e. Attacker-controlled input ends up, without proper escaping, in the remote_font_config.url argument that the proxy passes when it launches Collabora_Online.AppImage. From there it is classic shell abuse. Command substitution with $() and ${IFS} tricks to dodge naive space filtering get the payload executed through sh as the web server user. The observed payloads decode a Base64 blob that drops a PHP web shell into the app directory, then phone home to webhook.site with system identification output so the operator knows which victims landed.

Worth noting for anyone who patched the older Collabora bug last year and checked this box mentally. Collabora explicitly says this is not the same code path as CVE-2025-66208, and the earlier fix does not close it. If your remediation tracker says "Collabora proxy, done," it is lying to you.

What the attackers want

The post-exploitation behavior tells you a lot about who is likely behind this, even though nobody has publicly attributed the campaign to a named actor. Once the shell is in place, operators run reconnaissance and then go hunting for things they can turn into money quickly. Reported targets include KeePass .kdbx databases, Bitwarden and 1Password artifacts, wallet.dat files, keystore.json files, and Bitcoin, Monero, and Ethereum data directories. That is a smash-and-grab crew, not an espionage team tiptoeing around for a year.

Think about what a Nextcloud server actually is for most of the organizations running it. It is the company file share. It is where the accounting team syncs spreadsheets, where somebody exported the password vault "just for a minute" during a migration, and where the sysadmin keeps the folder labeled "keys" that everyone pretends not to know about. Anything readable by the web server account is fair game, and on a lot of small deployments that is effectively everything in the data directory. A credential store lifted from a file share rarely stays a single-server problem for long.

Reports date the earliest exploitation to around September 10, 2026, which is one day before the patched release went out and more than a month before the public advisory. The Nextcloud community forum posted an alert titled "To Collabora built-in user update ASAP" after administrators started finding web shells they did not put there, and CISA cites that thread directly in its catalog entry. No one has published a hard count of exposed instances, but the built-in CODE app is one of the most commonly installed add-ons in the Nextcloud ecosystem precisely because it removes the hassle of running Collabora separately. The population of small, lightly monitored, internet-facing installs is large.

Who is and is not affected

The scope is narrower than the "Collabora Online" headline suggests, and that matters for triage. Only the richdocumentscode app, the built-in CODE server that runs inside the Nextcloud PHP environment, is vulnerable. Standalone Collabora Online servers are not affected, and neither are Docker-based Collabora deployments, distribution packages, or hosted Collabora services connected to Nextcloud through the regular Office integration. If your Nextcloud talks to a separate Collabora host over the network, this specific bug is not your problem today. If you clicked "install" on the Built-in CODE Server app in the Nextcloud app store at any point, it very much is.

What to do right now

Update richdocumentscode to version 26.4.303 or later. If nobody in your organization actually uses in-browser document editing, remove the app entirely, which is the cleaner answer anyway. Here is the part people will get wrong. Collabora states plainly that disabling the app is not sufficient. A disabled app still leaves proxy.php sitting on disk where it can be reached, so "disable and move on" leaves the door open. Upgrade it or delete it.

Then assume you need to look for an intruder, because the exploitation window predates the advisory by more than a month. Start with the app directory itself and look under /apps/richdocumentscode/ for any PHP files that do not belong there, paying particular attention to names matching shx*.php and shrf*.php, which have been observed in this campaign. Do not stop at those patterns, since renaming a web shell takes about four seconds. Compare the directory against a clean copy of the app if you can.

Your web server logs are the next stop. Search access logs going back to at least early September for requests to proxy.php?status that contain encoded traversal like %2e%2e, along with unusual characters such as $( or IFS in the query string. Check egress logs, DNS logs, or firewall records for any outbound connections from the Nextcloud host to webhook.site, which has no business being contacted by a file server. On the host itself, look for unexpected long-running processes owned by www-data or whatever account your web server runs as, and kill and investigate anything that looks out of place.

If you find evidence of compromise, patching is the beginning of the cleanup, not the end. Rotate every secret the web server user could read, which includes Nextcloud's own config.php database credentials, any API keys or service tokens in synced folders, and any passwords sitting in vault files on the share. Notify users whose password manager databases lived in the data directory, because an offline .kdbx file is only as strong as the master password protecting it and attackers have all the time in the world to crack it. For organizations handling regulated data, involve legal and incident response early rather than after the fact.

For the longer term, this is a good reminder to put administrative and helper endpoints like this behind something smarter than the open internet. A reverse proxy rule or WAF signature that blocks encoded traversal and shell metacharacters on Nextcloud app paths would have blunted this campaign for a lot of victims, and it costs almost nothing to deploy.

The bigger picture

None of this is exotic. It is an unsanitized argument handed to a shell, in a component that only becomes exposed in a transient state most admins never think about. It is also a textbook case of the patch landing quietly while exploitation was already underway, with the public advisory trailing by a month. Small and midsize organizations running self-hosted collaboration stacks rarely subscribe to individual GitHub security advisories, and they absolutely do not read Nextcloud app changelogs on a Tuesday afternoon. That gap between "fix available" and "anyone noticed" is exactly where these crews make their living.

Self-hosting Nextcloud is a perfectly reasonable choice. It just comes with the expectation that somebody is actually watching it. If that somebody is nobody, this week is a good time to change that.

For MSPs, the opportunity is obvious. Nextcloud is everywhere in the small business and nonprofit space precisely because it is cheap and self-hosted, which means plenty of your prospects have an unmonitored instance sitting on the internet right now. Offer a fixed-price Nextcloud compromise assessment covering patch verification, web shell sweeps, log review, and credential rotation, then use the findings to sell ongoing managed patching and EDR coverage for self-hosted collaboration servers.