O objetivo de atualização do usuário da API REST (` PUT/ PARCH /api/v 2 / users/ {id}` e o V 1 equivalente) não aplica duas regras de autorização que a interface web aplica. Um usuário que detém a permissão `user_edit_others` mas não é um superusuário pode: 1. editar contas de usuário que pertencem a um super-usuário, e 2. definir a senha de qualquer conta, mesmo sem a permissão `user_passwd_ edit_others`. Por causa disso, um papel de "gerente de usuário" não- administrador pode enviar um único pedido de API que altera a senha do administrador, e então fazer login como administrador. Esta é uma escalada de privilégios completa e tomada de conta. As mesmas ações são explicitamente bloqueadas na interface de usuário da web, por isso a API é inconsistente com o modelo de permissão do próprio aplicativo. O modelo de permissões do Poweradmin trata estas como três permissões distintas. - ` user_ edit_ others` (id 57 ): "O usuário pode editar outros usuários." - `user_passwd_edit_others` (id 58 ): "O usuário pode editar a senha de outros usuários." - `user_is_ueberuser` (id 53 ): administrador completo.
A existência de uma permissão separada `user_passwd_edit_others` significa que "editar outros usuários" não deve incluir a alteração de suas senhas. A interface de usuário da web aplica isso, e também proíbe qualquer não superusuário de editar uma conta de superusuário. A API pula ambas as regras. ** Onde a API está faltando a verificação do superusuário.** `lib/Domain/Service/ApiPermissionService.php`, `canEditUser()`. ````php function public canEditUser(int $userId, int $targetUserId): bool { if ($this->userHasPermission($userId, 'user_is_ueberuser')) { return true; } if ($ userId=== $targetUserId && $this->userHasPermission($userId, 'user_edit_own')) { return true; } // User with user_edit_others can edit TODOS os usuários, incluindo superusuários se ($this->userHasPermission($userId, 'user_edit_others')) { return true; } return false; } ````````````} { return true;} { return true; Não há verificação se o alvo é um superusuário. Compare isto com o controlador web `lib/Application/Controller/EditUserController.php` (linhas 237 para 243 ), que se recusa explicitamente: ``` php // Evitar que não superusuários editem contas de superusuário (proteção de escalada de privilégios) $targetIsSuperuser = UserManager:: isUserSuperuser($this->db, $editId); $currentIsSuperuser = UserManager::verifyPermission($this->db, 'user_is_ueberuser');.
if ($ targetIsSuperuser & & &!$currentIsSuperuser) { $this-> showError(_('Você não tem permissão para editar uma conta de superuser.')); } ```` O comentário no código dos próprios mantenedores chama isso de "proteção de escalada privilegiada". A API não tem equivalente. **Onde a API está faltando a verificação da permissão da senha.** `lib/Domain/Service/UserManagementService.php`, ` updateUser()` (linhas) 393 para 413 ) escreve a senha sempre que for fornecido, sem nenhuma verificação de permissão (só se recusa quando o alvo é um usuário externo- auth): ```php if (!vazio($userData['password'])) { $user = $this->userRepository->getUserById($userId); $authMethod = $user['auth_method']?? 'sql'; $externalAuthMethods = ['oidc', 'saml', 'ldap']; se (in_array($authMethod, $externalAuthMethods, true)) { retorna [ 'sucesso' => false, 'message' => '...', 'status' => 400 ]; } // Hash senha se permite userRepository-> atualizarUser($userId, $userData); ```.
Compare o caminho da web `lib/Domain/Model/UserManager.php`, `editUser()`, que só escreve a coluna de senha quando o chamador tem a permissão certa: ``` php $edit_own_perm = self::verifyPermission($this->db, 'user_edit_own'); $passwd_edit_others_perm = self::verifyPermission($this->db, 'user_passwd_edit_others'); se ($user_password!= "" && ($edit_own_perm (') $passwd_edit_others_perm)) {... $query.= ", senha =:password"; } ``` **O caminho da chamada.** `lib/Application/Controller/Api/V 2 /UsersController.php`, `updateUser()` (linhas) 701 para 727 ): ````php if (!$this->apiPermissionService-> canEditUser($currentUserId, $targetUserId)) { // linha 708... 403... } $resultado = $this->userManagementService->updateUser( $targetUserId, $input); // linha 727 ```.
Então `canEditUser` retorna verdadeiro para qualquer suporte `user_edit_others` contra qualquer alvo, e ` updateUser` então escreve a senha sem mais verificação. O V 1 controlador (`lib/Application/Controller/Api/V 1 /UsersController.php`) tem a mesma forma. Nota: `perm_templ` é protegido separadamente (um `PermissionTemplateAssignmentGuard` o rejeita a menos que o chamador tenha `user_edit_templ_perm`), por isso um atacante não pode elevar seu próprio modelo através da API. Eles não precisam. Reconectar a senha do administrador e fazer login quando o administrador alcançar o controle completo diretamente. Testado no mestre PowerAdmin (commit 7 f 28 c 3 a 97 ) e o caminho de código está presente no 4.0.x, 4.1.x, 4.2.x e 4.3.x liberar ramos. **Configuração necessária (ambos são comuns em implantações reais, nem o padrão):**. - A API REST deve ser habilitada (`api. habilitated = true` em `config/ settings.php`). A API é destinada à automação, como o provedor Terraform, por isso é frequentemente ligada. - Deve existir um papel delegado de "gestor de usuário": um modelo de permissão que confere `user_ edit_ others` (e tipicamente `user_view_ others`) mas não `user_is_ueberuser` e não `user_passwd_ edit_ others`. Esta é uma maneira normal de deixar que um helpdesk ou equipe liderem as contas de usuário.
** Configuração (realizada uma vez pelo administrador para criar o papel delegado e o atacante):** 1. Como administrador, crie um modelo de permissão chamado "UserMgr" do tipo "usuário" com as permissões "O usuário é permitido editar outros usuários" e "O usuário é permitido ver outros usuários e seus detalhes" apenas. 2. Crie um usuário normal, por exemplo ` umgr`, e atribua- o ao modelo UserMgr. 3. Como ` umgr`, crie uma chave API a partir da página de chaves API do usuário. Chame- o, por exemplo, `pwa_umgr_key`. ` umgr` é agora o atacante: um usuário não- administrador com uma chave API auto- abrangida. **Exploitar o pedido (Burp Suite Repetidor).** Enviar este pedido único. `id` 1 é a conta de administrador. ``` PUT /api/v 2 /usuários/ 1 HTTP/ 1.1 Host: TARGET_HOST X-API-Key: pwa_umgr_key Tipo de Conteúdo: aplicativo/json Longitude de Conteúdo: 30.
{"palavra de passe":"Pass de novo administrador 1!"} ```. Resposta esperada (HTTP) 200 ): ``` {"sucesso":verdadeiro, "dados":{"user_id": 1 },"mensagem":"Usuário atualizado com sucesso"} ```. agora podemos fazer login para o usuário administrador com uma nova senha! A página se recusa com "Você não tem permissão para editar uma conta de super- usuário." Assim, o mesmo usuário com a mesma permissão é negado na web, mas permitido na API. Os ids de registro são os ids de usuário sequencial normais, e o administrador é geralmente id 1, então não é necessário adivinhar. O atacante também pode mudar o ` usename`, `email`, `active' e `use_ldap` em qualquer conta através do mesmo pedido.
Este é um problema de controle de acesso e escalada de privilégios quebrados (CWE- 285 Autorização inadequada, CWE- 266 Atribuição de privilégios incorreta. Quem é impactado: qualquer instalação do Poweradmin que tenha a API REST ativada e que tenha criado pelo menos um papel não-admin que segura ` user_ edit_ others` (um papel delegado do usuário- gestor ou do helpdesk). Em tal instalação, qualquer titular desse papel, usando nada mais do que a sua própria chave API, pode reiniciar a senha do superusuário e assumir a conta do administrador. A partir daí eles controlam todas as zonas, gravar, usuário e configuração no PowerAdmin, e, através da infra-estrutura PowerDNS, os dados DNS em si. A gravidade é alta porque o resultado é a tomada de controle administrativa completa de uma posição autenticada de baixo privilégio, através da rede, com um único pedido e sem interação do usuário. A razão pela qual não é classificado como crítico é a condição prévia para que exista um papel delegado `user_ edit_others` e a API esteja habilitada. O defeito subjacente é real independente da configuração: a API não aplica a proteção do super- usuário- editar ou a permissão `user_passwd_ edit_ others ' que a interface web executa, então a API concede mais autoridade do que o modelo de permissão pretende. Correção sugerida: espelhe os guardas da web na API. Em `ApiPermissionService::canEditUser`, rejeite um não superusuário editando um alvo de superusuário. Em `UserManagementService::updateUser`, só escreva a senha quando o chamador estiver editando sua própria conta ou tiver `user_passwd_edit_others`. Aplicar o mesmo para ambos os V 1 e V 2 controle.
Crédito de divulgação: encontrado por Saif Salah ( encontrado durante uma revisão de segurança do Poweradmin. Fico feliz em coordenar uma linha temporal e CVE corrigidos antes de qualquer gravação pública. Registro de aconselhamento: GHSA- h 4 hf- v 6 w 5 - 897 x. Não há nenhum identificador adicional listado. Tempo: GitHub Advisory Database publicou este registro em 2026 - 07 - 24 T 21: 54: 55.000 Z e lista a sua última modificação como 2026 - 07 - 24 T 21: 54: 55.000 Z.
Severidade: ALTAMENTE. Dados de pontuação publicados: CVSS_V 3: CVSS: 3.1 /AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Software afetado e informações de versão: Packagist package poweradmin/poweradmin — ECOSYSTEM: introduzido 4.0.0, corrigido 4.2.5. Packagist package poweradmin/ poweradmin — ECOSYSTEM: introduzido 4.3.0, corrigido 4.3.4. Classificação e evidência: identificadores de fraqueza CWE- 620, CWE- 862. O registro contém 8 suporte de referências nestes tipos: WEB, PACKAGE.