A critical command-injection flaw in Nextcloud's built-in Collabora CODE server, CVE-2026-110447, has been under active exploitation since mid-September — weeks before a formal advisory existed. For UK organisations running Nextcloud as a file-sync or backup-adjacent platform, this is a live incident, not a theoretical risk.
View the data behind this chart
| Phase | Starts (week) | Duration (weeks) |
|---|---|---|
| Silent fix, attacks underway | 0 | 3 |
| Community warning | 3 | 1 |
| Formal advisory & CVE | 4 | 2 |
What CVE-2026-110447 actually affects
The vulnerability sits in the richdocumentscode app — Nextcloud's optional built-in CODE server used to power in-browser document editing via Collabora Online — and impacts all versions before 26.4.303. It lives in the mechanism that starts the bundled Collabora process, and a malicious request to the app's proxy.php endpoint triggers OS command injection with no authentication or user interaction required.
Crucially, the flaw only affects the integrated, built-in CODE server app. Standalone Collabora Online deployments, Docker and RPM/DEB installations, and Nextcloud All-in-One setups are not vulnerable, according to Collabora. UK buyers running Nextcloud with a separate Collabora stack can rule themselves out of this specific issue — but should still verify which deployment model is actually in production, since mixed estates are common after migrations.
Why file-sync platforms are now backup-adjacent targets
Nextcloud is widely used across UK public sector, education and SME environments as a sovereign alternative to commercial cloud storage, often sitting alongside backup repositories and acting as a staging point for sensitive files. Attackers exploiting CVE-2026-110447 have planted PHP webshells and used them to hunt for password databases, password manager artefacts and cryptocurrency wallets — the kind of reconnaissance that typically precedes credential theft and lateral movement into broader infrastructure, including backup targets.
Some administrators have reported ransomware activity tied to this flaw, though BleepingComputer could not independently confirm it. Buyers should treat that as a plausible escalation path rather than confirmed fact, and plan accordingly — this is exactly the scenario where teams that prepare for incident response in advance recover faster than those improvising under pressure.
The disclosure timeline UK buyers need to understand
The fix was committed on 9 September and version 26.4.303 shipped on 11 September. Attacks against multiple endpoints were reported from 10 September onward — meaning exploitation began essentially alongside, or even before, the patch's public availability. A community warning followed on 3 October urging immediate updates, but without a CVE identifier, many administrators had no reliable way to confirm whether their environment was exposed. The formal advisory and CVE were not published until 14 October, over a month after the fix existed.
Nextcloud has said Collabora reported the issue in mid-September, that an update became available through the app store, and that the delay gave users time to patch without what it describes as widespread exploitation observed at the time. Collabora, for its part, attributed the delayed CVE publication primarily to processing backlogs it says are under strain from rising volumes of AI-driven security reports.
A wider pattern: CVE delays are getting longer
Research from Second Security, cited alongside this incident, found the median gap between a public fix and its corresponding CVE publication grew from 5.1 days in January to 39 days in August — a trend the firm links partly to AI-assisted vulnerability discovery straining CVE processing capacity. The researchers also found that working exploit code frequently appears online within hours of a fix, often days before the CVE itself is published.
For UK security teams, this matters operationally: vulnerability scanners and ticketing workflows that trigger off CVE IDs can miss weeks of real exposure. Teams that understand CVEs, CVSS, and KEVs and track vendor advisories and changelogs directly — not just CVE feeds — will close this gap faster than those waiting for a formal identifier.
What to do now
Nextcloud administrators should upgrade richdocumentscode to version 26.4.303 or later immediately, or remove the built-in CODE server app entirely if it isn't required — the vendor has explicitly warned that simply disabling the app is not sufficient protection. Given that the prerequisite for exploitation is the CODE server being stopped, any instance that has restarted, upgraded or crashed recently should be treated as higher risk and checked first.
Beyond patching, organisations should audit access and proxy logs back to 10 September for signs of webshell activity, unexpected PHP files, or unusual outbound connections, and rotate any credentials stored in password managers or wallets accessible from affected servers. This is also a good moment to strengthen your vulnerability management processes around app-store and plugin-based components, which often sit outside standard patch cycles.
Finally, verify that backup copies of Nextcloud data and configuration predate any suspected compromise window, and confirm those backups are isolated from the live environment. Teams that enhance your backup and disaster recovery posture — and better still, implement immutable backup architectures — reduce the chance that a webshell foothold turns into irrecoverable data loss.