SURIQ
A high-severity remote code execution bug in ONLYOFFICE Document Server, tracked as CVE-2026-110385, reached the public CVE catalog on October 14, 2026, a few days after the vendor shipped the fix inside Document Server 10.0. The record scores it 8.7 on the CVSS 4.0 scale. The headline is an RCE in one of the most widely self-hosted document backends on the internet. The detail that matters for your deployment is quieter: the attack runs through the Document Builder, and the only thing standing between a stranger and command execution is how you configured one JSON Web Token.
Here is the practitioner read, and why the word "authenticated" in the advisory undersells the exposure for a lot of installs.
What the flaw actually does
The Document Builder is ONLYOFFICE's server-side automation engine for generating and converting documents. One of its calls, builder.SaveFile(), takes an optional third argument that carries converter instructions as XML. According to the CVE record, that XML is not validated tightly enough. A request can smuggle in a second, duplicate output-path element (m_sFileTo), and the server honors the attacker's value instead of the one it generated. A save becomes an arbitrary file write, anywhere the ds service account can reach.
From there the chain is short. The write lands on runtime.json, the Document Builder's own runtime configuration. Control that file and you control which executable the Builder runs and with what arguments, so the next Builder job executes attacker-chosen commands as the ds account. It is a file-write-to-config-to-code-execution primitive, the same family as other self-hosted bugs where a write primitive turned into full control. The vendor's 10.0 changelog confirms the steps by name: it lists fixes for creating runtime.json through a Builder request, and for accepting an arbitrary filesystem path in the logging settings that runtime.json governs.
"Authenticated" is doing a lot of work
The CVE says the attacker needs a valid inbox-compatible JWT. Read fast, that sounds like a real barrier. In practice it is a configuration setting, not a user account, and it is the setting many self-hosted ONLYOFFICE deployments get wrong.
Inbound token validation lives in local.json, at /etc/onlyoffice/documentserver/local.json on Linux, under services.CoAuthoring.token.enable.request.inbox. If that is false, the server accepts unsigned requests and the token requirement is simply absent. If it is true but the inbox secret (services.CoAuthoring.secret.inbox.string) is weak, left at an example value, or shared across an integration that a wider set of systems can see, an attacker who learns it can mint the token the attack needs. So the real question for your install is not only "am I on a version before 10.0," it is "is inbound token validation on, and is my inbox secret strong and private." Plenty of instances sit behind Nextcloud, ownCloud, Zimbra, or Confluence integrations and are reachable from those application networks, which widens who can touch the Document Builder in the first place.
Affected versions, the fix, and exploitation status
-
Affected: ONLYOFFICE Document Server, every version before 10.0, on Linux, per the CVE record.
-
Fixed in: Document Server 10.0, released the week of October 10, 2026. The prior line was 9.4.
-
Exploitation: no public proof-of-concept and no reports of exploitation in the wild as of October 14, 2026. It is not in CISA's Known Exploited Vulnerabilities catalog. The CVE record and the vendor's changelog are the only public technical detail so far.
This is the second document-engine RCE worth a self-hoster's attention in recent weeks, after the LibreOffice document-open flaw. The common thread is that the dangerous surface is the conversion and rendering machinery, not the editor UI.
How you would know if you were hit
Patching closes the hole. It does not tell you whether someone walked through it in the window before you patched. Two observables are worth checking on any Document Server host that was exposed.
T1190 Exploit Public-Facing App a Document Builder SaveFile request whose converter XML carries a duplicate output-path element T1574 Hijack Execution Flow runtime.json rewritten to point the Document Builder at a new executable path or arguments T1059 Command and Scripting Interp the ds service account spawns a shell, interpreter, or network tool from a Builder job
Put file-integrity monitoring on the Document Builder's runtime configuration so any write to runtime.json raises an alert, and watch the ds service account for process ancestry it has no business having. A healthy Builder job does not launch a shell. This is the detection-over-patching habit we keep pressing on backend job runners, where the exploitable surface is a trusted internal engine rather than a login page.
Patch to 10.0, then check your token config
Upgrade Document Server to 10.0. That is the fix, and it is not optional given the executable-hijack primitive underneath. While you are in there, open local.json and confirm inbound token validation is enabled and the inbox secret is a long, unique, private string, not the example value and not something your integration leaks. If you cannot upgrade right away, enforcing token validation and restricting network access so only your front-end application can reach the Document Server both shrink the attack surface, though neither replaces the patch. Operators who run their own stack already know this drill from bugs like the WHMCS unauthenticated RCE: version first, configuration right behind it.
The pattern is the part worth filing away. A file-write became code execution because a configuration file was also a control file. Treat runtime config on your document, build, and automation servers as executable, because to an attacker holding a write primitive, it already is.