How to Check for Nextcloud Web Shells and Clean Up

To check for Nextcloud web shells, confirm which apps are installed, run Nextcloud's integrity check on the core and on each app, investigate every unexpected file it reports, and search the web server access logs for requests to those files. Doing this after any exploited app flaw, such as the October 2026 Collabora Built-in CODE Server attacks, tells you whether you only need a patch or need full incident response. Plan on about an hour for a single server with readable logs.

Why check for Nextcloud web shells after patching?

Patching closes the hole an attacker used but does nothing to files they already wrote. A web shell planted before the update keeps working afterwards, so every exploited Nextcloud flaw needs a file check as well as an upgrade.

In the Collabora CVE-2026-110447 attacks, the first requests landed on September 10, 2026, while the fix and the public warning came later. Servers that upgraded in October without checking may still carry shells. If you need background on what these files are, start with what a web shell is and how it gets onto a server.

Before you start

• Work from a copy if you can. Take a snapshot or backup of the server and its logs before deleting anything. You may need the evidence later.
• Close the entry point first. Update or remove the vulnerable app so a new shell cannot be written while you clean.
• Collect the logs. Find out how far back your web server access logs go. For the Collabora flaw you need coverage from September 10 onward.

Run Nextcloud's occ command as the web server user from the Nextcloud installation directory, the same way you run it for upgrades. Running it as root can change file ownership and break the instance.

Step 1: inventory the installed apps

Run occ app:list. It lists enabled and disabled apps with their versions.

Look for apps you do not recognize or no longer use. A disabled app is still a risk: in the Collabora case, the vulnerable proxy.php stayed reachable when the app was disabled, because its files remained on disk. Note each app's version and compare it with the vendor's fixed version. For the Built-in CODE Server app (richdocumentscode) that is 26.4.303 or later.

Remove apps you do not need. An uninstalled app cannot be exploited; a disabled one may still be.

Step 2: run the integrity checks

Nextcloud signs its core and app releases. The integrity checker compares what is on disk with the signed file list and reports anything missing, changed or extra.

• occ integrity:check-core checks the Nextcloud core files only.
• occ integrity:check-app richdocumentscode checks a single app. Repeat it for any app you suspect, or for every third-party app on the server.

Pay attention to EXTRA_FILE results. A file that is not in the signed list but sits inside an app folder is exactly where a dropped shell shows up. On October 16, 2026 a Nextcloud administrator found apps/richdocumentscode/Nx_33143.php this way, a name that did not match the shx*.php pattern reported earlier.

The integrity check only covers signed code. It does not check the data directory, config files or anything outside the Nextcloud tree.

Step 3: look for unexpected PHP files

How do you find a web shell the integrity check missed? List every .php file under the app directories and the web root, then compare names and modification times against a clean copy of the same versions.

Things that stand out:

• Short random-looking names, such as shx13a86.php or shrf4645.php from the Collabora attacks.
• PHP files with modification dates that do not match the last upgrade.
• Files containing calls such as shell_exec or system fed from request parameters. The shells recovered from Nextcloud servers were one line each.
• PHP files in places that should only hold data, such as upload or temporary folders.

Record the full path, size, owner and timestamps of each suspicious file before removing it.

Step 4: search the access logs

What should you search for in Nextcloud access logs? Look for requests to the suspicious files, and for the requests that created them. Both give you dates and source addresses.

For the Collabora flaw, the indicators reported in GitHub issue #354 and by WZ-IT were:

• Requests to /apps/richdocumentscode/proxy.php?status containing %2e%2e, $(, %24%28, ${IFS} or base64.
• Repeated requests with a ?c= parameter to PHP files in the app folder, which is the shell being used.
• Source addresses 139.28.18.122 and 89.38.98.50, and outbound callbacks to webhook.site.

No match is not proof of a clean server if the logs rotated before the attack window. Treat a log gap as unknown, not clean.

Step 5: remove, rotate and decide on a rebuild

If you found nothing and your logs cover the whole exposure window, the upgrade was enough. Keep monitoring.

If you found a shell:

1. Delete the shell files after recording them, and confirm the app is on a fixed version or removed.
2. Check for persistence outside the web root: cron jobs for the web server user, new Nextcloud admin accounts, and changes to config.php.
3. Rotate the database password and app passwords, as the Nextcloud forum warning advised, plus any other secret the web server account could read. Our piece on why your web server account should not read your secrets explains how wide that set usually is.
4. Review what the account could reach in the data directory and treat it as exposed.
5. If the shell was used to run commands and you cannot account for all of them, rebuild from a backup taken before the first malicious request.

How often should you run these checks?

Run the integrity check after every Nextcloud upgrade and after any advisory that mentions exploitation of an app you have installed. Monthly is a reasonable baseline for internet-facing servers.

Scheduling occ integrity:check-core and alerting on any result catches most file drops within a cycle, and it costs almost nothing to run.