A flaw that only opens during maintenance
Nextcloud is the self-hosted alternative teams choose specifically because they want their files and data under their own control rather than a vendor's cloud. Many of those deployments bundle Collabora Online's Built-in CODE Server, delivered through an app called richdocumentscode, so users can edit office documents in the browser without leaving the platform. CVE-2026-110447 lives in that add-on's proxy.php file, which starts a local document-editing server whenever a request comes in and the server is not already running.
The bug is that proxy.php placed part of the incoming request path inside a double-quoted bash command without sanitizing it. An unauthenticated request containing a command substitution payload could therefore execute arbitrary commands as the web server user, but only in the specific moment the local CODE server was down, such as during a restart, an upgrade, or a crash. That is a narrow window, but it is also exactly the moment IT teams are least likely to be watching closely, which is what made it exploitable in practice rather than just in theory.
From command injection to a planted web shell
Once an attacker could run a command, the next step was simple: decode a one-line PHP web shell and drop it into the app's own folder. From there, every future request to that shell let the attacker run whatever command they wanted, no further injection required. Logs reviewed by the people who found the attacks showed the intruders searching compromised servers for credential stores and cryptocurrency wallets, which points to opportunistic, financially motivated activity rather than a targeted espionage operation.
The good news, such as it is, is that reviewed logs showed no archiving or exfiltration commands at the point of discovery. The caveat matters more than the good news: the people who found this advise treating anything the web server account could read as potentially exposed, because a web shell that has not visibly exfiltrated data yet is still a standing door into whatever that account can touch, including configuration files and database credentials stored alongside the application.
A patch that did not read like a patch
The timeline here is the uncomfortable part. Collabora wrote the fix on August 20, 2026, but released version 26.4.302 eleven days later, on August 31, without it. The actual fix was committed on September 9 and shipped the next day in version 26.4.303, with release notes that named only the bundled CODE build update, not a security vulnerability. Any administrator scanning changelogs for the word 'security' before prioritizing an update would have had no reason to move this one to the top of the queue.
The first logged attack came the same day the fix shipped, September 10 at 19:51 local time, meaning attackers were ready to exploit this before most defenders even knew there was something to defend against. A second attempt hit an already-patched server on September 14 but produced no new shell file, which suggests attackers kept probing even after the window closed for some installations. A formal CVE record and advisory did not appear until October 14, more than a month after the silent fix shipped.
Disabling the app was not enough
Collabora's own advisory makes an unusual and important point explicit: turning off the richdocumentscode app does not close this hole. The vulnerable code in proxy.php still exists on disk and can still be triggered, so the only real fix is upgrading to version 26.4.303 or later, or removing the app entirely. Administrators running Nextcloud 29 or older face an additional wrinkle, since the fixed versions require Nextcloud 30 or later, turning what looked like a small office-add-on patch into a platform upgrade project.
This is a useful reminder that disabling a feature is a conditional incident-response step, not a universal one, and it only works when the vulnerable code actually stops running as a result. For data platforms specifically, where the whole point is that the organization, not a vendor, is responsible for operating the software securely, that responsibility includes knowing which mitigations are cosmetic and which actually remove the attack surface. This flaw punished anyone who assumed disabling an app automatically achieved the same result as patching it, a distinction that only becomes obvious once someone reads the advisory closely.
Found by admins, not by a scanner
Three Nextcloud administrators independently reported the attacks on GitHub before any formal disclosure existed, long before Collabora's advisory or a CVE record gave the problem a name. One administrator ran several servers and noticed the same odd pattern across them, which is how a one-off anomaly turned into a reportable trend. Another caught it because Nextcloud's own built-in integrity check flagged an unexpected new PHP file sitting in the application directory, exactly the kind of low-tech control that caught what a vulnerability scanner tuned to known CVEs would have missed entirely, since no CVE existed yet to scan for.
That detail is worth sitting with. Integrity checking, the simple practice of knowing what files are supposed to exist in your application and alerting on anything new, caught a zero-day that bypassed every patch-based defense, because there was no patch to check against yet. Any team running self-hosted data infrastructure should treat file integrity monitoring as a baseline control that earns its keep precisely because it does not depend on the vendor having already named the problem, a property patch-based scanning simply cannot offer on day one of an unknown attack.
The decision this forces on data platform owners
Self-hosting your data platform is a deliberate trade: you give up a vendor's security operations center in exchange for control over where your data lives and how it is handled day to day. That trade only pays off if your own patch management treats every release as a potential security release, not just the ones labeled as such, because this incident shows that labeling cannot always be trusted to flag the ones that matter most. A changelog entry about a bundled component update was, in this case, the only public signal that a maximum-impact remote code execution path had just been closed.
The practical takeaways are concrete: read patch notes with suspicion rather than trust, keep integrity monitoring running on anything that touches your document or data layer, and budget for the platform-version upgrades that a point patch sometimes quietly requires. Nextcloud and Collabora did eventually fix this and document it properly, but the month between the silent patch and the public advisory is exactly the gap attackers are now trained to exploit. Closing that gap on your own schedule, through your own monitoring and patch discipline, is the only reliable substitute for waiting on a vendor's advisory calendar.
