Nextcloud Servers Were Backdoored Through Their Built-In Office App for 34 Days Before an Advisory Existed. It Is Still Not in KEV.
Nextcloud is what you run when you can't afford, or don't trust, the big cloud. Schools run it. Nonprofits run it. Ten-person firms run it on a box in the closet so their files stay theirs. And since September 10, some of those boxes have been quietly backdoored through the office suite that ships with them.
The flaw is CVE-2026-110447, an unauthenticated command injection in Collabora's "Built-in CODE Server" app for Nextcloud (the app ID is richdocumentscode). Collabora rates it critical, CVSS 4.0 score 9.2. The CVE record says it was exploited in the wild in September and October. The advisory came out yesterday, October 14. As of this morning it is not in CISA's Known Exploited Vulnerabilities catalog. We read the catalog ourselves: version 2026.10.14, 1,745 entries, no CVE-2026-110447 and no Nextcloud or Collabora entry at all.
If you run Nextcloud with the built-in office app, stop reading after the next section and go check. Then come back.
Are you affected? Check this first
You're exposed if all three are true: you run Nextcloud, you installed the app listed as "Collabora Online - Built-in CODE Server," and it's older than 26.4.303. Installations that use only the Nextcloud Office app (richdocuments) pointed at a separate Collabora server, in Docker, from a Linux package or at a hosting provider, are not affected, according to the advisory and The Hacker News.
Disabling the app does not fix it. That's Collabora's own advisory, word for word: "It is not sufficient to disable the app to avoid the problem, it must be upgraded to >= 26.4.303 or removed." The vulnerable file is a plain PHP script that your web server runs directly. Turning the app off inside Nextcloud doesn't stop the web server from running the file.
How the attack works
The app's proxy.php script starts the local document server whenever a request arrives and nothing is listening. In versions up to 26.4.302 it built that start command by dropping request text, path included, inside a double-quoted bash command. Bash still runs anything written as $(...) inside double quotes. So an attacker puts a shell command in the URL path, and the server runs it as the web server user.
There's one condition. The attack only works while the local document server is down: during a container restart, an upgrade or a crash. That sounds like a narrow window. On a small server that restarts on a schedule, or one that crashes when memory runs short, it isn't narrow at all.
What the administrators found
This was found by the people who run the servers, not by a vendor. On September 11 a Nextcloud administrator, GitHub user HeikoBw, opened issue #354 on Collabora's richdocumentscode repository with the title "Security issue - Hack." His servers ran 26.4.302. His access logs showed requests from 139.28.18.122 to /apps/richdocumentscode/proxy.php?status on September 10 and 11, using %2e%2e path traversal, $(...) command substitution and ${IFS} in place of spaces, with a base64 blob decoded and piped to sh.
The payload wrote a one-line PHP web shell into the app folder, with names like shxa35d0.php and shrf4645.php. It takes a command in a URL parameter and runs it. It then tried to send uname -a output to a webhook.site address, which told the attacker which server had fallen.
On one server the attacker went looking for money and keys: *.kdbx (KeePass vaults), wallet.dat, keystore.json, and folders like .bitcoin, .electrum, .monero and .ethereum, plus bitwarden and 1password. The reviewed requests showed no commands that copied files out, and none of the reports show root. HeikoBw's conclusion is the right one, though: anything the web server account could read should be treated as exposed.
Two more administrators reported break-ins in issues #355 and #356. One found it because Nextcloud's integrity check flagged a new PHP file. The other found it through emails about failed sudo attempts by the web server account. On September 14 a second IP, 89.38.98.50, tried the same trick against a server already on 26.4.303. No shell file appeared.
The fix shipped quietly. The warning took 34 days.
The fix was committed September 9 and shipped in 26.4.303 on September 11, one day after the first logged attack. It's four lines: the start command is now passed to bash as one escaped argument. The release notes mentioned only the bundled CODE build. There was no security notice.
On October 3 a member of the Nextcloud forum warned that the flaw was "already being exploited" and that "no warning or CVE has been published." The CVE and Collabora's advisory, credited to reporter wwwshellcodeit and published by Caolán McNamara, came on October 14. Collabora maintainer mmeeks pointed in the GitHub thread to a "record backlog" at GitHub's advisory database. That's 34 days from the first logged attack to an advisory a scanner could match on.
We don't think anyone was hiding anything. A fix that ships fast is good. But a self-hoster who updates when there's a security reason to update had no security reason until yesterday. That gap is where these servers fell.
Which version, exactly
26.4.303 is the fix. It needs Nextcloud 30 or later.
26.4.402 came out September 24 and rewrote the start command again. Administrators report it fails to start or fails to open documents on some setups, and some rolled back to 26.4.303. Rolling back to 26.4.303 is still patched. Rolling back further is not.
Nextcloud 29 and older are end of life and can't install 26.4.303. Per The Hacker News, the app store still serves them an affected version. Upgrade Nextcloud, or remove the app.
What to do today
All of this is free, and none of it needs us.
Upgrade or remove. richdocumentscode to 26.4.303 or later, or uninstall it. Not disable. Remove.
Look for shells, then delete them. List any file whose name starts with shx and ends in .php, beginning in your Nextcloud apps/richdocumentscode folder, then search the whole web root. Also look for shrf4645.php. The published shell's SHA-256 is 4b9fbd0663fbfd6028fc216ed18e0d6ef3ae498a7fdc97083e4b0ce3cec40562, but the file is one short line and trivial to change, so trust the file name and location over the hash. Collabora's maintainer also told users to remove leftover shx*.php files after upgrading.
Read your access logs back to September 10. Search for proxy.php?status requests whose path contains %2e%2e, $( or ${IFS}. Any hit before your upgrade date means assume compromise.
Check for sudo attempts by your web server user (www-data on Debian and Ubuntu) in the auth log.
Rotate what the web server could read. Database password in config.php, any API tokens, any vault or wallet file on that box.
Block [139.28.18.122](https://analytics.dugganusa.com/stix/register?ref=ioc-click&q=139.28.18.122) and [89.38.98.50](https://analytics.dugganusa.com/stix/register?ref=ioc-click&q=89.38.98.50), and search egress logs for webhook.site. Most small servers have no reason to talk to webhook.site at all.
One loose end. After upgrading, administrator UlliDieckmann reported processes still trying to create shx*.php files through the app's remote_font_config option. mmeeks said that output should be harmless. We'd still check that setting on any server that was hit before it was patched, because an attacker who got in first can leave configuration behind.
What we did, and what we can't see
This morning we ingested what the administrators published into our feed under source manual-batch-nextcloud-collabora-110447: the two IPs at confidence 80, the web shell hash at 90, and the two webhook.site callback tokens. Every record credits the GitHub reports and The Hacker News and says plainly that it's third-party reporting, not a DugganUSA observation. Both IPs are in our free ips.csv. The webhook.site domain itself is on our never-block list. It's a legitimate request-capture service, so the indicator is the per-token URL, never the whole site.
We make no lead claim here. We got these indicators the same way you could: by reading HeikoBw's issue and the Hacker News story.
And we have to be plain about our own instruments. We checked every edge sensor we have, the edge blocks, the edge canaries and the origin honeypot, for the richdocumentscode path and for both IPs, from September 1 to today. Zero hits across about 79,000 records. That zero isn't evidence nobody is scanning for this. We don't run Nextcloud and we had no canary for this path, so a scanner looking for Nextcloud had nothing on our side worth knocking on. A zero from a sensor that couldn't have fired is a gap, not a result.
Not in KEV is not low priority
This series keeps returning to one point. GitLab's GraphQL flaw was hitting honeypots while it was still out of KEV. On one day in August, 128 CVEs got public exploit code and only 19 were in the catalog. And KEV's date is the day CISA could confirm exploitation, not the day it started.
KEV is a federal mandate list. It's good, and it's free, and we lean on it every day. But it's built around what federal agencies run, and it adds a CVE only after the CVE exists, the exploitation is confirmed and the fix is clear. This one had a CVE for less than a day when we checked. The servers it hit belong to schools, nonprofits and small firms that will never appear in a federal patch deadline. If your patch queue sorts by "is it in KEV," this one sorts to the bottom while it's being exploited. Sort by "is it exploited, and do I run it" instead.
If this helped you check a server, or if you found something we didn't, rate this post with the widget at the bottom of the page. We read every response.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=nextcloud-servers-were-backdoored-through-their-built-in-office-app-for-34-days-before-an-advisory-e
Comments