Changed since version 2

• Sources renumbered: S1 is now The Hacker News, S2 the richdocumentscode GitHub issue #354, S3 BleepingComputer (previously S1); citations remapped throughout [S1][S2][S3].
• What happened: added the exploit path detail (proxy.php?status with $(...), ${IFS}, base64 -d|sh) [S1] and uname -a beaconing to webhook.site [S2].
• Hunt 2 now counts ?c= requests to shell files and starts September 1 [S2].
• Hunt 3 adds the Chrome/126.0 user agent from today's indicators.
• Hunt 4 widened from sudo only to sudo plus vault and wallet search by the web server account [S1][S2].
• Verify adds a process-history check for vault and wallet searches and a webhook.site workstation look-alike [S1][S2].
• Eradicate filled in from sourced persistence (web shells only) [S1].
• Contain: IP blocking no longer cited to a single source because the indicator list is unattributed.
• Debrief and open questions add unattributed indicators, inconsistent story dates and the post-dated KEV entry.

What happened

• Unauthenticated GET requests to /apps/richdocumentscode/proxy.php?status carrying $(...), ${IFS} and base64 -d|sh in the path executed shell commands on the server [S1].
• The flaw is reachable only while the built-in CODE server is stopped, for example after a restart, upgrade or crash [S3].
• Attackers wrote shx*.php web shells that run shell_exec on the c GET parameter, then used them to search for password vaults, password manager artifacts and crypto wallets [S1][S3].
• Payloads sent uname -a output to a webhook.site address [S2].
• One admin learned of the break-in from emails about failed sudo attempts by the web server account [S2].
• Fixed in richdocumentscode 26.4.303 [S1].

Timeline

Detect

Injection attempts against richdocumentscode proxy.php · Web server access log

index=* "/apps/richdocumentscode/proxy.php" ("%24%28" OR "$(" OR "IFS" OR "%2e%2e" OR "base64") earliest=09/01/2026:00:00:00 | stats count min(_time) as first max(_time) as last values(status) as status by host src http_user_agent

A hit means: A request matching the reported exploit pattern reached the app. Alone it shows an attempt; a 200 response followed by a shx*.php request points to success [S1].

Requests to generated web shells · Web server access log

index=* "/apps/richdocumentscode/" ".php" earliest=09/01/2026:00:00:00 | regex _raw="/apps/richdocumentscode/sh[a-z]?[0-9a-f]{4,6}\.php" | eval c_param=if(match(_raw,"\.php\?c="),1,0) | stats count sum(c_param) as c_param_requests min(_time) as first values(status) as status by host src

A hit means: Someone requested a file matching the reported shell naming. A 200 response, especially with ?c= such as ?c=id, means a shell likely exists and was used [S1][S2].

Known indicators · Proxy, DNS, firewall, web and EDR logs

index=* ("89.38.98.50" OR "139.28.18.122" OR "webhook.site" OR "4b9fbd0663fbfd6028fc216ed18e0d6ef3ae498a7fdc97083e4b0ce3cec40562" OR "shxa35d0.php" OR "shxd33ce.php" OR "shx13a86.php" OR "shx5cf91.php" OR "shxf4645.php" OR "shx56367.php" OR "shrf4645.php" OR "Win64; x64) Chrome/126.0") | stats count min(_time) as first by host src dest

A hit means: Contact with or presence of an indicator supplied with this thread. webhook.site is a public service and the user agent is generic, so a server-originated webhook.site connection or a shell filename is the meaningful case [S2].

Escalation and credential search by the web server account · Linux auth log and EDR process events

index=* ("www-data" OR "apache" OR "nginx") (sudo OR ".kdbx" OR "wallet.dat" OR "keystore.json" OR "bitwarden" OR "1password" OR ".electrum" OR ".bitcoin" OR ".monero" OR ".ethereum" OR "base64 -d") | stats count min(_time) as first values(process) as process by host user

A hit means: The web server account tried sudo or searched for vaults and wallets, the reported post-exploitation steps. Treat the host as compromised and secrets as exposed [S1][S2].

Verify

• Confirm the host runs Nextcloud with the built-in richdocumentscode app below 26.4.303, not a standalone, package or AIO Collabora deployment [S1][S3].
• Look for shx*.php files in the app folder; reported shells contain shell_exec on $_GET['c'] [S1].
• Run the Nextcloud integrity check for unexpected PHP files in the app directory [S1].
• Correlate a proxy.php injection request with a later shx*.php file or request and server egress to webhook.site [S1][S2].
• Check process history for find or search commands targeting .kdbx, wallet.dat, keystore.json or password manager paths after the first injection request [S1].
• Benign look-alike: normal proxy.php?status polling without $(, ${IFS}, %2e%2e or base64 in the path.

Scope

Affected

• Nextcloud servers running the Collabora Online Built-in CODE Server app (richdocumentscode) before 26.4.303 [S1]

Only if

• The built-in CODE server is stopped, for example after a restart, upgrade or crash [S3]
• proxy.php is reachable by the attacker; no authentication is required [S1][S3]

Not affected if

• richdocumentscode is not installed or is at 26.4.303 or later [S1]
• Collabora runs as a standalone server, from Docker, RPM or DEB packages, or as part of Nextcloud AIO [S3]

Fixed in: richdocumentscode 26.4.303 [S1]

Enumerate

• All Nextcloud instances, including shadow or departmental ones, and whether each is internet-facing
• Collabora deployment type per instance: built-in CODE app versus standalone, package or AIO
• richdocumentscode app version on each instance, including instances where it is disabled but still installed
• Files in each apps/richdocumentscode directory created since September 10
• Secrets readable by the web server account on affected hosts: password databases, password manager artifacts, keys, wallets and config credentials
• Other hosts reachable from an affected Nextcloud server

Contain

• Preserve first: copy web access logs back to September 10, any shx*.php files, auth logs and a disk or memory image of suspect hosts.
• On any unpatched instance, upgrade richdocumentscode to 26.4.303 or remove the app; disabling it is reported as insufficient [S1][S3]. Cut internet exposure until done.
• Block server egress to webhook.site [S2] and the IPs supplied with this thread's indicators.
• On confirmed hosts, isolate the server and rotate every credential readable by the web server account, including password manager and database contents. Data already read cannot be recalled [S1][S3].
• Deleting web shells or rebuilding the host destroys evidence and cannot be undone; do it only after preservation.

Eradicate

• Remove every shx*.php or similar file the integrity check flags in apps/richdocumentscode [S1].
• Remove or upgrade the vulnerable app to 26.4.303 or later [S1].
• Sources describe no persistence beyond web shells; if any is found, rebuild rather than clean.

Recover

• Before restoring, confirm the app is at 26.4.303 or later or removed, the integrity check is clean and no shx*.php files remain [S1].
• Afterwards, monitor proxy.php requests with injection characters, new PHP files in the app folder, sudo use by the web server account and egress to webhook.site [S1][S2].
• Watch rotated accounts, password manager vaults and any wallets for misuse.

Re-enter the loop when

• Collabora or Nextcloud publishes an advisory that changes affected versions, the stopped-server condition or the fix.
• Exploitation is reported against standalone, package or AIO Collabora deployments.
• New shell names, payload hosts or exfiltration endpoints appear in the GitHub issue or reporting [S2].
• A hunt finds activity before September 10 or on a host thought out of scope.

Debrief

• Record the earliest exploit request found against the reported September 10 start [S3].
• Record whether the CODE server was stopped at the time of compromise.
• Record which hosts had the app disabled rather than removed or upgraded.
• Record which secrets were readable and which were rotated.
• Source gap: no vendor or CERT advisory is among the sources; the fix version and the disable-is-insufficient claim come from secondary reporting.
• Source gap: no persistence beyond web shells and no confirmed exfiltration beyond uname -a to webhook.site are described.

Detection coverage — checked automatically

Checked automatically 2026-10-31 23:30Z from public sources: 6 published, 21 nothing found, 0 not machine-checkable, 0 failed. "Nothing found" means the public source answered and had nothing, as of that moment; a feed covers only its newest posts. Re-checked daily.

Exposure queries — generated automatically

vuln:CVE-2026-110447

cpe:"cpe:/a:collabora:collabora_online_-_built-in_code_server"

product:"Collabora Online - Built-in Code Server"

host.services: (software.product = "Collabora Online - Built-in Code Server")

Banner spellings: a model read 4 from the NVD names and this card's text (former and marketing names, console titles); 0 matched something on Shodan and are shown above, the rest were dropped.

Scope every query in your own tool, never in a shared document: Shodan `net:<your_ranges>`, `org:"<your_org>"` or `hostname:<your_domain>` (or a Shodan Monitor network alert, which applies the scope for you); Censys `host.ip: <your_ranges>` or `host.dns.names: <your_domain>`. Then compare the banner version with the affected range. Generated automatically 2026-10-31 23:30Z from the CVE ids and NVD's CPE configurations, each Shodan query counted against Shodan itself; re-built daily with the coverage check.

Open questions

• Is there a Collabora or Nextcloud advisory, CVSS score and official disclosure date for CVE-2026-110447?
• Which source attributes 89.38.98.50, 139.28.18.122, the SHA-256 and the Chrome/126.0 user agent, and what role does each play?
• Story dates are inconsistent: the thread is labelled oldest first, but the earlier entry is dated 2026-10-16 and today's 2026-10-15.
• The prior draft's coverage data lists a CISA KEV addition dated 2026-10-23, after the brief date; this needs checking before any KEV claim is made.
• Does the stopped-server condition hold for every exploitation path, or only the one reported?

Sources

• [S1] https://thehackernews.com/2026/10/hackers-backdoor-nextcloud-servers.html · The Hacker News
• [S2] https://github.com/CollaboraOnline/richdocumentscode/issues/354 · GitHub
• [S3] https://www.bleepingcomputer.com/news/security/hackers-exploit-collabora-rce-flaw-to-backdoor-nextcloud-servers/ · BleepingComputer

Public OSINT only. AI-generated by the pipeline; structure follows the DAIR model from Dynamic Incident Response (Joshua Wright). Published automatically once it crosses the publish bar.