Grayom

Existe uma falha de bypass de autenticação que permite que atacantes não autenticados forjem links de login utilizando o `AUTH SECRET` de exemplo publicamente conhecido. Esta falha permite que atacantes enumerem e-mails registrados através do endpoint '/api/ auth/signin', forjem JWTs (JSON Web Tokens, que são padrões abertos para transmitir informações com segurança entre partes como um objeto JSON) HS256 resgatados pelo endpoint '/api/ auth/continue', personifiquem usuários, exportem dados analíticos e transfiram a propriedade do aplicativo.

Atacantes não autenticados podem executar SQL arbitrário ao fornecer uma chave de grupo de tarefa manipulada para a API do orquestrador. Ao enviar um `group.key` malicioso para o endpoint 'POST /v1/immediate', a função `TaskEventsHandler.notify()` interpola a entrada em uma instrução Postgres NOTIFY, permitindo a execução de consultas empilhadas contra o banco de dados do agendador.

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.

Existe um problema na função `SAML.handleCallback()` onde ela não consome o RelayState, não registra identificadores de asserção ou não impõe o `Response.InResponseTo`. Em fluxos iniciados pelo Provedor de Serviço (SP), um invasor com uma resposta SAML válida e o RelayState correspondente pode resubmetê-los ao endpoint `/recipe/saml/callback` antes da expiração da asserção. Em fluxos iniciados pelo Provedor de Identidade (IdP), as asserções podem ser repetidas sem o RelayState. Além disso, a falta de verificações de `Response.InResponseTo` permite que um login em andamento seja concluído com uma asserção de uma identidade diferente e ignora a configuração `allowIDPInitiatedLogin=false`. O callback também não valida o Destination ou SubjectConfirmationData Recipient e NotOnOrAfter, resultando na criação de um novo código de autorização para a identidade do usuário capturado.

Uma falha de bypass de autorização permite que bots de agentes autenticados acessem outras contas ao fornecer um `source id` de caixa de entrada de contato estrangeiro. Isso é feito chamando o endpoint 'conversations create' com um `source id` pertencente a outra conta, permitindo a criação ou recuperação de conversas e o envio de mensagens para os contatos dessa conta.