0xmrma/cve-2026-33146
Eine öffentliche Freigabe sah im Seitenbaum sauber aus, aber der Such-Endpunkt erzählte eine andere Geschichte. In Docmost konnten eingeschränkte Unter-/Kinder-Seiten, die für Betrachter öffentlicher Freigaben verborgen waren, dennoch über öffentliche Freigabe-Suchergebnisse durchsickern.
Eine öffentliche Freigabe sah im Seitenbaum sauber aus, aber der Such-Endpoint erzählte eine andere Geschichte. In Docmost konnten eingeschränkte untergeordnete Seiten, die vor öffentlichen Freigabebetrachtern verborgen waren, dennoch über die öffentlichen Freigabe-Suchergebnisse durchsickern.
Ich fand dieses Problem bei der Überprüfung von Docmost, einer Open-Source-Plattform für kollaborative Wikis und Dokumentation, mit einer sehr einfachen Frage:
Wenn eine Seite absichtlich vor einem öffentlichen Freigabebetrachter verborgen wird, respektiert dann jedes öffentliche Feature dieselbe Einschränkungsgrenze?
In diesem Fall lautete die Antwort nein.
Eine eingeschränkte untergeordnete Seite konnte im öffentlichen Freigabebaum verborgen bleiben, während sie dennoch über den öffentlichen Freigabe-Such-Endpoint durchsickerte.
Das Problem wurde akzeptiert und erhielt die CVE-2026-33146.
Docmost: Docmost auf GitHub
CVE: CVE-2026-33146
Die offizielle Website von Docmost präsentiert es als ein unternehmensreifes On-Premises-Wiki mit 3 Mio.+ Downloads und gibt an, dass es von Teams in Organisationen wie Vilnius City, Bechtle, der australischen Regierung, dem Roten Kreuz und ETS Quebec verwendet wird.
öffentliche übergeordnete Freigabe mit aktivierten Unterseiten → eingeschränkter Nachkomme aus dem öffentlichen Baum ausgeschlossen → Angreifer fragt öffentliche Freigabe-Suche ab → Titel und Ausschnitt der eingeschränkten untergeordneten Seite werden preisgegeben
Docmost ist eine kollaborative Wiki- und Dokumentationsplattform.
Es bietet:
Das bedeutet, dass das öffentliche Freigabemodell eine echte Sicherheitsgrenze darstellt.
Die wichtige Frage war hier nicht, ob Docmost Seiten öffentlich teilen kann.
Die eigentliche Frage war:
Wenn Docmost entscheidet, dass eine untergeordnete Seite eingeschränkt ist und für einen öffentlichen Freigabebesucher nicht sichtbar sein soll, gilt diese Einschränkung dann überall im öffentlichen Freigabefluss?
In diesem Fall tat es das nicht.
Viele Sicherheitsüberprüfungen stoppen zu früh, sobald sie eine in der Benutzeroberfläche verborgene Seite sehen.
Das reicht nicht aus.
Die stärkere Frage ist diese:
Setzt jeder Backend-Pfad dieselbe Sichtbarkeitsentscheidung durch?
Das ist wichtig, weil Sicherheitsgrenzen nicht durch das Aussehen der Schnittstelle definiert werden.
Sie werden dadurch definiert, was der Server tatsächlich zurückgibt.
Hier verhielt sich der öffentliche Baum-Endpoint sicher:
Aber der öffentliche Freigabe-Suchpfad verhielt sich anders:
Das machte dies zu einem echten Problem der Autorisierungs- und Informationsoffenlegung, nicht nur zu einer Inkonsistenz der Darstellung.
Ich bin nicht an Docmost herangegangen, indem ich zufällig Routen gefuzzt und darauf gehofft habe, dass etwas Interessantes auftaucht.
Der stärkere Weg war, zuerst eine Vertrauensgrenze zu wählen.
Für Anwendungen, die Folgendes unterstützen:
ist eine der besten Fragen:
Setzt die Suchebene genau dieselbe Autorisierungsgrenze durch wie die Navigationsebene?
Diese Frage wird besonders wertvoll, wenn:
Genau dort zeigte sich dieses Problem.
Der Fehler lag nicht darin, dass Docmost die eingeschränkte Seite im normalen öffentlichen Baum nicht versteckt hat.
Der Fehler lag darin, dass die öffentliche Suche diese gleiche Einschränkungslogik nicht beachtet hat.
Aus der Quellcode-Überprüfung verwendete der öffentliche Baumfluss eine einschränkungsbewusste Traversierung der Nachkommen.
Relevanter Bereich:
apps/server/src/core/share/share.service.tsDieser Pfad schloss eingeschränkte Nachkommen absichtlich aus, indem er Folgendes verwendete:
getPageAndDescendantsExcludingRestricted(...)Aber der öffentliche Freigabe-Suchfluss folgte einem anderen Pfad.
Relevante Bereiche:
apps/server/src/core/search/search.controller.tsapps/server/src/core/search/search.service.tsDort sammelte der Code Nachkommen mit:
getPageAndDescendants(...)Das bedeutete, dass eingeschränkte Nachkommen für die Suche im Geltungsbereich blieben.
Im öffentlichen Freigabekontext ist das sehr wichtig, da der Suchzweig ohne einen normalen authentifizierten Benutzerberechtigungskontext läuft. Sobald eingeschränkte Nachkommen in die durchsuchbare Seitenmenge aufgenommen wurden, konnten ihre Metadaten über die Antwort durchsickern.
Weil der Angreifer kein authentifiziertes Konto benötigt.
Er benötigt nur:
Sobald diese Bedingung erfüllt ist, kann ein öffentlicher Besucher den Freigabe-Such-Endpoint abfragen und folgende Informationen abrufen:
Das reicht aus, um eine Vertraulichkeitslücke zu schaffen, selbst wenn der vollständige Seiteninhalt nicht zurückgegeben wird.
Der wichtige Unterschied ist, dass die Anwendung das beabsichtigte Sicherheitsmodell bereits klar signalisiert.
Der öffentliche Baum-Endpoint verbirgt eingeschränkte Nachkommen.
Die eigentliche Frage ist also nicht:
„Gibt die Suche zufällig eine breitere Ergebnismenge zurück?“
Die eigentliche Frage ist:
„Verletzt die Suche eine Autorisierungsentscheidung, die bereits anderswo für dieselbe öffentliche Freigabegrenze durchgesetzt wird?“
Bei Docmost war das der Fall.
Das verwandelt dies von:
in:
Deshalb ist dies eine echte Schwachstelle.
Ich habe das Problem validiert, indem ich die beiden relevanten öffentlichen Endpoints nebeneinander verglich.
Zuerst testete ich den normalen öffentlichen Baum-Endpoint mit dem öffentlichen Freigabeschlüssel.
Beispielanfrage:
POST /api/shares/tree HTTP/1.1
Host: 127.0.0.1:6752
Content-Type: application/json
{
"shareId": "public-share-key"
}
Die Antwort gab nur die öffentliche untergeordnete Seite im Seitenbaum zurück.
Repräsentatives Ergebnis:
{
"pageTree": [
{
"id": "public-child",
"title": "Public roadmap"
}
]
}
Damit war das erwartete Produktverhalten festgelegt:
Dann fragte ich den öffentlichen Freigabe-Such-Endpoint mit einem Begriff ab, der im eingeschränkten Nachkommen vorkam.
Beispielanfrage: