0xmrma/cve-2026-33146
Un partage public semblait propre dans l'arborescence de pages, mais le point de terminaison de recherche racontait une histoire différente. Dans Docmost, les pages enfants restreintes, cachées des spectateurs du partage public, pouvaient encore fuir à travers les résultats de recherche du partage public.
Un partage public semblait propre dans l'arborescence des pages, mais le point de terminaison de recherche racontait une histoire différente. Dans Docmost, les pages enfants restreintes, masquées aux visiteurs du partage public, pouvaient tout de même fuiter via les résultats de recherche du partage public.
J'ai découvert ce problème en examinant Docmost, une plateforme wiki et de documentation collaborative open-source, avec une question très simple en tête :
Si une page est intentionnellement masquée à un visiteur de partage public, est-ce que toutes les fonctionnalités publiques respectent cette même restriction ?
Dans ce cas, la réponse était non.
Une page enfant restreinte pouvait rester cachée dans l'arborescence du partage public tout en fuitant via le point de terminaison de recherche du partage public.
Le problème a été accepté et a reçu l'identifiant CVE-2026-33146.
Docmost : Docmost sur GitHub
CVE : CVE-2026-33146
Le site officiel de Docmost le présente comme un wiki sur site 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 comme Vilnius City, Bechtle, le gouvernement australien, la Croix-Rouge et ETS Québec.
partage parent public avec sous-pages activées → descendant restreint omis de l'arborescence publique → attaquant interroge la recherche du partage public → titre et extrait de l'enfant restreint fuient
Docmost est une plateforme wiki et de documentation collaborative.
Elle propose :
Cela signifie que son modèle de partage public constitue une véritable frontière de sécurité.
La question importante ici n'était pas de savoir si Docmost peut partager des pages publiquement.
La vraie question était :
Lorsque Docmost décide qu'une page descendante est restreinte et ne doit pas apparaître à un visiteur du partage public, cette restriction est-elle appliquée partout dans le flux de partage public ?
Dans ce cas, elle ne l'était pas.
De nombreuses analyses de sécurité s'arrêtent trop tôt dès qu'elles constatent qu'une page est masquée dans l'interface utilisateur.
Ce n'est pas suffisant.
La question plus forte est celle-ci :
Est-ce que chaque chemin côté serveur applique la même décision de visibilité ?
C'est important car les frontières de sécurité ne sont pas définies par l'apparence de l'interface.
Elles sont définies par ce que le serveur renvoie réellement.
Ici, le point de terminaison de l'arborescence publique se comportait correctement :
Mais le chemin de recherche du partage public se comportait différemment :
Cela en faisait un véritable problème d'autorisation et de divulgation d'informations, et pas seulement une incohérence d'affichage.
Je n'ai pas abordé Docmost en effectuant des tests aléatoires sur les routes en espérant que quelque chose d'intéressant apparaisse.
La meilleure approche était de choisir d'abord une frontière de confiance.
Pour les applications qui prennent en charge :
l'une des meilleures questions à se poser est :
La couche de recherche applique-t-elle exactement la même frontière d'autorisation que la couche de navigation ?
Cette question devient particulièrement pertinente lorsque :
C'est exactement là où ce problème est apparu.
Le bug n'était pas que Docmost n'ait pas masqué la page restreinte dans l'arborescence publique normale.
Le bug était que la recherche publique n'honorait pas cette même logique de restriction.
D'après la revue du code source, le flux de l'arborescence publique utilisait une traversée des descendants tenant compte des restrictions.
Zone concernée :
apps/server/src/core/share/share.service.tsCe chemin excluait intentionnellement les descendants restreints en utilisant :
getPageAndDescendantsExcludingRestricted(...)Mais le flux de recherche du partage public suivait un chemin différent.
Zones concernées :
apps/server/src/core/search/search.controller.tsapps/server/src/core/search/search.service.tsLà, le code collectait les descendants en utilisant :
getPageAndDescendants(...)Cela signifiait que les descendants restreints restaient dans le périmètre de la recherche.
Dans le contexte du partage public, cela a une grande importance car la branche de recherche s'exécute sans le contexte de permissions d'un utilisateur authentifié normal. Ainsi, une fois que les descendants restreints étaient inclus dans l'ensemble des pages consultables, leurs métadonnées pouvaient fuiter via la réponse.
Parce que l'attaquant n'a pas besoin d'un compte authentifié.
Il a seulement besoin :
Une fois cette condition réunie, un visiteur public peut interroger le point de terminaison de recherche du partage et récupérer :
C'est suffisant pour créer une fuite de confidentialité, même si le corps complet de la page n'est pas renvoyé.
La distinction importante est que l'application signale déjà clairement le modèle de sécurité prévu.
Le point de terminaison de l'arborescence publique masque les descendants restreints.
Donc la vraie question n'est pas :
« Est-ce que la recherche renvoie par hasard un ensemble de résultats plus large ? »
La vraie question est :
« Est-ce que la recherche viole une décision d'autorisation déjà appliquée ailleurs pour la même frontière de partage public ? »
Dans Docmost, c'était le cas.
Cela transforme ce problème :
en :
C'est pourquoi il s'agit d'une véritable vulnérabilité.
J'ai validé le problème en comparant les deux points de terminaison publics concernés côte à côte.
D'abord, j'ai testé le point de terminaison normal de l'arborescence publique en utilisant la clé de partage public.
Exemple de requête :
POST /api/shares/tree HTTP/1.1
Host: 127.0.0.1:6752
Content-Type: application/json
{
"shareId": "public-share-key"
}
La réponse renvoyait uniquement la page enfant publique dans l'arborescence.
Résultat représentatif :
{
"pageTree": [
{
"id": "public-child",
"title": "Public roadmap"
}
]
}
Cela établissait le comportement attendu du produit :