0xmrma/cve-2026-33146A public share looked clean in the page tree, but the search endpoint told a different story. In Docmost, restricted child pages hidden from public share viewers could still leak through public share search results.
A public share looked clean in the page tree, but the search endpoint told a different story. In Docmost, restricted child pages hidden from public share viewers could still leak through public share search results.
I found this issue while reviewing Docmost, an open-source collaborative wiki and documentation platform, with a very simple question in mind:
If a page is intentionally hidden from a public share viewer, does every public feature respect that same restriction boundary?
In this case, the answer was no.
A restricted child page could stay hidden in the public share tree while still leaking through the public share search endpoint.
The issue was accepted and assigned CVE-2026-33146.
Docmost: Docmost on GitHub
CVE: CVE-2026-33146
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.
public parent share with subpages enabled → restricted descendant omitted from public tree → attacker queries public share search → restricted child title and snippet leak
Docmost is a collaborative wiki and documentation platform.
It provides:
That means its public-sharing model is a real security boundary.
The important question here was not whether Docmost can share pages publicly.
The real question was:
When Docmost decides a descendant page is restricted and should not appear to a public share visitor, does that restriction hold everywhere in the public share flow?
In this case, it did not.
A lot of security reviews stop too early once they see a page hidden in the UI.
That is not enough.
The stronger question is this:
Does every backend path enforce the same visibility decision?
That matters because security boundaries are not defined by what the interface looks like.
They are defined by what the server actually returns.
Here, the public tree endpoint behaved safely:
But the public share search path behaved differently:
That made this a real authorization and information disclosure issue, not just a presentation inconsistency.
I did not approach Docmost by randomly fuzzing routes and hoping something interesting appeared.
The stronger path was to choose a trust boundary first.
For applications that support:
one of the best questions to ask is:
Does the search layer enforce the exact same authorization boundary as the browse layer?
That question becomes especially valuable when:
That is exactly where this issue showed up.
The bug was not that Docmost failed to hide the restricted page in the normal public tree.
The bug was that public search did not honor that same restriction logic.
From source review, the public tree flow used restricted-aware descendant traversal.
Relevant area:
apps/server/src/core/share/share.service.tsThat path intentionally excluded restricted descendants by using:
getPageAndDescendantsExcludingRestricted(...)But the public share search flow followed a different path.
Relevant areas:
apps/server/src/core/search/search.controller.tsapps/server/src/core/search/search.service.tsThere, the code collected descendants using:
getPageAndDescendants(...)That meant restricted descendants remained in scope for search.
In the public-share context, that matters a lot because the search branch runs without a normal authenticated user permission context. So once restricted descendants were included in the searchable page set, their metadata could leak through the response.
Because the attacker does not need an authenticated account.
They only need:
Once that condition exists, a public visitor can query the share-search endpoint and recover:
That is enough to create a confidentiality leak, even if the full page body is not returned.
The important distinction is that the application already signals the intended security model clearly.
The public tree endpoint hides restricted descendants.
So the real question is not:
“Does search happen to return a broader result set?”
The real question is:
“Is search violating an authorization decision already enforced elsewhere for the same public share boundary?”
In Docmost, it was.
That turns this from:
into:
That is why this is a real vulnerability.
I validated the issue by comparing the two relevant public endpoints side by side.
First, I tested the normal public tree endpoint using the public share key.
Example request:
POST /api/shares/tree HTTP/1.1
Host: 127.0.0.1:6752
Content-Type: application/json
{
"shareId": "public-share-key"
}
The response returned only the public child page in the page tree.
Representative result:
{
"pageTree": [
{
"id": "public-child",
"title": "Public roadmap"
}
]
}
That established the expected product behavior:
I then queried the public share search endpoint using a term that appeared inside the restricted descendant.
Example request:
POST /api/search/share-search HTTP/1.1
Host: 127.0.0.1:6752
Content-Type: application/json
{
"shareId": "public-share-key",
"query": "salary"
}
The response included the restricted child anyway:
{
"items": [
{
"id": "public-child",
"title": "Public roadmap",
"highlight": "release plan and milestones"
},
{
"id": "restricted-child",
"title": "Payroll Q4",
"highlight": "salary bands and bonus targets"
}
]
}
That proved the core claim:
The strongest part of this issue is not the second request by itself.
It is the contrast between the two endpoints.
It shows the product already has an intended restriction model for public shares.
The restricted descendant is not supposed to be visible to the public visitor.
It proves the search path breaks that exact same boundary.
That makes the issue harder to dismiss as expected search behavior or a documentation gap.
The application itself establishes the rule through the tree response, then violates it through the search response.
That is powerful evidence.