CVE-2026-110447 affects Nextcloud installations running the Collabora Online built-in CODE Server app below version 26.4.303. A remote attacker can run operating system commands as the web server user when the embedded document server isn’t running. Public reports describe successful exploitation, PHP web shells, and searches for password databases and cryptocurrency wallet files.
The timing is what should worry administrators. The fix was released on September 11, 2026, but the formal GitHub security advisory didn’t appear until October 14. An issue in the project’s public repository reports exploitation going back to September 10. If you waited for a CVE notification before patching, you missed about a month of warning. (issue #354)
Affected software and severity
CVE-2026-110447 is an OS command injection vulnerability (CWE-78). Collabora’s official advisory gives it a CVSS v4.0 base score of 9.2, which is Critical. The affected component is richdocumentscode, the Nextcloud app that bundles Collabora Online Development Edition (CODE) and starts the document server locally when needed. Versions earlier than 26.4.303 are vulnerable, and 26.4.303 contains the fix. Exploitation needs no authentication and no user interaction. The vulnerable endpoint is apps/richdocumentscode/proxy.php, and the attack only works while the built-in CODE server is not running.
The advisory covers the built-in Nextcloud app and says standalone Collabora Online servers are not vulnerable to this issue. Check which component you actually run before assuming every Collabora deployment shares the exposure.
This is also a different bug from CVE-2025-66208, an earlier command injection in the same proxy component. The fix for that one does not stop CVE-2026-110447. (advisory)
How the vulnerable proxy works
Nextcloud’s Collabora integration lets users edit office documents in the browser. The built-in CODE Server app ships the document server alongside Nextcloud so you don’t have to deploy a separate Collabora server. Its proxy.php script sits between Nextcloud clients and the local document service, forwarding document requests to the CODE server, which normally listens on a local socket at port 9983.
The proxy also handles the case where the service is down. When the document server is unavailable, the PHP script can enter a path that starts the bundled server, and in the vulnerable version, request-controlled data can influence the operating system command used during that startup. An attacker can get the server to treat part of that data as shell syntax instead of an ordinary URL or configuration value.
No malicious office file is involved and nobody has to open anything. The attack goes straight at the server-side PHP proxy and its command-execution path.
Why the running state matters
The advisory says exploitation works only while the built-in CODE server is not running. A restart, an upgrade, or a crash can create that condition, and all three are routine maintenance events. None of them is a reliable security barrier.
So an installation can look fine for weeks and still be exposed during a short interruption. The attacker doesn’t have to cause the interruption either, only to send the malicious request while the startup path is reachable. A green Collabora status on your monitoring dashboard tells you the state at one moment. It says nothing about whether every reachable code path is safe.
📬 Stay Ahead of Cyber Threats
Get the latest cybersecurity news, critical vulnerabilities, threat intelligence, tutorials, and exclusive giveaways delivered straight to your inbox. No spam. Unsubscribe anytime.
Subscribe to the Newsletter →The command injection problem
PHP applications sometimes call operating system commands to start services or do maintenance, and that requires keeping the command itself strictly separate from any value derived from an HTTP request. The boundary that matters here includes the shell that receives the finished command, not only the PHP script.
Functions like escapeshellarg() can protect a value passed as a shell argument, but the quoting has to be correct for the complete command and every layer of shell interpretation. If input is escaped for one context and then dropped into another where expansion is still active, the protection can fail. Bash command substitution is the classic example. An expression like $(...) runs a command and substitutes its output into the surrounding expression, so if attacker-controlled text reaches a context where that syntax is live, the shell executes it before finishing the intended operation.
The public exploitation reports show command substitution, encoded path traversal, ${IFS} whitespace substitution, and Base64-encoded shell commands. Those are typical ways to get a shell to run commands while hiding their structure inside an HTTP request. The incident report includes examples of the malicious requests and what they did: issue #354.
The engineering takeaway is that escaping a value doesn’t make a process-launch interface safe. Where possible, applications should run executables with argument arrays instead of concatenating a shell command string. If a shell is unavoidable, the whole command has to be built so untrusted input can’t add shell syntax.
The fix is in 26.4.303. Use the patched app, and don’t try to reproduce the fix by hand-editing proxy.php. Local changes can be incomplete, get overwritten on upgrade, and are hard to validate against what the vendor intended.
What attackers did after exploiting the flaw
Issue #354 describes successful compromise of multiple Nextcloud installations running richdocumentscode 26.4.302. The requests targeted proxy.php?status, used shell-oriented payloads, and ended with PHP files written into the app directory. The issue also documents attempts to contact webhook.site and to collect information about the compromised systems. (issue #354)
Those PHP files worked as web shells, which are server-side scripts that let a remote party run commands through HTTP requests. If the web server can reach and execute such a file, the attacker keeps a way in even after the original vulnerability is patched.
The incident report names files such as shrf4645.php and shxa35d0.php, and other reports describe names beginning with shx. They’re useful starting points for an investigation, but not a complete signature, since attackers can change filenames, write to other directories, or delete files after use.
Post-exploitation activity included searches for KeePass databases (*.kdbx), crypto wallet files such as wallet.dat and keystore.json, and artifacts tied to Bitwarden, 1Password, Bitcoin, Monero, and Ethereum. The operators were clearly after credentials and financial assets, though a search command alone doesn’t prove any particular secret was stolen.
The IP addresses 139.28.18.122 and 89.38.98.50 appear in the public reports, along with the outbound requests to webhook.site. Treat them as leads for reviewing historical logs, not as attribution, and correlate them with timestamps, request contents, process activity, and file changes before concluding anything.
Some reports raise the possibility of ransomware. The evidence cited here doesn’t show that all or even some of these intrusions were run by ransomware operators. What’s confirmed is exploitation, web-shell deployment, and attempts to locate valuable files.
The disclosure timeline
According to the incident timeline, a fix was committed to the richdocumentscode repository on September 9, 2026. The public incident report records successful exploitation attempts on September 10. Version 26.4.303 was released with the fix on September 11, as the project changelog shows, and Collabora published the formal advisory on October 14. The public issue contains requests timestamped September 10, so exploitation reports came before the advisory, and a patched release came before both. (issue #354)
That gap matters because many vulnerability management workflows start from a CVE feed. Scanners match on CVE identifiers, and change-control processes often want a vendor advisory before approving an emergency update. A missing identifier slows all of that down, even when the fix is already out. It doesn’t mean the release is unrelated to security, though. Administrators who watch changelogs, release announcements, repository commits, and vendor security pages get more chances to catch an important change early.
That doesn’t mean every commit deserves an emergency patch. It does mean that an unexpected security-relevant change in a widely deployed, internet-facing component is worth investigating. I can’t say why the advisory trailed the fix by a month, and these dates alone don’t tell us. Any claim about the cause, or about industry-wide CVE processing times, would need its own sources.
How to tell whether your Nextcloud installation is affected
Start by finding out whether the built-in CODE Server app is installed and which version is running. In the Nextcloud admin interface, open Apps and look for “Collabora Online – Built-in CODE Server.” Anything earlier than 26.4.303 is affected.
The app version is what counts. Being able to edit documents with Nextcloud Office in the browser doesn’t tell you which setup you have, because some deployments use a separate Collabora Online server instead. Those need to be assessed against their own architecture and versions.
Check compatibility before you upgrade. The advisory warns that installations on end-of-life Nextcloud 29 or earlier should upgrade Nextcloud or remove the vulnerable app, and an installation that can’t take the fixed version shouldn’t sit exposed until the next routine maintenance window.
You can send a request to the proxy endpoint to see whether the route responds, but that can’t prove the code is vulnerable or the host is clean. A response from proxy.php?status is not a clean bill of health, since the documented exploit targeted that very endpoint.
Immediate remediation
Upgrade richdocumentscode to 26.4.303 or later, or remove the app if you don’t need it. Disabling it in the Nextcloud interface is not enough, because the vendor warns that the vulnerable PHP script can execute directly without loading the application framework. (advisory)
If you can’t upgrade right away, you can reduce exposure by blocking external access to /apps/richdocumentscode/proxy.php at the reverse proxy or web server. That’s a stopgap and doesn’t replace patching. Test the rule against your real URL layout instead of copying it blindly. An instance hosted under /cloud/ may expose the endpoint at /cloud/apps/richdocumentscode/proxy.php, and a rule that only matches the root-level path would leave it open. Make sure legitimate internal document-editing traffic still works.
After updating or removing the app, confirm the installed version and review the application and web server logs for unexpected requests. Updating doesn’t delete files an attacker created beforehand.
investigate before declaring the system clean
Treat any installation that ran a vulnerable version as possibly compromised, especially if the CODE server restarted, crashed, or was upgraded in that window. Exploitation attempts are documented from September 10, 2026, so that’s a reasonable start date for log review, adjusted for your own exposure window.
Search for unexpected PHP files
Look in the built-in CODE Server app directory for PHP files that aren’t part of the official distribution. On a typical installation the path looks like this:
find /var/www/nextcloud/apps/richdocumentscode \ -type f -name '*.php' -newermt '2026-09-01'
Then search for the filenames from the incident:
find /var/www/nextcloud/apps/richdocumentscode \ -type f \( -name 'shx*.php' -o -name 'sh*.php' \)
The second command is deliberately broad and can return legitimate files, so treat the output as candidates. Compare each suspicious file with the official package, its ownership and permissions, its modification time, and your backups. Don’t execute a suspected web shell to test it.
Nextcloud’s integrity check can also surface unexpected files. An EXTRA_FILE finding inside the app directory deserves a close look, particularly when the name and timestamp match the reported pattern.
Review web server access logs
Search historical access logs for requests to the vulnerable endpoint, especially ones with encoded traversal sequences or shell syntax:
grep -E 'richdocumentscode/proxy\.php.*(%2e%2e|%24%28|\$\(|IFS|base64)' \ /var/log/nginx/access.log
That’s a first-pass filter, not a detector. Encoded characters can vary, and reverse proxies or frameworks may normalize URLs before they’re logged. Apache setups and rotated or compressed logs need equivalent searches wherever your logs actually live.
Read the original requests around any suspicious timestamps. Look for $(...), %2e%2e, ${IFS}, and Base64 command patterns, and line them up with periods when the built-in CODE server was starting or down. Then check whether PHP files appeared shortly afterward. A request matching a known payload shows an attempted exploit. A matching web-shell file, suspicious process, or outbound connection is much stronger evidence that it worked. And a missing match in one access log doesn’t rule out compromise if your logs are incomplete or requests passed through other components.
Inspect processes and outbound connections
On a live host, check what’s running under the web server account for unexpected shells or child processes. A basic listing is a place to start:
ps auxww
PHP applications can launch subprocesses legitimately, so a process name proves nothing by itself. Parent process, command line, start time, open files, and network connections are more useful.
Check outbound traffic for requests to webhook.site and for connections involving the IPs from the public reports, using DNS, firewall, proxy, and endpoint logs where you have them. These indicators are historical leads that may go stale or get reused, and they aren’t a full list of attacker infrastructure.
Rotate credentials and recover safely
A web shell running as the web server user can read whatever that account can read. Depending on your permissions, that may include Nextcloud’s config/config.php, database credentials, application secrets, stored app passwords, and other readable config files. The real impact depends on the account’s privileges and the host’s filesystem permissions.
If you confirm a compromise, isolate the host where practical, preserve logs and forensic evidence, and remove the attacker’s access through a controlled recovery. Once the host is contained, rotate the credentials that may have been exposed, including database passwords and application secrets, with a plan for updating the services that depend on them. Review access to external services and any credentials the web server account could reach.
Deleting a suspicious PHP file is not a complete solution. The attacker may have created more files or scheduled tasks, modified application code, or obtained credentials that allow later access. If you can’t establish the extent of execution, rebuilding from a known-clean source and restoring verified data is safer than hoping an in-place cleanup caught every persistence mechanism.
What this means for administrators
Optional apps belong in your vulnerability inventory. Tracking a server as just “Nextcloud” doesn’t tell you which apps are installed, which versions they run, or which of their endpoints face the internet. The built-in CODE Server app has its own release history and its own security requirements.
The incident also shows the limit of relying on CVE notifications alone. The patch came first, exploitation reports came next, and the advisory arrived last. Watching vendor releases and security-relevant repository changes can shrink the time between a fix existing and you applying it.
Patching and incident response are two separate jobs. Upgrading to 26.4.303 or later closes the known vulnerable path, but it can’t tell you whether a web shell was planted earlier. You have to check both the software version and the system’s history.
Frequently asked questions
Is CVE-2026-110447 being exploited in the wild?
Yes, going by public reports in the project’s issue tracker. They describe successful exploitation of Nextcloud installations running vulnerable versions of richdocumentscode, including the creation of PHP web shells. They don’t establish the full scale of the activity. (issue #354)
Does disabling the Collabora app stop the vulnerability?
No. The advisory says disabling the app is insufficient because the vulnerable proxy.php script can execute directly. Upgrade to 26.4.303 or later, or remove the app.
Are standalone Collabora servers affected?
The advisory says standalone Collabora Online servers are not affected by this specific vulnerability. Confirm your deployment type before applying remediation meant for the built-in Nextcloud app.
Does an attacker need a Nextcloud account?
No. The advisory lists no required privileges and no user interaction. Exploitation depends on the built-in CODE server being stopped when the malicious request hits the vulnerable code path.
Does the fix for CVE-2025-66208 also fix this issue?
No. Collabora identifies CVE-2026-110447 as a different vulnerable path, so you need richdocumentscode 26.4.303 or later.
Is upgrading enough if the server was previously exposed?
No. Upgrading removes the known entry point, but it doesn’t remove a web shell or undo credential exposure. Review the filesystem, historical logs, processes, and outbound connections, then rotate affected secrets if you suspect or confirm a compromise.
Conclusion
CVE-2026-110447 is a critical command injection in the Nextcloud Collabora Online built-in CODE Server app. According to the official advisory, an unauthenticated request can run operating system commands as the web server user while the embedded CODE server is stopped, and public incident reports document exploitation and PHP web-shell deployment before the advisory was published. Upgrade richdocumentscode to 26.4.303 or later, remove the app if you don’t need it, and investigate any system that ran a vulnerable version. A missing CVE identifier doesn’t make a known fix less urgent.
