Recovery Proof After the Nextcloud richdocumentscode Exploit
Closing CVE-2026-110447 requires more than a successful package update. The advisory requires richdocumentscode version 26.4.303 or later, or removal of the app. The exploitation reports add a second requirement: a host that was exposed during the vulnerable period must be checked for web shells, credential access, and persistence. Recovery is complete only when both the vulnerability and the compromise question have evidence behind them.
The event is specific enough to support a useful verification plan. The affected app is optional. Standalone Collabora Online servers are not affected. The vulnerable request reaches proxy.php. The attack works while the built-in CODE server is not running. Reported webshell examples use shx*.php names and execute a query parameter as a shell command. The public report does not establish a victim count, so an organization should not use an external match as a substitute for its own inventory.
Define the closure criteria
Start with four closure criteria. The application is fixed or removed. The public route is controlled. The host has been checked for exploitation and persistence. Credentials and sessions reachable by the web server account have been reviewed and remediated where necessary.
The first criterion is a version or absence check. Read the installed richdocumentscode version from the host. If the app is needed, it must be at least 26.4.303. If it is not needed, confirm removal and check that the application directory and endpoint are no longer present. The advisory warning that disabling is insufficient should be reflected in the exception process.
The second criterion is an external and internal route check. Request the relevant Nextcloud path from a network that represents the attacker's reach. Confirm that it returns the intended denial or safe response and does not reach a vulnerable app. Repeat the check through alternate hostnames, proxies, or load-balancer nodes if those paths exist.
Prove the compromise review
The third criterion is a documented host review. Collect access logs for the vulnerable period and search for requests to richdocumentscode/proxy.php with encoded traversal or command substitution. Review the application directory for unexpected PHP files, including the shx*.php examples. Compare the filesystem with the approved package or container image.
Look for process activity under the web server and PHP-FPM identity. The reported payload can spawn a shell and execute a query parameter. Review outbound connections and proxy records for callback behavior. Check for changes to application configuration, scheduled tasks, startup hooks, web-server configuration, and other persistence that the account could modify.
If the host uses a container, inspect the image and mounted volumes as well as the running layer. If the evidence is unavailable because the container was replaced, state that limitation and use the rebuild as an opportunity to establish a trusted baseline. Do not describe an unobserved filesystem as clean.
Address credentials and sessions
The web server account may have access to database credentials, application secrets, mail credentials, object-storage keys, integration tokens, and user-uploaded files. Issue 354 reports commands that searched for password databases, password-manager artifacts, and cryptocurrency wallets. Those reports establish the attacker's interest and capability. They do not prove that every host contained those files or that every file was taken.
Inventory the resources available to the compromised identity. Rotate high-value credentials from a clean system. Revoke active sessions and tokens where the provider supports revocation. Verify that old credentials no longer work. Confirm that integrations and users can operate with the replacement values. Keep the rotation evidence with the incident record.
If the investigation cannot determine whether a secret was read, use a conservative remediation decision based on the account's actual access. This is different from claiming exfiltration. The report should say which facts are confirmed, which are possible, and which have been mitigated.
Rebuild or clean with a reason
A trusted rebuild is the strongest option when an attacker had command execution and the host's integrity cannot be established. It removes uncertain filesystem changes and gives the team a reproducible baseline. Restore only reviewed configuration and data, then rotate secrets that were available to the old host.
Cleaning in place is reasonable only when the scope is understood and the team can account for every change. Replace application files from a trusted release, remove confirmed persistence, inspect configuration and startup paths, and compare the result with the expected build. A single shell deletion is not a complete recovery.
After the rebuild, re-run the version and route checks. Validate that the app is absent or fixed. Test that users can perform the required document workflow through an approved path. Confirm logging and monitoring are connected before returning the service to its normal exposure.
Use external context without overclaiming
ZoomEye can help find public pages that mention the application, but it cannot verify recovery on a specific host. On November 5, 2026, the query http.body="richdocumentscode" returned 122,126 all-asset matches. The combined Nextcloud-title query returned 109,876, and an exact endpoint-string query returned 20. These are page-string observations in indexed responses, not vulnerable or recovered server counts.
Use the external observation to identify pages that need an owner. Use the closure evidence to decide whether a host is remediated. The evidence package should include version output, removal records, route tests, log search scope, filesystem results, credential rotation, session revocation, and the final owner approval.
A completion statement that holds
A defensible completion statement names the actual result. For example: "richdocumentscode was upgraded to a verified 26.4.303 or later on the host; the vulnerable proxy route was checked from an external network; access logs for the affected period were reviewed; no unexpected PHP files or shell processes were found; exposed application credentials were rotated; the owner approved return to service."
If any clause is unknown, leave it unknown and keep the task open. The incident's value is not a claim that every public match is fixed. It is a repeatable path from the advisory to a host record, from the host record to evidence, and from evidence to a defensible recovery decision.
Top comments (0)