CVE-2026-110447 One Request to Own Your Nextcloud

A pre-authentication OS command injection in Nextcloud’s richdocumentscode app allows an unauthenticated attacker to achieve full RCE with a single HTTP request – no credentials, no session, no prior interaction. Exploited in the wild from September 10, 2026. CISA KEV added October 23, 2026.

On September 10, 2026, attackers began exploiting a critical command injection flaw in a Nextcloud component that hundreds of thousands of organizations use to run collaborative document editing. The exploit required no authentication, no session, and no prior knowledge of the target beyond its URL – a single crafted HTTP GET request was enough to gain code execution on the server.

The affected component is richdocumentscode, the Collabora Online Built-in CODE Server – a Nextcloud app that embeds a LibreOffice-based document editor directly into Nextcloud installations. The vulnerability lives in a PHP file (proxy.php) that is intentionally public-facing and authentication-free. The flaw itself is a subtle shell-quoting error: a correctly used defensive function whose output is placed in a context that makes the defense meaningless.

CISA added CVE-2026-110447 to the Known Exploited Vulnerabilities catalog on October 23, 2026, with a federal agency remediation deadline of October 26, 2026. At the time of that listing, attackers had already been exploiting the flaw in the wild for six weeks – beginning the day before the official patch was released.

Vulnerability At a Glance

NOT AFFECTED: Standalone collabora/code Docker containers (RPM/DEB packages) and Nextcloud All-in-One (AIO) deployments are not affected. This CVE applies exclusively to the richdocumentscode Nextcloud app (Development Edition / Built-in CODE Server).

What is richdocumentscode?

Nextcloud is a self-hosted file sync and collaboration platform widely used by enterprises, universities, healthcare providers, and government agencies. The richdocumentscode app – formally the “Collabora Online Built-in CODE Server” – embeds a full LibreOffice-based document editor into Nextcloud, letting users open, edit, and collaboratively annotate Word documents, spreadsheets, and presentations without leaving the Nextcloud interface.

The integration works by running a Collabora AppImage (coolwsd) locally on the Nextcloud server and routing browser document-editing requests to it through proxy.php. Because proxy.php must respond to health-check requests before a Nextcloud session exists – and because coolwsd launch can be triggered by an unauthenticated request – this file intentionally bypasses Nextcloud’s authentication middleware. It is reachable by any client with network access to the Nextcloud URL.

That design decision is not the vulnerability. The vulnerability is in what proxy.php does with one specific piece of attacker-controlled input.

What Actually Breaks

When coolwsd is not running – always true at server startup, after a container restart, after a crash, or after an upgrade – proxy.php calls startCoolwsd() to launch the AppImage. This function assembles an OS command. In versions ≤ 26.4.302, the vulnerable code looks like this:

proxy.php - Vulnerable (richdocumentscode ≤ 26.4.302)
// HTTP_HOST is taken directly from the incoming request
$lok_allow = "--o:net.lok_allow.host[14]="
. escapeshellarg($_SERVER['HTTP_HOST']);

$launchCmd = “bash -c \”( $appImage $remoteFontConfig $IPv4only ”
. “$lok_allow –pidfile=$pidfile || ”
. “$appImage –appimage-extract-and-run $remoteFontConfig ”
. “$IPv4only $lok_allow –pidfile=$pidfile) >/dev/null & disown\””;

exec($launchCmd);

PHP’s escapeshellarg() correctly wraps the HTTP Host header value in single quotes. If an attacker sends Host: victim.com$(id), escapeshellarg() produces ‘victim.com$(id)’. This looks correct in isolation.

The flaw: that single-quoted string is then interpolated into the outer double-quoted argument passed to bash -c. In shell, single quotes inside double-quoted strings are literal characters – they are not quoting operators, and they do not suppress $() command substitution. The outer shell (the one PHP’s exec() invokes to run bash) processes the double-quoted string and expands $() before bash -c even starts.

There are two injection vectors in the vulnerable code path. Vector 1 (primary): $_SERVER[‘HTTP_HOST’] controls the $lok_allow argument and fires over both HTTP and HTTPS – this is the vector used in all documented wild attacks. Vector 2: over HTTPS only, $_SERVER[‘REQUEST_URI’] is also used to build a remote font config URL ($remoteFontConfig), which is similarly injectable. All publicly documented exploitation uses Vector 1.

Exploitation chain - shell quoting breakdown
HTTP_HOST value: victim.com$(id)
|
v escapeshellarg()
result: 'victim.com$(id)' <- looks safe (single-quoted) | v embedded into outer double-quoted bash -c argument bash -c "( $appImage ... 'victim.com$(id)' ...) >/dev/null & disown"
|
v outer exec() shell evaluates the double-quoted string
| single quotes inside double quotes = literal chars only
v
$(id) EXPANDS here <-- injection fires before bash even starts | v bash -c receives: uid=33(www-data) already substituted into the string The fix in commit 6cc8dae (September 9, 2026) wraps the entire inner command with escapeshellarg() before passing it to bash -c: proxy.php - Fixed (26.4.303+, commit 6cc8dae) // The entire inner command is now single-quoted at the outer shell level $lok_allow = "--o:net.lok_allow.host[14]=" . escapeshellarg($_SERVER['HTTP_HOST']); $innerCmd = "( $appImage $remoteFontConfig $IPv4only " . "$lok_allow --pidfile=$pidfile || " . "$appImage --appimage-extract-and-run $remoteFontConfig " . "$IPv4only $lok_allow --pidfile=$pidfile) >/dev/null & disown";

$launchCmd = "bash -c " . escapeshellarg($innerCmd);
exec($launchCmd);

Now the outer exec() shell sees bash -c ‘…’ – a single-quoted argument. Single quotes at the outer level prevent all special syntax interpretation. The injection is neutralized.

The fix progression across subsequent releases:

Impact: From a Request to Complete Server Compromise

The injected command runs as www-data – the web server user that owns the entire Nextcloud installation. That includes the web root, all PHP source, all configuration files, the data directory, and any secrets stored on the filesystem.

[Figure 1: Terminal showing curl command and resulting uid=33(www-data) confirmation – a single unauthenticated request executes id as www-data with no prior interaction.]

Credential Theft

Nextcloud’s config/config.php stores the database password, the application secret key (used to forge session tokens and email verification links), and the password salt used for all user password hashes. All are readable as www-data. Extracting them requires a single additional HTTP request to the planted webshell.

In a real attack, these three values (dbpassword, secret, passwordsalt) enable database access, Nextcloud session forgery, offline cracking of all user password hashes, and silent manipulation of any file or share in the installation.

Persistent Access

Attackers drop a PHP webshell into the richdocumentscode app directory, which is web-accessible. The webshell survives Nextcloud restarts and container reboots – only patching plus manual cleanup removes it. Wild-observed filenames follow two patterns: shx*.php and shrf*.php (e.g., shrf4645.php, shxa35d0.php, shx5cf91.php).

[Figure 2: Browser showing webshell response – grep output of config.php revealing dbpassword, secret, and passwordsalt values via a single unauthenticated HTTP request to the planted webshell.]

Why This Matters Beyond the Document Editor

The natural instinct is to scope this vulnerability to Nextcloud’s document-editing feature. That framing understates the risk. proxy.php is reachable from anywhere with a path to the Nextcloud URL – there is no document-editing action required, no user logged in, no session in flight. The attack fires on the health-check endpoint that the app uses to determine whether coolwsd is running.

That endpoint is queried every time a Nextcloud page loads, every time a monitoring system checks app health, and every time an attacker sends a probe. The precondition (coolwsd not running) is satisfied on every cold start and every container restart. In container-based deployments – which represent the majority of modern Nextcloud installations – this means the vulnerability is reliably exploitable within seconds of the container coming up, before any user ever opens a document.

The compromise is also deeper than the application layer. www-data in a Nextcloud container typically has access to the entire Nextcloud data tree, the database credentials in config.php, and any secrets mounted into the container at runtime. A file-sync platform for a healthcare or government organization holds not just credentials but the files themselves.

That changes the enterprise question from “is our document editor vulnerable?” to: What can an attacker reach once they have shell access to the Nextcloud server as www-data?

Attack Scenarios

Both scenarios below require only a single HTTP GET request for initial compromise. No authentication, no prior knowledge beyond the Nextcloud URL.

Scenario 1: Direct OS Command Execution

The simplest attack confirms code execution without leaving a persistent artifact. The attacker sends one request with a crafted Host: header. The injected command runs immediately as www-data.

Scenario 1 - Attack flow
Attacker
|
| GET /apps/richdocumentscode/proxy.php?status HTTP/1.1
| Host: target.com$(id>/tmp/pwned)
|
v
Nextcloud server (no auth check -- proxy.php bypasses middleware)
|
v
proxy.php: coolwsd not running --> startCoolwsd()
|
v
exec("bash -c \"... 'target.com$(id>/tmp/pwned)' ...\"")
|
v outer exec() shell expands $(id>/tmp/pwned)
|
v
/tmp/pwned: uid=33(www-data) gid=33(www-data) groups=33(www-data)
|
|--> Full OS command execution confirmed as www-data


Scenario 2: Webshell Persistence and Credential Extraction

Exploitation in the Wild

The first documented attacks occurred on September 10, 2026 – the day before the patch was released (September 11). Attackers exploited a 24-hour window between discovery and patch availability. CISA added the CVE to the KEV catalog on October 23, 2026, six weeks after exploitation began, with a federal agency remediation deadline of October 26, 2026.

Attack pattern: A single GET request to /apps/richdocumentscode/proxy.php?status with a crafted Host header containing a base64-encoded webshell drop command. Some attacks URL-encoded the injection as %24%28 to bypass WAF rules that blocked the literal $( sequence.

Observed webshell filenames in compromised deployments: shrf4645.php, shxa35d0.php, shx5cf91.php – located in /apps/richdocumentscode/. SHA-256 of one recovered sample: 4b9fbd0663fbfd6028fc216ed18e0d6ef3ae498a7fdc97083e4b0ce3cec40562.

Indicators of Compromise:

How Enterprises Should Respond

1. Patch Immediately

Upgrade richdocumentscode to 26.4.303 or later via the Nextcloud app store or the Admin → Apps panel. 26.4.303 applies the shell-quoting fix. 26.4.402 eliminates the shell invocation entirely via proc_open(). 26.4.502 adds HostFile enforcement and a proper HTTP 503 response when the app is disabled. Any version above 26.4.302 is not affected by this CVE.

2. Hunt for Planted Webshells

3. Rotate Exposed Credentials

If you cannot rule out that an attacker read config.php, treat these as compromised and rotate them:

• Database password (dbpassword) – change in both config.php and your database server.

• Application secret (secret) – invalidates all existing session tokens and email verification links.

• Password salt (passwordsalt) – requires re-hashing all user passwords; consider a forced password reset.

4. Restrict proxy.php Access While Patching

If immediate patching is not possible, block external access to /apps/richdocumentscode/proxy.php at the reverse proxy or firewall layer. Internal document-editing will be disrupted, but this closes the external attack surface until the patch is applied. Disabling the richdocumentscode app alone is insufficient in versions ≤ 26.4.402 – the file remains accessible.

5. Assess Your Exposure Surface

Query your asset inventory for all Nextcloud instances running richdocumentscode. Prioritize instances exposed to the internet, then internal instances reachable from untrusted networks. Any instance with the app installed and coolwsd not permanently running (the common state at startup) was vulnerable from the moment the container last restarted – the precondition is not a rare condition but the default state.

6. Review Log Detection Coverage

Closing: The Defender Arrived One Day Late

CVE-2026-110447 is a compound vulnerability: two technically correct decisions – using escapeshellarg() for input sanitization, and using a double-quoted bash -c argument for command composition – that become a critical flaw when combined. Each choice looks right in isolation. Together, they cancel each other out.

The shell quoting rule that produced this flaw is subtle enough to have surfaced in multiple projects across multiple years. The fact that escapeshellarg() was used at all demonstrates developer awareness of the risk; the flaw is in the precise context where the sanitized value lands, not in a failure to sanitize. That is exactly the category of vulnerability that evades code review: the reviewer sees the defensive function and moves on.

What makes this particularly instructive for defenders is the timeline. The first attacks were logged on September 10, 2026. The patch was released September 11. CISA KEV was added October 23. The gap between exploitation in the wild and widespread remediation was more than six weeks – in that window, every Nextcloud installation running richdocumentscode ≤ 26.4.302 that restarted its container was exploitable within seconds of coming up.

One request. No authentication. Full server compromise. The attack surface is any Nextcloud URL – a path with no context required beyond its existence.