CISA Flags Active Attacks on Self-Hosted Nextcloud Servers Running Collabora’s Built-In Office App. Turning It Off Is Not Enough
CISA has added a command injection flaw in Collabora’s Built-in CODE Server app for Nextcloud to its list of exploited vulnerabilities. Attackers have used it to plant web shells and hunt for password vaults. Here is a five-step walkthrough to tell whether your server is exposed and what to do next.
Plenty of small firms run their own Nextcloud server so staff can share files and edit documents without paying for a big cloud suite. If yours also uses the optional Collabora Online – Built-in CODE Server app, it needs attention today. On Friday the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added the app’s flaw, CVE-2026-110447, to its Known Exploited Vulnerabilities catalog, confirming that attackers are using it.
This post is based on The Hacker News’ report on CISA’s catalog update and its earlier investigation of the Nextcloud break-ins.
What happened, in brief
The built-in app (its package name is richdocumentscode) runs a copy of Collabora Online Development Edition right on the Nextcloud server, so Nextcloud Office can edit documents without a separate Collabora machine. A helper script in the app, proxy.php, starts that local document server when a request arrives and nothing is running. In versions up to 26.4.302, the script dropped text from the incoming request into a shell command, so a request with a hidden command in its path could run that command as the web server account, with no login.
The catch is timing: the attack only works while the local document server is down, for example during a restart, an upgrade or after a crash. Administrators reported on GitHub that attackers used it starting September 10 to drop a one-line PHP web shell, then searched for password manager files, credential stores and cryptocurrency wallets. CISA rates the flaw 9.2 on the CVSS scale, and federal civilian agencies have been told to fix it by October 26, 2026.
Are you affected? A five-step walkthrough
- Check whether you self-host Nextcloud. If your files live in a Nextcloud instance you or an IT provider run, keep going. Standalone Collabora Online servers are not affected, according to Collabora’s advisory.
- Open the Nextcloud app list and look for “Collabora Online – Built-in CODE Server.” A community forum warning noted that installations using only the Nextcloud Office app, with a Collabora server running in Docker, from a Linux package or at a hosting provider, are not affected.
- Do not just disable it. Collabora’s advisory is explicit that disabling the app does not close the hole, because the vulnerable script can be reached directly. Update it to version 26.4.303 or later, or remove it entirely.
- Check your Nextcloud version. The fixed app requires Nextcloud 30 or later. Nextcloud 29 and older are end of life and the app store still offers them a vulnerable build, so those servers need a Nextcloud upgrade or the app removed.
- Hunt for leftovers, even if you already patched. Look for files named shx*.php, starting in the apps/richdocumentscode folder, and delete them. Review access logs back to at least September 10 for proxy.php?status requests containing %2e%2e, $( or the shell variable IFS wrapped in braces, and check for sudo attempts by the web server account.
Why the patch was easy to miss
The code change that closed the flaw shipped in 26.4.303 on September 11, one day after the first logged attack, with release notes that did not mention security. The CVE and advisory only appeared on October 14. A later version, 26.4.402, has caused startup and document-opening problems for some administrators, who rolled back to 26.4.303, the version the advisory names as the fix.
What we still do not know
- How many servers were compromised. The CVE record says the flaw was exploited in the wild in September and October 2026, but no count has been published.
- Who is behind the attacks. None of the administrator reports show the attacker getting root access, but anything the web server account could read should be treated as potentially exposed.
What this means for your company
Self-hosting gives you control, and it also makes you the patch team. Today, confirm whether that built-in app exists on any server you own, update or remove it, and search for the leftover web shell files. If you find one, assume shared documents and any credentials stored on that server were readable, and rotate passwords and API keys used there. Longer term, put self-hosted apps on the same patch schedule and change log as your workstations, and make sure someone is subscribed to security advisories for each app you run.
Need help checking a self-hosted file server for exposure, or cleaning one up after a compromise? Reach out to Layer 7 Data Solutions to discuss how we’ve helped companies similar to yours.
About The Author
