Secretus logo
newsnextcloudcollaboracve-2026-110447

Nextcloud Servers Backdoored Through Collabora’s Built-In CODE App: Treat What the Web Server Could Read as Exposed

An unauthenticated command injection in Collabora's built-in CODE app has been used to plant web shells on Nextcloud servers since 10 September. One attacker went looking for password databases and wallet files.

·8 min read·Secretus Editorial

A self-hosted file server holds more than files. After this week's Nextcloud reports, the question is what the web server account on yours could read. The Hacker News reports that attackers exploited an unauthenticated command injection in Collabora Online's Built-in CODE Server app, which ships with Nextcloud, to plant PHP web shells. Three administrators reported the issue on GitHub, and the first logged attack was on 10 September. On at least one server, the attacker searched for password-database and crypto-wallet files.

The advisory was published on 14 October, more than a month after the first attack and about a month after a fixed version was released.

What is confirmed

The flaw is CVE-2026-110447, in the richdocumentscode package's proxy.php: text from the request path is placed into a double-quoted shell command. It is reachable without logging in and is triggered when the local document server is not running, for example after a restart, upgrade or crash. All versions before 26.4.303 are affected. Standalone Collabora servers, and the richdocuments app on its own, are not. Collabora fixed it in 26.4.303, released on 11 September, which requires Nextcloud 30 or later. Nextcloud 29 and older are end of life and cannot install the fix.

Collabora's advisory says disabling the app is not enough: it must be upgraded to 26.4.303 or later, or removed. A Collabora maintainer says the impact is limited to the Development Edition's built-in mode, and describes one alarming-looking output from a 14 September attempt as harmless.

What the attackers did

According to the administrators' reports, as relayed by The Hacker News, the attackers dropped one-line PHP web shells in the app's directory and sent system information to an external webhook. On one server, they searched for credential stores such as password-manager databases and wallet files. The reviewed requests showed no archiving or copying of files, and no root access was reported. Administrators spotted the compromise through Nextcloud's integrity check and through failed sudo emails.

What is not known

  • How many servers were compromised. Three administrators reported it. The true number is unknown.
  • Whether anything was stolen. The reviewed requests showed no file collection, but absence of evidence on a handful of servers is not evidence for yours.
  • Who is behind it. No attribution.
  • The severity score. The Hacker News does not state a CVSS score; one CVE aggregator lists 9.2. Treat that as unconfirmed.
  • A clean new release. The reporting says a later build, 26.4.402, fails to start or open documents on some setups and administrators have gone back to 26.4.303. Nothing newer was available when the article was published.
  • Nextcloud's official position. The reporting cites a community-forum warning, not a Nextcloud statement.

A detail worth knowing: the four-line fix was committed on 9 September, did not make it into the 26.4.302 build, and was not flagged as a security fix in the release notes. If you keep current with release notes alone, this one was easy to miss.

What to do

  1. Find out whether you have the app. Check whether the built-in CODE Server app is installed, and its version. If you use a separate Collabora server instead, you are not in scope.
  2. Upgrade to 26.4.303 or later, or remove the app. Do not just disable it. If you are on Nextcloud 29 or older, upgrade Nextcloud or remove the app.
  3. Look for the shells. Search the app's directory for PHP files with names beginning shx, and run Nextcloud's integrity check. Take the file hashes and addresses from the original reporting rather than from a summary.
  4. Search the logs back to 10 September. Look for requests to proxy.php that contain encoded path traversal, shell substitution or base64 decoding, and for sudo attempts by the web server account. Keep the logs before you change anything.
  5. If you find a shell, treat the server as compromised. Rebuild from a known-good state rather than cleaning in place, and restore data from before the first attack.
  6. Treat anything the web server account could read as exposed. The article does not say this explicitly; it is our recommendation, and it follows from a shell running as that account. That means the Nextcloud configuration file, with its database password, instance secret and any mail or LDAP credentials; external-storage credentials; app passwords; and keys or password files kept on the same machine. Rotate these in dependency order and then check connected services.
  7. Remove credential stores from the server. A password database or wallet file sitting on a file server is the very thing the attacker went looking for. Move it somewhere else.

The handover step

Rotating a database password or an external-storage key means giving the new value to the administrator who configures it. On a small self-hosted setup that is often one person in a chat or an email, and it is the moment a replacement secret is most likely to be left lying around in a message history.

Where Secretus fits, and where it does not

Secretus covers that handover: a person encrypts a short text secret in the browser and shares a link that stops working after the expiry they set or the first successful open. Team Split can require several holders to reconstruct a high-value text secret.

It is not a server hardening tool or a password manager. It cannot patch Nextcloud, find web shells, rotate your database password or tell you whether your server was touched. Do those with Collabora's and Nextcloud's guidance, and use a one-time link for the moment one person gives another a new credential.

Sources