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:
POST /api/search/share-search HTTP/1.1
Host: 127.0.0.1:6752
Content-Type: application/json
{
"shareId": "public-share-key",
"query": "salary"
}
Die Antwort enthielt trotzdem das eingeschränkte Kind:
{
"items": [
{
"id": "public-child",
"title": "Public roadmap",
"highlight": "release plan and milestones"
},
{
"id": "restricted-child",
"title": "Payroll Q4",
"highlight": "salary bands and bonus targets"
}
]
}
Das bewies die Kernaussage:
Der stärkste Aspekt dieses Problems ist nicht die zweite Anfrage allein.
Es ist der Kontrast zwischen den beiden Endpoints.
Es zeigt, dass das Produkt bereits ein beabsichtigtes Einschränkungsmodell für öffentliche Freigaben hat.
Der eingeschränkte Nachkomme soll für den öffentlichen Besucher nicht sichtbar sein.
Es beweist, dass der Suchpfad genau diese Grenze durchbricht.
Das macht es schwerer, das Problem als erwartetes Suchverhalten oder eine Dokumentationslücke abzutun.
Die Anwendung selbst legt die Regel durch die Baumantwort fest und verletzt sie dann durch die Suchantwort.
Das sind starke Beweise.
Dieses Problem legt nicht beliebige Inhalte im gesamten Arbeitsbereich offen.
Sein Umfang ist enger als das.
Aber innerhalb des betroffenen öffentlichen Freigabe-Teilbaums gibt es einem Angreifer dennoch nützliches unbefugtes Wissen:
Selbst kurze Ausschnitte können von Bedeutung sein.
Ein Titel wie:
schafft bereits einen Sicherheitswert für einen Angreifer.
Obwohl dies letztendlich als Mittel eingestuft wurde, handelt es sich dennoch um ein gültiges Vertraulichkeitsproblem mit einem klaren und vertretbaren Grenzverstoß.
Dieses Problem wurde zugewiesen:
Der Schweregrad der Beratung war:
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:NDiese Bewertung spiegelt eine engere Vertraulichkeitslücke wider und keinen vollständigen unbefugten Dokumentenzugriff.
Der wichtige Punkt ist, dass das Problem dennoch gültig ist.
Die Behauptung hier ist nicht:
Die Behauptung ist:
Das ist eine echte autorisierungsbezogene Informationsoffenlegung.
Manche Leute weisen Metadatenlecks zu schnell ab.
Das ist ein Fehler.
Die eigentliche Frage ist, ob die durchgesickerten Daten eine beabsichtigte Grenze überschreiten.
Hier taten sie es.
Wenn die Anwendung sagt:
aber ein öffentlicher Endpoint dennoch preisgibt:
dann ist das Vertraulichkeitsmodell gescheitert, selbst wenn die Auswirkungen begrenzt sind.
Das macht es meldenswert.
Saubere, abgegrenzte und reproduzierbare Fehler wie dieser sind genau die Art von Problemen, die helfen, gutes Urteilsvermögen bei Sicherheitsüberprüfungen zu demonstrieren.
Die sicherste Richtung für eine Behebung ist, die öffentliche Suche dieselbe einschränkungsbewusste Nachkommenlogik verwenden zu lassen wie der öffentliche Baumfluss.
In der Praxis bedeutet das, dass der Freigabe-Suchzweig keine Nachkommen mit:
getPageAndDescendants(...)
auflisten sollte.
Er sollte sich stattdessen an der sichereren öffentlichen Freigabe-Traversierung orientieren und Folgendes verwenden:
getPageAndDescendantsExcludingRestricted(...)
Eine alternative Behebung wäre, die breitere Aufzählung beizubehalten und eingeschränkte Nachkommen explizit herauszufiltern, bevor die Suchanfrage Ergebnisse zurückgibt.
Aber das sauberere Design ist einfach:
die Suchgrenze sollte der Navigationsgrenze entsprechen
Das ist die Sicherheitseigenschaft, die versagt hat.
Dieses Problem wurde privat über den Sicherheitsmeldefluss von GitHub gemeldet.
Der Bericht zeigte:
/api/shares/tree/api/search/share-searchDas Problem wurde akzeptiert und zugewiesen:
CVE-2026-33146
Der endgültige Schweregrad der Beratung war Mittel, was besser zu dem engeren Leckumfang passt, als eine breitere Kritikalität behaupten zu können.
Das schwächt die Gültigkeit des Fundes nicht.
Es definiert seine Auswirkungen nur präziser.
Die wichtigste Lektion hier ist einfach:
etwas in einem öffentlichen Endpoint zu verstecken, reicht nicht, wenn ein anderer öffentlicher Endpoint es immer noch preisgibt.
Viele Entwickler denken bei der Autorisierung nur an den offensichtlichen Rendering-Pfad:
Aber die eigentliche Grenze ist breiter.
Man muss auch fragen:
Bei Docmost war die Antwort nein.
Das ist die eigentliche Erkenntnis.
Diese Schwachstelle ging nicht um auffällige Payloads oder komplexe Exploit-Ketten.
Es ging darum, eine sehr praktische Frage zur Vertrauensgrenze zu stellen.
Docmost verbarg die eingeschränkte Seite an einer Stelle.
Und ließ sie dann an einer anderen durchsickern.
Deshalb wurde dies zu CVE-2026-33146.