Someshhackz-Spec

**Nome do Software Vulnerável e Versões Afetadas** Capgo versões anteriores a 12.261.1 **Descrição** O backend restringe inadequadamente as funções que a função de organização `apikey manager` pode atribuir a novas chaves de API. Quando um usuário autenticado com permissões de `apikey manager` (especificamente `org.manage apikeys` e `org.read`) chama o endpoint 'POST /apikey', o sistema não verifica se o solicitante possui as permissões da função que está sendo atribuída. O processo de validação baseia-se em uma lista de negação e em uma comparação de classificação de prioridade na função `createRoleBindingForPrincipal()`. Como a lista de negação omite várias funções de implantação—`app developer`, `app uploader`, `channel developer` e `channel uploader`—e o `apikey manager` possui uma classificação de prioridade superior a essas funções, a verificação é ignorada. Isso permite que um usuário com privilégios limitados crie uma chave de API com funções de implantação e envie atualizações arbitrárias de JavaScript Over-the-Air (OTA) para todos os usuários finais dos aplicativos da organização. **Recomendações** No momento, não há informações sobre uma versão mais recente que contenha a correção para esta vulnerabilidade.

**Nome do Software Vulnerável e Versões Afetadas** Capgo (capgo.app) versões anteriores a 12.261.0 **Descrição** Uma correção de controle de acesso incompleta na tabela `public.sso providers` permite que um usuário com permissões de `org admin` e a permissão `org.update settings` realize uma escalada de privilégios vertical. Embora a função `enforce sso provider client update guard()` restrinja atualizações em certas colunas, as variáveis `provider id`, `metadata url` e `attribute mapping` permanecem graváveis. Devido a concessões de tabela permissivas e políticas de segurança de nível de linha que não restringem colunas específicas, um invasor pode usar uma requisição PATCH via PostgREST para alterar o `provider id` para um provedor de identidade (IdP) sob seu controle. Ao afirmar o e-mail do proprietário da organização através de seu próprio IdP, o invasor pode mesclar sua identidade com a conta do proprietário, resultando no sequestro da conta, anulação da senha e bloqueio do proprietário legítimo. Isso requer que a organização tenha um provedor SSO ativo configurado e que o invasor já possua o status de `org admin`. **Recomendações** No momento, não há informações sobre uma versão mais recente que contenha a correção para esta vulnerabilidade.