Poweradmin: API user-update endpoint leads to a non-admin reset any user's password and take over the superuser account — poweradmin / poweradmin
Unverified Password ChangeSummary
The REST API user-update endpoint (PUT/PATCH /api/v2/users/{id} and the V1 equivalent) does not enforce two authorization rules that the web interface enforces. A user who holds the user_edit_others permission but is not a superuser can:
- edit user accounts that belong to a superuser, and
- set the password of any account, even without the
user_passwd_edit_otherspermission.
Because of this, a non-admin "user manager" role can send a single API request that changes the administrator's password, then log in as the administrator. This is a full privilege escalation and account takeover. The same actions are explicitly blocked in the web UI, so the API is inconsistent with the application's own permission model.
Details
Poweradmin's permission model treats these as three distinct permissions:
user_edit_others(id 57): "User is allowed to edit other users."user_passwd_edit_others(id 58): "User is allowed to edit the password of other users."user_is_ueberuser(id 53): full admin.
The existence of a separate user_passwd_edit_others permission means that "edit other users" is not supposed to include changing their passwords. The web UI enforces this, and it additionally forbids any non-superuser from editing a superuser account at all. The API skips both rules.
Where the API is missing the superuser check.
lib/Domain/Service/ApiPermissionService.php, canEditUser():
public function 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 ALL users, including superusers
if ($this->userHasPermission($userId, 'user_edit_others')) {
return true;
}
return false;
}
There is no check on whether the target is a superuser. Compare this with the web controller lib/Application/Controller/EditUserController.php (lines 237 to 243), which explicitly refuses:
// Prevent non-superusers from editing superuser accounts (privilege escalation protection)
$targetIsSuperuser = UserManager::isUserSuperuser($this->db, $editId);
$currentIsSuperuser = UserManager::verifyPermission($this->db, 'user_is_ueberuser');
if ($targetIsSuperuser && !$currentIsSuperuser) {
$this->showError(_('You do not have permission to edit a superuser account.'));
}
The comment in the maintainers' own code calls this "privilege escalation protection." The API has no equivalent.
Where the API is missing the password permission check.
lib/Domain/Service/UserManagementService.php, updateUser() (lines 393 to 413) writes the password whenever one is supplied, with no permission check at all (it only refuses when the target is an external-auth user):
if (!empty($userData['password'])) {
$user = $this->userRepository->getUserById($userId);
$authMethod = $user['auth_method'] ?? 'sql';
$externalAuthMethods = ['oidc', 'saml', 'ldap'];
if (in_array($authMethod, $externalAuthMethods, true)) {
return [ 'success' => false, 'message' => '...', 'status' => 400 ];
}
// Hash password if allowed <-- no permission check happens here
$userData['password'] = password_hash($userData['password'], PASSWORD_DEFAULT);
}
$success = $this->userRepository->updateUser($userId, $userData);
Compare the web path lib/Domain/Model/UserManager.php, editUser(), which only writes the password column when the caller has the right permission:
$edit_own_perm = self::verifyPermission($this->db, 'user_edit_own');
$passwd_edit_others_perm = self::verifyPermission($this->db, 'user_passwd_edit_others');
if ($user_password != "" && ($edit_own_perm || $passwd_edit_others_perm)) {
...
$query .= ", password = :password";
}
The call path. lib/Application/Controller/Api/V2/UsersController.php, updateUser() (lines 701 to 727):
if (!$this->apiPermissionService->canEditUser($currentUserId, $targetUserId)) { // line 708
... 403 ...
}
$result = $this->userManagementService->updateUser($targetUserId, $input); // line 727
So canEditUser returns true for any user_edit_others holder against any target, and updateUser then writes the password with no further check. The V1 controller (lib/Application/Controller/Api/V1/UsersController.php) has the same shape.
Note: perm_templ is separately protected (a PermissionTemplateAssignmentGuard rejects it unless the caller has user_edit_templ_perm), so an attacker cannot elevate their own template through the API. They do not need to. Resetting the administrator's password and logging in as the administrator achieves full control directly.
<img width="1324" height="986" alt="temp-perm" src="https://github.com/user-attachments/assets/f4411543-2f07-457c-9681-46bdada09d15" />
PoC
Tested on Poweradmin master (commit 7f28c3a97) and the code path is present in the 4.0.x, 4.1.x, 4.2.x and 4.3.x release branches.
Configuration required (both are common in real deployments, neither is the default):
- The REST API must be enabled (
api.enabled = trueinconfig/settings.php). The API is intended for automation such as the Terraform provider, so it is frequently turned on. - A delegated "user manager" role must exist: a permission template that grants
user_edit_others(and typicallyuser_view_others) but notuser_is_ueberuserand notuser_passwd_edit_others. This is a normal way to let a helpdesk or team lead manage user accounts.
Setup (performed once by the administrator to create the delegated role and the attacker):
- As admin, create a permission template named "UserMgr" of type "user" with the permissions "User is allowed to edit other users" and "User is allowed to see other users and their details" only.
- Create a normal user, for example
umgr, and assign it the UserMgr template. - As
umgr, create an API key from the user's API keys page. Call it, for example,pwa_umgr_key.umgris now the attacker: a non-admin user with a self-scoped API key.
Exploit request (Burp Suite Repeater). Send this single request. id 1 is the administrator account.
PUT /api/v2/users/1 HTTP/1.1
Host: TARGET_HOST
X-API-Key: pwa_umgr_key
Content-Type: application/json
Content-Length: 30
{"password":"NewAdminPass1!"}
Expected response (HTTP 200):
{"success":true,"data":{"user_id":1},"message":"User updated successfully"}
<img width="1574" height="817" alt="burp-api-request" src="https://github.com/user-attachments/assets/465a365b-511b-4cf5-900d-3779622bb10e" />
now we can login to admin user with a new password!
The page refuses with "You do not have permission to edit a superuser account." So the same user with the same permission is denied on the web but allowed on the API.
<img width="1228" height="699" alt="umgr-perm-denied" src="https://github.com/user-attachments/assets/5bdb9c82-e00b-4f00-9d25-3887826e5ee3" />
Record ids are the normal sequential user ids, and the administrator is usually id 1, so no guessing is required. The attacker can also change username, email, active and use_ldap on any account through the same request.
Impact
This is a broken access control and privilege escalation issue (CWE-285 Improper Authorization, CWE-266 Incorrect Privilege Assignment).
Who is impacted: any Poweradmin installation that has the REST API enabled and that has created at least one non-admin role holding user_edit_others (a delegated user-manager or helpdesk role). On such an installation, any holder of that role, using nothing more than their own API key, can reset the superuser's password and take over the administrator account. From there they control every zone, record, user and setting in Poweradmin, and, through the PowerDNS backend, the DNS data itself.
The severity is high because the outcome is full administrative takeover from a low-privilege authenticated position, over the network, with a single request and no user interaction. The reason it is not rated critical outright is the precondition that a delegated user_edit_others role exists and the API is enabled. The underlying defect is real regardless of configuration: the API does not enforce the superuser-edit protection or the user_passwd_edit_others permission that the web interface enforces, so the API grants more authority than the permission model intends.
Suggested fix: mirror the web guards in the API. In ApiPermissionService::canEditUser, reject a non-superuser editing a superuser target. In UserManagementService::updateUser, only write the password when the caller is editing their own account or holds user_passwd_edit_others. Apply the same to both V1 and V2 controllers.
Disclosure
Credit: Found by Saif Salah (https://saifsalah.github.io/) Found during a security review of Poweradmin. Happy to coordinate a fix timeline and CVE before any public write-up.
| Software | From | Fixed in |
|---|---|---|
poweradmin / poweradmin
|
4.0.0 | 4.2.5 |
|
poweradmin / poweradmin
|
4.3.0 | 4.3.4 |
- https://github.com/poweradmin/poweradmin/commit/36e9081a5c83cb962dc6275b7adcd6cb463f1028
- https://github.com/poweradmin/poweradmin/commit/9bdda77bc103f283a0babcaf3355f3f95b360122
- https://github.com/poweradmin/poweradmin/commit/b90fd83e67e6d7b6ad6c9be3a1c0d2f45bd73b6c
- https://github.com/poweradmin/poweradmin/commit/ffb95d5201cad5cb38e3eabc4f8103cac2ca18e2
- https://github.com/poweradmin/poweradmin/releases/tag/v4.2.5
- https://github.com/poweradmin/poweradmin/releases/tag/v4.3.4
- https://github.com/poweradmin/poweradmin/security/advisories/GHSA-h4hf-v6w5-897x
Deep Security Visibility Without the Complexity
SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.
- No setup fees
- 5-min deployment
- Cancel anytime
Frequently Asked Questions
A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.
CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.
A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.
Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.
Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.
SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.