Khoadb175

Quando o Suporte Completo a Múltiplas Empresas (Full Multiple Company Support) está habilitado, a aplicação falha ao aplicar a filtragem de escopo de empresa no endpoint 'GET /hardware/requested'. Isso permite que usuários autenticados com a permissão `assets.view` acessem solicitações de ativos pendentes de todas as empresas. Esta falha possibilita a recuperação de dados entre locatários (cross-tenant), incluindo nomes de ativos solicitados, nomes de exibição e links de perfil dos solicitantes, locais e datas de check-in esperadas, sem a necessidade de manipulação de parâmetros.

Ocorre uma falha de bypass de autorização nas ações de relatório de checkout-acceptance quando o Suporte Completo a Múltiplas Empresas (Full Multiple Company Support) está habilitado. Usuários autenticados com a permissão `reports.view` podem enumerar IDs de aceitação sequenciais para excluir logicamente (soft-delete) ou disparar e-mails de lembrete para aceitações pertencentes a outras empresas. Isso é possível ao explorar uma verificação de nulo na coluna legada `users.company id`.

Um Server-Side Request Forgery (SSRF) cego existe quando a configuração `[oauth2 client] UPDATE AVATAR = true` está habilitada. O problema ocorre porque o servidor busca a URL do avatar fornecida por um provedor OAuth2/OIDC — geralmente a claim `picture` — usando o cliente HTTP padrão do Go sem aplicar restrições de host ou IP de saída. Um usuário com baixos privilégios que consiga influenciar sua própria claim `picture` pode forçar o servidor Gitea a fazer requisições HTTP GET arbitrárias para endereços de loopback, endereços de rede privada RFC 1918 e endereços link-local IPv4, como `169.254.169.254`. Detalhes técnicos incluem: - **Função Vulnerável**: `oauth2UpdateAvatarIfNeed()` em `routers/web/auth/oauth.go` e `oauth2SignInSync()` em `routers/web/auth/oauth signin sync.go`. - **Variável Vulnerável**: `gothUser.AvatarURL`. Embora o problema seja primariamente cego, pois respostas que não sejam imagens são rejeitadas, o impacto aumenta se o servidor conseguir alcançar serviços de metadados de nuvem ou serviços internos que retornem dados de imagem válidos, que poderiam então ser armazenados como o avatar do usuário.

Existe um problema no callback de login OAuth2 que permite que uma conta de usuário desativada seja reativada ao fazer login por meio de uma fonte de autenticação que não emite tokens de atualização, como o GitHub ou fontes OIDC/OAuth2 configuradas sem `offline access`. O sistema utiliza incorretamente um token de atualização vazio como sinal de que a conta foi desativada pelo cron de sincronização automática, em vez de ter sido desativada por um administrador. Consequentemente, quando um usuário desativado faz login através desses provedores, o sistema define `IsActive` como `true` e concede uma sessão completa, ignorando a desativação do administrador. Isso afeta a função `handleOAuth2SignIn` em `routers/web/auth/oauth.go`. Se a conta desativada possuía privilégios administrativos, esses privilégios também são restaurados. Isso não afeta contas desativadas através do recurso Prohibit Login.