CVE-2026-34212: Stored XSS in Docmost Attachment Nodes via Unsanitized URL Schemes · 0xMRMA
CVE
CVE-2026-34212: Stored XSS in Docmost Attachment Nodes via Unsanitized URL Schemes
Docmost accepted a javascript: URL inside an attachment node, preserved it through storage and rendering, and turned it back into a clickable anchor in the Docmost origin.
I identified, responsibly disclosed, and reproduced a High-severity stored XSS issue in Docmost, the open-source collaborative documentation platform.
Docmost’s official site presents it as an enterprise-ready on-premises wiki with 3M+ downloads, and says it is trusted by teams at organizations including Vilnius City, Bechtle, the Australian Government, the Red Cross, and ETS Quebec.
The bug sat in a place that is easy to miss in rich-text systems:
not in the ordinary link extension, but in a separate custom node type used for file attachments.
I was reviewing the editor pipeline with a very specific question in mind:
if normal links block javascript: URLs, do attachment nodes enforce the same rule before they reach an anchor sink?
In vulnerable versions, they did not.
Docmost accepted a malicious attachment node in page JSON, stored its url attribute unchanged, and later rendered that value back into a clickable <a href="javascript:..."> element.
This bug was not merely about unsafe HTML aesthetics.
It allowed an attacker who could edit a page to persist a malicious payload that would later execute in the Docmost origin when another user interacted with the rendered attachment.
That matters because in-origin script can:
read data the victim can access
issue authenticated requests as the victim
modify content the victim is allowed to modify
abuse any DOM or API surface exposed to the session
The requirement for a click does not reduce this to a trivial issue.
The click is part of the normal product behavior:
the UI intentionally presents the attachment as an actionable link/icon.
So the security question is not "can the attacker force arbitrary JS without any interaction?"
The real question is:
does the application store attacker-controlled script-bearing content and later present it back to other users as a trusted interaction path?
any user with page edit rights could plant the payload
the malicious URL survived storage unchanged
the page rendered normally
viewers only needed standard access to the page
one click on the attachment action was enough to trigger execution
This also made higher-privileged users realistic targets.
If a workspace owner, admin, or broadly trusted editor viewed attacker-controlled content and clicked the attachment action, the attacker's script would run in that more privileged session context.
That is the important practical point:
the attacker's privilege requirement was only low.
The victim's privilege level determined how much value the XSS session carried.
The fix shipped in v0.71.0 and addressed the rendered exploit path by applying URL sanitization to attachment URLs.
The attachment extension now imports and uses sanitizeUrl, including:
sanitizing data-attachment-url during parsing
sanitizing data-attachment-url during rendering
sanitizing the anchor href
Conceptually, the patch changed the attachment node from:
trust raw attachment URL
emit raw attachment URL
to:
normalize attachment URL before it becomes part of the rendered node
The client-side helper getFileUrl() was also updated so that unknown schemes no longer pass through untouched.
In the patched version, the fallback path returns sanitizeUrl(src) instead of returning src as-is.
That is an important part of the fix because the vulnerable design had two reinforcing problems:
the node rendered a raw href
the client fallback treated unknown schemes as acceptable
The patch removed both assumptions.
This was a good fix for the live XSS path because it brought attachment URL handling back into alignment with the rest of the editor's security model.
That said, there is still a broader hardening lesson:
client-side or render-time sanitization is necessary here, but server-side rejection of dangerous schemes during page create/update would be an even stronger invariant.
CWE-79: Improper Neutralization of Input During Web Page Generation
CVSS v3.1:
TEXT
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:N
That lands at 7.6 / High.
This is a defensible classification.
The important properties are:
low attacker privilege requirement
stored payload
execution in the Docmost origin
scope change
meaningful confidentiality impact because the script can access victim-visible in-app data
User interaction remains required because the victim has to activate the attachment link/icon.
That is why UI:R is correct.
But once that interaction happens, the security boundary has already failed much earlier:
the application stored a dangerous scheme and rendered it back into an execution sink.
It was about a custom content node that bypassed the application's own URL safety assumptions.
Docmost accepted an attacker-controlled attachment URL, preserved it through storage, and then rendered it back into a live anchor in the application origin.
That is why it became CVE-2026-34212.
The patch in v0.71.0 closed the active XSS path cleanly, but the broader lesson is the one worth keeping:
in editor-heavy applications, every custom node that can carry a URL is its own security boundary, and it has to be reviewed like one.
