Collabora Built-in CODE Server command injection: CVE-2026-110447

Most server bugs are exposed whenever the service is up. CVE-2026-110447 works the other way around. It sits in the PHP proxy of Collabora's Built-in CODE Server, the Nextcloud app that runs a document server on the Nextcloud host itself, and an unauthenticated request can only reach it while that document server is down. Restarts, upgrades and crashes all open the window, and switching the app off does not close it.

The fix shipped first and the explanation came later. Collabora released version 26.4.303 on 11 September 2026, built on a commit described as a tidy-up of how the server's launch command is assembled. Attacks had already started: an administrator opened a public GitHub issue that day with log entries from 10 September. The advisory and CVE followed on 14 October, and CISA added the bug to its Known Exploited Vulnerabilities catalog on 23 October, giving federal agencies until 26 October to act.

Who is affected

The bug is in the Nextcloud app, not in Collabora Online itself. Only installations that run the bundled document server through richdocumentscode are exposed. Censys could not confirm whether the ARM64 build of the app, richdocumentscode_arm64, is affected. Its internet scan found 19,454 hosts showing the app, a count that includes ARM64 installs and may overstate exposure.

How the Built-in CODE Server injection works

What Collabora confirms

The advisory is brief. A request to the app's proxy.php can make the server run an operating system command as the web server user, with no login. It only works while the built-in CODE server is not running. Collabora also says this is a different path from the 2025 proxy bug, CVE-2025-66208, and that the earlier fix does not block it.

What the code change suggests

Collabora has not published a root-cause write-up. One independent analysis by xhack, based on the published diff, describes the following mechanism. When proxy.php starts the local server, it builds a launch command that includes values taken from the request, such as the Host header and the request path. Each value was escaped once for the inner shell, but the whole command then went through a second shell inside double quotes. That outer shell still expands command substitution, so text in the request could run. The fixed version quotes the whole inner command as a single argument, so the outer shell has nothing left to expand.

Treat that explanation as a third-party reading of the diff, not a vendor statement. It does fit the observed attacks: GET requests to proxy.php?status with an encoded .. path and shell syntax in the URL.

Is it being exploited?

Yes, and the evidence is public:

• CISA added CVE-2026-110447 to KEV on 23 October 2026, with a remediation deadline of 26 October.
• The CVE record says the flaw was exploited in September and October 2026.
• Administrators in GitHub issue #354 posted logs and reported shx*.php web shells, plus commands that searched for password vaults and cryptocurrency wallet files.
• Sources disagree on the first attack. The issue's logs show a request on 10 September, against version 26.4.302. Censys dates the first malicious request it saw in an administrator's logs to 16 September.
• CERT Polska says the bug is being used in ransomware attacks. None of the other sources here confirms that.

Censys found no public proof-of-concept code as of 16 October, but real attack requests are visible in the logs posted to the issue.

Check your exposure

Check the installed app version and whether its files have been tampered with. Run occ as the web server user from the Nextcloud directory, and adjust paths to your installation:

# Installed version of the built-in CODE server app (fixed: 26.4.303)
sudo -u www-data php occ app:list | grep richdocumentscode
 
# Report files in the app that do not match the signed release
sudo -u www-data php occ integrity:check-app richdocumentscode
 
# Web shells reported in the wild were named shx*.php
find /var/www/nextcloud -path '*richdocumentscode*' -name 'shx*.php'

The integrity check matters because shell names vary. Besides shx*.php, administrators reported shrf*.php and other names in the app directory.

Fix it

Update richdocumentscode to 26.4.303 or later from Nextcloud's app management page or with occ app:update richdocumentscode. If you do not use the built-in server, remove the app with occ app:remove richdocumentscode instead.

The fixed version needs Nextcloud 30 or later. On Nextcloud 29 or older, Collabora's guidance is to upgrade Nextcloud or remove the app. The vendor lists no configuration workaround.

Updating does not undo a compromise. Censys advises investigating every internet-facing server that ran the app from 10 September 2026 onward, whatever its current version.

Detect attempts and compromise

Published signals, mainly from CERT Polska and Censys:

• Access logs. Requests to /apps/richdocumentscode/proxy.php?status that contain %2e%2e, $( or ${IFS}.
• Files. shx*.php files under apps/richdocumentscode, or any extra PHP file the integrity check reports.
• Processes. sudo attempts by the web server account.
• Hash. One shell recovered in issue #354 has SHA-256 4b9fbd0663fbfd6028fc216ed18e0d6ef3ae498a7fdc97083e4b0ce3cec40562.

zgrep -hE 'richdocumentscode/proxy\.php\?status' /var/log/nginx/access.log* /var/log/apache2/access.log* 2>/dev/null \
  | grep -E '%2e%2e|%24%28|\$\(|\$\{IFS\}'

If any of these turn up, treat the host as compromised. Delete the shells, then rotate everything the web server user could read: the database password in Nextcloud's configuration, app passwords and any other stored credentials. One administrator on 26.4.303 also saw attack strings in the arguments of a running document server process. The maintainer called those listings harmless once the fix is in place, but they are a sign the server was targeted.

Beyond this patch

Two lessons carry beyond this bug. Treat a state your software rarely sits in, such as "stopped" or "disabled", as part of its attack surface, not as a safe default. And update promptly even when a release has no advisory: here the advisory trailed the fix by more than a month. When a fix lands before its advisory, checking for compromise matters as much as the version number; how a retest verifies a fix describes what evidence beyond a version string looks like.