0xmrma/cve-2026-34212Docmost a accepté une URL javascript: à l'intérieur d'un attachment node, l'a préservée lors du stockage et du rendu, et l'a retransformée en une ancre cliquable dans l'origine de Docmost.
Docmost a accepté une URL de type javascript: dans un nœud de pièce jointe, l’a conservée lors du stockage et du rendu, et l’a transformée en un lien cliquable dans l’origine de Docmost.
J’ai identifié, divulgué de manière responsable et reproduit un problème de stored XSS de sévérité élevée dans Docmost, la plateforme de documentation collaborative open-source.
Le site officiel de Docmost le présente comme un wiki interne prêt pour l’entreprise avec plus de 3 millions de téléchargements, et indique qu’il est utilisé par des équipes d’organisations telles que Vilnius City, Bechtle, le gouvernement australien, la Croix-Rouge et ETS Québec.
Le bogue se trouvait à un endroit facile à manquer dans les systèmes de texte enrichi :
pas dans l’extension de lien ordinaire, mais dans un type de nœud personnalisé distinct utilisé pour les pièces jointes.
Je passais en revue le pipeline de l’éditeur avec une question très précise en tête :
si les liens normaux bloquent les URLs javascript:, les nœuds de pièces jointes appliquent-ils la même règle avant d’atteindre un sink d’ancrage ?
Dans les versions vulnérables, ce n’était pas le cas.
Docmost acceptait un nœud de pièce jointe malveillant dans le JSON de la page, stockait son attribut url sans modification, puis rendait cette valeur sous la forme d’un élément <a href="javascript:..."> cliquable.
Ce problème est devenu CVE-2026-34212.
Docmost : docmost/docmost
Avis : GHSA-cf68-cff9-hq4w
CVE : CVE-2026-34212
Corrigé dans : v0.71.0
URL du nœud de pièce jointe contrôlée par l’attaquant -> JSON de la page accepté et stocké sans modification -> rendu HTML/React transformant cette URL en href d’ancrage -> victime clique sur l’action de la pièce jointe -> JavaScript contrôlé par l’attaquant s’exécute dans l’origine de Docmost
Docmost stocke le contenu des pages dans un format JSON compatible avec ProseMirror/Tiptap.
Ce modèle de contenu inclut des nœuds de bloc personnalisés pour des éléments tels que :
Le nœud de pièce jointe stocke des champs comme :
urlnamemimesizeattachmentIdLe serveur accepte le contenu des pages dans plusieurs formats :
jsonmarkdownhtmlet le normalise en JSON ProseMirror avant de le stocker.
Cela signifie que tout type de nœud pouvant porter une URL fait partie d’une frontière de confiance directe.
Si l’un de ces types de nœuds finit par être rendu sous la forme d’un <a href>, la gestion des schémas d’URL n’est pas facultative.
Elle fait partie du modèle de sécurité.
Les extensions d’éditeur personnalisées sont une source fréquente de dérive de sécurité.
Le système de base peut déjà savoir comment traiter correctement les URLs dangereuses, mais chaque nœud personnalisé doit réappliquer les mêmes règles à ses propres sinks.
Cela crée une stratégie de révision prévisible :
C’est exactement ce qui a exposé ce bogue.
L’extension de lien normal de Docmost traitait déjà javascript: comme dangereux.
Son nœud de pièce jointe ne le faisait pas.
Une fois que vous voyez cette asymétrie, la question de sécurité devient évidente :
puis-je persister un nœud de pièce jointe dont l’url est javascript: et obtenir qu’il soit rendu sous forme d’ancrage actif ?
La réponse était oui.
La cause racine était un nettoyage d’URL incohérent entre les types de nœuds de contenu.
Le chemin de contenu côté serveur acceptait des URLs de pièces jointes arbitraires tant que le contenu global correspondait au schéma ProseMirror.
Dans la version vulnérable :
CreatePageDto acceptait content?: string | objectPageService.parseProsemirrorContent() normalisait markdown, html ou jsonjsonToNode(prosemirrorJson)Cette étape de validation vérifiait la validité structurelle, pas la sécurité de l’URL.
La partie critique de la logique serveur vulnérable était effectivement :
prosemirrorJson = content;
jsonToNode(prosemirrorJson);
return prosemirrorJson;
Aucune normalisation de schéma d’URL de pièce jointe n’avait lieu ici.
Plus tard, l’extension de pièce jointe rendait directement la valeur contrôlée par l’attaquant.
Le nœud de pièce jointe vulnérable faisait ceci :
url: {
default: "",
parseHTML: (element) => element.getAttribute("data-attachment-url"),
renderHTML: (attributes) => ({
"data-attachment-url": attributes.url,
}),
},
puis :
[
"a",
{
href: HTMLAttributes["data-attachment-url"],
class: "attachment",
target: "blank",
},
`${HTMLAttributes["data-attachment-name"]}`,
]
Côté client, la vue de nœud React encapsulait cela à nouveau dans :
<a href={getFileUrl(url)} target="_blank">
Mais getFileUrl() ne traitait de manière spéciale que :
http absolues/api/.../files/...Tout le reste était renvoyé sans modification.
Ainsi, une charge utile comme :
javascript:alert(document.domain)
survivait à :
Cela seul serait déjà suffisant pour une XSS stockée.
Ce qui rend la cause racine particulièrement claire, c’est le point de comparaison.
L’extension de lien normal de Docmost bloquait explicitement javascript: :
javascript: dans parseHTML()javascript: dans renderHTML()Le produit savait donc déjà que ce schéma était dangereux.
Le nœud de pièce jointe n’a tout simplement pas appliqué la même politique.
Voilà pourquoi ce n’était pas une « XSS générique dans l’éditeur ».
C’était un écart de frontière de confiance propre à un nœud.
Ce bogue ne concernait pas simplement une esthétique HTML dangereuse.
Il permettait à un attaquant capable de modifier une page de persister une charge utile malveillante qui s’exécuterait plus tard dans l’origine de Docmost lorsqu’un autre utilisateur interagirait avec la pièce jointe rendue.
Cela compte car un script dans l’origine peut :
L’exigence d’un clic ne réduit pas cela à un problème trivial.
Le clic fait partie du comportement normal du produit : l’interface utilisateur présente intentionnellement la pièce jointe comme un lien/icône actionnable.
La question de sécurité n’est donc pas « l’attaquant peut-il forcer du JS arbitraire sans aucune interaction ? »
La vraie question est :
l’application stocke-t-elle du contenu porteur de script contrôlé par l’attaquant et le présente-t-elle ensuite à d’autres utilisateurs comme un chemin d’interaction de confiance ?
Dans les versions vulnérables, oui.
C’est une XSS stockée.
Le chemin d’exploitation était simple :