Nextcloud and CVE-2026-110447: the hole opens when something goes down

On 14 October Collabora published the advisory for CVE-2026-110447: operating system command injection, with no authentication and no user interaction, in an optional Nextcloud app that plenty of people installed one afternoon so they could open documents in the browser. It scores 9.2 out of 10 on CVSS 4.0. It had been exploited since September, with webshells planted on the servers of companies that did not know they had it installed.

So far, just another advisory on an October Wednesday. What makes this one worth half an hour of your time is a sentence from the advisory itself, verbatim: "The attack only works while the built-in CODE server is not running. So on a container restart, an upgrade, or after a crash." The attack only works while the built-in document server is not running. On a container restart, on an upgrade, or after a crash.

Read it again with your calendar in mind. The exploitation window is your maintenance window. And the other two times it opens are the ones you write down nowhere: the process that died on Tuesday at three in the morning and came back by itself, and the one that died and did not come back.

Why the hole needs something to be down

The app is called Collabora Online - Built-in CODE Server (richdocumentscode) and it is the all-in-one version: instead of standing up a separate Collabora server, it puts the engine inside the Nextcloud installation itself. To talk to that engine there is a PHP middleman, apps/richdocumentscode/proxy.php.

That middleman has a courtesy that turns out to be the door: if nobody answers on the other side, it tries to start the engine itself. To start it, it builds a shell command line and, while building it, it drops in data that came from the request. If what came in the request has the shape $(...), the shell does not treat it as text: it runs it. And it runs it as the web server user, which is the user that can write into the apps directory.

Hence the precondition. If the engine is running, the middleman just forwards the request and builds nothing: no command, no injection. The hole is not a permanent state of the system, it is a transient one. And that is the uncomfortable part: that transient state is not caused by the attacker. You cause it, every time you update. Or the server causes it, when the process runs out of memory in the small hours.

A note for anyone who thinks they already patched this: the advisory spends a sentence making it clear. "This is not the same path as CVE-2025-66208, and the fix for that issue does not prevent it." It is not the same path as the earlier flaw in the same component, and having fixed that one does not cover you for this one.

The 9.2 carries a letter almost nobody reads

The full vector in the advisory is CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. The piece that almost never makes the news is AT:P: Attack Requirements: Present. It is a field CVSS 4.0 added for exactly this, to say the attack depends on a deployment or execution condition that is not always there. In other flaws, that AT:P is a reasonable comfort: the condition is rare, or it depends on a race you have to win by luck.

Not here. It is the clearest case we can remember where catching up on updates opens, for a few seconds, precisely the door updates are meant to close. It is not a deep paradox: it is a property of on-demand startup. What does change is how the number reads, because the 9.2 does not say how many times a month the condition occurs. Only you know that, and probably not even you.

Your monitoring says green

Think about what your monitoring actually watches on that machine today. Almost always: that port 443 answers, that the home page returns 200, that the certificate is not expiring, that the disk is not filling up. With the document engine dead, all four stay green. Nextcloud answers, people log in, files sync and the desktop client does not complain. The only thing that does not work is opening a document in the browser, and that almost never raises a ticket: it makes somebody download the file and open it on their laptop, which is what they would have done anyway.

It is the same pattern we have written about in another context: the job turns green and it skipped disks. Green on a dashboard does not say everything works; it says that what we measure works. We monitor with Zabbix and SmokePing and we have had the same obsession for years: the useful alert does not watch the front page, it watches the process. A check looking at whether the document engine has its socket listening would not have protected you from the CVE — the hole exists precisely while nobody is listening — but it would have told you something you do not know today: how many hours this month you spent in the vulnerable state.

The patch shipped as an ordinary release

The timeline:

During those thirty-three days, whoever kept up with updates was protected. But not by a decision: by accident. Nobody could prioritise a patch nobody had flagged as urgent. It mirrors something we covered a few weeks ago — the patch for your switch had been out 97 days — and it is worth not drawing the easy lesson. The easy one would be "always update everything blindly". The real one has a caveat: on 24 September 26.4.402 shipped and, according to one user quoted by IT-Connect, the CODE server stopped starting on installations whose PHP-FPM open_basedir does not allow /dev/null. Updating blindly is not free either.

Disabling is not uninstalling

The advisory devotes one line to this and it is the most important line for anyone in a hurry: "It is not sufficient to disable the app to avoid the problem, it must be upgraded to >= 26.4.303 or removed." Disabling the app is not enough: it has to be upgraded or removed.

"Disabled" is a state Nextcloud understands, not the web server. The file proxy.php is still on disk, inside the folder Apache or nginx serve, and it is still an executable PHP file reachable by URL. Whoever requests that file does not go through Nextcloud's app logic: they go through the PHP interpreter. The toggle in the admin panel turns the app off for your users, not for the internet.

If it already happened to you

Public reports from affected administrators and the technical coverage agree on what to look for. We have not responded to any of these incidents, so we pass it on as it stands, with its provenance: files named shx*.php or shrf*.php (the public report lists shxa35d0.php and shrf4645.php) inside apps/richdocumentscode, and in the access logs, requests to proxy.php?status since 10 September whose path contains %2e%2e, $( or ${IFS}. The addresses cited as associated with the activity are 139.28.18.122 and 89.38.98.50.

What they went looking for afterwards says a lot about who was on the other end, and about why this is not a "files" problem: password databases (.kdbx), credential manager folders, cryptocurrency wallets (wallet.dat, keystore.json). A company file server is, in fact, where people park their password manager file "while" they switch laptops. We covered that same lesson with another self-hosted tool: the data dashboard that was also the keyring. If you find something, the order is not "delete the webshell and move on": it is rotate credentials, because the access lasted as long as it lasted and you do not know how long.

When this is not your problem

We will say it early and plainly, because the alternative is somebody spending the afternoon hunting a flaw they do not have. It affects only the optional built-in CODE server app. It does not affect a separately deployed Collabora Online server — not in Docker, not with Linux packages, not hosted by a third party — nor the Nextcloud All-in-One deployment, nor Nextcloud Office if you never installed that app. If your installation falls in one of those boxes, close the tab: this one is not yours.

And something else we will not claim: how many servers are exposed. We have not measured it and there is no public figure: the number of affected servers is unknown, and the specialist press says it asked Nextcloud without ever publishing an answer. Nor is it, as of today, in CISA's Known Exploited Vulnerabilities catalogue: we checked against catalogue version 2026.10.16, 1,748 entries, and CVE-2026-110447 is not there. That catalogue has never set dates for a Spanish company — it binds US federal agencies — but it is the thermometer almost everyone checks. Here it marks nothing. Only the vendor advisory and the fact that it is already being used.

What we would do this week

1. Find out whether you have it, first of all. The question is not "do we use Nextcloud?", it is "is the built-in CODE server app installed, and on which version?". Those are two different questions and the second one almost never has an owner.
2. Upgrade to 26.4.303 or later, or remove it. If nobody edits documents in the browser — and in many places nobody does — removing it is the right call: less surface and one app less to maintain. Disabling it does not count.
3. Look back through the logs to 10 September for the patterns above, and in the app directory for files you did not put there. If something turns up, this stops being an update and becomes an incident with credential rotation.
4. Add a check on the process, not on the front page. Teach your monitoring to tell "the site answers" apart from "all the site's services are up". This does not fix the CVE: it fixes that you see the next silent outage before anyone else does.
5. And the question that generalises this to your whole estate: what other services do you have that start themselves on demand, when somebody asks for them? Those have a "stopped" state nobody has ever reviewed. This flaw is not about Nextcloud: it is about starting things on the fly with data that came from outside.

What we do, and what we do not claim

We are not resellers of any particular platform and this is not an argument against self-hosted software: we use it. We run containers in production on Docker Swarm and Kubernetes, with reproducible and reversible deployments from GitLab, and we have self-hosted tools in our own daily work — n8n, for instance — treated as what they are: production services, inventoried, with an owner and an update window. The difference between running your own document server and having a problem is not whether it is self-hosted; it is whether somebody has it written down, somewhere, that the piece exists and whose it is. That is half of the IT maintenance that actually helps.

And what we do not claim: we have not run the exploit, we have not responded to any of these incidents and we do not know how many systems are affected. The indicators above come from the public reports, not from our telemetry.

Sources (checked 17 Oct 2026): the sentence "The attack only works while the built-in CODE server is not running. So on a container restart, an upgrade, or after a crash", the sentence "It is not sufficient to disable the app to avoid the problem, it must be upgraded to >= 26.4.303 or removed", the 9.2 score with its full vector and the fixed version all come from the Collabora Online security advisory (GHSA-g3vx-3m76-fghh, 14 Oct 2026). The CWE-78 classification and the "as exploited in the wild in September and October 2026" come from the CVE-2026-110447 entry in GitHub's advisory database. The date and title of the 9 September commit, the timestamps of the first two documented attacks (10-09 19:51 and 11-09 09:56), the 26.4.302 version the victims ran, the 11 September release of 26.4.303 with no security mention, the startup problems of 26.4.402 on some PHP-FPM configurations, the IP addresses and the log patterns come from IT-Connect (15 Oct 2026). The shx*.php and shrf*.php webshell patterns and the subsequent hunt for password databases, credential manager folders and crypto wallets come from IT-Connect and Security Online; the specific file names and timestamps come from the public thread where affected administrators reported it. That there is no figure for affected systems, and that Nextcloud was asked for one, comes from BleepingComputer. The absence from CISA's Known Exploited Vulnerabilities catalogue we checked ourselves against catalogue version 2026.10.16 (1,748 entries). Ours, and we bound it: reading AT:P as a condition produced by your own change calendar, the argument for why disabling is not enough, the green-monitoring point, the five steps and the framing of "when this is not your problem" (the exact scope of what is unaffected comes from the advisory and BleepingComputer).