CVE-2026-33146: Docmost Public Share Search Leaks Restricted Child Page Metadata

Intro

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.

Attack Chain

public parent share with subpages enabled → restricted descendant omitted from public tree → attacker queries public share search → restricted child title and snippet leak

What Docmost Does

Docmost is a collaborative wiki and documentation platform.

It provides:

• shared pages
• public share links
• nested page trees
• workspace and space-level content organization
• search across shared content

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.

Why This Bug Was Worth Looking At

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:

• restricted descendants were hidden

But the public share search path behaved differently:

• restricted descendants still influenced results
• their titles leaked
• their highlighted content snippets leaked

That made this a real authorization and information disclosure issue, not just a presentation inconsistency.

The Boundary I Focused On

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:

• public sharing
• nested objects
• per-page restrictions
• content search

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:

• a parent object is public
• descendants have different visibility rules
• search is implemented through a separate service path

That is exactly where this issue showed up.

Root Cause

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.ts

That 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.ts
• apps/server/src/core/search/search.service.ts

There, 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.

Why this is exploitable

Because the attacker does not need an authenticated account.

They only need:

• a valid public share key
• subpages included in the share
• knowledge of, or guesses about, search terms likely to appear in hidden descendants

Once that condition exists, a public visitor can query the share-search endpoint and recover:

• hidden page titles
• highlighted body snippets
• proof that a restricted child page exists under the shared parent

That is enough to create a confidentiality leak, even if the full page body is not returned.

What Makes This a Security Issue, Not Just Different Endpoint Behavior

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:

• inconsistent functionality

into:

• inconsistent access control enforcement

That is why this is a real vulnerability.

PoC

I validated the issue by comparing the two relevant public endpoints side by side.

Case 1: Public tree correctly hides the restricted child

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:

• the restricted child was intentionally hidden from the public visitor

Case 2: Public share search still leaks the restricted child

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 restricted child was hidden in the public tree
• but still leaked through public share search

Why the Two Reproductions Matter

The strongest part of this issue is not the second request by itself.

It is the contrast between the two endpoints.

First

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.

Second

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.

What the Leak Actually Gives an Attacker

This issue does not expose arbitrary content across the whole workspace.

Its scope is narrower than that.

But within the affected public share subtree, it still gives an attacker useful unauthorized knowledge:

• hidden document titles
• highlighted snippets from hidden content
• confirmation that restricted descendants exist
• clues about payroll, legal, planning, credentials, or internal operations depending on document content

Even short snippets can matter.

A title like:

• payroll
• hiring plan
• legal draft
• customer incident
• credential rotation

already creates security value for an attacker.

So while this was ultimately classified as Moderate, it is still a valid confidentiality issue with a clean and defensible boundary break.

Severity and Classification

This issue was assigned:

• CVE-2026-33146

The advisory severity was:

• Moderate
• CVSS: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:N

That scoring reflects a narrower confidentiality leak rather than full unauthorized document access.

The important point is that the issue is still valid.

The claim here is not:

• full page read
• arbitrary workspace disclosure
• integrity impact
• availability impact

The claim is:

• a public share visitor can retrieve metadata from a restricted child page that the product intentionally hides elsewhere in the same public-share flow

That is a real authorization-related information disclosure.

Why This Was Still Worth Reporting

Some people dismiss metadata leaks too quickly.

That is a mistake.

The real question is whether the leaked data crosses an intended boundary.

Here, it did.

If the application says:

• this restricted child should not be visible to public share viewers

but a public endpoint still reveals:

• its title
• part of its content

then the confidentiality model has failed, even if the impact is limited.

That makes it worth reporting.

Clean, scoped, and reproducible bugs like this are exactly the kind of issues that help demonstrate strong security review judgment.

Fix Analysis

The safest fix direction is to make public search use the same restriction-aware descendant logic as the public tree flow.

In practice, that means the share-search branch should not enumerate descendants with:

getPageAndDescendants(...)

It should instead align with the safer public-share traversal and use:

getPageAndDescendantsExcludingRestricted(...)

An alternative fix would be to keep the broader enumeration and then explicitly filter restricted descendants out before the search query returns results.

But the cleaner design is simple:

the search boundary should match the browse boundary

That is the security property that failed.

Disclosure

This issue was reported privately through GitHub’s security reporting flow.

The report showed:

• the intended safe behavior through /api/shares/tree
• the inconsistent vulnerable behavior through /api/search/share-search
• the underlying source-level cause
• a concrete reproduction path

The issue was accepted and assigned:

CVE-2026-33146

The final advisory severity was Moderate, which fits the narrower leak scope better than a broader criticality claim would have.

That does not weaken the validity of the finding.

It just defines its impact more precisely.

What This Bug Actually Teaches

The key lesson here is simple:

hiding something in one public endpoint is not enough if another public endpoint still reveals it.

A lot of developers think about authorization only in the obvious rendering path:

• page tree
• page view
• main UI

But the real boundary is broader.

You also have to ask:

• does search honor the same rules?
• do side channels honor the same rules?
• do metadata responses honor the same rules?

In Docmost, the answer was no.

That is the real takeaway.

Key Points

• public-share features must enforce the same visibility model across browse and search paths
• metadata leaks still matter when they cross an intended authorization boundary
• side-by-side endpoint comparison makes this class of issue much stronger
• restricted descendants should never remain searchable if they are hidden from the same public viewer
• tight scope does not make a valid bug unworthy of reporting
• good security review is often about testing consistency, not just finding crashes or full bypasses

Final Words

This vulnerability was not about flashy payloads or complex exploit chains.

It was about asking a very practical trust-boundary question.

Docmost hid the restricted page in one place.
Then leaked it in another.

That is why this became CVE-2026-33146.