Nextcloud Servers Backdoored: Collabora Flaw CVE-2026-110447

Hackers Exploit Critical Collabora Online Flaw to Backdoor Nextcloud Servers (CVE-2026-110447)

Quick Answer
Attackers are abusing CVE-2026-110447, a critical flaw in Nextcloud's Collabora Built-in CODE Server app, to plant web shells. Update richdocumentscode to 26.4.303 or later, or remove it, then hunt for leftover shx*.php files.

Last verified: October 18, 2026. This story is still developing, so check the vendor advisory for updates.

Picture a routine Friday-night maintenance window. An admin restarts the container that hosts the company's self-hosted file-sharing platform, goes to get coffee, and comes back to a healthy dashboard. Nothing looks wrong. But during the few seconds the document server was down, a single unauthenticated request may have been all an attacker needed.

That is the shape of the Nextcloud security vulnerability now tracked as CVE-2026-110447. (This is an illustrative scenario, not a reported incident.) Below I walk through what is confirmed, how to check your own servers, and how to harden self-hosted collaboration stacks so one optional app can't become your weakest link.

Table of Contents

• What Happened and What Is Confirmed
• Why the Flaw Works Only at Certain Moments
• Timeline: A Patch Without a Warning
• Who Is and Is Not Affected
• Key Indicators of Compromise
• Verification and Hunting Commands
• If You Find a Web Shell: Incident Response Steps
• Web Shell Detection and Long-Term Hardening
• Expert Tips from a SOC Perspective
• FAQ
• Conclusion

What Happened and What Is Confirmed

According to the GitHub advisory and Collabora's own security advisory, CVE-2026-110447 is an operating system command injection flaw (CWE-78) in the Collabora Online Built-in CODE Server app for Nextcloud, packaged as richdocumentscode. It carries a CVSS v4 score of 9.2. Every version before 26.4.303 is affected.

The CVE record states the flaw was exploited in the wild in September and October 2026. Reports from The Hacker News and BleepingComputer describe attackers dropping PHP web shells on compromised servers. A web shell is a small server-side script that lets an attacker run commands through ordinary web requests, usually with the privileges of the web server account.

What is not confirmed: no threat group has been publicly named, and the number of compromised servers is unknown. Treat any attribution you see online as speculation unless it cites a primary source.

Why the Flaw Works Only at Certain Moments

The Built-in CODE Server app downloads a copy of Collabora Online Development Edition and runs it on the same machine as Nextcloud. That lets Nextcloud Office edit documents without a separate Collabora server, which is convenient for small deployments.

Per the published analysis, the vulnerable file is proxy.php. It is a plain PHP script that the web server runs directly from the app folder, without loading any Nextcloud code. So Nextcloud's own authentication and request handling never get a chance to inspect the request.

When a request arrives and no CODE server is listening, the script starts one. Researchers say the request data reached the shell unsafely at that step. That explains the unusual precondition: exploitation depends on the built-in CODE server not running when the malicious request lands.

In practice that window opens during a container restart, an upgrade, or a crash. Routine maintenance becomes the attack surface, which is why I'd call this a patch-management lesson as much as a bug.

Commands run as the web server user (often www-data), not automatically as root. That is still serious. Anything the web server account can read, including configuration files, stored credentials, and user data, should be considered exposed on a compromised host.

Timeline: A Patch Without a Warning

The sequence of events is a case study in why "no CVE yet" must never mean "no urgency." Dates below come from The Hacker News, BleepingComputer, and the WZ-IT timeline. Sources differ slightly, noted where relevant.

Date (2026)	Event
Sept 10	Earliest logged attacks reported by administrators on GitHub (BleepingComputer describes activity as "mid-September")
Sept 11	Collabora ships version 26.4.303 (WZ-IT lists Sept 14 as the date the fix was confirmed)
Sept 18	Collabora advises deleting leftover shx*.php files in addition to updating
Sept 29	Operators ask in the issue tracker for a CVE number
Oct 3	Nextcloud community forum post warns the flaw is already being exploited
Oct 14	CVE and GitHub advisory published, roughly four to five weeks after the patch

The 26.4.303 changelog reportedly listed only a new AppImage version, with no security note. BleepingComputer reports that Collabora attributed the delay mainly to GitHub CVE-processing backlogs, which it said were strained by a rising volume of AI-driven security reports.

The takeaway for SOC and IT teams: apply app updates on a schedule, independent of whether a security bulletin exists. Waiting for a CVE ID would have left defenders exposed for weeks.

Who Is and Is Not Affected

Setup	Status
richdocumentscode before 26.4.303	Vulnerable
richdocumentscode 26.4.303 or later	Entry point closed, but an already-planted web shell remains
Standalone Collabora Online server	Not affected, per Collabora
Docker, RPM/DEB installs, Nextcloud All-in-One	Not affected, per Collabora (via BleepingComputer)
Nextcloud 29 or earlier	Cannot install the fixed app; upgrade Nextcloud or remove the app

Two details trip people up. First, disabling the app is not enough. Collabora says it must be updated or removed, because the script can still be reached directly from the web server. Second, the earlier fix for CVE-2025-66208, a separate command injection in the same script, does not protect against this one.

Key Indicators of Compromise

Public reporting points to a small set of artifacts worth checking first:

• Unexpected PHP files named shx*.php or shrf*.php inside apps/richdocumentscode/
• Web server access log entries for /apps/richdocumentscode/proxy.php, especially from addresses that have no reason to touch your document server
• Requests that reference the odd PHP filenames above
• Version 26.4.302 or older still installed on any host
• Recent modification times on PHP files in the app directory that don't match your update history

Reports also say attackers searched for password databases and cryptocurrency wallet files. That suggests opportunistic credential hunting rather than a targeted campaign, though that is an inference, not a confirmed finding.

Verification and Hunting Commands

These are read-only checks to run on the Nextcloud host. Adjust paths to your install and web server. Run them as an administrator.

1. Check whether the app is installed and which version. Use this first on every Nextcloud host you own. Expect a line showing richdocumentscode and its version, or no output if it isn't installed.

sudo -u www-data php occ app:list | grep richdocumentscode

2. Look for suspicious web shell filenames. This searches the app folder for the shx and shrf patterns named in public reporting. Expect no output on a clean system; any match needs investigation.

find /var/www/nextcloud/apps/richdocumentscode -name 'sh[xr]*.php'

3. Review recent PHP file changes in the app folder. This lists PHP files changed in the last 60 days so you can compare against your update history. Expect only files that match your last app update.

find /var/www/nextcloud/apps/richdocumentscode -name '*.php' -mtime -60 -ls

2. Search access logs for requests to the affected paths. Use zgrep so rotated logs are included. The log path below is an example for Apache; Nginx and custom setups differ. Expect legitimate hits to proxy.php from your own users, so look for odd source IPs, odd request shapes, or hits to filenames that shouldn't exist.

sudo zgrep -hE 'richdocumentscode/(proxy\.php|sh[xr][^ ]*\.php)' /var/log/apache2/access.log*

Update or remove the app. Run one of these only after you've completed the checks above if you suspect compromise, so you don't destroy evidence. Updating needs Nextcloud 30 or later for the fixed versions. Warning: removing the app disables built-in document editing until you deploy a replacement.

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

If You Find a Web Shell: Incident Response Steps

Updating closes the entry point, but it does not remove a shell that is already on disk. If you find one, treat the host as compromised and follow your incident handling process (NIST SP 800-61 is a solid general reference).

1. Contain. Restrict inbound access to the server or take it off the public internet while you investigate.
2. Preserve evidence. Copy the suspicious files, hash them, and save the web server logs before deleting anything.
3. Remove and patch. Delete the shells, then update or remove the app.
4. Rotate secrets. Assume anything the web server account could read is exposed: database credentials, instance secrets, external storage credentials, and API tokens.
5. Hunt for persistence. Check for other unexpected PHP files, new admin accounts, scheduled jobs, and changed configuration.
6. Assess data exposure. If personal or regulated data was reachable, involve your privacy and legal teams early. Breach notification obligations under rules like GDPR or HIPAA depend on your facts, so this is a question for counsel, not a blog post.

Web Shell Detection and Long-Term Hardening

This incident shows how an optional component can undermine an otherwise well-run server. A few controls reduce the risk of the next one:

• Separate the document server. Collabora says standalone deployments are not affected. Moving to a standalone or containerized Collabora server also keeps vulnerable code away from the web server's file system.
• Treat third-party apps as attack surface. Keep an inventory of installed Nextcloud apps and remove what you don't use. The affected app is reportedly meant for testing and non-production use.
• Monitor file integrity. Alert on new PHP files appearing in application directories. This catches web shells regardless of which bug dropped them.
• Restrict execution paths. Where your setup allows it, block direct web access to app scripts that don't need to be public.
• Use endpoint detection. Modern EDR and server monitoring tools can flag a web server process spawning shells or unusual child processes, a classic web shell behavior.
• Patch on a cadence. A weekly or biweekly app-update routine would have closed this hole before the advisory ever appeared.

Expert Tips from a SOC Perspective

• Don't wait for a CVE. Community forums and GitHub issues often carry the first warning. Put them in your monitoring rotation for software you run.
• Correlate restarts with web traffic. Alert on requests to app scripts that happen right after a container restart or upgrade. That timing is exactly what this flaw depends on.
• Look at what the web server process runs. A PHP-serving account launching shell commands is rarely normal. Process-creation telemetry makes that visible quickly.
• Check every host, not just production. Admins who run several Nextcloud servers reportedly found shells on multiple machines with the same version.
• Be careful with "clean" verdicts. No shx*.php files today does not prove nobody got in earlier. Review logs back to early September.

Related Cybersecurity Topics You Should Explore

• Linux killall Command: 31 Examples & Safe Usage Cheat Sheet
  
• Linux pkill Command Cheat Sheet: 40 Safe Examples + pgrep Tips
  
• Linux Kill Command Cheat Sheet: 37 Examples for SOC Teams
  
• Linux htop Command Cheat Sheet: Spot Hidden Threats in Seconds
  
• Linux top Command Cheat Sheet: Find Suspicious Processes Fast
  
• Linux ps Command Cheat Sheet: 41 Examples SOC Analysts Use
  
• Linux ps Command Cheat Sheet: 41 Examples SOC Analysts Use
  
• Linux findmnt Command: 43 Examples for Security Audits
  
• Linux tune2fs Cheat Sheet: 41 Commands, 4 Costly Mistakes
  
• Linux blkid Command: 41 Examples Every SOC Analyst Should Know

FAQ

What is CVE-2026-110447?

It is a critical OS command injection flaw (CVSS v4 9.2) in the Collabora Online Built-in CODE Server app for Nextcloud. It lets an unauthenticated attacker run commands as the web server user under specific conditions.

Which versions are affected?

All richdocumentscode versions before 26.4.303. Standalone Collabora Online servers are not affected, per Collabora.

Is turning the app off enough?

No. According to Collabora, the app must be updated or removed. Disabling it in the Nextcloud interface does not close the vulnerable entry point.

I already updated. Am I safe?

The entry point is closed, but a web shell planted earlier would still be there. Check for shx*.php and shrf*.php files and review your logs.

Does the attacker get root access?

Commands run as the web server user, not automatically as root. No root compromise has been reported, but data readable by that account should be treated as exposed.

I run Nextcloud 29 or older. What should I do?

Those versions can't install the fixed app. Upgrade Nextcloud to a supported release or remove the affected app.

Conclusion

CVE-2026-110447 is a reminder that the dangerous bug is often in the optional piece you installed once and forgot. A fix shipped weeks before the advisory, and attackers had that gap to work with.

Your next steps are simple: confirm the app version, update to 26.4.303 or later or remove it, hunt for leftover shells, and rotate credentials if anything turns up. Then consider moving to a standalone Collabora server so this class of bug stays off your web host.

If this was useful, subscribe for more practical threat breakdowns, share it with whoever runs your self-hosted stack, and drop a comment if you've seen suspicious activity worth discussing.

Analysis based on SOC monitoring and public threat intelligence review.