Nextcloud Collabora Vulnerability 2026 Explained: Patch the Built-in CODE Server

A value that looks harmless can carry a command when the shell reads it. That is the Nextcloud Collabora vulnerability tracked as CVE-2026-110447, fixed in richdocumentscode 26.4.303.

Picture a common setup. A team self-hosts a file server so staff can edit documents in the browser. To open a document, a small helper starts a local document server on demand, then passes the browser's request to it. The setup is made up, but the bug is real.

The helper builds the start command as one line of shell text. Into that line it pastes a couple of values taken from the incoming request. It wraps each value with an escaping function first, so this feels safe.

Now ask the question the team skipped. Where exactly does the escaped value sit in that line? Here it sits inside a second quoted command handed to another shell. At that spot the escaping no longer holds, and a hidden command in the value runs.

You need six: the built-in CODE server, proxy.php, the shell, command substitution, escaping, and unauthenticated. Each gets a plain meaning and an example from the team's setup.

Built-in CODE server. This is an optional Nextcloud app, richdocumentscode. Instead of pointing at a separate document server, it downloads one and runs it on the Nextcloud machine. Example: the team ticked a box and skipped running a second server.

proxy.php. This is one PHP file inside that app. It takes a web request, makes sure the document server is running, and forwards the request to it. Example: every document the staff open passes through this file.

The shell. The shell is the program that reads a command line and runs it, like bash or sh. It treats some characters as instructions, not plain text. Example: starting a background program is a shell job.

Command substitution. Writing a command inside a dollar sign and parentheses tells the shell to run that command first and drop its output in place. Example: a date wrapped that way becomes today's date before the main command runs. We call this a dollar-group below.

Escaping. Escaping rewrites a value so the shell treats it as one plain argument. PHP's escapeshellarg wraps a value in single quotes and neutralises quotes inside it. Example: a filename with a space stays one argument.

Unauthenticated. An unauthenticated request needs no login and no account. Anyone who can reach the address can send it. Example: a request to proxy.php never checks who you are before it acts.

It is an operating-system command injection in proxy.php in the Built-in CODE Server app, in every richdocumentscode version before 26.4.303. An unauthenticated request could make the server run a shell command as the web server user.

The flaw is reachable only while the local document server is not running. That is the case right after a restart, during an upgrade, or after a crash, because proxy.php then has to start the server itself.

The advisory rates it critical, CVSS v4.0 score 9.2, under CWE-78, the catalogue name for OS command injection. Its vector marks an attack requirement (AT:P), which fits the server-down condition. The CVE record says it was exploited in the wild in September and October 2026. It is a different bug from CVE-2025-66208, and the older fix does not stop it.

One detail makes it worse. proxy.php is a plain PHP file run straight from the app folder. We read the source: it loads none of Nextcloud's code and checks no login, so the usual Nextcloud guards never run for this file.

Because the value was escaped for the wrong place. We read proxy.php at tag 26.4.302, the last release before the fix. In its start function it builds the launch command like this (names kept, line shortened):

$launchCmd = "bash -c \"( $appImage $remoteFontConfig "
              . "$IPv4only $lok_allow --pidfile=$pidfile || ... ) >/dev/null & disown\"";
exec($launchCmd, $output, $return);

Read the quotes carefully. The whole thing is a double-quoted PHP string. Inside it sits bash -c followed by another double-quoted string: the real command. Two of the pasted pieces are built from the request. lok_allow carries the Host header, and remoteFontConfig, added only on HTTPS, carries a URL made from the host and the request path.

Those two pieces do pass through escapeshellarg first. We confirmed that in the source. escapeshellarg wraps a value in single quotes, which is the right way to hand it to a shell as one argument.

But the value is not handed over as an argument. It is pasted inside the inner double-quoted command. PHP's exec gives the outer string to one shell. Inside double quotes, a single quote is just an ordinary character to that shell, so it runs any dollar-group it finds. The inner bash only sees the single quotes after the damage is done.

Because the shell treats the two quote styles differently. Inside double quotes the shell still does command substitution and variable expansion. Inside single quotes it treats every character as literal text. This one rule is the whole bug class.

Here is a harmless check you can run. It never touches Nextcloud. It just prints what the shell does with the same text in each quote style.

# Double quotes: the shell runs the inner command and pastes its output.
echo "value is $(echo EXPANDED)"
# Single quotes: the shell leaves it as plain text.
echo 'value is $(echo EXPANDED)'
# Single quotes placed INSIDE a double-quoted string do not protect it.
sh -c "echo 'value is $(echo EXPANDED)'"

Check it worked: run it with bash. The first line prints value is EXPANDED. The second prints value is $(echo EXPANDED), untouched. The third, where single quotes sit inside double quotes, prints value is EXPANDED again. That third case is the shape of the bug.

Now the same idea in PHP, with a value that is escaped first. The dangerous value here only tries to create an empty file named MARKER, so you can see whether the command ran. It sends nothing and attacks nothing.

<?php
$value = 'hello $(touch MARKER)';
$opt = '--url=' . escapeshellarg($value);   // wraps value in single quotes

// A. Like 26.4.302: escaped value pasted inside a double-quoted bash -c string.
exec("bash -c \"( echo $opt )\"");
echo file_exists('MARKER') ? "A: command ran\n" : "A: safe\n";
@unlink('MARKER');

// B. Like 26.4.303: escape the WHOLE inner command once more.
exec('bash -c ' . escapeshellarg("( echo $opt )"));
echo file_exists('MARKER') ? "B: command ran\n" : "B: safe\n";
@unlink('MARKER');

Check it worked: run it with PHP. Case A prints A: command ran, because the escaped value sits inside the inner double quotes, exactly the 26.4.302 pattern. Case B prints B: safe, because the inner command is escaped as one unit. We ran this on PHP 8.3.6 and saw that result.

By escaping the whole inner command, not just the values inside it. We read proxy.php at tag 26.4.303. The start function now builds the command in two steps:

$innerCmd = "( $appImage $remoteFontConfig $IPv4only "
              . "$lok_allow --pidfile=$pidfile || ... ) >/dev/null & disown";
$launchCmd = "bash -c " . escapeshellarg($innerCmd);
exec($launchCmd, $output, $return);

Now escapeshellarg wraps the entire inner command as one argument to bash -c. The outer shell sees a single quoted blob and does no substitution inside it. The dollar-group in a pasted value stays plain text. Our case B above runs this exact shape and stays safe.

The change is small. The fix commit is 6cc8dae, titled tidy up how the coolwsd launch command is built, by the maintainer caolanm. The commit page shows one file changed, proxy.php, three lines added and one removed. A quiet title for a critical fix.

The newest release, 26.4.402, goes one step further. We read its source: it calls proc_open with an argument array. It keeps a fixed bash script, but passes each option as a separate argument, so bash never parses them as code. It also validates the Host header and no longer uses the request path.

You can stop here if you never had the Built-in CODE app installed. If you ran a version before 26.4.303 at any point since about 10 September, read the compromise checks below, even if you have patched. Attacks began a day before the fix shipped.

Only one setup is affected: the Nextcloud app Built-in CODE Server, richdocumentscode, before 26.4.303. That is the app that downloads and runs the document server on the Nextcloud machine itself.

The advisory says standalone Collabora Online servers are not affected. Collabora's blog adds its Docker images, RPM and DEB packages, and Nextcloud All-in-One. The Nextcloud forum warning adds Nextcloud Office on its own, with richdocumentscode not installed.

Note the scope of Docker. It means Collabora's own image. A Nextcloud server that itself runs in Docker is affected if the Built-in CODE app is installed, and the advisory lists a container restart as a trigger. The Hacker News quotes the store listing as for local testing and non-production use, and Collabora's blog calls the app focused on home users.

One group is stuck. Nextcloud 29 and older are end of life, and the fixed app needs Nextcloud 30 or later. As of 23 October 2026 the app store offers Nextcloud 25 to 29 version 26.4.104, which is still affected, so they cannot patch by updating the app. They must upgrade Nextcloud or remove the app.

Read the installed version with Nextcloud's command line tool, occ, run as the web server user. That user is www-data on Debian and Ubuntu; other systems may use apache or nginx. In the official Nextcloud Docker image, run docker exec -it --user www-data CONTAINER_ID php occ instead.

1. 1

   List the app and its version

   Run sudo -E -u www-data php occ app:list and find the line that reads richdocumentscode followed by its version. We checked the occ source: it prints each app as name and version. Confirm 26.4.303 or higher.

2. 2

   Update the app if it is older

   Run sudo -E -u www-data php occ app:update richdocumentscode, or update it from the apps page. On Nextcloud 29 or older the store has no fixed build, so this will not help you.

3. 3

   Remove it if you do not need it

   If the app was only for testing, first run the integrity check in the next section, because removing the app deletes its folder and any planted file with it. Then run sudo -E -u www-data php occ app:remove richdocumentscode. The advisory says disabling is not enough, so remove or upgrade; do not just disable.

4. 4

   Prefer a standalone server for production

   If staff need document editing in production, run a standalone Collabora server in Docker or from a package, and point Nextcloud Office at it. That setup never had this flaw.

Patching closes the door, but it does not undo an earlier break-in. Attacks were logged from about 10 September, weeks before the public warning. If your app ran a vulnerable version while the document server was down, check for signs of compromise.

The advisory gives no detection steps, so use the checks affected admins reported in GitHub issue 354 and the Nextcloud forum. Nextcloud's own integrity check is the strongest, because it knows every file that should be in an app.

1. 1

   Run the integrity check

   Run sudo -E -u www-data php occ integrity:check-app richdocumentscode, then occ integrity:check-core for the server files. The manual says EXTRA_FILE means a file on disk is not in the signed list. A forum user found a planted file this way.

2. 2

   Look for unexpected PHP files

   Reporters found planted files named shx*.php and shrf*.php in apps/richdocumentscode, and a forum user found Nx_*.php there. Start in that folder, then look for recently changed PHP files elsewhere in the web root.

3. 3

   Review web server access logs

   Search access logs back to at least 10 September. Requests to proxy.php?status are normal polling, so do not panic at them. Flag ones whose path also has encoded dot-dot segments, and any request for an unfamiliar PHP file in the app folder.

4. 4

   Check for odd account activity

   One admin found the break-in only from failed sudo alert emails sent by the web server account. Look for sudo attempts or other actions by the www-data user that you did not expect.

5. 5

   Rotate anything the web user could read

   The first reporter in issue 354 advised treating anything the web server account could read as exposed. If you find a planted file, change every such secret, remove the file, and keep investigating.

Keep it to the mechanism and the lesson, not the payload. Walk through where the untrusted value travelled and which layer parsed it. These five steps give a clean frame.

1. 1

   Name the bug class

   Call it OS command injection, CWE-78. A request value reached a shell as a command, with no login needed, because proxy.php runs outside Nextcloud's guards.

2. 2

   Locate the exact slip

   The value was escaped with escapeshellarg, but then pasted inside a second double-quoted command. A shell parsed it again there, where the escaping did not apply.

3. 3

   State the trigger window

   It only fires while the local document server is down, during a restart, upgrade, or crash, because that is when proxy.php builds the start command.

4. 4

   Give the fix and the sturdier option

   Escape the whole inner command as one argument, as 26.4.303 does, or better, pass each value as a separate argument to a fixed script, as 26.4.402 does.

5. 5

   Draw the general lesson

   Know which layer parses your value. Escaping for a shell argument is useless once the value is embedded in another quoted command parsed by a shell.