Lissy93

Um problema de escalonamento de privilégios permite que proprietários de equipes obtenham direitos administrativos ou a propriedade de projetos compartilhados apenas para leitura. Um invasor pode conseguir isso criando um bot, adicionando-o à sua equipe e, em seguida, excluindo-o através do endpoint de bots. Esse processo aciona a função `ensureProjectAdminUser()`, que promove compartilhamentos de apenas leitura e bloqueia o proprietário real.

Existe um problema de divulgação de informações onde colaboradores de projetos com acesso de escrita podem ler tarefas de projetos inacessíveis ao registrar webhooks. Isso ocorre porque as cargas úteis (payloads) do webhook são construídas usando as permissões do usuário que dispara o evento. Consequentemente, quando outro usuário modifica uma tarefa vinculada, invasores podem obter títulos, descrições e metadados de `related tasks` de projetos privados.

O servidor de carga de trabalho do supervisor apresenta a ausência de autenticação, permitindo que cargas de trabalho manipulem execuções pertencentes a outras implantações sem a verificação de propriedade. Um invasor com acesso à rede e um par de execução/snapshot válido pode acessar o endpoint 'attempts/start' para obter variáveis de ambiente resolvidas e JWTs (JSON Web Tokens, utilizados para a transmissão segura de informações entre partes) de execução. Além disso, isso permite que o invasor inicie, complete ou suspenda execuções de outros locatários.

Um problema de cross-site request forgery existe no fluxo de código de autorização da CLI. O processo de carregamento do endpoint '/account/authorization-code/<code>' gera um Personal Access Token (PAT) sem exigir uma etapa de consentimento. Um invasor pode gerar um código não autenticado e atrair um usuário autenticado para essa URL, recuperando posteriormente o PAT da vítima através do endpoint não autenticado '/api/v1/token' para assumir o controle da conta.

Instalações self-hosted contêm um segredo de autenticação padrão codificado no namespace Socket.IO `/coordinator`. Isso permite que invasores não autenticados se conectem usando o valor padrão `coordinator-secret`. Uma vez conectados, os invasores podem explorar o seguinte: 1. Divulgação de Informações: Ao emitir o evento `READY FOR EXECUTION`, invasores podem recuperar variáveis de ambiente descriptografadas de qualquer execução se possuírem o `runId`. Isso afeta especificamente implantações que ainda utilizam o Run Engine 1.0. 2. Modificação Não Autorizada de Dados: Invasores podem enviar eventos como `TASK RUN FAILED TO RUN`, `TASK RUN COMPLETED`, `TASK RUN COMPLETED WITH ACK`, `CHECKPOINT CREATED` ou `CREATE WORKER` para adulterar execuções arbitrárias usando payloads fornecidos pelo invasor. Isso é possível porque o sistema não verifica se o chamador tem autoridade sobre o `runId` ou `attemptId` fornecido na mensagem.

Express XSS Sanitizer, middleware for Express 4.x and 5.x, sanitizes user input data in `req.body`, `req.query`, `req.headers`, and `req.params` to prevent Cross-Site Scripting (XSS) attacks. A flaw exists where restrictive sanitization configurations are silently ignored. Specifically, when `allowedTags` is set to an empty array (`[]`) and `allowedAttributes` is set to an empty object (`{}`), the library incorrectly falls back to default permissive settings instead of stripping all HTML tags and attributes. This allows a wide range of HTML elements and attributes, such as `<a href="...">` and `<div>`, to be injected. The issue stems from validation logic that incorrectly interprets empty configurations as not provided, leading to a mismatch between developer intent and actual behavior. The vulnerable component is the sanitization logic within the library.