{"answers":{"affected":"4 open source packages ship an affected version, including poweradmin/poweradmin.","exploited":"There is no known exploitation of GHSA-h4hf-v6w5-897x in the wild and no public exploit code.","fix":"Upgrade poweradmin/poweradmin to a fixed version for your release line: 4.2.5 or 4.3.4.","what":"GHSA-h4hf-v6w5-897x is a missing authorization vulnerability in poweradmin/poweradmin, published on 24 Jul 2026. Any signed-in user can exploit it over the network, with no action from the victim."},"fix_prompt":"Check this codebase for GHSA-h4hf-v6w5-897x and fix it if it is affected.\n\nWhat it is: GHSA-h4hf-v6w5-897x is a missing authorization vulnerability in poweradmin/poweradmin, published on 24 Jul 2026. Any signed-in user can exploit it over the network, with no action from the victim.\nExploitation: There is no known exploitation of GHSA-h4hf-v6w5-897x in the wild and no public exploit code.\n\nAffected packages and fixed versions:\n- poweradmin/poweradmin (Packagist): affected from 4.0.0; fixed in 4.2.5\n- poweradmin/poweradmin (Packagist): affected from 4.0.0; fixed in 4.2.5\n- poweradmin/poweradmin (Packagist): affected from 4.3.0; fixed in 4.3.4\n- poweradmin/poweradmin (Packagist): affected from 4.3.0; fixed in 4.3.4\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/GHSA-h4hf-v6w5-897x/ (Markdown: https://insights.sbomify.com/GHSA-h4hf-v6w5-897x/index.md)","id":"GHSA-h4hf-v6w5-897x","markdown":"https://insights.sbomify.com/GHSA-h4hf-v6w5-897x/index.md","name":"GHSA-h4hf-v6w5-897x","record":{"aliases":[],"analysis":{"component_type":"web_application","fix_type":"patch","impacts":["privilege_escalation","account_takeover"],"network_reachable":"yes","non_default_config":false,"product_category":"Poweradmin web application","requires_auth":"low_privilege","summary":"A low-privileged user can bypass API authorization checks to reset the superuser password and gain full administrative control.","user_interaction":"not_required","vuln_class":"missing_authorization"},"analysis_generated_by":"qwen3.8-flash-next","assigner":null,"cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"### Summary\n\nThe 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:\n\n1. edit user accounts that belong to a superuser, and\n2. set the password of any account, even without the `user_passwd_edit_others` permission.\n\nBecause 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.\n\n### Details\n\nPoweradmin's permission model treats these as three distinct permissions:\n\n- `user_edit_others` (id 57): \"User is allowed to edit other users.\"\n- `user_passwd_edit_others` (id 58): \"User is allowed to edit the password of other users.\"\n- `user_is_ueberuser` (id 53): full admin.\n\nThe 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.\n\n**Where the API is missing the superuser check.**\n`lib/Domain/Service/ApiPermissionService.php`, `canEditUser()`:\n\n```php\npublic function canEditUser(int $userId, int $targetUserId): bool\n{\n    if ($this-\u003euserHasPermission($userId, 'user_is_ueberuser')) {\n        return true;\n    }\n    if ($userId === $targetUserId \u0026\u0026 $this-\u003euserHasPermission($userId, 'user_edit_own')) {\n        return true;\n    }\n    // User with user_edit_others can edit ALL users, including superusers\n    if ($this-\u003euserHasPermission($userId, 'user_edit_others')) {\n        return true;\n    }\n    return false;\n}\n```\n\nThere 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:\n\n```php\n// Prevent non-superusers from editing superuser accounts (privilege escalation protection)\n$targetIsSuperuser = UserManager::isUserSuperuser($this-\u003edb, $editId);\n$currentIsSuperuser = UserManager::verifyPermission($this-\u003edb, 'user_is_ueberuser');\n\nif ($targetIsSuperuser \u0026\u0026 !$currentIsSuperuser) {\n    $this-\u003eshowError(_('You do not have permission to edit a superuser account.'));\n}\n```\n\nThe comment in the maintainers' own code calls this \"privilege escalation protection.\" The API has no equivalent.\n\n**Where the API is missing the password permission check.**\n`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):\n\n```php\nif (!empty($userData['password'])) {\n    $user = $this-\u003euserRepository-\u003egetUserById($userId);\n    $authMethod = $user['auth_method'] ?? 'sql';\n    $externalAuthMethods = ['oidc', 'saml', 'ldap'];\n    if (in_array($authMethod, $externalAuthMethods, true)) {\n        return [ 'success' =\u003e false, 'message' =\u003e '...', 'status' =\u003e 400 ];\n    }\n    // Hash password if allowed  \u003c-- no permission check happens here\n    $userData['password'] = password_hash($userData['password'], PASSWORD_DEFAULT);\n}\n$success = $this-\u003euserRepository-\u003eupdateUser($userId, $userData);\n```\n\nCompare the web path `lib/Domain/Model/UserManager.php`, `editUser()`, which only writes the password column when the caller has the right permission:\n\n```php\n$edit_own_perm = self::verifyPermission($this-\u003edb, 'user_edit_own');\n$passwd_edit_others_perm = self::verifyPermission($this-\u003edb, 'user_passwd_edit_others');\nif ($user_password != \"\" \u0026\u0026 ($edit_own_perm || $passwd_edit_others_perm)) {\n    ...\n    $query .= \", password = :password\";\n}\n```\n\n**The call path.** `lib/Application/Controller/Api/V2/UsersController.php`, `updateUser()` (lines 701 to 727):\n\n```php\nif (!$this-\u003eapiPermissionService-\u003ecanEditUser($currentUserId, $targetUserId)) {   // line 708\n    ... 403 ...\n}\n$result = $this-\u003euserManagementService-\u003eupdateUser($targetUserId, $input);         // line 727\n```\n\nSo `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.\n\nNote: `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.\n\n\u003cimg width=\"1324\" height=\"986\" alt=\"temp-perm\" src=\"https://github.com/user-attachments/assets/f4411543-2f07-457c-9681-46bdada09d15\" /\u003e\n\n### PoC\n\nTested 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.\n\n**Configuration required (both are common in real deployments, neither is the default):**\n\n- The REST API must be enabled (`api.enabled = true` in `config/settings.php`). The API is intended for automation such as the Terraform provider, so it is frequently turned on.\n- A delegated \"user manager\" role must exist: a permission template that grants `user_edit_others` (and typically `user_view_others`) but not `user_is_ueberuser` and not `user_passwd_edit_others`. This is a normal way to let a helpdesk or team lead manage user accounts.\n\n**Setup (performed once by the administrator to create the delegated role and the attacker):**\n\n1. 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.\n2. Create a normal user, for example `umgr`, and assign it the UserMgr template.\n3. As `umgr`, create an API key from the user's API keys page. Call it, for example, `pwa_umgr_key`. `umgr` is now the attacker: a non-admin user with a self-scoped API key.\n\n**Exploit request (Burp Suite Repeater).** Send this single request. `id` 1 is the administrator account.\n\n```\nPUT /api/v2/users/1 HTTP/1.1\nHost: TARGET_HOST\nX-API-Key: pwa_umgr_key\nContent-Type: application/json\nContent-Length: 30\n\n{\"password\":\"NewAdminPass1!\"}\n```\n\nExpected response (HTTP 200):\n\n```\n{\"success\":true,\"data\":{\"user_id\":1},\"message\":\"User updated successfully\"}\n```\n\n\u003cimg width=\"1574\" height=\"817\" alt=\"burp-api-request\" src=\"https://github.com/user-attachments/assets/465a365b-511b-4cf5-900d-3779622bb10e\" /\u003e\n\nnow we can login to admin user with a new password!\n\nThe 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.\n\n\u003cimg width=\"1228\" height=\"699\" alt=\"umgr-perm-denied\" src=\"https://github.com/user-attachments/assets/5bdb9c82-e00b-4f00-9d25-3887826e5ee3\" /\u003e\n\nRecord 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.\n\n### Impact\n\nThis is a broken access control and privilege escalation issue (CWE-285 Improper Authorization, CWE-266 Incorrect Privilege Assignment).\n\nWho 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.\n\nThe severity is high be","ecosystems":["Packagist"],"exploits":{"exploitdb":null,"first_seen":null,"github_poc":null,"max_poc_stars":null,"metasploit":null,"nuclei":null,"refs":[],"tier":null},"has_fix":true,"headline":"Poweradmin: API user-update endpoint leads to a non-admin reset any user's password and take over the superuser account","id":"GHSA-h4hf-v6w5-897x","indexable":true,"kev":null,"kind":"advisory","links":{"ecosystem":"Packagist","product":null,"products":[],"type":"missing_authorization","year":"2026"},"n_packages":4,"n_references":null,"packages":[{"ecosystem":"Packagist","fixed":["4.2.5"],"introduced":["4.0.0"],"last_affected":[],"package":"poweradmin/poweradmin","purl":null,"source":"GHSA-h4hf-v6w5-897x"},{"ecosystem":"Packagist","fixed":["4.2.5"],"introduced":["4.0.0"],"last_affected":[],"package":"poweradmin/poweradmin","purl":"pkg:composer/poweradmin/poweradmin","source":"GHSA-h4hf-v6w5-897x"},{"ecosystem":"Packagist","fixed":["4.3.4"],"introduced":["4.3.0"],"last_affected":[],"package":"poweradmin/poweradmin","purl":null,"source":"GHSA-h4hf-v6w5-897x"},{"ecosystem":"Packagist","fixed":["4.3.4"],"introduced":["4.3.0"],"last_affected":[],"package":"poweradmin/poweradmin","purl":"pkg:composer/poweradmin/poweradmin","source":"GHSA-h4hf-v6w5-897x"}],"products":null,"published":"2026-07-24","related":[],"sources":[{"class":"attribution","licence":"CC BY 4.0","name":"GitHub Advisory Database","prefix":"GHSA"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":null,"updated":null,"vendors":null},"summary":"A low-privileged user can bypass API authorization checks to reset the superuser password and gain full administrative control.","url":"https://insights.sbomify.com/GHSA-h4hf-v6w5-897x/"}