Skip to content
KitploitKITPLOIT
StrumentiExploitsBlog
Log in
Invia
StrumentiExploitsBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
CVE-2026-33146 — Una condivisione pubblica sembrava pulita nell'albero delle pagine, ma l'endpoint di ricerca raccontava una storia diversa. In Docmost, le pagine figlie limitate nascoste agli spettatori della condivisione pubblica potevano comunque trapelare attraverso i risultati di ricerca della condivisione pubblica. | Kitploit
Strumenti/GitHubGitHub/0xmrma/cve-2026-33146
Analisi delle VulnerabilitàRaccolta InformazioniSicurezza WebPenetration TestingPaper e RicercaApprendimento e Formazione
GitHub0xmrma/cve-2026-33146

CVE-2026-33146

Vedi Repository
43 mesi faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →

Informazioni

Una condivisione pubblica sembrava pulita nell'albero delle pagine, ma l'endpoint di ricerca raccontava una storia diversa. In Docmost, le pagine figlie limitate nascoste agli spettatori della condivisione pubblica potevano comunque trapelare attraverso i risultati di ricerca della condivisione pubblica.

Condividi

CVE-2026-33146

Una condivisione pubblica sembrava pulita nell'albero delle pagine, ma l'endpoint di ricerca raccontava un'altra storia. In Docmost, le pagine figlie con restrizioni nascoste ai visitatori della condivisione pubblica potevano comunque trapelare attraverso i risultati di ricerca della condivisione pubblica.

Introduzione

Ho trovato questo problema durante la revisione di Docmost, una piattaforma wiki e documentazione collaborativa open-source, partendo da una domanda molto semplice:

Se una pagina è intenzionalmente nascosta a un visitatore della condivisione pubblica, ogni funzionalità pubblica rispetta lo stesso confine di restrizione?

In questo caso, la risposta è stata no.

Una pagina figlia con restrizione poteva rimanere nascosta nell'albero della condivisione pubblica mentre trapelava comunque attraverso l'endpoint di ricerca della condivisione pubblica.

Il problema è stato accettato e gli è stato assegnato CVE-2026-33146.

Docmost: Docmost su GitHub
CVE: CVE-2026-33146

Il sito ufficiale di Docmost lo presenta come un wiki on-premise pronto per le aziende con 3M+ download, e afferma che è utilizzato da team in organizzazioni tra cui Vilnius City, Bechtle, il Governo Australiano, la Croce Rossa e ETS Quebec.

photo0

Catena d'attacco

condivisione pubblica genitore con sottopagine abilitate → discendente con restrizione omesso dall'albero pubblico → attore malintenzionato interroga la ricerca della condivisione pubblica → titolo e snippet del figlio con restrizione trapelano


Cosa fa Docmost

Docmost è una piattaforma wiki e documentazione collaborativa.

Fornisce:

  • pagine condivise
  • link di condivisione pubblica
  • alberi di pagine nidificati
  • organizzazione dei contenuti a livello di spazio di lavoro e spazio
  • ricerca tra i contenuti condivisi

Ciò significa che il suo modello di condivisione pubblica è un vero confine di sicurezza.

La domanda importante qui non era se Docmost può condividere pagine pubblicamente.

La vera domanda era:

Quando Docmost decide che una pagina discendente è limitata e non deve apparire a un visitatore della condivisione pubblica, quella restrizione è valida ovunque nel flusso di condivisione pubblica?

In questo caso, non lo era.


Perché valeva la pena analizzare questo bug

Molte revisioni di sicurezza si fermano troppo presto quando vedono una pagina nascosta nell'interfaccia utente.

Questo non basta.

La domanda più forte è questa:

Ogni percorso backend impone la stessa decisione di visibilità?

Questo è importante perché i confini di sicurezza non sono definiti dall'aspetto dell'interfaccia.
Sono definiti da ciò che il server restituisce effettivamente.

Qui, l'endpoint dell'albero pubblico si è comportato in modo sicuro:

  • i discendenti con restrizione erano nascosti

Ma il percorso di ricerca della condivisione pubblica si è comportato diversamente:

  • i discendenti con restrizione influenzavano comunque i risultati
  • i loro titoli trapelavano
  • i loro snippet di contenuto evidenziati trapelavano

Questo ha reso il problema una reale violazione dell'autorizzazione e della divulgazione di informazioni, non solo un'incoerenza di presentazione.


Il confine su cui mi sono concentrato

Non ho affrontato Docmost facendo fuzzing casuale degli endpoint sperando che apparisse qualcosa di interessante.

La strada più solida era scegliere prima un confine di fiducia.

Per le applicazioni che supportano:

  • condivisione pubblica
  • oggetti nidificati
  • restrizioni per pagina
  • ricerca di contenuti

una delle migliori domande da porsi è:

Il livello di ricerca impone esattamente lo stesso confine di autorizzazione del livello di navigazione?

Questa domanda diventa particolarmente preziosa quando:

  • un oggetto genitore è pubblico
  • i discendenti hanno regole di visibilità diverse
  • la ricerca è implementata attraverso un percorso di servizio separato

È esattamente qui che si è manifestato questo problema.


Causa principale

Il bug non era che Docmost non riusciva a nascondere la pagina con restrizione nell'albero pubblico normale.

Il bug era che la ricerca pubblica non onorava la stessa logica di restrizione.

Dalla revisione del codice sorgente, il flusso dell'albero pubblico utilizzava la traversata dei discendenti consapevole delle restrizioni.

Area rilevante:

  • apps/server/src/core/share/share.service.ts

Quel percorso escludeva intenzionalmente i discendenti con restrizione utilizzando:

  • getPageAndDescendantsExcludingRestricted(...)

Ma il flusso di ricerca della condivisione pubblica seguiva un percorso diverso.

Aree rilevanti:

  • apps/server/src/core/search/search.controller.ts
  • apps/server/src/core/search/search.service.ts

Lì, il codice raccoglieva i discendenti utilizzando:

  • getPageAndDescendants(...)

Ciò significa che i discendenti con restrizione rimanevano nel campo d'azione per la ricerca.

Nel contesto della condivisione pubblica, questo è molto importante perché il ramo di ricerca viene eseguito senza un contesto di autorizzazione utente autenticato normale. Quindi, una volta che i discendenti con restrizione erano inclusi nel set di pagine ricercabili, i loro metadati potevano trapelare attraverso la risposta.

Perché è sfruttabile

Perché l'attaccante non ha bisogno di un account autenticato.

Ha solo bisogno di:

  • una chiave di condivisione pubblica valida
  • sottopagine incluse nella condivisione
  • conoscenza o ipotesi sui termini di ricerca che potrebbero apparire nei discendenti nascosti

Una volta che questa condizione esiste, un visitatore pubblico può interrogare l'endpoint di ricerca della condivisione e recuperare:

  • titoli di pagine nascoste
  • snippet di corpo evidenziati
  • prova che una pagina figlia con restrizione esiste sotto il genitore condiviso

Questo è sufficiente per creare una fuga di informazioni, anche se l'intero corpo della pagina non viene restituito.


Perché è un problema di sicurezza, non solo un comportamento diverso dell'endpoint

La distinzione importante è che l'applicazione segnala già chiaramente il modello di sicurezza previsto.

L'endpoint dell'albero pubblico nasconde i discendenti con restrizione.

Quindi la vera domanda non è:

"La ricerca restituisce per caso un insieme di risultati più ampio?"

La vera domanda è:

"La ricerca sta violando una decisione di autorizzazione già applicata altrove per lo stesso confine di condivisione pubblica?"

In Docmost, sì.

Questo trasforma il problema da:

  • funzionalità incoerente

a:

  • applicazione incoerente del controllo di accesso

Ecco perché è una vulnerabilità reale.


PoC

Ho validato il problema confrontando i due endpoint pubblici rilevanti fianco a fianco.

Caso 1: L'albero pubblico nasconde correttamente il figlio con restrizione

Prima, ho testato l'endpoint normale dell'albero pubblico utilizzando la chiave di condivisione pubblica.

Richiesta di esempio:

POST /api/shares/tree HTTP/1.1
Host: 127.0.0.1:6752
Content-Type: application/json

{
  "shareId": "public-share-key"
}

La risposta restituiva solo la pagina figlia pubblica nell'albero delle pagine.

Risultato rappresentativo:

{
  "pageTree": [
    {
      "id": "public-child",
      "title": "Public roadmap"
    }
  ]
}

Questo ha stabilito il comportamento atteso del prodotto:

  • il figlio con restrizione era intenzionalmente nascosto al visitatore pubblico

Caso 2: La ricerca della condivisione pubblica fa ancora trapelare il figlio con restrizione

Ho quindi interrogato l'endpoint di ricerca della condivisione pubblica utilizzando un termine che appariva all'interno del discendente con restrizione.

Richiesta di esempio:

Scarica lo strumento