Hosting and security
Patching without waiting for the CVE
The Collabora flaw in Nextcloud was exploited a month before its CVE appeared. Update what faces the internet on a fixed schedule, not after an advisory.
A critical flaw in the built-in Collabora server for Nextcloud was exploited from 10 September, while the CVE only appeared on 14 October. Administrators who waited for an advisory were a month behind. My advice is to update everything you host yourself that faces the internet on a fixed schedule, CVE or no CVE.
What happened
The flaw is in Collabora Online's Built-in CODE Server app for Nextcloud, technical name richdocumentscode. A request to proxy.php let anyone run a command as the web server user, without logging in. Collabora rates it 9.2 on CVSS and it is tracked as CVE-2026-110447.
There is one condition. The attack only works while the built-in CODE server is not running, for example after a container restart, an upgrade or a crash.
The timeline shows the problem. According to BleepingComputer, the fix was committed on 9 September and version 26.4.303 was released on 11 September. In the project's GitHub issue, administrators reported the first attacks on 10 and 11 September. The advisory and the CVE followed on 14 October.
What the attackers did
The attackers dropped PHP files with names like shx*.php into the app's folder. These are web shells: small scripts that let them run any command afterwards. On one server they used the web shell to search for password manager databases and cryptocurrency wallets.
The administrators in the issue drew the right conclusion. Anything the web server user can reach should be treated as exposed. On a Nextcloud server that is a lot: users' files and the configuration of Nextcloud itself.
Why the CVE came so late
Collabora mainly blames GitHub. According to Collabora, the time to request and publish a CVE there grew this year from about a day to many weeks. Collabora itself received a large volume of security reports from AI tools, of mixed quality, and is now applying to issue its own CVEs.
The problem is wider than Collabora. Second Security looked at 18,594 open source CVEs from January to August 2026 and measured the time between the first public fix in the code and the CVE. In January the median was 5.1 days, in August 39.2 days. The fastest tenth of public exploits appeared 1.8 days after the fix.
Anyone who sees a fix in a public repository can turn it into an exploit. An attacker has no reason to wait for the CVE, and neither do you.
What this means for your team
A scanner that watches CVEs only sees a flaw like this once the CVE exists. With Collabora, that was a month after the first attacks. If you run Nextcloud, GitLab, a wiki or any other package with plugins yourself, you need a schedule that does not depend on that feed.
When 26.4.303 came out, administrators in the issue were still asking what exactly it fixed, because the release notes mentioned no security fix. So you cannot rely on release notes either. Update because there is a new version, not because it comes with a reason.
Where I would start
First, list everything you host yourself that can be reached from outside, including the apps and plugins running inside it. The Collabora flaw was in an optional app, not in Nextcloud itself.
Then put a fixed update slot in the planning, for example weekly for everything that faces the internet. For a package like Nextcloud, automatic updates for apps and plugins are often wiser than waiting until someone has time.
Remove what you do not use. With this flaw, Collabora says disabling the app was not enough; only updating or removing it helped. An app that is not installed cannot be exploited.
Where you can, choose the installation method the vendor recommends. According to Collabora, the built-in CODE server is not the recommended route, and the Docker images and packages were not affected.
Finally, limit what the web server user can reach. No password vaults, keys or backups on the same server, and no tokens with more rights than they need. I wrote about keeping backups separate in backups and disaster recovery.
If you had the app running
Update to 26.4.303 or later, or remove the app. On Nextcloud 29 or older, the advisory only lists upgrading Nextcloud or removing the app.
Then check for unknown PHP files in the richdocumentscode folder, such as shx*.php, and search your logs for requests to proxy.php. One administrator in the issue found the first trace through Nextcloud's integrity check, which flagged an unknown PHP file.
If you find something, treat the server as compromised. Replace the passwords and tokens that were on it and preferably rebuild the server from a clean base. What other major incidents teach about this is in lessons from well-known hacks. If you are unsure whether to host it yourself at all, read Vercel or self-hosting as well.
Sources
Frequently asked questions
Which Nextcloud installations are vulnerable to CVE-2026-110447?
Only installations running Collabora Online's Built-in CODE Server app (richdocumentscode) below version 26.4.303. According to Collabora, standalone Collabora servers, the Docker images, RPM and DEB packages and Nextcloud All-in-One are not affected.
Is disabling the app enough?
No. Collabora's advisory says disabling does not help. Update to 26.4.303 or later, or remove the app. On Nextcloud 29 or older, upgrade Nextcloud or remove the app.
Why can't you wait for the CVE?
The time between a public fix and the CVE is growing. Second Security measured a median of 5.1 days in January 2026 and 39.2 days in August, while the fastest public exploits appeared within two days of the fix.
About the author
Aleksa
Tech lead, Belgrade
Aleksa is tech lead in Belgrade. He leads the development team, oversees the architecture and reports to Erik.
More from Aleksa
