What is vulnerable and what is not
The problem affects a single app from the Nextcloud app store: Collabora Online – Built-in CODE Server (technical name richdocumentscode). It is a convenient option for smaller installations: Nextcloud downloads and runs a local document server itself, with no separate machine or container. The proxy.php script is used to start it. When the document server is not running, a crafted request to this script results in an arbitrary system command being executed with the privileges of the web server user (usually www-data). No login is required.
Not affected: standalone Collabora Online servers, installations from Docker images and RPM/DEB packages, Nextcloud All-in-One, and hosted Collabora services. If an organisation uses the richdocuments app (Nextcloud Office) connected to a separate Collabora server, this flaw does not apply.
Why it is urgent despite the precondition
The attack only works while the built-in CODE server is not running. That sounds like a serious limitation, but in practice this state is common: after a server or container restart, after an upgrade, after a process crash, and also when nobody has opened a document for a while. Collabora rates the flaw 9.2 on CVSS 4.0 (critical).
The flaw is being exploited. Administrators reported intrusions from 10 September 2026. Attackers left PHP files with names starting with shx (webshells) in the app directory, then searched the server for password manager databases (*.kdbx) and cryptocurrency wallets. On 23 October CISA added CVE-2026-110447 to its KEV catalogue. The fix was released on 11 September, but the security advisory and CVE number were only published on 14 October, so many servers received no signal for a month that an update was needed.
In our view, every internet-facing installation with this app should be patched today and checked for compromise straight away. There is no reason to wait for a maintenance window.
Versions
- Vulnerable:
richdocumentscodeversions below 26.4.303. - Fixed: 26.4.303 and later.
- Nextcloud 29 and older (end of life): the vendor recommends upgrading Nextcloud or removing the app.
There is also a richdocumentscode_arm64 variant for ARM servers. The vendor has not stated clearly whether it is affected, so we recommend treating it the same way.
How to check an installation
On the Nextcloud server, from the installation directory and as the web server user:
sudo -u www-data php occ app:list | grep -i richdocumentscodeshows whether the app is installed and which version. The “disabled” state also counts: disabling the app does not protect against the attack.ls -la apps/richdocumentscode/*.phpandfind apps/ -name 'shx*.php'help find foreign PHP files.sudo -u www-data php occ integrity:check-app richdocumentscodereports files that are not part of the official package (in reported cases the webshell showed up asEXTRA_FILE).- Search the web server logs for requests to
richdocumentscode/proxy.phpsince 10 September, e.g.grep 'richdocumentscode/proxy.php' /var/log/nginx/access.log*(or the Apache equivalent). Requests containing%2e%2e,$(,${IFS}or base64 strings are suspicious.
What to do
- Update the app:
sudo -u www-data php occ app:update richdocumentscode. If document editing is not used, it is better to remove it:occ app:remove richdocumentscode. - Delete any
shx*.phpfiles and other foreign scripts found. The update does not remove webshells already on the server. - If the logs or disk show signs of attack, treat the server as compromised at the
www-datauser level. Change the database password fromconfig.php, app passwords and any keys this user could read, and check crontab, processes and other app directories. Reports from the attacks do not indicate root compromise, but data available to the web server (including user files) should be considered exposed. Where personal data is involved, the obligation to notify the data protection authority (UODO in Poland) must also be assessed.
The longer-term lesson
This flaw exposes two weak points. The first is add-on apps in Nextcloud, WordPress and similar systems: they rarely make it into the software inventory, yet they run with the same privileges as the whole system. The second is delayed advisories: the fix was available a month before the CVE number. Companies that update add-ons automatically or on a fixed schedule were safe from mid-September. Those that wait for a security alert learned about the problem when attacks had already been going on for several weeks.