CVE-2026-46552

Links de Base Compartilhada do NocoDB Podem Convidar Membros Reais da Base e Sobreviver à Revogação do Compartilhamento

Introdução

Encontrei esse problema ao revisar o NocoDB, com uma simples questão de segurança em mente:

Um link público de base compartilhada pode cruzar a fronteira do acesso temporário compartilhado para a associação real autenticada à base?

Neste caso, a resposta foi sim.

Uma sessão de base compartilhada autenticada apenas por xc-shared-base-id foi tratada como um visualizador normal da base para fins de ACL. Como as permissões de visualizador ainda alcançavam endpoints de gerenciamento de membros, um usuário com apenas o UUID da base compartilhada podia enumerar membros existentes da base e convidar um endereço de e-mail arbitrário para a base como membro real.

Esse usuário convidado podia então resgatar o convite através do fluxo normal de cadastro, obter uma conta autenticada padrão e manter o acesso à base mesmo depois que o proprietário desabilitasse o link de base compartilhada.

Esse problema se tornou CVE-2026-46552.

Projeto: NocoDB

Versão afetada validada: 0.301.3

Isso afetou o NocoDB; no site oficial, o NocoDB é apresentado como confiável por 35.000+ organizações, com 20+ milhões de downloads. O site também lista empresas como Accenture, Western Digital, Hyundai, Walmart, PwC, Bosch e American Express.

Cadeia de Ataque

link público de base compartilhada -> xc-shared-base-id tratado como visualizador normal da base -> ACL de visualizador alcança endpoints de gerenciamento de membros -> atacante lista usuários da base e convida e-mail arbitrário -> usuário convidado resgata token de cadastro normal -> acesso autenticado durável à base sobrevive à revogação do link compartilhado

O que o NocoDB Faz

NocoDB é uma plataforma de colaboração orientada a banco de dados que expõe acesso à base via navegador, compartilhamento, gerenciamento de metadados e fluxos de trabalho de associação de usuários.

Isso significa que seu modelo de compartilhamento é uma fronteira de segurança real.

A questão importante aqui não era se links de base compartilhada podem ler conteúdo compartilhado.

A verdadeira questão era:

Um principal de compartilhamento público pode realizar ações que deveriam pertencer apenas a membros autenticados da base?

Neste caso, podia.

Por que Essa Superfície Valia a Pena ser Examinada

Recursos de compartilhamento público são fáceis de subestimar.

Isso é um erro.

Uma vez que um aplicativo suporta:

• acesso anônimo ou baseado em link,
• mapeamento de funções,
• e APIs comuns de gerenciamento autenticado por trás do mesmo sistema de ACL,

o principal risco não é apenas a exposição de dados.

O risco mais forte é o colapso de fronteira:

• um principal de menor confiança herda capacidades de maior confiança,
• ações de gerenciamento tornam-se acessíveis a partir de um contexto de compartilhamento público,
• e o acesso temporário pode ser convertido em acesso persistente.

Esse era o verdadeiro problema aqui.

Isso não foi um bug na validação de login. Não foi um problema de falsificação de token. Não foi uma falha de redefinição de senha.

Foi uma clássica falha de fronteira de autorização:

• um principal de link compartilhado foi mapeado em funções normais da base,
• essas funções ainda incluíam capacidades de gerenciamento de membros,
• e o estado durável de controle de acesso podia então ser modificado a partir do contexto de compartilhamento público.

A Fronteira na qual Foquei

Não abordei isso sondando endpoints aleatoriamente na esperança de que algo interessante respondesse.

O caminho mais forte foi identificar primeiro a fronteira de confiança de maior valor.

Para o NocoDB, essa era a fronteira entre:

• acesso à base compartilhada
• e associação autenticada à base

Esses dois estados não deveriam ser intercambiáveis.

Um link de base compartilhada deveria representar acesso limitado, revogável e baseado em link. Não deveria ser capaz de criar novos principais de longa duração dentro da base.

Essa é exatamente a fronteira que falhou aqui.

Causa Raiz

A vulnerabilidade veio de como o acesso à base compartilhada foi integrado ao caminho normal de ACL.

No fluxo frontend da base compartilhada, xc-shared-base-id era injetado enquanto cabeçalhos normais de autenticação eram removidos.

Então, no backend, BaseViewStrategy aceitava xc-shared-base-id e traduzia o link compartilhado diretamente em roles / base_roles normais derivados da configuração da base compartilhada.

Esse foi o primeiro problema.

O segundo problema foi que permissões de nível de visualizador ainda incluíam ações de gerenciamento de membros.

Na camada de ACL, ProjectRoles.VIEWER podia alcançar:

• baseUserList
• userInvite

Essas permissões guardavam rotas meta normais:

• GET /api/v2/meta/bases/:baseId/users
• POST /api/v2/meta/bases/:baseId/users

Portanto, uma sessão de compartilhamento público era efetivamente autorizada a acessar endpoints de associação destinados a participantes reais da base.

O último passo estava no próprio fluxo de convite.

BaseUsersService.userInvite() verificava o poder da função e então criava:

• uma linha real de usuário com um invite_token
• uma linha real de associação à base para a base alvo

E para sessões de base compartilhada:

• invited_by tornava-se null

porque não havia uma identidade real de convidador autenticado por trás da requisição.

Essa é toda a cadeia do bug.

Por que isso é explorável

Porque a posse de um link de base compartilhada era suficiente.

O atacante não precisava de:

• xc-auth
• uma conta pré-existente
• credenciais roubadas
• ou associação prévia na base

A cadeia de exploração era direta:

• o atacante obtém um UUID de base compartilhada
• o UUID é aceito como um principal de visualizador da base
• a ACL de visualizador alcança endpoints de gerenciamento de membros
• o atacante lista membros atuais da base
• o atacante convida um endereço de e-mail arbitrário
• o usuário convidado resgata o token através do fluxo normal de cadastro
• a nova conta torna-se um membro real autenticado da base
• o proprietário posteriormente desabilita o link compartilhado
• a conta convidada ainda mantém acesso autenticado normal

Isso converte compartilhamento de link revogável em associação durável.

O que Torna Isso um Problema de Segurança, Não Apenas um Comportamento Estranho de Compartilhamento

A distinção importante é a persistência após a revogação.

Isso não era apenas:

"um visualizador podia chamar um endpoint de visualizador"

O principal vulnerável não era um visualizador autenticado normal.

Era uma sessão de compartilhamento público.

Isso importa porque o aplicativo tratava um principal transitório, limitado ao link, como se fosse confiável o suficiente para:

• enumerar membros reais,
• alterar o estado de controle de acesso,
• e criar novos principais duráveis dentro da base

A verdadeira questão não era:

"Um usuário compartilhado pode ler dados compartilhados?"

A verdadeira questão era:

"O acesso de compartilhamento público pode ser convertido em acesso autenticado permanente que sobrevive à revogação do compartilhamento?"

A resposta foi sim.

É por isso que esta é uma vulnerabilidade real de autorização, e não apenas um comportamento surpreendente do aplicativo.

PoC

Validei isso localmente contra:

• versão do produto: 0.301.3
• commit: dac49b0122c5ee655fb8f46a1b6e42dfeec1f3ad
• URL base: http://127.0.0.1:8080

A reprodução foi direta.

Primeiro, entrei como uma conta de proprietário normal, criei uma nova base, criei uma tabela e habilitei o acesso à base compartilhada como viewer:

PATCH /api/v2/meta/bases/<baseId>/shared
Content-Type: application/json

{
  "roles": "viewer"
}

Isso retornou o UUID da base compartilhada.

Então, sem enviar nenhum xc-auth, usei apenas:

xc-shared-base-id: <sharedBaseUuid>

Usando apenas esse cabeçalho, chamei:

GET /api/v2/meta/bases/<baseId>/users

Isso retornou 200 OK e expôs membros reais da base, incluindo endereços de e-mail.

Ainda usando apenas xc-shared-base-id, chamei:

POST /api/v2/meta/bases/<baseId>/users
Content-Type: application/json

{
  "email": "[email protected]",
  "roles": "viewer"
}

Isso também retornou 200 OK.

Para validação local em laboratório sem entrega de e-mail, confirmei diretamente no banco de dados meta SQLite que:

• nc_users_v2 continha o usuário convidado com um invite_token não nulo
• nc_base_users_v2 continha uma linha real de associação para a base alvo
• invited_by era NULL

Então resgatei o convite através do fluxo normal de cadastro:

POST /api/v2/auth/user/signup
Content-Type: application/json

{
  "email": "[email protected]",
  "password": "Password123.",
  "token": "<invite_token>"
}

Usando o xc-auth retornado, chamei:

GET /api/v2/meta/bases/<baseId>/tables

Isso retornou 200 OK.

Finalmente, como proprietário, desabilitei o link de base compartilhada:

DELETE /api/v2/meta/bases/<baseId>/shared

Após isso:

• o acesso ao link compartilhado com xc-shared-base-id falhou com 401
• a conta convidada usando xc-auth normal ainda teve sucesso com 200

Resultados observados

• lista de usuários compartilhados: 200
• convite compartilhado: 200
• cadastro: 200
• acesso à tabela autenticado convidado antes de desabilitar o compartilhamento: 200
• desabilitação do compartilhamento: 200
• acesso à tabela via link compartilhado após desabilitar: 401
• acesso à tabela autenticado convidado após desabilitar: 200

Isso estabeleceu a afirmação central de segurança:

• o acesso de compartilhamento público podia alcançar endpoints de associação
• as alterações de associação criavam acesso autenticado durável real
• revogar o compartilhamento original não removia esse acesso

Por que a Reprodução é Importante

Um único convite bem-sucedido de base compartilhada já teria sido suficiente para mostrar uma falha de autorização.

Mas a cadeia de validação completa importava por dois motivos.

Primeiro

Mostrou que não se tratava apenas de exposição de endpoint.

A sessão de compartilhamento público não apenas alcançou uma API restrita. Ela completou toda a cadeia de conversão de privilégio:

• enumerar membros
• convidar um novo principal
• resgatar o convite
• obter acesso autenticado normal

Segundo

Provou que isso não era autorrevogável.

O impacto mais sério veio após a desabilitação do link compartilhado:

• o link original morreu
• a conta criada pelo atacante não morreu

Isso é o que transformou acesso temporário por link em persistência de acesso durável.

Impacto

Esta vulnerabilidade permite que qualquer pessoa com um link de base compartilhada:

• enumere membros reais da base e seus endereços de e-mail
• convide endereços de e-mail arbitrários para a base como membros reais
• converta acesso temporário baseado em link em associação autenticada persistente
• preserve esse acesso mesmo depois que o proprietário revogar o link compartilhado

O impacto principal é confidencialidade, porque um atacante pode manter acesso de leitura duradouro aos dados da base compartilhada através de uma conta autenticada comum.

Há também impacto na integridade, porque um principal de compartilhamento público pode modificar o estado de controle de acesso adicionando novos membros à base.

Isso é um resultado mais forte do que um vazamento de dados comum. É uma quebra de fronteira de privilégio entre compartilhamento anônimo e associação autenticada.

Gravidade e Classificação

Este problema é razoavelmente classificado como uma falha de autorização entre escopos com impacto na confidencialidade.

CVSS:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N

Esse vetor se encaixa no comportamento central aqui:

• comportamento acessível via rede
• nenhuma conta autenticada prévia necessária
• nenhuma interação do usuário necessária da vítima durante a exploração
• mudança de escopo porque um principal de compartilhamento público cruza para a capacidade normal de gerenciamento de membros
• impacto na confidencialidade através de acesso não autorizado duradouro à base

Mitigação Sugerida

A direção da correção é direta.

Sessões de base compartilhada não devem herdar capacidades de gerenciamento de membros.

No mínimo:

• remova baseUserList e userInvite de quaisquer permissões acessíveis através de xc-shared-base-id
• imponha um bloqueio explícito para que principais compartilhados/públicos não possam chamar endpoints de associação à base, como GET e POST /api/v2/meta/bases/:baseId/users
• trate o acesso à base compartilhada como um tipo de principal distinto, em vez de mapeá-lo diretamente nas permissões normais de visualizador da base
• adicione testes de regressão que verifiquem que requisições de base compartilhada não podem enumerar membros, não podem convidar usuários e não podem criar acesso durável que sobreviva à revogação do compartilhamento

Divulgação

Este problema foi validado localmente contra NocoDB 0.301.3 no commit dac49b0122c5ee655fb8f46a1b6e42dfeec1f3ad.

O relatório demonstrou:

• o mapeamento de ACL de xc-shared-base-id para funções normais da base
• o caminho de permissão de visualizador para endpoints de gerenciamento de membros
• a criação de usuários convidados reais e linhas de associação à base
• a capacidade de resgatar o convite através do fluxo normal de cadastro
• a persistência do acesso autenticado após a revogação do link compartilhado

O problema foi atribuído:

CVE-2026-46552

O que Esse Bug Realmente Ensina

A lição principal aqui é simples:

acesso por link compartilhado não é a mesma coisa que associação confiável.

Muitos sistemas se metem em problemas quando colapsam essas duas ideias no mesmo modelo de função.

Um link compartilhado pode parecer operacionalmente semelhante a uma conta de visualizador, mas as suposições de confiança são diferentes:

• links compartilhados são fáceis de redistribuir
• links compartilhados devem ser revogáveis
• links compartilhados são geralmente principais de menor garantia

Se esse principal de menor garantia pode realizar ações de gerenciamento ou criar novas identidades duráveis, a fronteira de compartilhamento já está quebrada.

Essa é a verdadeira lição.

Pontos-chave

• recursos de compartilhamento público são fronteiras de segurança
• principais de link compartilhado não devem herdar capacidades comuns de gerenciamento de associação
• enumeração de membros a partir de um contexto de compartilhamento público já é sensível
• convite não autorizado é pior porque cria principais duráveis reais
• revogar o compartilhamento original não é suficiente se a conta criada pelo atacante sobreviver
• tratar o acesso de compartilhamento público como um tipo de principal separado é o design mais seguro

Palavras Finais

Esta vulnerabilidade não era sobre contornar a autenticação completamente.

Era sobre colapsar dois níveis de confiança que deveriam ter permanecido separados.

No NocoDB, um link de base compartilhada deveria fornecer acesso temporário e revogável ao conteúdo compartilhado. Em vez disso, podia ser usado para enumerar membros, convidar um usuário real para a base e converter o acesso de compartilhamento público em associação autenticada durável que sobrevivia à revogação do compartilhamento.

É por isso que isso se tornou CVE-2026-46552.