Fernando Bortotti

**Nome do Software Vulnerável e Versões Afetadas** pgAdmin 4 versões anteriores a 9.15 **Descrição** O FileBackedSessionManager no pgAdmin 4 realiza a desserialização insegura de conteúdos de arquivos de sessão usando o módulo de serialização de objetos padrão do Python antes de realizar uma verificação de integridade HMAC. Isso permite que qualquer arquivo colocado no diretório de sessões seja desserializado incondicionalmente. Um usuário autenticado com acesso de gravação ao diretório de sessões, potencialmente por meio de configuração incorreta ou de uma falha de path-traversal, poderia usar um payload serializado manipulado para alcançar a execução remota de código no nível do sistema operacional sob a identidade do processo pgAdmin. **Recomendações** Atualize para a versão 9.15 ou posterior.

**Nome do Software Vulnerável e Versões Afetadas** pgAdmin 4 versões anteriores a 9.15 **Descrição** Um problema de travessia de caminho via link simbólico existe no Gerenciador de Arquivos do pgAdmin 4. A função `check access permission()` utilizava `os.path.abspath`, que resolve referências de diretórios pai ('..'), mas não resolve links simbólicos. Como a operação de gravação subsequente do kernel segue links simbólicos, um usuário autenticado pode criar um link simbólico em seu diretório de armazenamento apontando para um local fora dele. Isso permite que o usuário induza o pgAdmin a gravar em qualquer caminho acessível pelo processo do pgAdmin. Trata-se de uma falha de Time-of-Check to Time-of-Use (TOCTOU), onde existe uma condição de corrida entre a verificação de acesso e a abertura real do arquivo. **Recomendações** Atualize para a versão 9.15 ou posterior.

**Nome do Software Vulnerável e Versões Afetadas** pgAdmin 4 versões anteriores a 9.15 **Descrição** Ocorre uma restrição inadequada de tentativas excessivas de autenticação porque o limite `MAX LOGIN ATTEMPTS` é aplicado apenas na view '/authenticate/login'. A view '/login' padrão do Flask-Security não verifica o campo `User.locked`, pois o modelo de Usuário dependia de `UserMixin.is locked()` (que sempre retorna 'não bloqueado') e `is active` (que verifica apenas a coluna ativa). Isso permite que um invasor ignore a proteção contra força bruta para contas que utilizam a fonte de autenticação INTERNAL, enviando credenciais diretamente para '/login'. Consequentemente, as tentativas de login via '/login' não são limitadas, permitindo ataques de adivinhação de senha online ilimitados. Este problema não afeta usuários de LDAP, OAuth2, Kerberos ou Webserver. **Recomendações** Atualize para a versão 9.15 ou posterior para garantir que a coluna de bloqueio seja aplicada em todos os caminhos de autenticação.