An unauthenticated attacker could run operating-system commands as your web-server user through document-editing middleware, the exploitation reports include dropped PHP webshells and credential-hunting commands, the vendor fixed it quietly five days before the first reported compromise, and the advisory explaining why that update mattered came a month later. This is the app-store patch surface written up three weeks ago on this site — "the app store is the part of the inventory that silently rots" — and this month it rotted all the way to a CISA Known Exploited Vulnerabilities entry.

The full disclosure: that October 16 roundup covered six Nextcloud advisories and is also the reason this post is late. The Collabora advisory was public on October 14. This site had it in hand two days later, covered the advisory batch instead, and missed the exploitation record underneath — the KEV listing on October 23 was this site's first signal too. A roundup of advisories is exactly the wrong instrument when the incident is running and the paperwork is what comes last.

The bug, and the condition that shapes everything

Collabora's advisory (GHSA-g3vx-3m76-fghh, CVE-2026-110447, CWE-78, CVSS v4.0 9.2) describes an unauthenticated OS command injection in proxy.php — part of the richdocumentscode app, Nextcloud's "Collabora Online – Built-in CODE Server" — where a crafted request causes an operating-system command to run as the web server user.

The CVSS vector reads AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H. That AT:P — attack requirements present — is the whole story. From the advisory:

The attack only works while the built-in CODE server is not running. So on a container restart, an upgrade, or after a crash.

Read that against how servers actually behave. Nobody's server avoids restarts, upgrades or crashes. Kernel updates reboot, occ app:update --all bounces the app, containers crash-loop on bad health checks and get restarted by the scheduler. On an unpatched instance, every one of those ordinary maintenance moments is one door open. To their credit, the reports do not claim an outsider can force the stopped state — and nobody has ruled it out either. The conservative reading is the one you already assumed: if the vulnerable version is installed, the precondition eventually holds, and public-facing Nextcloud hosts are probed constantly.

Two more facts from the advisory that operators should not skip:

  • It is not the same path as CVE-2025-66208, and the fix for that issue does not prevent this one. If your patch notes from 2025 say "upgraded the CODE proxy," you are not covered here.
  • Disabling the app is not sufficient. Vendor's words: "it must be upgraded to >= 26.4.303 or removed."

What exploitation actually looked like, per the administrator reports in the richdocumentscode issue tracker: crafted GET /apps/richdocumentscode/proxy.php?status requests carrying URL-encoded .. path traversal (%2e%2e) and shell command substitution, followed by PHP webshells named shx*.php written into the app directory. On one compromised server the attacker ran commands searching for credential files and cryptocurrency wallets. The same attack pattern and webshell family showed up on multiple independent installations — this was automation, not one operator with one grudge.

Scope, precisely — because the headline is doing too much

"Nextcloud is vulnerable" is the wrong sentence, and the coverage that used it wasted everyone's triage time. The accurate version:

Exposed: Nextcloud servers that installed the optional Built-in CODE Server app (richdocumentscode) at a version below 26.4.303, reachable over the internet.

Not affected (per Collabora's advisory and their public boundary statement, relayed on October 15): standalone Collabora Online servers, Collabora's Docker images, Collabora RPM/DEB packages, Nextcloud All-in-One images, and hosted Collabora services. Collabora also noted no Collabora Online customers (their own deployments) were affected — the flaw lives in the convenience wrapper Nextcloud ships for home users, not in Collabora Online proper.

If your organization connects Nextcloud to a properly installed Collabora (or LibreOffice-Online) instance, or only edits documents once in a blue moon without the built-in app, this CVE was never yours. If you clicked "install" on the built-in one because it was the easy path to sharing document edits with volunteers — this one is yours, and Collabora's framing puts the built-in app's audience at home users, which is exactly who runs the community instances where nobody is watching the app store.

One honest gap: the advisory names richdocumentscode only. Censys's fingerprinting also catches richdocumentscode_arm64 (about 1,001 of the hosts below) and the advisory never states whether the ARM64 package carries the same bug. If you run ARM64 Nextcloud, apply the same check and the same caution — treat it as affected until the advisory says otherwise.

The timeline is the story

Count the days backward from the advisory:

  • Sept 11 — richdocumentscode 26.4.303 ships with the fix, quietly, looking like any monthly bump.
  • Sept 16 — first malicious request in the issue-tracker reporter's access logs.
  • Sept–Oct — administrators report shx*.php webshells on independent installs.
  • Oct 14 — advisory + CVE go public (GHSA-g3vx-3m76-fghh).
  • Oct 15 — Collabora draws the deployment boundary publicly.
  • Oct 23 — CISA adds it to the KEV catalog — verified tonight against the live feed: dateAdded: 2026-10-23, dueDate: 2026-10-26.
  • Oct 26 — federal remediation deadline passes.

Count it: the fix and the advisory are 33 days apart. The first reported compromise is 28 days before the CVE existed. For those five weeks, the app store showed operators "update available" with the same severity-free face it shows every month, and nothing on the internet said the vulnerable version was being actively farmed for webshells. Community threads were telling people to update as early as October 3 — the crowd knew before any vendor document did.

This is the mirror image of the release-note accounting this site keeps documenting. The Gitea and Keycloak posts were about CVE numbers missing from notes. Here the notes themselves didn't exist yet: the fix preceded the advisory, the advisory preceded the KEV entry, and the exploitation record — the thing that would have moved a careful operator to the top of the queue — was the last thing to arrive. The only escalation signal most operators ever got was a federal government catalog.

Scale check: Censys's platform query serving the richdocumentscode fingerprint counts 19,454 hosts and 103,350 web properties — with the caveat the query's body-matching also catches pages that merely reference the app name, so read it as an upper bound on deployment, not a census of vulnerable instances. Even halved, it is a lot of community servers holding a webshell-planting door whose exposure condition is "restarted at some point."

What to actually do

```console

Is the app installed, and at what version?

occ app:list | grep -i richdocuments

or, reading the app's own metadata on disk (works inside containers too):

grep -m1 version apps/richdocumentscode/appinfo/info.xml

Version below 26.4.303? Update the app:

occ app:update richdocumentscode ```

  1. Upgrade to 26.4.303 or later, or remove the app. Those are the only vendor-endorsed options; disabling is not a fix. If the machine serves documents over the internet, do this before the next scheduled restart — remember, the window opens when the CODE server stops, so a half-updated instance that crashes mid-maintenance tonight is exactly the sequence the exploit needs.
  2. On Nextcloud 29 or older, there is no fix path. The vendor line is blunt: users of EOL Nextcloud ≤ 29 should upgrade their Nextcloud or remove the app. The fixed release itself requires Nextcloud 30 or later, so on an EOL branch the app is unpatchable — removal (or the Nextcloud upgrade you are avoiding) is the move.
  3. If the vulnerable version ran here at any point since mid-September, patching is not the end. A webshell planted in September keeps working on a patched October install. Hunt:

```console

the observed webshell family, right in the app directory:

ls -la apps/richdocumentscode/ | grep -i 'shx' find apps/richdocumentscode/ -name '*.php' -newer apps/richdocumentscode/appinfo/info.xml

the exploit probe shape in access logs (nginx example — adjust paths):

grep 'richdocumentscode/proxy.php' /var/log/nginx/access.log | grep -E '%2e%2e|..' ```

  1. Rotate what the web-server user could read. Commands ran as www-data (or your distribution's equivalent) — that account reads Nextcloud's config/config.php, which holds the database password and the instance secret, and writes PHP anywhere the web server executes. Rotate the database credentials and instance secrets, and inventory any app tokens stored on the box. If the access logs show proxy.php probes followed by POSTs to files you do not recognize, treat the machine as compromised and say so to the people whose minutes and case files live in it.
  2. If none of this applies — standalone Collabora, Docker, packages, All-in-One — there is no action for this CVE beyond routine updates. Enjoy that feeling; it is rare.

The part worth keeping

The KEV entry exists because exploitation was confirmed, and it is the honest instrument in the whole record: no score inflation, no vendor discomfort, just "this product, exploited, with a deadline." It is also free and greppable, which makes it one of the few government feeds worth wiring into the same nightly loop as advisories:

```console

which of your software is being actively farmed this month?

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \ | grep -o '"cveID": "[^"]*"' ```

A community server admin who ran that grep in late September would have seen nothing — the entry only landed October 23. A community server admin who ran it this week gets an answer that the CVE feeds only delivered five days earlier. The lag between the wild and the paperwork is the invariant here: it was five weeks for the KEV ledger to catch the webshells, thirty-three days for the fix to get an advisory, and the app store never said a word at any point. Second patch surface, exploitation record, federal deadline. The checklist item survives intact: occ app:list is half the risk register.

Sources: Collabora advisory GHSA-g3vx-3m76-fghh (published Oct 14, 2026); GitHub advisory GHSA-f97p-r72q-64h2; EUVD-2026-100780; richdocumentscode issue #354 — administrator reports of in-the-wild webshells and first malicious request Sept 16 (dates via Censys's advisory write-up, which also carries the fingerprint counts); CISA KEV catalog entry verified against the Oct 27 feed release (dateAdded 2026-10-23, dueDate 2026-10-26); Security Affairs on the KEV listing; The Hacker News on the GitHub reports; community-aggregator write-up with the full timeline for cross-check.