# Your Nextcloud Patch Needs an Intrusion Check

> CISA has added an exploited flaw in Nextcloud’s built-in Collabora CODE server to its priority catalog. Updating closes the command-injection route, but exposed operators also need to look for web shells, review the affected window, and rotate secrets the web server could read.

- **Author:** Kubilay Tunca
- **Published:** 2026-10-26
- **Category:** For Developers
- **Tags:** Nextcloud, Vulnerability Management, Incident Response, Self-Hosting
- **Canonical URL:** https://cyber-security-in-plain-english.com/post/developers/news/nextcloud-collabora-patch-needs-intrusion-check

---

An administrator updates the office editor inside a Nextcloud server. The version number now looks safe. Documents still open. The security scanner stops complaining.

That is the patching job. It is not the whole incident job.

On 23 October 2026, the US Cybersecurity and Infrastructure Security Agency added CVE-2026-110447 to its Known Exploited Vulnerabilities catalog. The flaw affects the **Collabora Online - Built-in CODE Server** app for Nextcloud, also called `richdocumentscode`, before version 26.4.303. It can let an unauthenticated visitor run operating-system commands when the bundled document server is not running. CISA says exploitation is active and set 26 October as the federal remediation deadline ([CISA KEV catalog, accessed 26 October 2026](https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-110447); [NVD, updated 24 October 2026](https://nvd.nist.gov/vuln/detail/CVE-2026-110447)).

The narrow scope is good news. A standalone Collabora Online server is not affected by this particular bug. Neither is a Nextcloud installation that uses the regular connector app without the built-in CODE package. The dangerous combination is the built-in server package, an affected version, and the code path used while that local server is down ([GitHub Advisory Database, updated 23 October 2026](https://github.com/advisories/GHSA-f97p-r72q-64h2)).

The bad news is equally specific. Operators reported PHP web shells on Nextcloud servers before the public CVE arrived. Security reporting says attackers used those footholds to inspect systems and search for credentials, password-manager material, and cryptocurrency wallets ([Nextcloud community report, updated 26 October 2026](https://help.nextcloud.com/t/to-collabora-built-in-user-update-asap/250516); [The Hacker News, 23 October 2026](https://thehackernews.com/2026/10/cisa-flags-two-actively-exploited.html)). A repaired app cannot remove a file that an attacker planted yesterday. It cannot invalidate a database password copied last week.

If you run the affected app, update it now. Then answer a second question with evidence: **was this server touched before the update?**

## What changed on 23 October

The vulnerability itself was not new on 23 October. Version 26.4.303, which contains the repair, was published on 11 September 2026. Community warnings about active exploitation appeared in early October. The CVE record followed on 14 October. CISA's 23 October catalog entry changed the public response from “serious report” to “known exploited vulnerability with a dated remediation requirement” ([Collabora built-in CODE release 26.4.303, 11 September 2026](https://github.com/CollaboraOnline/richdocumentscode/releases/tag/26.4.303); [Nextcloud community report, updated 26 October 2026](https://help.nextcloud.com/t/to-collabora-built-in-user-update-asap/250516); [NVD, updated 24 October 2026](https://nvd.nist.gov/vuln/detail/CVE-2026-110447)).

CISA's deadline directly binds US federal civilian agencies, not every private Nextcloud owner. Its value for everyone else is the exploitation signal. A long queue of theoretical bugs can be scheduled by ordinary severity and exposure. A bug already used against real systems deserves a shorter clock.

The catalog describes CVE-2026-110447 as operating-system command injection. NVD gives it a CVSS 4.0 base score of 9.2 and records that no login or user interaction is required. The attack does have a condition: the built-in CODE server must not be running. A restart is one example of how that state can occur ([NVD, updated 24 October 2026](https://nvd.nist.gov/vuln/detail/CVE-2026-110447)).

That condition does not make an internet-facing server safe. Services restart during upgrades, crashes, host maintenance, memory pressure, and routine operations. A state that exists for only part of the day can still be reachable by automated scanning. A healthy document editor at inspection time proves little. Ask whether the vulnerable route was reachable at any point while an attacker was looking.

The public evidence does not support a claim that every affected installation was compromised. It also does not provide a reliable count of victims. The careful conclusion is smaller: exploitation happened in September and October, users reported web shells, and any internet-exposed installation that ran `richdocumentscode` 26.4.302 or earlier needs both remediation and review.

This distinction matters because security language often collapses four different states into one word:

- **Affected** means the vulnerable component and version were present.
- **Exposed** means an attacker could reach the vulnerable route under the required condition.
- **Exploited** means someone used the flaw successfully.
- **Persisted** means the attacker left another way back, such as a web shell, account, key, scheduled task, or modified application file.

An app update changes the first state. Network controls may change the second. Logs and host evidence are needed for the third and fourth. Calling the server “fixed” because the package is current skips the two states that determine whether an intruder remains.

## The mechanism is a shell command built from a web request

The built-in CODE app exists to make deployment convenient. Instead of asking the operator to run a separate Collabora server, Nextcloud can install a large app package containing the document service. The app then starts and connects that local service for browser-based editing.

Convenience changes the trust boundary. A web application is now responsible for launching another program on the host. Somewhere between an HTTP request and the operating system, the application has to build a command.

CVE-2026-110447 sits in `proxy.php`. The public advisory says the vulnerable path can be reached while the bundled CODE server is down. Request data is handled incorrectly before the app uses an operating-system command. The weakness is classified as CWE-78: improper neutralisation of special elements in an OS command ([GitHub Advisory Database, updated 23 October 2026](https://github.com/advisories/GHSA-f97p-r72q-64h2); [NVD, updated 24 October 2026](https://nvd.nist.gov/vuln/detail/CVE-2026-110447)).

In plain English, a value that should have been treated as data could change what the shell did. The server did not merely misunderstand a document request. It could execute an attacker-chosen command with the authority of the web-server process.

That last phrase sets the immediate boundary. Remote command execution does not automatically mean the attacker became the Unix `root` user. The first command normally runs as the account serving Nextcloud, often `www-data` on Debian-family systems. That account still carries useful authority: it reads Nextcloud's code and configuration, writes to selected application or data paths, connects to the database, and processes user files.

A web-server foothold can therefore be enough to plant a PHP file in a web-reachable directory. The file becomes a web shell: a small endpoint that accepts later commands. Once the shell exists, the original vulnerable app can be patched and the attacker can return through the new file.

This is the central operational lesson. The vulnerability is the door. The web shell is a second door installed after entry. Replacing the lock on the first door does not remove the second.

The server state also explains why a spot check can mislead. If the local CODE process is running now, a test request may not travel through the vulnerable startup path. That says little about the minutes after a reboot two weeks ago. Incident review has to cover the historical window, not reproduce only the current state.

There is one more scope trap. “Collabora” names several deployment patterns. The GitHub advisory explicitly excludes standalone Collabora Online servers. The community warning also distinguishes the affected built-in package from deployments using Docker, distribution packages, or hosted Collabora services ([GitHub Advisory Database, updated 23 October 2026](https://github.com/advisories/GHSA-f97p-r72q-64h2); [Nextcloud community report, updated 26 October 2026](https://help.nextcloud.com/t/to-collabora-built-in-user-update-asap/250516)).

Do not patch every product with a similar name and assume the work is done. Inventory the Nextcloud apps actually installed on each instance. The relevant package name is `richdocumentscode`; the ordinary connector is `richdocuments`. Similar labels do not imply the same exposure.

## Why an update cannot prove the host is clean

Imagine a Nextcloud server ran version 26.4.302 through the end of September. An attacker reached `proxy.php` during a service restart, executed a command as the web user, and wrote a file named to resemble a cache or generated PHP artifact. The attacker then used that file once to read the Nextcloud configuration and left it in place.

The operator updates to 26.4.303 in October. The vulnerable command construction disappears. The planted PHP file does not. The database password the attacker copied does not change. A malicious app password or SSH key, if one was added later, does not expire. All three can outlive the patch.

This is not an exotic chain invented to make the story frightening. Community members reported unexpected PHP files, and current news coverage describes web shells used for reconnaissance. The exact filenames and attacker behaviour can vary, which is why searching only for one published name is weak evidence ([Nextcloud community report, updated 26 October 2026](https://help.nextcloud.com/t/to-collabora-built-in-user-update-asap/250516); [BleepingComputer, 15 October 2026](https://www.bleepingcomputer.com/news/security/hackers-exploit-collabora-rce-flaw-to-backdoor-nextcloud-servers/)).

A good review starts with known indicators but asks a broader question: what changed in places the web-server account could reach?

Nextcloud's integrity checker can help. It compares core and app files with expected signatures and reports additions or modifications. That is useful because a web shell beside legitimate PHP files may stand out as an extra file. It is not a complete forensic verdict. Unsigned local apps, legitimate administrator changes, log deletion, files outside checked trees, and persistence in accounts or scheduled tasks require other evidence.

File modification time is useful too, but not conclusive. An attacker can alter timestamps. A restore or deployment can rewrite many files at once. Use timestamps to build a review set, then compare hashes, package manifests, backups, deployment records, and surrounding logs.

The same caution applies to access logs. A request to the vulnerable path can show targeting, but an HTTP status code alone may not prove command execution. A missing request does not prove safety if logs rotated, lived behind another proxy, or were deleted. Correlate the reverse proxy, web server, PHP, Nextcloud, system journal, and outbound-network records where available.

Retention policy becomes a security control here, not mere storage housekeeping. If exploitation began in September but the reverse proxy keeps seven days of logs, an operator investigating in late October cannot recreate the full window. The correct conclusion is “history unavailable,” not “no evidence found.”

The distinction should appear in the incident record. **No evidence of compromise** means the retained sources were checked and nothing suspicious was found. **Evidence unavailable** means the sources needed to answer the question no longer exist. Those sentences lead to different decisions about secret rotation and rebuilding.

## First establish whether this exact app was present

Before hunting through every file on the server, settle scope. Record the answer for each Nextcloud instance, including test and forgotten departmental systems.

From the Nextcloud application directory, the `occ` command can list enabled and disabled apps. It usually runs as the web-server account, but the exact user and PHP path depend on the installation. The administrative app page can also show the package. Look for `richdocumentscode`, not only a display name containing “Collabora.”

If `richdocumentscode` was never installed, CVE-2026-110447 does not apply to that instance. Preserve the inventory result and stop chasing this particular bug. The server may have other risks, but they belong to another review.

If the app is installed, record the current version and how the server obtains updates. Version 26.4.303 is the repaired floor identified by the advisory and release record. Installing a later current release is preferable when it is supported by your Nextcloud version, because the floor is a historical fact, not a recommendation to remain on an old build ([Collabora built-in CODE release 26.4.303, 11 September 2026](https://github.com/CollaboraOnline/richdocumentscode/releases/tag/26.4.303); [GitHub Advisory Database, updated 23 October 2026](https://github.com/advisories/GHSA-f97p-r72q-64h2)).

Do not treat “disabled” as equivalent to “absent.” Published operator guidance warns that disabling the app is not the recommended repair; update it or remove it. A disabled app's files can remain under the web root, and the relevant question is whether an unauthenticated route can still reach them in that deployment. Removal narrows the file surface when the built-in service is not needed ([BleepingComputer, 15 October 2026](https://www.bleepingcomputer.com/news/security/hackers-exploit-collabora-rce-flaw-to-backdoor-nextcloud-servers/)).

Next, reconstruct the affected period. Check package-management records, Nextcloud app update logs, backup manifests, filesystem snapshots, and deployment history. Write down when a vulnerable build first appeared, when 26.4.303 or later was installed, and whether the server was reachable from the public internet during that interval.

A current inventory says what exists now. Incident scope needs what existed then.

Exposure deserves its own line in the record. A server behind a reverse proxy may still be internet-facing. An allowlist, private network, or authenticated access gateway may reduce reachability, but confirm which routes the control covered. Do not infer protection from the architecture diagram if the live routing rules differed.

Finally, note service restarts and outages in the affected window. The public description says the vulnerable route matters when the built-in CODE server is not running. Host reboots, app upgrades, crash loops, and maintenance events can therefore identify periods worth inspecting closely. They are prioritisation clues, not proof that all other times were safe.

## Patch, preserve, and inspect in the right order

For an exposed vulnerable server, the response has two goals that can pull in opposite directions. You want to close the route quickly. You also want to preserve enough evidence to learn whether it was used.

Start by restricting public access if that can be done safely and quickly. A maintenance page, firewall rule, load-balancer change, or removal from the proxy can stop new requests while the operator records state. Avoid a long forensic ritual that leaves known remote command execution open to the internet.

Before making broad changes, preserve what is cheap and volatile. Record the time, app list and versions, running processes, active network connections, logged-in sessions, recent service status, relevant logs, and hashes of suspicious files. Take a snapshot through the hosting platform when that snapshot is trustworthy and does not destroy other evidence. Keep collected material away from the potentially compromised host.

Then update `richdocumentscode` to a supported release at or above 26.4.303, or remove it if the built-in server is not required. Verify the installed result rather than trusting a successful-looking button. Re-run the app inventory, confirm the files on disk match the expected release, restart the services required by the vendor's procedure, and test document editing from the user side.

Now inspect. Run Nextcloud's integrity checks for core and installed apps. Compare the application and web directories against a known-good package or backup. Review recently created and modified PHP files, but do not limit the search to PHP: shell scripts, configuration changes, uploaded binaries, modified rewrite rules, and scheduled tasks can all support persistence.

Review the accounts and keys that matter around Nextcloud. Look for new administrators, unexpected app passwords, unfamiliar tokens, changed email addresses, new SSH authorised keys, new system users, altered `sudo` rules, web-server cron entries, systemd units, and timers. The web user may not have permission to create all of these. Checking them tells you whether the activity crossed the initial account boundary.

Read logs as a timeline. Start with requests to the affected `proxy.php` route, especially near restarts and before the fixed version arrived. Then look for follow-on requests to unfamiliar PHP paths, unusual query strings, command-like parameters, downloads from external hosts, outbound connections from PHP or the web account, and access to configuration or credential files.

Do not execute a suspected web shell to “see what it does.” Preserve a copy and hash, then inspect it in an isolated environment. Opening the public URL can alert the attacker, trigger destructive behaviour, or add noise to the evidence.

If the review finds a credible web shell or unexplained command execution, stop treating the machine as a normal patch case. Isolate it, preserve evidence, and rebuild from a known-good source where practical. Deleting the one visible file is not enough because the attacker had the same operating-system foothold that created it.

A rebuild should not import the compromise. Restore user data and configuration selectively, scan them, reinstall applications from trusted packages, and recreate secrets. Copying the old application tree onto a clean host can faithfully restore the attacker's persistence along with the service.

## Rotate the secrets that the web process could reach

Secret rotation should follow a map, not a reflexive reset of every password in the company.

Begin with the Nextcloud configuration. The web application needs database credentials and security values to operate. If the web-server account could read those values during the affected period, assume a successful attacker could read them too. Change the database credential and update the application through a controlled process. Review the database account's privileges while doing it; a Nextcloud service account should not administer unrelated databases.

Then inspect integrations. Nextcloud may connect to object storage, SMTP, LDAP or another directory, external file shares, antivirus services, monitoring systems, backup locations, and webhook endpoints. Some credentials live in configuration, some in environment variables, some in mounted secret files, and some in the database. Inventory where the running PHP process could read them.

Revoke active sessions and app tokens when the evidence justifies it. A copied session or app password can survive an ordinary account password change. Check administrative users first, then users whose files or credentials appear in the investigation.

Host credentials need separate treatment. If the web account could read private SSH keys, cloud credentials, deployment tokens, or backup keys, replace them from a clean machine. Remove the old public keys or tokens at the service that accepts them. Generating a new key without revoking the old one leaves both valid.

Order matters. Closing the vulnerable route and isolating persistence comes before placing fresh secrets on the host. Otherwise a surviving shell can read each replacement as soon as it is installed.

Keep a rotation register with five fields: secret, where it was exposed, owner, revoked time, and verification. “Changed database password” is weaker than “old database credential rejected at 14:32 UTC; application connected with replacement; audit log retained.” The second statement can be tested.

When no historical logs remain, use accessible authority to decide. A public server that held a readable database password throughout the exploited period may merit rotation even without a discovered web shell. The cost of changing one scoped credential can be lower than pretending missing evidence is reassuring.

## Turn this incident into a deployment test

A thicker emergency checklist would add little. A repeatable deployment test makes the next answer quick.

Build an inventory query that reports Nextcloud version, installed app identifiers, app versions, exposure, update channel, owner, and last backup test. Run it across production, staging, disaster-recovery systems, and old hosts that still resolve in DNS. A vulnerability that affects one optional app will not be found reliably by a server spreadsheet listing only “Nextcloud.”

Make package provenance visible. The built-in CODE release page provides a SHA-256 digest for its published archive. Record the source and digest used by automation rather than downloading “latest” without a receipt ([Collabora built-in CODE release 26.4.303, 11 September 2026](https://github.com/CollaboraOnline/richdocumentscode/releases/tag/26.4.303)). A digest does not prove the package is vulnerability-free. It proves the deployed bytes are the bytes the release process selected.

Add an integrity baseline after each approved deployment. Store hashes or signed manifests outside the server. Nextcloud's own checks remain valuable, but an external baseline gives the responder another source when the application host is suspect.

Test log retention against the response window you expect. If a monthly review is normal, seven days of logs cannot answer a September-to-October exploitation question. Keep enough reverse-proxy, application, authentication, process, and network history to investigate the time between release, discovery, and patching. Protect the logs from the web-server account.

Monitor service transitions, not just uptime. This flaw becomes reachable in a particular down-state of the bundled service. An alert that says “document editor recovered after six minutes” is useful operationally. A security record that marks those six minutes gives investigators a precise interval to examine.

Separate the web application from the operating system where practical. A dedicated host or container, limited filesystem writes, narrow outbound access, a read-only application tree, and a database account scoped to one schema all reduce what command execution can reach. These measures do not excuse an update. They shrink the second problem if an update is late.

Review internet access from the server. A web shell that can make unrestricted outbound connections is easier to turn into a durable remote-control channel and easier to use for downloading tools. Allow only the destinations the service needs, then log denials and exceptions. “The computer still had a way out” is the practical fact behind an egress review.

Finally, test restoration. A backup is not a clean recovery point merely because it predates the day the operator noticed the incident. The exploitation record reaches into September. Recovery procedures should let the team choose a dated image, reinstall current packages, restore selected data, rotate secrets, and verify integrity before public traffic returns.

## The finish line is a receipt, not a green badge

For CVE-2026-110447, a useful completion record fits on one page.

It names every Nextcloud instance and says whether `richdocumentscode` was present. For affected systems, it records the old version, fixed version, exposure window, update time, and verification. It states which logs and snapshots were preserved, which integrity checks ran, what suspicious files or requests were found, and where evidence was unavailable.

It lists secrets reachable by the web process and records each revocation. If compromise was found, it names the clean recovery source and explains how persistence was excluded from the restore. If no evidence was found, it names the data examined and its retention period.

That receipt is more valuable than a screenshot of an update screen. It separates a known fact from an assumption and makes the residual risk visible to the person who must accept it.

The immediate action is straightforward: if the built-in CODE app is below 26.4.303, update or remove it. The durable lesson is broader. Once a vulnerability is known to have been exploited, package state and host state become two different questions.

Patch the door. Then check whether someone came through it.

For more security explained without the panic, join the newsletter. One email per month.

## Sources

- [CISA: Known Exploited Vulnerabilities catalog entry for CVE-2026-110447](https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-110447), accessed 2026-10-26
- [NIST National Vulnerability Database: CVE-2026-110447](https://nvd.nist.gov/vuln/detail/CVE-2026-110447), accessed 2026-10-26
- [GitHub Advisory Database: GHSA-f97p-r72q-64h2](https://github.com/advisories/GHSA-f97p-r72q-64h2), accessed 2026-10-26
- [CollaboraOnline: richdocumentscode 26.4.303 release](https://github.com/CollaboraOnline/richdocumentscode/releases/tag/26.4.303), accessed 2026-10-26
- [Nextcloud community: To Collabora Built-in User: Update ASAP](https://help.nextcloud.com/t/to-collabora-built-in-user-update-asap/250516), accessed 2026-10-26
- [BleepingComputer: Hackers exploit Collabora RCE flaw to backdoor Nextcloud servers](https://www.bleepingcomputer.com/news/security/hackers-exploit-collabora-rce-flaw-to-backdoor-nextcloud-servers/), accessed 2026-10-26
- [The Hacker News: CISA Flags Two Actively Exploited Critical Flaws in Collabora Online and Arista VeloCloud](https://thehackernews.com/2026/10/cisa-flags-two-actively-exploited.html), accessed 2026-10-26

---

## About the author

Kubilay Tunca — Senior Full Stack Developer and Author. Founded Cyber Security in Plain English to translate complex security concepts into clear, practical advice, and writes the accompanying books on security, privacy, secure development, and AI systems.

## Books by this author

- **The Digital Fortress** — Your Everyday Guide to a Safer Digital Life. A warm, plain-English guide for people with real lives and finite patience. Learn the handful of habits that genuinely protect your money, accounts, and family, and get honest permission to ignore the rest. [Amazon](https://buy.cyber-security-in-plain-english.com/digital-fortress) · [Details](https://cyber-security-in-plain-english.com/books/the-digital-fortress)
- **The Anonymity Playbook** — Digital Survival for Whistleblowers, Journalists, Activists, and Everyone Else. A practitioner’s field manual for journalists protecting sources, whistleblowers, and activists. It explains how the surveillance actually works, what each technique costs you, and exactly where it fails. [Amazon](https://buy.cyber-security-in-plain-english.com/anonymity-playbook) · [Details](https://cyber-security-in-plain-english.com/books/the-anonymity-playbook)
- **Secure Software Development** — Practical patterns for building secure software. A hands-on security guide for developers and IT professionals who ship real software. Build, deploy, and maintain secure systems without slowing down or drowning in theory. [Amazon](https://buy.cyber-security-in-plain-english.com/secure-software-development) · [Details](https://cyber-security-in-plain-english.com/books/secure-software-development)
- **The Secure Harness** — Shipping Production Code with AI Coding Agents. A calm, practical guide to letting agents do useful work inside boundaries you set, enforce, and audit. Ships with 15 copy-pasteable artifacts: hook scripts, permission configs, release gates, and MCP templates. [Amazon](https://buy.cyber-security-in-plain-english.com/secure-harness) · [Details](https://cyber-security-in-plain-english.com/books/the-secure-harness)
- **The AI Native Engineer** — Build, Evaluate, and Ship AI Systems That Work in Production. Sixteen hands-on chapters, one real product. Grow it from a single model call into a retrieved, tool-using, observable, production-grade system, with evaluation treated as a habit from the first feature. [Amazon](https://buy.cyber-security-in-plain-english.com/ai-native-engineer) · [Details](https://cyber-security-in-plain-english.com/books/the-ai-native-engineer)

Full catalogue with contents and intended audience: https://cyber-security-in-plain-english.com/books

_As an Amazon Associate I earn from qualifying purchases. Buying through these links costs you nothing extra and helps pay for the blog._