Bl4Cksku11

Um problema existe no endpoint `ProjectBulkAssetEndpoint.post` em `apps/api/plane/app/views/asset/v2.py`, onde os ativos são recuperados usando `id in=asset ids` e `workspace slug=slug`, mas a consulta não é restringida pelo `project id` fornecido na URL. Isso permite que um Convidado (Guest) do workspace forneça UUIDs de ativos de outro projeto no mesmo workspace e reatribua o `issue id`, `comment id`, `page id`, `draft issue id` ou `project id` a uma entidade controlada pelo invasor. Consequentemente, o sistema trata o projeto do invasor como o novo proprietário e fornece uma URL de download pré-assinada para o arquivo sequestrado.

O Plane confia em endereços de e-mail retornados pelo Gitea OAuth e por implantações do GitLab OAuth autogerenciadas onde a confirmação de e-mail está desativada, sem verificar se o provedor autenticou a propriedade do endereço. Um invasor pode definir o e-mail não verificado de uma identidade OAuth para o endereço de uma vítima, o qual o sistema associa diretamente à conta local existente da vítima. Isso permite que um invasor acesse a conta da vítima sem saber a senha.

Existe um problema onde o endpoint de introspecção de token OAuth permite que qualquer cliente OAuth autenticado recupere metadados de tokens emitidos para outros clientes, violando a seção 4 da RFC 7662. O servidor não verifica se o cliente solicitante é o público-alvo do token, retornando informações sensíveis independentemente da propriedade. **API Endpoints:** '/login/oauth/introspect' **Vulnerable Parameters or Variables:** `token` **Function Names:** `IntrospectOAuth()` Um invasor com um cliente OAuth válido pode usar este endpoint como um oráculo de validade de token para verificar se tokens roubados ainda estão ativos sem disparar trilhas de auditoria de uso real do token. Além disso, isso permite a enumeração de metadados entre locatários, permitindo que um invasor identifique o `username` e o `scope` associados a tokens pertencentes a outros clientes.

Um usuário com permissões de escrita no repositório pode ignorar a lista de permissões (allowlist) de extensões de arquivo configurada ao renomear anexos de releases através da interface web. Enquanto os endpoints da API impõem a restrição `Repository.Release.AllowedTypes`, o manipulador web `EditReleasePost` em `routers/web/repo/release.go` não chama a função `upload.Verify()` antes de atualizar o nome do anexo no banco de dados via `repo model.UpdateAttachmentByUUID()`. Isso permite que um invasor renomeie um arquivo anteriormente enviado e compatível para uma extensão proibida, como `.exe`, `.html` ou `.svg`. Isso pode ser utilizado para distribuir malware ou hospedar ataques de Cross-Site Scripting (XSS) armazenado caso o servidor renderize certos tipos de arquivos inline.

Convites de organização podiam ser aceitos ou recusados por usuários com um endereço de e-mail correspondente ao convite que não havia sido verificado. Embora o sistema utilize OIDC (OpenID Connect, uma camada de identidade sobre o protocolo OAuth 2.0) para comparar o e-mail do alvo do convite com o token do solicitante, os caminhos de aceitação e recusa de convites não exigiam a verificação do e-mail. Isso permite que um agente, utilizando um provedor de identidade que permita o cadastro automático e emita sessões antes da verificação, registre um e-mail correspondente a um convite pendente e entre na organização alvo com a função atribuída, que poderia ser de até Proprietário (Owner).