Judel777

Existe uma falha de autorização na função `checkPermissionsForCreateOrUpdate()` dentro da classe `Multitenancy`. Em implantações multi-tenant licenciadas onde várias aplicações compartilham um domínio de URI de conexão não padrão e utilizam `api keys` separadas, um invasor com uma chave de API válida para uma aplicação pode atualizar o domínio de URI de conexão pai. Isso ocorre porque o sistema não exige que a aplicação e o tenant de origem sejam públicos ao verificar o domínio durante operações de criação ou atualização. Consequentemente, um invasor pode substituir a chave pai e as chaves de aplicações irmãs, modificar usuários irmãos, sequestrar sessões e estabelecer persistência via usuários de painéis irmãos. Além disso, a omissão do identificador opcional nos manipuladores de criação ou atualização v2 permite que um invasor direcione o tenant base, ignorando verificações de permissão e travas de recursos empresariais para modificar `firstFactors`, fatores secundários obrigatórios e sinalizadores de receitas habilitadas, comprometendo a integridade e disponibilidade do login.

A aplicação falha ao validar se os principais em `channel permission overrides` pertencem à organização. Isso permite que administradores de aplicativos ou organizações autenticados concedam permissões de canal a usuários externos à organização, inserindo linhas de substituição com UUIDs de usuários externos arbitrários. Isso pode resultar na concessão não autorizada de permissões com escopo de canal, como `channel.promote bundle`.

Existe um problema incompleto de controle de acesso e aplicação de bloqueio de conteúdo onde os bloqueios `enforce encrypted bundle trigger` e `check encrypted bundle on insert` isentam linhas em `app versions` se o `storage provider` anterior for `r2-direct`. Isso permite que colunas críticas para a entrega—incluindo `name`, `app id`, `session key`, `key id`, `storage provider`, `r2 path`, `external url`, `checksum`, `manifest` e `native packages`—permaneçam mutáveis. Adicionalmente, o endpoint `/updates` não exclui versões `r2-direct`, tornando-as selecionáveis para atualizações Over-the-Air (OTA). Um invasor com uma chave de API com permissões de gravação ou upload de pacotes pode manter um pacote no estado `r2-direct` e modificar esses campos via requisições PostgREST, resultando no fornecimento de metadados de pacotes alterados para os dispositivos.

Um membro autenticado de uma organização pode criar uma chave de API com escopo de aplicativo que não expira, ignorando a política de expiração de chaves de API da organização. Isso ocorre quando a organização proprietária possui a opção `require apikey expiration` ativada e um limite de `max apikey expiration days` configurado. No endpoint 'POST /apikey', solicitações que fornecem `app id`, mas omitem `org id`, `limited to orgs` e `expires at`, não adicionam a organização proprietária do aplicativo à lista de IDs passados para a função `validateExpirationAgainstOrgPolicies()`. Como a lista fica vazia, o processo de validação é encerrado prematuramente sem aplicar a política de expiração.

Um proxy de upload TUS de build nativa no endpoint `supabase/functions/ backend/public/build/upload.ts` lida incorretamente com a autorização. O proxy valida o chamador em relação a um trabalho de build específico usando o `builder job id` e verifica o `upload path` armazenado, mas encaminha um sufixo de recurso TUS controlado pelo usuário do caminho `/build/upload/:jobId/*` para o serviço de build enquanto injeta uma chave de API de build privilegiada do Capgo. Como o sufixo encaminhado não está vinculado ao `upload path` ou `upload session key` do trabalho autorizado, um invasor com uma chave de API do Capgo válida do tipo 'all' ou 'write' e permissão `app.build native` para um aplicativo pode gravar no recurso de upload TUS de outro trabalho, desde que o sufixo do recurso seja conhecido, resultando na corrupção dos artefatos de build.

Existe um problema na política de atualização de segurança em nível de linha (row-level security) na tabela `public.orgs`. Um administrador de organização autenticado com permissões `org.update settings` pode ignorar o endpoint oficial de atualização de organização `supabase/functions/ backend/public/organization/put.ts` e a rota de faturamento privada do Stripe, enviando uma atualização diretamente para o Supabase PostgREST. Isso permite que o usuário modifique a coluna de ponteiro de faturamento interno `customer id`, mesmo sem a permissão `org.update billing`. Ao anular ou corromper esse valor, o usuário pode fazer com que as verificações de plano e faturamento falhem, movendo efetivamente a organização de um plano pago para um estado não pago ou sem plano.

🚨 CVE-2026-100623 Capgo (capgo.app) exposes the legacy membership table public.org users directly through Supabase PostgREST. The table's row-level security policies "Allow org admin to insert" and "Allow org admin to update" only verify that the caller has admin rights in the target organization (public.check min rights('admin', ...)); they do not require a pending invitation in tmp users, acceptance of an invite token via /private/accept invitation, any action by the target user, or the membership/role-consistency and anti-escalation checks enforced by the RBAC role-binding path. As a result, an authenticated user who is an admin of an organization can INSERT or UPDATE org users rows directly to add any existing public.users account as an active member of that organization with user right="admin", bypassing the invitation and role-assignment workflow entirely. In testing, an account with no prior access to the organization or its apps could, after such a direct insert, read the organization and app and pass check min rights. All versions are affected and no patch was available at the time of publication. 🎖@cveNotify

A função de banco de dados `transfer app()` não exclui nem revalida as linhas existentes em `channel permission overrides` ao transferir um aplicativo, seus canais, versões e registros relacionados para uma organização de destino. Isso permite que um usuário que possuía uma sobreposição de permissão de canal na organização de origem mantenha essa sobreposição após a transferência, mesmo sem ter vínculo de membro ou de Controle de Acesso Baseado em Função (RBAC) na organização de destino. Um invasor pode usar um JSON Web Token (JWT) autenticado contra a API PostgREST para modificar o canal pertencente ao destino para apontar para um pacote diferente, fazendo com que o endpoint `/updates` forneça uma versão do aplicativo selecionada pelo invasor aos dispositivos.

Existe uma evasão indireta da política de segurança de nível de linha na tabela `public.manifest`. Um usuário ou principal com chaves de API de upload, gravação ou todas as permissões no escopo do aplicativo, ou um usuário autenticado com direitos de gravação+, pode atualizar `public.app versions.manifest` para versões que utilizam o provedor de armazenamento `r2-direct`, pois estas não são cobertas pela verificação de bloqueio de conteúdo do pacote. O worker assíncrono `on version update` confia no `record.manifest` e utiliza um cliente Supabase de função de serviço para inserir as variáveis `file name`, `file hash` e `s3 path` controladas pelo invasor na tabela `public.manifest`. Consequentemente, o endpoint `/updates` retorna esta entrada como uma `download url` voltada ao cliente, permitindo o envenenamento de manifesto Over-the-Air (OTA). OTA refere-se à entrega sem fio de atualizações para um dispositivo.

Existe uma falha de autorização no processo de atualização do ícone do aplicativo. O endpoint 'PUT /app/:id' aceita um valor `icon` controlado pelo usuário e o armazena em `public.apps.icon url` sem verificar se o caminho da imagem pertence ao namespace de imagem do aplicativo de destino. A atualização deste valor dispara o gatilho `on app update`, que executa a função `cleanStoredImageMetadata()` usando credenciais de função de serviço. Este processo baixa e faz o upload do objeto de armazenamento referenciado com `upsert: true`. Consequentemente, um usuário autenticado com uma chave de API de gravação limitada ao aplicativo pode forçar o worker privilegiado a sobrescrever objetos de imagem privados, como logotipos de organizações, aos quais o usuário normalmente não teria acesso sob o Row Level Security (RLS) do Supabase Storage, um recurso de segurança que restringe o acesso aos dados com base em funções de usuário.

O endpoint de proxy TUS '/build/upload/:jobId' não impõe a expiração do upload ou o estado do ciclo de vida da compilação. Embora as solicitações de compilação nativa incluam um timestamp `upload expires at` e um status 'pending', o proxy de upload verifica apenas a permissão `app.build native` antes de encaminhar solicitações POST, PATCH e HEAD para o construtor interno. Consequentemente, um usuário autenticado com a permissão `app.build native` pode continuar gravando em uma sessão de upload de compilação após o tempo de expiração ter passado ou após a compilação ter avançado além da fase de upload, desde que o serviço de construtor interno não rejeite a solicitação independentemente.

O backend falha ao validar a delegação pai-filho ao processar o cabeçalho `x-limited-key-id`. A função `checkKeyByIdPg()` em `supabase/functions/ backend/utils/hono middleware.ts` resolve o ID numérico da chave de API usando apenas o ID da chave, o estado de expiração e o `user id` da chave de autenticação. Simultaneamente, `hasLimitedRbacSubkeyScope()` aceita qualquer chave com uma vinculação RBAC não organizacional, e `validateSubkeyUser()` apenas compara os IDs de usuário proprietários. Isso permite que uma chave de API `apikey manager` autenticada, sem acesso ao aplicativo, forneça o ID numérico de uma chave mais privilegiada pertencente ao mesmo usuário. O middleware então utiliza `setSubkeyAuthContext` para substituir o principal e o segredo autenticados pelos da chave privilegiada, permitindo que o usuário exerça permissões de `app admin` sem conhecer o segredo.

Capgo (capgo.app) fails to restrict direct write access to the public.sso providers table exposed through Supabase PostgREST. A holder of an ordinary Capgo full API key can insert a row with status='active' and enforce sso=true, bypassing the intended backend SSO provisioning route (supabase/functions/ backend/private/sso/providers.ts) and its controls: the Enterprise plan requirement, SSO provider creation via the Supabase Management API, DNS TXT domain-ownership verification, the pending verification → verified → active status transition, and issuance of a trusted provider ID by Supabase Auth. The forged row is trusted by SSO discovery and enforcement logic, including the unauthenticated login preflight endpoint /private/sso/check-domain, which then reports {"has sso": true, "enforce sso": true} for domains that were never verified, allowing attacker-controlled SSO enforcement to be asserted for arbitrary domains and disrupting normal login. All versions are affected; at the time of the advisory no patch was available.

O Capgo falha ao limpar as sobreposições de permissão de canal quando a última vinculação de função de organização de um usuário é excluída, mantendo sobreposições obsoletas ativas. Isso permite que invasores mantenham permissões específicas de canal mesmo após o acesso base de Controle de Acesso Baseado em Função (RBAC) ter sido revogado, possibilitando ações não autorizadas, como a alteração de versões de atualização Over-the-Air (OTA) de produção.

Capgo (Cap-go/capgo.app) contains an authentication bypass affecting all versions (no patched version available at time of publication). The Edge authorization path allows a password-only Supabase aal1 session to exercise privileged RBAC permissions even when the account has a verified MFA factor that has not been used for the session: the Edge JWT middleware (foundJWT() in supabase/functions/ backend/utils/hono middleware.ts) accepts the JWT without validating its assurance level, and the direct RBAC path (checkPermission()/checkPermissionPg() in supabase/functions/ backend/utils/rbac.ts calling public.rbac check permission direct()) authorizes by user ID without passing or checking the session aal, unlike the public.verify mfa() control which correctly requires aal2. An attacker who knows only the victim's password can therefore authenticate, mint a persistent app-scoped app admin API key that remains valid after the aal1 session is logged out, and perform privileged operations such as modifying production OTA channel configurations (validated by changing a public production channel from bundle 1.0.0 to 1.0.1), defeating the protection provided by MFA.

Um problema de divulgação de informações existe na função RPC Supabase PostgREST SECURITY DEFINER `public.rescind invitation()`. Atacantes não autenticados, utilizando apenas uma chave de API publicável, podem enumerar a existência de organizações. Isso é possível porque a função retorna mensagens de erro distintas, especificamente `NO ORG` e `NO RIGHTS`, permitindo que atacantes identifiquem IDs de organizações válidos. Essa descoberta pode ser usada para facilitar campanhas de phishing direcionado ou engenharia social.

Existe um problema onde usuários rebaixados da função `super admin` mantêm acesso não autorizado a funções específicas. Isso ocorre porque a coluna `org users.user right` não é limpa durante a exclusão de vinculações de função, resultando em permissões obsoletas. Um invasor pode usar isso para enumerar e excluir em massa pacotes não conformes em toda a organização. As funções afetadas são os RPCs `delete non compliant bundles` e `count non compliant bundles`.

Um problema de divulgação de informações existe no endpoint `global stats` do Supabase PostgREST. Atacantes não autenticados podem usar a `apikey` pública para consultar o endpoint '/rest/v1/global stats', expondo métricas financeiras e operacionais sensíveis, incluindo a Receita Recorrente Mensal (MRR), receita total, detalhamento de receita por nível de plano, contagem de clientes e telemetria operacional.

Um problema de isolamento de escopo existe no endpoint 'POST /webhooks/test'. Esta falha permite que usuários com chaves de API de escopo de aplicativo executem operações de webhook de escopo de organização, ignorando a verificação de autorização `limited to apps`. Consequentemente, um invasor usando credenciais de escopo de aplicativo pode disparar entregas de webhooks de organização arbitrários que estejam fora do limite do aplicativo declarado.

Um problema de interrupção de conta entre organizações existe no endpoint de pré-vinculação de SSO. Administradores corporativos com a permissão `org.update settings` e um provedor de SSO ativo podem utilizar o endpoint `prelink-users` para excluir permanentemente as identidades de senha de usuários de outras organizações, desde que os usuários correspondam ao domínio de e-mail do provedor. Esta ação força os usuários afetados a utilizar o provedor de SSO do invasor ou a realizar um processo de recuperação de redefinição de senha.