Detection Engineering for the richdocumentscode Command Injection
Detection Engineering for the richdocumentscode Command Injection CVE-2026-110447 is not a quiet file-format bug. The exploit path leaves several opportunities for detection: an unusual HTTP request, a shell process cr
Detection Engineering for the richdocumentscode Command Injection
CVE-2026-110447 is not a quiet file-format bug. The exploit path leaves several opportunities for detection: an unusual HTTP request, a shell process created by the web stack, a new PHP file in the application directory, or an outbound connection from the web server. A detection program should use those layers together.
The Collabora advisory identifies proxy.php in the Nextcloud richdocumentscode app as the vulnerable path. A request can run an operating system command as the web server user when the local CODE server is stopped. Issue 354 provides observed request features, including /apps/richdocumentscode/proxy.php?status, %2e%2e, %24%28, ${IFS}, base64 decoding, shell execution, and later requests to shx*.php files. The examples are valuable because they connect the code flaw to evidence that a defender can test.
Model the attack sequence
The first stage is a request to the vulnerable route. The request may include encoded traversal or command substitution. The second stage is command execution under the web server or PHP process. The third stage may create a file in a web-accessible directory, contact a callback service, or run discovery commands. Later requests to the generated file may execute additional commands.
No single event is reliable in every deployment. A request can be blocked by an edge control. A process may not be visible without EDR. A transient container may lose its filesystem evidence. Detection coverage should be documented per host, not assumed from the presence of one log source.
Build layered rules
The HTTP layer should capture the full URI and relevant headers for requests to richdocumentscode proxy paths. A high-signal condition is the combination of the route, traversal or command substitution markers, and a successful response. A generic alert on every richdocumentscode request will be noisy. The rule should preserve the raw request for investigation.
The process layer should look for shell interpreters, base64 utilities, curl, wget, discovery commands, or other unexpected children of the web-server and PHP-FPM process. A web application may legitimately call shell utilities in some environments, so baseline the approved behavior. Alert on the unusual parent-child relationship and command line, not merely on the name of a utility.
The filesystem layer should detect new PHP files in the richdocumentscode app directory. The reported names begin with shx in the examples, but the rule should cover unexpected files that are not in the package manifest. File creation by the web server account is useful context. Hash and content review separate a true shell from a benign deployment artifact.
The network layer should monitor outbound connections from the web application to unfamiliar destinations. Issue 354 reported webhook.site in the exploit request. A generic collaboration service can be legitimate elsewhere, so use the application identity, destination, timing, and parent process together. Include proxy and DNS telemetry when direct connection logs are unavailable.
Make correlation the primary signal
A request match becomes stronger when it is followed by a process event, a file event, or a network event on the same host within a short interval. A file event becomes stronger when a later HTTP request targets the new path. A shell process becomes stronger when its command line includes discovery or download activity.
Store the timestamps in a common timezone and keep the host identity stable across container restarts. A correlation rule that joins anonymous events without an asset identifier will create both false positives and missed links. The data model should include the application version and whether the local CODE server was running.
An analyst should be able to move from an alert to the raw request, the process tree, the file metadata, and the owner. If one link is unavailable, the case should record the gap rather than mark the chain complete.
Test before production
Use controlled test data that resembles the observed request without executing a real payload against production. Confirm that the HTTP parser captures the full URI, that the proxy does not rewrite the interesting characters, and that the process sensor reports the child process. Test a benign application update to see which file events occur, then tune the rule to avoid treating normal deployment as a web shell.
Review alert ownership. The application team can confirm version and expected behavior. The security team can validate the indicator and coordinate incident response. The infrastructure team can preserve logs and isolate the host. A rule without an accountable owner is likely to become a dashboard artifact.
The external layer can support prioritization. On November 5, 2026, ZoomEye returned 122,126 all-asset page matches for http.body="richdocumentscode". The count finds public references to the application name. It does not replace authenticated asset data, request logs, or process telemetry.
Measure detection quality
Track whether rules are deployed on all Nextcloud environments, whether they capture the vulnerable route, and whether they retain evidence long enough for the investigation. Track the number of hosts whose process and filesystem coverage is unknown. Those numbers matter more than the number of alerts generated.
Run a tabletop exercise using the public issue. Ask the team to identify the host, establish whether the affected version was installed, determine whether the local CODE server was stopped, review the request, and decide whether a web shell exists. The exercise will reveal missing log fields and unclear ownership before a real alert.
The final detection goal is not to prove that every public match is an incident. It is to make the path from a suspicious request to a defensible host decision fast and repeatable. Patch the vulnerable app, preserve the evidence, and verify that the correlation still works after the remediation.
References
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.