Nextcloud Office Add-on Flaw: Check Your Server

Since around 10 September 2026, attackers have been planting hidden backdoors on Nextcloud servers through one add-on: "Collabora Online – Built-in CODE Server", version 26.4.302 and older. The fix, 26.4.303, shipped on 11 September. Update it or remove it (switching it off is not enough), then look for leftover files named shx*.php.

Nextcloud is the file-sharing platform many companies run on their own server as an alternative to Google Drive or OneDrive. This add-on is the quick way to let staff open and edit Word or Excel files in the browser. If your company, or your IT provider, picked that quick option, this article is for you.

What happened, and when?

The unusual part of this incident is the order of events. The fix came first, quietly. The official warning came a month later.

A CVE is the public ID number the security industry gives each flaw, and most patch dashboards and vulnerability scanners only react once that number exists. For 33 days, from the fix to the CVE, those tools had nothing to show while attackers were already active.

How does an office add-on become a way in?

The add-on bundles its own copy of the Collabora office engine and starts it from inside Nextcloud. Think of it as a receptionist who phones the back office whenever a visitor asks for a document. When the back office is closed, the receptionist can be tricked into reading out a message the visitor wrote, and the building obeys it.

In technical terms, this is command injection: text from a web request ends up inside a command the server runs. According to the advisory, it only works while the bundled office engine is not running, for example after a restart, an upgrade, or a crash. No account and no click by any user is needed.

Attackers used it to drop a web shell, a small hidden web page that runs any command they send. Reports in the GitHub thread show what came next: searches for password-manager vault files (*.kdbx), cryptocurrency wallets, and other stored keys.

The commands run as the web server's user account, not as the server's full administrator. That still matters a great deal. The same account can read Nextcloud's configuration file, which holds the database password, email credentials, and storage keys, and it can read every file Nextcloud stores.

Why did turning the add-on off not help?

The advisory is explicit: disabling the add-on in Nextcloud's admin screen does not close the hole. Disabled apps stay on disk, and the vulnerable file can still be reached directly from the web. Only two states are safe: version 26.4.303 or newer, or the add-on removed from the server entirely.

The same goes for older Nextcloud installs. Since 26.4.302 the add-on needs Nextcloud 30 or newer, and Nextcloud 29 and earlier no longer get fixes. A company stuck on an old Nextcloud cannot simply update the add-on; it has to upgrade Nextcloud first or remove the add-on.

What should you check this week?

Work through these in order. Steps 1–3 are read-only and safe to run on a live server.

1. Is the add-on installed, and which version? Look in Nextcloud's Apps page for "Collabora Online – Built-in CODE Server", or ask your administrator to run the command below.
2. Are there extra files in the add-on folder? Nextcloud signs its apps, so it can tell you which files were not shipped by the developer.
3. Do the logs show the attack pattern? Search web server logs from 10 September onwards for requests to proxy.php that contain %2e%2e, $(, %24%28, or ${IFS}.
4. Update to 26.4.303 or newer, or remove the add-on. Then confirm the folder apps/richdocumentscode is gone if you removed it.
5. Delete any leftover backdoor files, even after updating. Collabora's developers advised this explicitly on 18 September, because updating does not remove files the attacker already planted.

# Run as the web server user from the Nextcloud folder
php occ app:list | grep -i richdocumentscode
php occ integrity:check-app richdocumentscode   # look for EXTRA_FILE
find apps/richdocumentscode \( -name 'sh*.php' -o -name 'Nx_*.php' \)
grep -E 'proxy\.php.*(%2e%2e|\$\(|%24%28|IFS)' /var/log/nginx/access.log*

File names seen so far include shx followed by random characters, shrf4645.php, and Nx_33143.php. Treat any PHP file you cannot explain as suspicious. One caution: if your logs rotate after a week or two, a clean log search proves very little for September.

What if you find a backdoor?

Then the server should be treated as compromised, not just "patched". The backdoor gave someone the same reach as Nextcloud itself.

• Change every secret the server could read: the database password, values in config.php, email account, object storage keys, app passwords, and any API tokens.
• Look for what else changed: new admin users, new files outside the add-on folder, unfamiliar outgoing connections.
• Restore from a backup taken before 10 September, or have an outside party review the cleanup. Deleting one file does not prove nothing else was left behind.
• Check your notification duty. If personal data of customers or staff was stored on that server, Article 46 of Indonesia's personal data protection law (UU PDP) requires written notice to the affected people and the supervising authority within 3×24 hours of a protection failure. The UU PDP article covers what is at stake.

Is the built-in option worth the convenience?

The built-in add-on exists so a small team can get document editing without running a second server. That convenience is also the risk: the office engine's launcher lives inside the same web application that holds all your files. Collabora's advisory notes that a separately run Collabora server is not affected by this flaw.

For a team of five testing Nextcloud, the built-in add-on is reasonable. For a company that keeps contracts, payroll, or customer data in Nextcloud, I recommend a separate Collabora server that is not reachable from the internet on its own. The extra work is one more service to update, which is far cheaper than the cleanup described above.

Why waiting for a CVE is not a patch policy

This case is not unusual. VulnCheck's 2026 State of Exploitation report, published 21 January 2026, found that 28.96% of the 884 flaws first seen exploited in 2025 were attacked on or before the day their CVE was published. More than one in four never gave defenders a CVE-based head start.

For self-hosted software, that changes what "keeping up to date" means:

• Turn on app updates in Nextcloud and apply them within days, not at the next quarterly maintenance window.
• Follow the projects you depend on directly: release notes, GitHub issues, and the vendor forum. The first public signal here was a GitHub issue on 11 September, not a CVE.
• Keep an inventory of add-ons and remove the ones nobody uses. Every add-on is code running with access to all your files.
• Keep the admin and add-on surfaces off the open internet where you can, for example behind a VPN, the same lesson as the AhsayCBS backup console attacks earlier this month.

If your Nextcloud is run by a vendor or IT provider, ask them three questions this week: which version of the add-on was installed between September and now, whether the integrity check is clean, and how long your web server logs are kept. A provider who can answer all three within a day is managing the server; one who cannot is only hosting it.