Vulnerabilidades do Makeplane Plane

O Plane é uma ferramenta de gestão de projetos de código aberto. Antes da versão 1.4.0, o Plane confia em endereços de e-mail retornados pelo OAuth do Gitea e pelo OAuth de implantações self-managed do GitLab em que a confirmação de e-mail está desabilitada, sem verificar se o provedor autenticou a posse do endereço. Um atacante pode definir o e-mail não verificado de uma identidade OAuth como o endereço de uma vítima, que o Plane associa diretamente à conta local existente da vítima. O atacante pode então entrar na conta Plane da vítima sem conhecer a senha dela. GitHub, GitLab.com e Google não são afetados porque esses provedores retornam endereços de e-mail verificados. Este problema está corrigido na versão 1.4.0.

O Plane é uma ferramenta open source de gestão de projetos. Antes da versão 1.4.0, o login por código mágico enviado por e-mail do Plane usa um código OTP numérico de seis dígitos com aproximadamente 20 bits de entropia. O verificador não possui contador de tentativas falhas por código e um código incorreto não incrementa um contador, não invalida a entrada no Redis nem bloqueia o endereço de e-mail. O verificador estende django.views.View em vez do APIView do DRF, de modo que o limite configurado do AnonRateThrottle não se aplica. A pilha de middleware também não contém limitador de taxa no nível do Django, como django-ratelimit, django-axes ou middleware de limitação por IP. Esta vulnerabilidade está corrigida na versão 1.4.0.

Plane é uma ferramenta de gestão de projetos de código aberto. Antes da versão 1.4.0, os manifestos deployments/aio/community/ e deployments/cli/community/ fornecem valores padrão fixos e publicamente conhecidos para SECRET_KEY e LIVE_SERVER_SECRET_KEY, que permanecem ativos quando os operadores não os substituem. O script setup.sh de nível superior randomiza os segredos apenas para o caminho de desenvolvimento com Docker Compose, deixando as implantações aio e cli community inalteradas com segredos de produção compartilhados. O conhecimento de SECRET_KEY permite que atacantes forjem valores assinados pelo Django e comprometam contas ou sessões. O conhecimento de LIVE_SERVER_SECRET_KEY permite contornar a autenticação do serviço ao vivo em implantações community inalteradas. Este problema está corrigido na 1.4.0.

Plane is an open-source project management tool. Prior to 1.4.0, Plane's signup flow creates a logged-in User row for any submitted email without an out-of-band ownership check, while User.email is unique=True. The authenticated user can call GET /api/users/me/workspaces/invitations/, which returns each WorkspaceMemberInvite whose email matches request.user.email. WorkSpaceMemberInviteSerializer uses fields = "all", exposing the token that protects the invitation join endpoint. An unauthenticated attacker who knows a target's email can register an account using that address, enumerate pending invitations, and accept an invitation as the target, joining a workspace at the invited role. The term pre-auth describes the attacker's initial state: the attacker has no credential before signup, while the enumeration and join requests use the session created by that signup. This issue is fixed in 1.4.0.

Plane é uma ferramenta de gerenciamento de projetos de código aberto. Antes da versão 1.4.0, ProjectBulkAssetEndpoint.post em apps/api/plane/app/views/asset/v2.py recupera ativos usando id__in=asset_ids e workspace__slug=slug, mas não restringe a consulta com o project_id da URL. Um Guest do workspace pode fornecer UUIDs de ativos de outro projeto do mesmo workspace e reatribuir seus issue_id, comment_id, page_id, draft_issue_id ou project_id a uma entidade controlada pelo atacante. O Plane então trata o projeto do atacante como novo proprietário e fornece uma URL de download pré-assinada para o arquivo sequestrado. Este problema foi corrigido na versão 1.4.0.

O Plane é uma ferramenta de gerenciamento de projetos de código aberto. Antes da versão 1.4.0, a tarefa de entrega de webhooks em apps/api/plane/bgtasks/webhook_task.py chama requests.post() sem allow_redirects=False e não valida os destinos dos redirecionamentos. A função validate_url() bloqueia endereços privados, de loopback, link-local e reservados na URL original do webhook, mas a URL final alcançada após um ou mais redirecionamentos não é verificada. Um usuário que pode criar um workspace pode registrar um webhook apontando para um endpoint público controlado pelo atacante que responde com um redirecionamento 302 para um endereço interno. O worker do Plane então busca recursos internos, incluindo metadados de nuvem, e armazena o corpo da resposta em webhook_logs, onde o atacante pode recuperá-lo pela API de logs de webhooks do workspace. Este problema está corrigido na 1.4.0.