Adamkorcz

Um problema ocorre quando o registro está habilitado e a configuração `[oauth2 client].ACCOUNT LINKING` está definida como `auto`. O formulário de inscrição de vínculo de conta identifica contas existentes para vincular com base no nome de usuário ou e-mail fornecido no formulário, em vez da identidade verificada pelo provedor OAuth2. Isso permite que um invasor com uma conta válida em um provedor OAuth2 configurado envie o nome de outro usuário, vincule sua identidade externa a essa conta e obtenha acesso não autorizado sem senha, potencialmente incluindo privilégios de administrador. Esse vínculo permanece ativo para logins subsequentes.

Existe uma falha de bypass de autenticação na UI do Login V2 que permite que atacantes não autenticados assumam o controle de contas de usuários que ainda não configuraram nenhum método de autenticação. Ao computar um cookie `verificationCheck` válido usando o ID do usuário e a impressão digital do navegador, um atacante pode definir uma senha, registrar uma passkey ou vincular um provedor de identidade para a conta alvo.

Existe um problema em que a expressão regular de redação de senha usada durante o tratamento de erros da API consome recursos excessivos de CPU ao processar corpos de requisição longos. Atacantes remotos não autenticados podem enviar simultaneamente um pequeno número de requisições de API grandes para esgotar os workers do servidor, resultando em uma negação de serviço que torna o sistema lento ou indisponível para usuários legítimos.

Um problema de SQL injection existe na interface de administração do Mautic no endpoint '/s/ajax'. O problema ocorre porque um parâmetro de requisição usado para selecionar o campo de contato para pesquisa não é devidamente validado antes de ser incluído em uma consulta ao banco de dados. Qualquer usuário autenticado, independentemente de sua função ou permissões atribuídas, pode explorar isso usando técnicas cegas—como métodos baseados em booleano ou tempo—para executar consultas SQL arbitrárias. Isso permite que o invasor leia informações sensíveis do banco de dados, incluindo contas de usuário, endereços de e-mail, hashes de senha, dados de contato e conteúdo de campanhas.

Um problema de SQL Injection existe no endpoint da API de dados do widget do painel '/api/data/{type}'. Isso ocorre porque os parâmetros de filtro de gráfico fornecidos pelo cliente não são devidamente validados antes de serem usados em consultas ao banco de dados que geram dados de gráficos do painel. Um usuário autenticado com acesso à API pode usar blind SQL injection—uma técnica usada para recuperar dados de um banco de dados fazendo perguntas de verdadeiro/falso—para ler informações arbitrárias do banco de dados, incluindo detalhes de contato, dados de marketing e hashes de senha de contas de usuário. Além disso, o SQL injetado pode ser usado para desacelerar as consultas, impactando potencialmente a disponibilidade. A modificação de dados não é possível, e a exploração requer que a API do Mautic esteja habilitada.

Um problema de cross-site scripting armazenado existe no modal de pré-visualização de arquivos. O sistema republica dados binários como uma URL de blob de mesma origem não isolada. Isso permite que um membro faça o upload de um item manipulado e execute scripts na origem do n8n de qualquer usuário que visualize o arquivo, como o proprietário, permitindo que o invasor atue usando a sessão desse usuário.

Existe uma falha de bypass de autenticação no callback de intenção do provedor de identidade SAML. O sistema verifica a assinatura da asserção usando o provedor especificado na URL da requisição, mas resolve o usuário a partir da intenção de login sem verificar se eles coincidem. Isso permite que atacantes com permissões de administrador de organização registrem um provedor SAML com sua própria chave de assinatura para obter sessões autenticadas como qualquer usuário vinculado a outro provedor SAML na instância, inclusive em outras organizações.

A interface de usuário do Login V1 hospedada contém uma falha na qual o manipulador de alteração de nome de usuário processa solicitações para a conta associada a um fluxo de login antes de verificar qualquer fator de autenticação. Isso permite que invasores não autenticados forneçam o nome de login de uma vítima e enviem um novo nome de usuário para renomear qualquer usuário humano ativo, incluindo administradores, resultando no bloqueio do acesso desses usuários às suas contas.

O software possui uma configuração permissiva de Cross-Origin Resource Sharing (CORS) que confia em todas as portas no localhost e 127.0.0.1 com credenciais, independentemente da configuração `service.publicurl`. Isso permite que um invasor que controle uma página em qualquer porta do localhost envie uma solicitação com credenciais para o endpoint de atualização de token e recupere o bearer JSON Web Token (JWT), que é um meio compacto e seguro para URLs de representar reivindicações a serem transferidas entre duas partes, resultando na tomada total da conta do usuário conectado.

O Plane não valida adequadamente a variável `GITEA HOST`, verificando apenas o esquema da URL e permitindo hosts que resolvem para endereços IP privados ou internos. Isso ocorre porque as quatro requisições externas no fluxo OAuth do Gitea são derivadas deste host não validado e não chamam a função `validate url()`. Além disso, a `avatar url` é obtida do perfil do usuário do Gitea, onde os usuários podem configurar URLs externas. Um invasor pode definir uma URL interna como avatar do perfil e fazer login via Gitea, fazendo com que o sistema busque o alvo interno sem validação, potencialmente permitindo Server-Side Request Forgery (SSRF).

O `aPITokenLogMiddleware` registra chaves de API em texto simples, o que permite que um usuário com baixos privilégios roube essas chaves e escale seus privilégios.

Uma falha de autenticação ausente existe na interface do usuário do Login V1 hospedado. Os manipuladores de inicialização e registro de segundo fator processam sessões apenas de identificação antes que o fator primário seja verificado. Um invasor que conheça o nome de login de uma vítima pode registrar fatores TOTP, OTP-SMS, OTP-Email ou U2F controlados pelo invasor, sobrescrever o número de telefone verificado e enumerar usuários através de mensagens de erro discrepantes.

Existe uma falha de bypass de autenticação na interface de usuário Login V1 hospedada. O problema ocorre porque o endpoint de registro para contas externas não encontradas confia em campos de identidade externa fornecidos pelo cliente sem a necessidade de um callback de Provedor de Identidade (IdP) concluído. Um invasor não autenticado pode enviar valores forjados de `IDPConfigID` e `ExternalUserID` para pré-criar uma conta vinculada à identidade de IdP externo de uma vítima. Quando a vítima posteriormente realiza um login externo legítimo, ela é autenticada na conta pré-criada.

Existe uma falha de bypass de autenticação nas interfaces de usuário (UIs) hospedadas Login V1 e Login V2. O sistema permite o registro de uma passkey ou outro autenticador durante sessões de login apenas para identificação, antes que qualquer fator primário seja verificado. Um invasor não autenticado que conheça o nome de login de uma vítima pode registrar um autenticador controlado pelo invasor para obter acesso não autorizado à conta, ignorando senhas e a autenticação de múltiplos fatores (MFA).

Uma falha de autorização inadequada ocorre durante a emissão de códigos de registro de passkey ou autenticação sem senha. O sistema valida a organização especificada no cabeçalho `x-zitadel-orgid`, mas não verifica a organização do usuário alvo. Isso permite que um invasor com permissão de escrita de usuário em uma organização obtenha um código de registro para um usuário pertencente a outra organização na mesma instância, permitindo que o invasor registre seu próprio autenticador e assuma o controle da conta.

Existe um problema onde links são criados entre contas de usuário e provedores de identidade externos sem a verificação de um fator primário ou da permissão do solicitante. Isso ocorre durante sessões de Login V2 apenas para identificação e através do endpoint 'AddIDPLink' do User Service V2. Um invasor não autenticado que conheça o nome de login de uma vítima pode vincular sua própria identidade de provedor externo à conta da vítima para sequestrá-la e entrar como a vítima.

Um problema de escalação de privilégios existe no endpoint de API `POST /users/{username}/tokens` utilizado para criar Tokens de Acesso Pessoal. O endpoint é protegido pelo middleware `reqBasicOrRevProxyAuth`, que foi projetado para exigir autenticação baseada em senha para evitar que um token comprometido seja usado para gerar novos tokens. No entanto, se um token for fornecido no formato `Authorization: Basic <token>:x-oauth-basic`, o sistema define incorretamente o `AuthedMethod` como `basic` e `IsBasicAuth` como `true`, ignorando a proteção do middleware. Uma vez superada a proteção, a função `CreateAccessToken` não aplica um limite de escopo, o que significa que ela não verifica se os escopos solicitados são um subconjunto dos escopos atuais do solicitante. Consequentemente, um invasor que possua um token restrito (como um com permissões apenas de `write:user`) pode criar um novo token com o escopo `all`, obtendo acesso total à conta sem saber a senha do usuário.

Um usuário autenticado pode causar a negação de serviço ao enviar uma chave pública RFC 4716 (SSH2) especialmente manipulada para o endpoint de ingestão de chaves SSH. O problema decorre de uma função de normalização que utiliza um loop de concatenação de strings O(N²) sem limites de tamanho de entrada. Quando uma chave contém um grande número de linhas de conteúdo curtas, o servidor executa uma quantidade quadrática de trabalho tanto em tempo quanto em alocações de memória, pois as strings em Go são imutáveis, exigindo a alocação de um novo array e a cópia a cada concatenação. Isso pode levar ao esgotamento da CPU e da memória, deixando a instância offline. **API Endpoints:** '/api/v1/user/keys' **Vulnerable Parameters or Variables:** `key` **Function Names:** `parseKeyString()`, `CheckPublicKeyString()`, `CreateUserPublicKey()`

Existe um problema na lógica de validação do token Remember-Me onde o sistema falha em invalidar todas as sessões ativas quando um token comprometido é detectado. O Gitea utiliza um design de token dividido composto por um ID e um Hash. Quando um token é utilizado, o Hash é rotacionado enquanto o ID permanece constante. Se um invasor roubar um token e se autenticar, ele receberá um novo token rotacionado. Quando o usuário legítimo tenta posteriormente usar seu token original, o sistema detecta uma incompatibilidade de hash. Embora a função `CheckAuthToken()` identifique essa incompatibilidade, o processo `autoSignIn` apenas exclui o cookie local da vítima e não remove o token comprometido do banco de dados. Isso permite que um invasor mantenha acesso persistente à conta. O endpoint afetado é `POST /user/login` e qualquer outro endpoint que acione o `autoSignIn` via cookie Remember-Me.

O analisador do registro de pacotes Debian contém dois problemas que podem levar a uma negação de serviço completa. Primeiro, existe uma falha de descompressão ilimitada na função `ParseControlFile()`. Ao processar um arquivo `.deb` enviado, o analisador descompacta o `control.tar.gz` e copia o fluxo para um `strings.Builder` sem limitar a quantidade de dados lidos. Um invasor pode usar uma bomba de descompressão — um payload pequeno que se expande para um tamanho massivo — para esgotar a memória do servidor. Segundo, o analisador utiliza `+=` para concatenação de strings ao processar linhas de continuação no campo Description, resultando em operações de alocação e cópia `O(N²)`. Isso pode saturar a CPU e desencadear ciclos frequentes de coleta de lixo (garbage collection). Qualquer usuário autenticado com acesso de escrita ao registro de pacotes pode disparar esses problemas por meio de uma requisição ao manipulador em `routers/api/packages/debian/debian.go:146`.