Nextcloud servers were backdoored through Collabora's Built-in CODE Server for a month before it had a CVE.

A fix without a CVE is invisible to most patch programs

For 33 days in September and October, attackers were planting webshells on Nextcloud servers through a bug that already had a fix, and almost no patch program could see it. The fix shipped in a routine app update whose notes said nothing about security. No advisory, no CVE ID, no scanner signature. If your vulnerability management keys on CVE IDs, and nearly all of it does, this flaw did not exist for you until 14 Oct.

That is the lesson worth taking from CVE-2026-110447, and it is bigger than one Nextcloud app. A CVE is a record of a disclosure, not a record of a vulnerability. The two can sit weeks apart. Collabora committed the fix on 9 Sep, the first malicious requests in one administrator's logs date from 10 Sep, and the fixed release went out on 11 Sep. Everything a defender needed to act was public by mid-September, in a GitHub issue where administrators reported being hacked, and later in a community forum thread. None of it was in the feeds that drive patching.

The app itself makes the point sharper. The Built-in CODE Server, richdocumentscode, is the convenient way to get document editing into Nextcloud: install one app from the app store and it fetches and runs a copy of CODE, the Collabora Online Development Edition, next to your Nextcloud. Convenience components like that tend to get installed once, forgotten, and left on the internet. They also tend to sit below the layer that asset inventories track. A scanner that knows you run Nextcloud 31 may have no idea which of the hundreds of store apps you added.

CVEs still matter, and the KEV listing that followed on 23 Oct is exactly the signal a busy team needs. The argument is narrower. For self-hosted applications with plugin ecosystems, a CVE-only patch process has a blind spot measured in weeks, and attackers are already working inside it. Closing it means watching the components, not just the catalogues.

What Collabora disclosed about CVE-2026-110447

Collabora published advisory GHSA-g3vx-3m76-fghh on 14 Oct 2026, titled "Unauthenticated OS command injection in the richdocumentscode proxy." The CVE record went live the same day. The flaw is CWE-78, OS command injection, rated CVSS 9.2 under version 4.0. The vector reads network reachable, low attack complexity, no privileges, no user interaction, with high impact on confidentiality, integrity and availability, and one qualifier: attack requirements present.

That qualifier is the condition the advisory describes in plain words. The injection sits in the app's proxy.php, and it only works "while the built-in server is not running." Collabora lists the moments that happens: a container restart, an upgrade, or a crash. When the condition holds, "a request can cause an operating system command to run as the web server user."

Two lines in the advisory matter more than the score. First, the fix: the bug is fixed in richdocumentscode release 26.4.303. Second, the workaround that is not one: "It is not sufficient to disable the app to avoid the problem, it must be upgraded to >= 26.4.303 or removed."

The CVE record adds the part the advisory leaves out. It says the flaw was "exploited in the wild in September and October 2026," and that it is a different vulnerability from an earlier Collabora flaw, CVE-2025-66208. CISA added CVE-2026-110447 to the Known Exploited Vulnerabilities catalog on 23 Oct with a federal due date of 26 Oct, three days, and flagged it for forensic triage. Federal agencies are expected to look for compromise, not only to update.

What attackers did with it comes from the administrators who found them. In issue 354 on the app's repository, the first reporter described requests to the app's proxy endpoint from 10 Sep that carried path traversal and shell command substitution, followed by small PHP webshells named in the pattern shx*.php written into the app directory. On one server the attacker then searched for password manager databases and cryptocurrency wallet files. The reporter saw no explicit exfiltration in the logs, and was right to treat everything the web server account could read as exposed anyway. A second site reported a compromise on 18 Sep after noticing failed sudo attempts. BleepingComputer, which covered the attacks on 15 Oct, notes that some users reported ransomware, which it could not confirm.

Which Nextcloud servers are affected, and which are not

Scope is where most of the confusion about this bug lives, so it is worth being exact.

The vulnerable component is one Nextcloud app, richdocumentscode, in releases before 26.4.303. The Nextcloud core is not the bug. Collabora Online itself is not the bug. The advisory says standalone Collabora Online servers are not affected, and according to BleepingComputer, Collabora also lists Docker and RPM or DEB installations of Collabora Online and Nextcloud All-in-One deployments as unaffected. A Nextcloud that uses the richdocuments connector against a separate Collabora server, which is the setup most larger deployments run, does not have this flaw.

Three groups need to look harder.

Servers with the app disabled but still installed. This is the trap in the advisory. Disabling an app in the Nextcloud admin panel is the natural first response to a scary headline, and Collabora says it does not help. Only upgrading or removing the app closes the hole. In issue 354, one administrator reported the server still referencing the disabled app's proxy path while attack attempts continued. Disabled in the interface and gone from the web root are different states, and only the second one counts.

Servers on Nextcloud 29 or earlier. The fixed release requires Nextcloud 30 or later, and the app store's newest build for Nextcloud 25 to 29 is 26.4.104, which is below the fixed version. Censys's advice for those servers is to upgrade Nextcloud or remove the app. There is no in-branch fix to wait for. Anyone running an older Nextcloud because an upgrade was awkward has been carrying this flaw with no patch available on their branch at all.

Servers that restart. The condition that sounds like a mitigation, the bundled server must be down, is met by routine operations. Every container restart, every Nextcloud upgrade, every crash opens a window. An attacker does not need to cause the outage. They need to keep asking until one happens, and the reports in issue 354 describe exactly that pattern of repeated requests. Treat the qualifier as a delay, not a defence.

How many servers is that? Censys reports 19,454 hosts and 103,350 web properties on the internet with the app, counts that include 1,001 hosts running the separate ARM64 build, richdocumentscode_arm64. Censys does not say whether that ARM64 app is affected, and neither does the advisory, so we would treat it as in scope until Collabora says otherwise. The counts measure presence of the app, not vulnerable versions, and not compromise. They do tell you this is not a niche deployment.

Five weeks between the fix and the CVE

The timeline is the story. Read it as two lanes over the same five weeks: what attackers could do, and what a CVE-driven patch program could see.

The vendors have explained the gap. Collabora told BleepingComputer the delayed announcement was mainly down to "GitHub CVE-processing backlogs," which it linked to a rising volume of AI generated security reports. Nextcloud said Collabora reported the flaw in mid-September, that the update was available through the app store, and that the delay gave users time to update; it also said it "had not observed widespread exploitation."

Both explanations can be true and the outcome is still the problem. Holding an advisory to give users time to patch works when nobody else knows about the bug. Here attackers knew before the release did. The first malicious requests in the reporter's logs are from the day after the fix was committed to a public repository. We cannot tell from public sources whether the attackers found the bug on their own or read the commit, and nobody has said. Either way, the users who were given time to update were not told they needed to, while the people attacking them already knew.

Inside the issue, users asked for a CVE at the end of September and pointed out that the release notes for 26.4.303 did not mention security fixes. We checked the release ourselves: the notes name the bundled CODE build and nothing else. A team reading release notes to decide what to prioritise would have had no reason to rush.

This is the blind spot in numbers. A patch program built on CVE feeds, scanner plugins and KEV alerts had nothing to act on from 11 Sep to 14 Oct, 33 days, and nothing marked urgent until 23 Oct. The teams that were safe in September were the ones that update store apps on a schedule without waiting for a reason, or the ones that happened to read the issue tracker.

The same mechanics showed up on the PHP side this week, when we wrote about a PHP core flaw where the version string could not be trusted. The pattern repeats: the identifiers defenders rely on, version numbers and CVE IDs, trail the facts that decide exposure.

How to check a Nextcloud server for CVE-2026-110447 webshells

Upgrading closes the door. It does not remove anyone already inside. Censys says it plainly: patching does not remove existing webshells, and servers exposed since at least 10 Sep should be investigated. CISA's KEV entry asks for forensic triage for the same reason.

Preserve the web server access logs and the app directory before you change anything, then work through these checks on every server that has ever had richdocumentscode installed, including the ones where it is now disabled or was removed recently.

Start with the files. Look for PHP files in the app directory that do not belong there, in particular anything matching shx*.php, which both the issue reporters and Censys name. One forum reply describes a backdoor with a different name in the same directory, so do not stop at the pattern. Nextcloud's code integrity check flags files that do not match the signed app, and Censys lists unfamiliar files flagged by it as an indicator.

Then the access logs. Censys points to requests for /apps/richdocumentscode/proxy.php that contain %2e%2e, encoded path traversal, as the sign of an attempt. A hit means someone tried. A hit followed by requests to a new PHP file in the same directory means someone probably got in.

Then the account. The webshells ran as the web server user, so assume anything that account could read was read: the Nextcloud config.php with its database password and secret, any mounted storage credentials, and the data directory if it is readable.

title: Nextcloud richdocumentscode proxy.php request with encoded path traversal
status: experimental
description: Web requests to the Collabora Online Built-in CODE Server proxy for Nextcloud that carry encoded path traversal, the request pattern Censys lists as an indicator for CVE-2026-110447.
references:
  - https://github.com/CollaboraOnline/online/security/advisories/GHSA-g3vx-3m76-fghh
  - https://censys.com/advisory/cve-2026-110447
logsource:
  category: webserver
detection:
  proxy:
    cs-uri-stem|contains: '/apps/richdocumentscode/proxy.php'
  traversal:
    - cs-uri-query|contains: '%2e%2e'
    - cs-uri-stem|contains: '%2e%2e'
  condition: proxy and traversal
falsepositives:
  - Vulnerability scanners checking for CVE-2026-110447
level: high
tags:
  - attack.initial_access
  - attack.t1190
  - cve.2026-110447

If you find a webshell, the job is incident response, not patching. Rebuild from a known good state if you can, rotate the database credentials and the Nextcloud secrets in config.php, rotate any external storage or mail credentials the server held, and review what else the web server account could reach on the network.

How we test self-hosted collaboration apps

On a sanctioned engagement, a self-hosted Nextcloud, GitLab, Jira or similar is one of the first things we look for on the external perimeter. These platforms hold the documents, the credentials people paste into them, and often single sign-on into everything else. They also share a property that makes them good targets: a small core that gets patched, and a large plugin layer that often does not.

Our approach, at a high level, follows the same order an attacker would. We start from the outside and inventory what the platform exposes, which usually reveals the installed apps through their public paths and assets. We map each app to its own release history, not to the core platform's. Then we look for the gap: apps that are installed but disabled, apps pinned to an old branch because the core was never upgraded, bundled helper services that start and stop on their own schedule. Our web application recon guide walks through that mapping step, including checking every version string against advisories, and the external recon guide covers finding the platforms in the first place.

What we report is rarely a single CVE. More often it is a finding like this one: the organisation patches Nextcloud promptly, but nobody owns the twelve store apps installed over the years, three of them are disabled rather than removed, and one is on a branch with no fixes left. That is a process finding, and it outlives any single bug.

For the inventory part, the tools we publish on our open source page do the repetitive work. Our recon tool maps what a domain exposes, and our web scanner runs the checks that are the same on every app, so the manual time goes to the plugin layer where findings like this one live.

What is still coming for silent fixes

Expect more of this, for three reasons.

The first is the backlog Collabora named. Whatever the exact cause, a vendor said on the record that CVE processing slowed its disclosure, and it linked that to the volume of AI generated reports. If triage queues at CVE numbering authorities and platforms keep growing, the distance between a fix and its CVE grows with them. Every day of that distance is a day CVE-driven tooling is blind.

The second is that attackers read the same public repositories defenders do. Patch diffing, comparing the fixed release with the one before it to find what changed, is an old technique. When a fix lands in a public commit days or weeks before an advisory, the commit is the advisory for anyone paying attention. We do not know whether that happened here. We do know the attacks started the day after the commit.

The third is the plugin economy. Nextcloud, WordPress, Jenkins, Grafana, Confluence: the core is maintained by a vendor with a security process, and the extensions come from everyone else, on their own timelines, with their own ideas about what counts as a security release. The LiteLLM compromise we wrote about this week came from a different direction, a poisoned release rather than a quiet fix, but the lesson for defenders rhymes. The component layer is where you have the least visibility and attackers have the most room.

None of this calls for exotic tooling. It calls for treating store apps and plugins as software you run, with an owner, an update schedule that does not wait for a CVE, and a rule that unused means removed.