Two Addresses and a Public Callback Service: Pivoting on the CVE-2026-110447 Indicators
What the operators left behind
The public record for this incident includes a small set of network indicators, worth examining for what they can and cannot support.
The first reporter listed two source addresses: 139.28.18.122 for the attacks on September 10 and 11, and 89.38.98.50 for a later attempt on September 14 against a server that had already been patched. The callback domain was webhook.site, a legitimate service for testing HTTP requests, with two callback identifiers recorded: 45060ed4-de0b-4119-8f0d-2a2776bbd413 and 774cf5e1-b5a4-4174-a1ad-0241861029a2.
Why a public callback service is a weak signal
webhook.site is not attacker infrastructure. It is a tool anyone can use, and it appears in benign development traffic constantly. Blocking it outright is likely to break legitimate work, and treating a request to it as proof of compromise generates noise.
What made it relevant here is the combination: a request to proxy.php?status whose path carried a command that base64-decoded into a file write, followed by a curl of the server's uname -a output to a webhook.site URL. Any one element alone is weak. Together they describe an operator checking that a shell works.
Pivoting on the addresses without overclaiming
The two addresses are the more actionable indicators, with the usual caveat that hosting providers reassign addresses and a shared host can carry unrelated tenants.
A defensible use is retrospective search: query web logs for requests from those addresses to any path under /apps/richdocumentscode/. That is a bounded question with a clear answer. A blocklist entry assuming the operator will not change addresses is less defensible, and the September 14 attempt already contradicts it.
The payload structure is the better pivot
The payload structure outlives the addresses. Three markers appear in the logged requests: %2e%2e for traversal, $( and ${IFS} for shell expansion and whitespace substitution, and a long base64 string piped into sh. The recovered shell is a one-line PHP file with the SHA-256 hash 4b9fbd0663fbfd6028fc216ed18e0d6ef3ae498a7fdc97083e4b0ce3cec40562.
A rule built on the path plus the base64-to-shell pattern catches this tooling regardless of source address, a better investment than address blocking because the tooling is what the operator reuses.
Building an indicator set that survives
A practical indicator set has four parts. Addresses 139.28.18.122 and 89.38.98.50, for retrospective log search and short-term watch. The path /apps/richdocumentscode/proxy.php?status, for request-pattern rules. The webhook.site callback identifiers, for matching specific requests rather than the service as a whole. The web shell hash and the shx*.php filename pattern, for file-based detection.
None of that provides a count of affected hosts. A body search over http.body="richdocumentscode" returned 121131 matches on 2026-10-20 and describes exposure only. Indicator lists describe behaviour, and behaviour is what turns exposure into an incident.
References
- richdocumentscode issue #354: https://github.com/CollaboraOnline/richdocumentscode/issues/354
- Collabora advisory GHSA-g3vx-3m76-fghh: https://github.com/CollaboraOnline/online/security/advisories/GHSA-g3vx-3m76-fghh
- CVE-2026-110447 record: https://www.cve.org/CVERecord?id=CVE-2026-110447
