What richdocumentscode 26.4.303 fixes
CVE-2026-110447 is an unauthenticated operating-system command injection, classed CWE-78 and scored 9.2 on CVSS 4.0 in Collabora's advisory. It affects a single application: Collabora Online - Built-in CODE Server, identifier richdocumentscode, an optional Nextcloud module that embeds a Collabora server inside the app itself. The entry point is the application's proxy.php file. The advisory states that a request can make the system run a command with the web server user's rights.
The fix is version 26.4.303: the commit dates from September 9, 2026 and the version has been available since September 11, 2026. The advisory itself was only published on October 14, 2026, more than a month later. Collabora puts the delay down to CVE-processing backlogs on GitHub. The practical consequence: a server that stayed behind may have been attacked well before the identifier existed. This article starts from that fact and therefore deals with two questions, not one: the fix, and the search for traces.
What is known about the exploitation
- Attack condition — the advisory specifies that the attack only works while the built-in CODE server is not running: container restart, upgrade, crash. No authentication or interaction is required.
- Start of the attacks — administrators report first attacks on September 10 and 11, 2026 against version 26.4.302. BleepingComputer says mid-September; sources differ by a few days, and we do not settle it.
- Listed in KEV — CISA added CVE-2026-110447 to its Known Exploited Vulnerabilities catalog on October 23, 2026, with a federal deadline of October 26. Exploitation is observed, not theoretical.
- What the attackers looked for — PHP webshells dropped on the server, then searches for password databases, password managers and cryptocurrency wallets.
- Ransomware: unconfirmed — users mentioned it on the project's issue; BleepingComputer could not confirm it. We report it as a rumour, nothing more.
- Number of servers affected — unknown. No primary source gives a figure.
Affected versions, fixed versions, unaffected setups
Scroll the table
| Setup | Status | Action |
|---|---|---|
| `richdocumentscode` app older than 26.4.303 | Vulnerable | Update to 26.4.303 or later, or remove the app |
| `richdocumentscode` app at 26.4.303 or later | Fixed | Still look for traces dating from before the update |
| `richdocumentscode` app merely disabled | Not protected | Disabling is not enough: update or remove |
| Standalone Collabora Online server | Not affected, per Collabora | No action tied to this CVE |
| Collabora in Docker or as an RPM/DEB package | Not affected, per Collabora | No action tied to this CVE |
| Nextcloud All-in-One | Not affected, per Collabora | No action tied to this CVE |
| Nextcloud 29 or earlier | End of life | Update Nextcloud, or remove the app |
Built-in CODE or external server: how to tell
Many administrators do not know which of the two they run, because the Nextcloud Office app shows the same editor in both cases. The difference is found elsewhere. The "external" Collabora server is a separate service (container, package, dedicated machine) that Nextcloud connects to through a URL entered in the Nextcloud Office settings. The "built-in" server is one more Nextcloud app, richdocumentscode, which downloads and starts a local server.
The reliable criterion is therefore the presence of the app, not the address shown in the settings. If richdocumentscode is installed, you are within the advisory's scope, whether it is enabled or not. If it is absent, this CVE does not concern you, even if you use Collabora. A Nextcloud forum participant also notes that installations using richdocuments without richdocumentscode are not affected.
Inventory one server, then a whole fleet, in five steps
List the installed apps
From the Nextcloud directory, or inside the container, run
sudo -E -u www-data php occ app:list | grep richdocumentscode. Adapt the user and path to your installation. A line in the output means the app is present, enabled (Enabled) or not (Disabled).Read the installed version
Run
sudo -E -u www-data php occ config:app:get richdocumentscode installed_version. If the number is below 26.4.303, the installation falls within the advisory's range.Check what Nextcloud Office uses
Open the Nextcloud Office settings and note the Collabora server URL. It does not replace step 1: the presence of the app takes precedence over the displayed address.
Compare with the updates available
sudo -E -u www-data php occ app:update --showonlylists the app updates on offer without applying them. Check whetherrichdocumentscodeappears.Repeat on every server and record the result
On a fleet, run the same three commands over SSH on each client instance and paste the output into a table: client, server, app present, version, check date. That table is what lets you answer a client who asks whether they are affected.
Disabling is not enough: update or remove
The reflex is to disable the app in the meantime. Collabora's advisory is unambiguous: it is not sufficient to disable the app, which must be upgraded to 26.4.303 or later, or removed. The vulnerable file stays on disk as long as the app is not removed, and the advisory does not say that a disabled file becomes unreachable.
Choose according to use. If your users edit documents with the built-in server, update. If you do not use it, or if you have an external Collabora server, remove the app: it is the only option that removes the attack surface. If your Nextcloud is version 29 or earlier, it is no longer maintained: the advisory asks you to upgrade Nextcloud itself, or remove the app.
Fixing it: update or removal
Back up before acting
Take a snapshot of the machine or a backup of the database and data directory. If you already suspect a compromise, also keep a copy of the logs before changing anything: they will serve the trace hunt below.
Update the app
sudo -E -u www-data php occ app:update richdocumentscode. Then runocc config:app:get richdocumentscode installed_versionagain to confirm the number is 26.4.303 or higher.Or remove the app
sudo -E -u www-data php occ app:remove richdocumentscode. The command disables then removes the app; the--keep-dataoption keeps its data. Confirm withocc app:list, which should no longer mention it.Restart the relevant service
Restart PHP-FPM or the Nextcloud container so that no process keeps the old code in memory. Remember that the exploitation condition is precisely a restart or crash of the built-in server.
Check the result
Replay the inventory from the previous section: the app must be absent or at 26.4.303 minimum. Note the date and time of the fix; they will serve as a boundary in the trace hunt.
A server patched today may have been compromised before
The update closes the door; it says nothing about what has already come in. The first reported attacks date from September 10, 2026, and an administrator reported on the Nextcloud forum that a malicious file had remained after the update. An up-to-date server is therefore not a healthy server.
The official advisory lists no indicator of compromise. What follows is not an official indicator list: it is a generic hunting method, together with what administrators reported on the project's richdocumentscode#354 issue. One piece of common sense applies to all of it: none of these checks proves the absence of a compromise; they can only reveal one.
Trace-hunting method (generic, to adapt)
- Recent PHP files —
find /var/www/nextcloud/apps/richdocumentscode -name '*.php' -newermt 2026-09-01lists PHP files modified since September 1 in the app directory. Do the same on the data directory, where no PHP file has any reason to exist. - Reported names — administrators found
shx*.phpfiles in the Nextcloud directory (issue #354); another found a file with a different name inapps/richdocumentscode/. Searching forshx*.phpis useful, but the absence of that name proves nothing: attackers can choose another. - Comparison with the official archive — download the app version from the official catalogue, unpack it in a temporary directory and compare with
diff -r. Any extra or different file is suspect. - Nextcloud integrity check — one administrator discovered their malicious file because the integrity check flagged it. Run it and read the result.
- Web server logs —
zgrep -hE 'proxy\.php.*(%2e%2e|IFS)' /var/log/nginx/access.log*looks for requests toproxy.phpcarrying a%2e%2esequence or the shell variable IFS. The requests reported on the issue targeted/apps/richdocumentscode/proxy.php?status; a forum administrator advises going back to September 10. Adapt the path to Apache or to your log rotation. - Odd processes — administrators observed
coolwsdandcoolforkit-nsprocesses under the web server user with a payload in theremote_font_config.urlargument. These processes also exist legitimately when the built-in server runs; it is the content of the argument that is abnormal.
If you find something: the machine is compromised
A webshell runs commands with the web server user's rights. Treat everything that user can read as exposed: Nextcloud's config.php (database credentials, secrets), app passwords, SSH keys and tokens it can read, mounted external storage. Rotate those secrets, then restore from a backup dating from before September 10, 2026 rather than "cleaning" the machine in place. For a client, tell them: it is their content that was exposed.
A fleet of client Nextclouds: who carries what
For an agency, this CVE is not a command, it is an inventory. Each client has their own instance, their own version, sometimes an app installed "to try" two years ago. A client's question is predictable: "are we affected, and have you checked?". The honest answer is in the table from step 5 of the inventory, with the check dates.
Responsibility splits simply: you manage the client relationship and decide the action (update, removal, restore); we keep the infrastructure these servers run on. With ServOrbit.com's solutions for agencies, a single space brings together each client's servers, renewals and security, which avoids rebuilding the fleet from spreadsheets on the day of an alert. If you are a professional running a single instance, the solutions for professionals page describes the support that suits you.
The lasting safeguard: a Collabora kept separate from Nextcloud
According to Collabora, standalone Collabora Online servers, Docker and RPM/DEB installations and Nextcloud All-in-One are not affected. The common point is that the editing server lives in its own container or service, outside Nextcloud's PHP tree. That is the "sidecar" architecture described in our guide Nextcloud, Collabora and OnlyOffice: we do not redo the tutorial here. To start from scratch, hosting Nextcloud covers the deployment.
This is not an argument against the built-in app as such, only a way to reduce what has to be watched. We have also published two other emergency update guides, PHP2Shell and nginx CVE-2026-15176: the method is the same, inventory, fix, verify, then look for what may have got through earlier.
