0xmrma/cve-2026-46552NocoDB Shared-Base Links potrebbe invitare membri reali del database e sopravvivere alla revoca della condivisione
I collegamenti di base condivisa di NocoDB potrebbero invitare membri reali della base e sopravvivere alla revoca della condivisione
Ho trovato questo problema mentre esaminavo NocoDB, con una semplice domanda di sicurezza in mente:
Un link pubblico di base condivisa può superare il confine dall'accesso temporaneo condiviso all'iscrizione autenticata reale alla base?
In questo caso, la risposta è stata sì.
Una sessione di base condivisa autenticata solo da xc-shared-base-id veniva trattata come un normale visualizzatore di base ai fini ACL. Poiché i permessi del visualizzatore raggiungevano ancora gli endpoint di gestione dei membri, un utente con solo l'UUID della base condivisa poteva elencare i membri esistenti della base e invitare un indirizzo email arbitrario nella base come membro reale.
Quell'utente invitato poteva quindi riscattare l'invito tramite il normale flusso di registrazione, ottenere un account autenticato standard e mantenere l'accesso alla base anche dopo che il proprietario aveva disabilitato il link di base condivisa.
Tale problema è diventato CVE-2026-46552.
Progetto: NocoDB
Versione affetta validata: 0.301.3
Questo ha interessato NocoDB; sul suo sito ufficiale, NocoDB viene presentato come affidabile per oltre 35.000 organizzazioni, con oltre 20 milioni di download. Il sito elenca anche aziende come Accenture, Western Digital, Hyundai, Walmart, PwC, Bosch e American Express.
link pubblico di base condivisa -> xc-shared-base-id trattato come normale visualizzatore di base -> ACL del visualizzatore raggiunge gli endpoint di gestione membri -> l'attaccante elenca gli utenti della base e invita un'email arbitraria -> l'utente invitato riscatta il normale token di registrazione -> l'accesso autenticato alla base persiste nonostante la revoca del link condiviso
NocoDB è una piattaforma di collaborazione orientata ai database che espone accesso alla base tramite browser, condivisione, gestione dei metadati e flussi di lavoro di iscrizione degli utenti.
Ciò significa che il suo modello di condivisione è un vero confine di sicurezza.
La domanda importante qui non era se i link di base condivisa potessero leggere contenuti condivisi.
La vera domanda era:
Un principal di condivisione pubblica può eseguire azioni che dovrebbero appartenere solo ai membri autenticati della base?
In questo caso, poteva.
Le funzionalità di condivisione pubblica sono facili da sottovalutare.
È un errore.
Una volta che un'applicazione supporta:
il rischio principale non è solo l'esposizione dei dati.
Il rischio più forte è il collasso dei confini:
Questo era il vero problema qui.
Non era un bug nella validazione del login. Non era un problema di falsificazione del token. Non era un difetto nel reset della password.
Era un classico errore del confine di autorizzazione:
Non ho affrontato questo problema sondando a caso endpoint sperando che qualcosa di interessante rispondesse.
La via più solida era identificare prima il confine di fiducia di maggior valore.
Per NocoDB, quello era il confine tra:
Questi due stati non dovrebbero essere intercambiabili.
Un link di base condivisa dovrebbe rappresentare accesso limitato, revocabile e basato su link. Non dovrebbe essere in grado di generare nuovi principal di lunga durata all'interno della base.
È esattamente il confine che è fallito qui.
La vulnerabilità derivava da come l'accesso alla base condivisa era integrato nel normale percorso ACL.
Nel flusso frontend della base condivisa, xc-shared-base-id veniva iniettato mentre le normali intestazioni di autenticazione venivano rimosse.
Poi, nel backend, BaseViewStrategy accettava xc-shared-base-id e traduceva direttamente il link condiviso in normali roles / base_roles derivati dalla configurazione della base condivisa.
Questo era il primo problema.
Il secondo problema era che i permessi a livello di visualizzatore includevano ancora azioni di gestione dei membri.
Nel layer ACL, ProjectRoles.VIEWER poteva raggiungere:
baseUserListuserInviteQuei permessi proteggevano le normali meta rotte:
GET /api/v2/meta/bases/:baseId/usersPOST /api/v2/meta/bases/:baseId/usersQuindi una sessione di condivisione pubblica era effettivamente autorizzata a colpire endpoint di appartenenza destinati a partecipanti reali della base.
L'ultimo passo era nel flusso di invito stesso.
BaseUsersService.userInvite() controllava il potere del ruolo, poi creava:
invite_tokenE per le sessioni di base condivisa:
invited_by diventava nullperché non c'era una reale identità di invito autenticata dietro la richiesta.
Questa è l'intera catena del bug.
Perché il possesso di un link di base condivisa era sufficiente.
L'attaccante non aveva bisogno di:
xc-authLa catena di sfruttamento era semplice:
Questo converte la condivisione di link revocabile in appartenenza durevole.
La distinzione importante è la persistenza attraverso la revoca.
Non si trattava solo di:
"un visualizzatore poteva chiamare un endpoint da visualizzatore"
Il principal vulnerabile non era un normale visualizzatore autenticato.
Era una sessione di condivisione pubblica.
Questo è importante perché l'applicazione trattava un principal transitorio e limitato al link come se fosse abbastanza fidato per:
La vera domanda non era:
"Un utente condiviso può leggere dati condivisi?"
La vera domanda era:
"L'accesso di condivisione pubblica può essere convertito in accesso autenticato permanente che sopravvive alla revoca della condivisione?"
La risposta era sì.
Ecco perché questa è una vera vulnerabilità di autorizzazione, non solo un comportamento applicativo sorprendente.