GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-620

Allowed

Unverified Password Change

Abstraction: Base · Status: Draft

When setting a new password for a user, the product does not require knowledge of the original password, or using another form of authentication.

177 vulnerabilities reference this CWE, most recent first.

GHSA-FF7M-H5F6-V93R

Vulnerability from github – Published: 2026-05-29 18:31 – Updated: 2026-05-29 18:31
VLAI
Details

The affected KMW CCTV Security Cameras are vulnerable to a critical unauthenticated password reset. This flaw allows an attacker to remotely reset the administrator password to a known value without authentication, granting full access to the camera feeds and settings.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-5386"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-620"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-29T18:17:12Z",
    "severity": "CRITICAL"
  },
  "details": "The affected\u00a0KMW CCTV Security Cameras are\u00a0vulnerable to a critical unauthenticated password reset. This flaw allows an attacker to remotely reset the administrator password to a known value without authentication, granting full access to the camera feeds and settings.",
  "id": "GHSA-ff7m-h5f6-v93r",
  "modified": "2026-05-29T18:31:36Z",
  "published": "2026-05-29T18:31:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5386"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2026/icsa-26-148-06.json"
    },
    {
      "type": "WEB",
      "url": "https://main.kmw.ro/pub/Firmware/521_421.zip"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-148-06"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FJH6-8679-9PCH

Vulnerability from github – Published: 2025-11-14 20:57 – Updated: 2025-11-14 20:57
VLAI
Summary
Flowise does not Prevent Bypass of Password Confirmation - Unverified Password Change
Details

Summary

Bypass of Password Confirmation - Unverified Password Change (authenticated change without current password)

An authenticated user is allowed to change their account password without supplying the current password or any additional verification. The application does not verify the actor’s authority to perform that credential change (no current-password check, no authorization enforcement). An attacker who is merely authenticated (or who can trick or coerce an authenticated session) can set a new password and gain control of the account. (ATO - Account Takeover)

Details

Occurence - code: https://github.com/FlowiseAI/Flowise/blob/main/packages/ui/src/views/account/index.jsx#L278

Remote and physical scenarios can be considered.

PoC

Repro steps: 1. As logged in user https://cloud.flowiseai.com/account scroll down to 'Security' section 2. Change password to the new password 3. Notice Unverified Password Change (authenticated change without current password)

POC: Password changed, and notice "Password updated" message.

Screenshot: secpw

Impact

Full account takeover (ATO) of affected accounts (loss of confidentiality and integrity of account data). User account recovery mechanisms (password reset flows tied to email) can be bypassed or abused if combined with this issue and the second one which I've reported (similar security issue with the email - part of credentials). (gain persistence)

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "flowise-ui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.0.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-306",
      "CWE-620"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-11-14T20:57:31Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nBypass of Password Confirmation - Unverified Password Change (authenticated change without current password)\n\nAn authenticated user is allowed to change their account password without supplying the current password or any additional verification. The application does not verify the actor\u2019s authority to perform that credential change (no current-password check, no authorization enforcement). An attacker who is merely authenticated (or who can trick or coerce an authenticated session) can set a new password and gain control of the account. (ATO - Account Takeover)\n\n### Details\nOccurence - code:\nhttps://github.com/FlowiseAI/Flowise/blob/main/packages/ui/src/views/account/index.jsx#L278 \n\nRemote and physical scenarios can be considered.\n\n### PoC\n**Repro steps:**\n1. As logged in user https://cloud.flowiseai.com/account scroll down to \u0027Security\u0027 section\n2. Change password to the new password\n3. Notice Unverified Password Change (authenticated change without current password)\n\n**POC:** \nPassword changed, and notice \"Password updated\" message.\n\n**Screenshot:**\n\u003cimg width=\"467\" height=\"526\" alt=\"secpw\" src=\"https://github.com/user-attachments/assets/4cc52978-9f37-42ca-a2b2-7285c4da9f1c\" /\u003e\n\n\n### Impact\nFull account takeover (ATO) of affected accounts (loss of confidentiality and integrity of account data).\nUser account recovery mechanisms (password reset flows tied to email) can be bypassed or abused if combined with this issue and the second one which I\u0027ve reported (similar security issue with the email - part of credentials). (gain persistence)",
  "id": "GHSA-fjh6-8679-9pch",
  "modified": "2025-11-14T20:57:31Z",
  "published": "2025-11-14T20:57:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-fjh6-8679-9pch"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/pull/5294"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/FlowiseAI/Flowise"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/releases/tag/flowise%403.0.10"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Flowise does not Prevent Bypass of Password Confirmation - Unverified Password Change"
}

GHSA-G494-R69F-J7VQ

Vulnerability from github – Published: 2026-01-23 00:31 – Updated: 2026-01-23 00:31
VLAI
Details

A low-privileged user can bypass account credentials without confirming the user's current authentication state, which may lead to unauthorized privilege escalation.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-14751"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-620"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-22T22:16:14Z",
    "severity": "HIGH"
  },
  "details": "A low-privileged user can bypass account credentials without confirming the user\u0027s current authentication state, which may lead to unauthorized privilege escalation.",
  "id": "GHSA-g494-r69f-j7vq",
  "modified": "2026-01-23T00:31:16Z",
  "published": "2026-01-23T00:31:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14751"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-022-05"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-GF57-4MP6-M85X

Vulnerability from github – Published: 2026-06-26 17:33 – Updated: 2026-06-26 17:33
VLAI
Summary
OpenAM Account Takeover via Unverified Password Change in OAuth2 Module
Details

Summary

Description

An Unverified Password Change (CWE-620) and Use of Weak Credentials (CWE-1391) issue in OpenAM's OAuth2 authentication module silently rewrites a local user's password to the literal string of their username on OAuth2 re-login of an existing account. The default ldapService chain then accepts the username as the password for that user, allowing an unauthenticated attacker to obtain a session via the standard authenticate endpoint with both username and password set to the username, without any IdP interaction. This affects OpenAM Community Edition through version 16.0.6 and was patched in version 16.1.1.

Impact

OpenAM Community Edition deployments through version 16.0.6 that use the OAuth2 authentication module with account creation enabled (the default) are potentially affected. After two OAuth logins of a given user, that user's local password becomes their username, and the account is reachable through the default ldapService chain with username as both identifier and password. For pre-existing users whose IdP profile resolves against an existing local identifier, the rewrite fires on the very first re-login.

Usernames shorter than the default minimum password length have the rewrite silently denied (so very short administrative accounts are not affected), and the same update path marks accounts active on every OAuth login, silently reactivating disabled accounts.

Successful exploitation grants an unauthenticated attacker a session carrying the victim principal's privileges.

Patch

This has been patched in OpenAM Community Edition version 16.1.1. Users are encouraged to update to the latest release.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.openidentityplatform.openam:openam-auth-oauth2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "16.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46623"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1391",
      "CWE-620"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-26T17:33:35Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\n**Description**\n\nAn Unverified Password Change (CWE-620) and Use of Weak Credentials (CWE-1391) issue in OpenAM\u0027s OAuth2 authentication module silently rewrites a local user\u0027s password to the literal string of their username on OAuth2 re-login of an existing account. The default ldapService chain then accepts the username as the password for that user, allowing an unauthenticated attacker to obtain a session via the standard authenticate endpoint with both username and password set to the username, without any IdP interaction. This affects OpenAM Community Edition through version 16.0.6 and was patched in version 16.1.1.\n\n## Impact\nOpenAM Community Edition deployments through version 16.0.6 that use the OAuth2 authentication module with account creation enabled (the default) are potentially affected. After two OAuth logins of a given user, that user\u0027s local password becomes their username, and the account is reachable through the default ldapService chain with username as both identifier and password. For pre-existing users whose IdP profile resolves against an existing local identifier, the rewrite fires on the very first re-login.\n\nUsernames shorter than the default minimum password length have the rewrite silently denied (so very short administrative accounts are not affected), and the same update path marks accounts active on every OAuth login, silently reactivating disabled accounts. \n\nSuccessful exploitation grants an unauthenticated attacker a session carrying the victim principal\u0027s privileges.\n\n## Patch\nThis has been patched in OpenAM Community Edition version 16.1.1. Users are encouraged to update to the latest release.",
  "id": "GHSA-gf57-4mp6-m85x",
  "modified": "2026-06-26T17:33:35Z",
  "published": "2026-06-26T17:33:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/OpenIdentityPlatform/OpenAM/security/advisories/GHSA-gf57-4mp6-m85x"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/OpenIdentityPlatform/OpenAM"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenAM Account Takeover via Unverified Password Change in OAuth2 Module"
}

GHSA-GFXR-MVPH-45QR

Vulnerability from github – Published: 2023-06-02 18:30 – Updated: 2023-06-02 18:30
VLAI
Details

Unverified Password Change in GitHub repository tsolucio/corebos prior to 8.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-3069"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-620"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-02T17:15:13Z",
    "severity": "HIGH"
  },
  "details": "Unverified Password Change in GitHub repository tsolucio/corebos prior to 8.",
  "id": "GHSA-gfxr-mvph-45qr",
  "modified": "2023-06-02T18:30:19Z",
  "published": "2023-06-02T18:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3069"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tsolucio/corebos/commit/e3dabd74c68646bb54538d66411fc1e633ec454b"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/00544982-365a-476b-b5fe-42f02f11d367"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H4HF-V6W5-897X

Vulnerability from github – Published: 2026-07-24 21:54 – Updated: 2026-07-24 21:54
VLAI
Summary
Poweradmin: API user-update endpoint leads to a non-admin reset any user's password and take over the superuser account
Details

Summary

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:

  1. edit user accounts that belong to a superuser, and
  2. set the password of any account, even without the user_passwd_edit_others permission.

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.

temp-perm

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 = true in config/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 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.

Setup (performed once by the administrator to create the delegated role and the attacker):

  1. 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.
  2. Create a normal user, for example umgr, and assign it the UserMgr template.
  3. 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.

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"}

burp-api-request

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.

umgr-perm-denied

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.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "poweradmin/poweradmin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.2.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "poweradmin/poweradmin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.3.0"
            },
            {
              "fixed": "4.3.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-620",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T21:54:55Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### 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\u0027s 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\u0027s own permission model.\n\n### Details\n\nPoweradmin\u0027s 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, \u0027user_is_ueberuser\u0027)) {\n        return true;\n    }\n    if ($userId === $targetUserId \u0026\u0026 $this-\u003euserHasPermission($userId, \u0027user_edit_own\u0027)) {\n        return true;\n    }\n    // User with user_edit_others can edit ALL users, including superusers\n    if ($this-\u003euserHasPermission($userId, \u0027user_edit_others\u0027)) {\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, \u0027user_is_ueberuser\u0027);\n\nif ($targetIsSuperuser \u0026\u0026 !$currentIsSuperuser) {\n    $this-\u003eshowError(_(\u0027You do not have permission to edit a superuser account.\u0027));\n}\n```\n\nThe comment in the maintainers\u0027 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[\u0027password\u0027])) {\n    $user = $this-\u003euserRepository-\u003egetUserById($userId);\n    $authMethod = $user[\u0027auth_method\u0027] ?? \u0027sql\u0027;\n    $externalAuthMethods = [\u0027oidc\u0027, \u0027saml\u0027, \u0027ldap\u0027];\n    if (in_array($authMethod, $externalAuthMethods, true)) {\n        return [ \u0027success\u0027 =\u003e false, \u0027message\u0027 =\u003e \u0027...\u0027, \u0027status\u0027 =\u003e 400 ];\n    }\n    // Hash password if allowed  \u003c-- no permission check happens here\n    $userData[\u0027password\u0027] = password_hash($userData[\u0027password\u0027], 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, \u0027user_edit_own\u0027);\n$passwd_edit_others_perm = self::verifyPermission($this-\u003edb, \u0027user_passwd_edit_others\u0027);\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\u0027s 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\u0027s 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\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\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\u0027s 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 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.\n\nSuggested 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.\n\n## Disclosure\nCredit: Found by Saif Salah (https://saifsalah.github.io/)\nFound during a security review of Poweradmin. Happy to coordinate a fix timeline and CVE before any public write-up.",
  "id": "GHSA-h4hf-v6w5-897x",
  "modified": "2026-07-24T21:54:55Z",
  "published": "2026-07-24T21:54:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/poweradmin/poweradmin/security/advisories/GHSA-h4hf-v6w5-897x"
    },
    {
      "type": "WEB",
      "url": "https://github.com/poweradmin/poweradmin/commit/36e9081a5c83cb962dc6275b7adcd6cb463f1028"
    },
    {
      "type": "WEB",
      "url": "https://github.com/poweradmin/poweradmin/commit/9bdda77bc103f283a0babcaf3355f3f95b360122"
    },
    {
      "type": "WEB",
      "url": "https://github.com/poweradmin/poweradmin/commit/b90fd83e67e6d7b6ad6c9be3a1c0d2f45bd73b6c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/poweradmin/poweradmin/commit/ffb95d5201cad5cb38e3eabc4f8103cac2ca18e2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/poweradmin/poweradmin"
    },
    {
      "type": "WEB",
      "url": "https://github.com/poweradmin/poweradmin/releases/tag/v4.2.5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/poweradmin/poweradmin/releases/tag/v4.3.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Poweradmin: API user-update endpoint leads to a non-admin reset any user\u0027s password and take over the superuser account"
}

GHSA-H5FP-7R6F-5X9M

Vulnerability from github – Published: 2025-01-18 09:30 – Updated: 2025-01-18 09:30
VLAI
Details

The Adifier System plugin for WordPress is vulnerable to privilege escalation via account takeover in all versions up to, and including, 3.1.7. This is due to the plugin not properly validating a user's identity prior to updating their details like password through the adifier_recover() function. This makes it possible for unauthenticated attackers to change arbitrary user's passwords, including administrators, and leverage that to gain access to their account.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-13375"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-620"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-18T09:15:07Z",
    "severity": "CRITICAL"
  },
  "details": "The Adifier System plugin for WordPress is vulnerable to privilege escalation via account takeover in all versions up to, and including, 3.1.7. This is due to the plugin not properly validating a user\u0027s identity prior to updating their details like password through the adifier_recover() function. This makes it possible for unauthenticated attackers to change arbitrary user\u0027s passwords, including administrators, and leverage that to gain access to their account.",
  "id": "GHSA-h5fp-7r6f-5x9m",
  "modified": "2025-01-18T09:30:23Z",
  "published": "2025-01-18T09:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-13375"
    },
    {
      "type": "WEB",
      "url": "https://themeforest.net/item/adifier-classified-ads-wordpress-theme/21633950"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/fbf2aeed-0f18-4ef6-aff8-9e8c4531d789?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HPP6-2PRW-CVWR

Vulnerability from github – Published: 2023-12-29 12:30 – Updated: 2024-02-29 03:32
VLAI
Details

A vulnerability, which was classified as problematic, was found in Poly CCX 400, CCX 600, Trio 8800 and Trio C60. Affected is an unknown function of the component Configuration File Import. The manipulation of the argument device.auth.localAdminPassword leads to unverified password change. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. VDB-249258 is the identifier assigned to this vulnerability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-4465"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-620"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-29T10:15:12Z",
    "severity": "LOW"
  },
  "details": "A vulnerability, which was classified as problematic, was found in Poly CCX 400, CCX 600, Trio 8800 and Trio C60. Affected is an unknown function of the component Configuration File Import. The manipulation of the argument device.auth.localAdminPassword leads to unverified password change. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. VDB-249258 is the identifier assigned to this vulnerability.",
  "id": "GHSA-hpp6-2prw-cvwr",
  "modified": "2024-02-29T03:32:46Z",
  "published": "2023-12-29T12:30:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4465"
    },
    {
      "type": "WEB",
      "url": "https://fahrplan.events.ccc.de/congress/2023/fahrplan/events/11919.html"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modzero/MZ-23-01-Poly-VoIP-Devices"
    },
    {
      "type": "WEB",
      "url": "https://modzero.com/en/advisories/mz-23-01-poly-voip"
    },
    {
      "type": "WEB",
      "url": "https://modzero.com/en/advisories/mz-23-01-poly-voip-devices"
    },
    {
      "type": "WEB",
      "url": "https://support.hp.com/us-en/document/ish_9929371-9929407-16/hpsbpy03899"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.249258"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.249258"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HV8Q-7RJW-5H3J

Vulnerability from github – Published: 2025-04-24 09:30 – Updated: 2025-04-24 09:30
VLAI
Details

The Buddypress Force Password Change plugin for WordPress is vulnerable to authenticated account takeover due to the plugin not properly validating a user's identity prior to updating their password through the 'bp_force_password_ajax' function in all versions up to, and including, 0.1. This makes it possible for authenticated attackers, with subscriber-level access and above and under certain prerequisites, to change arbitrary user's passwords, including administrators, and leverage that to gain access to their accounts.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-3793"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-620"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-24T09:15:32Z",
    "severity": "MODERATE"
  },
  "details": "The Buddypress Force Password Change plugin for WordPress is vulnerable to authenticated account takeover due to the plugin not properly validating a user\u0027s identity prior to updating their password through the \u0027bp_force_password_ajax\u0027 function in all versions up to, and including, 0.1. This makes it possible for authenticated attackers, with subscriber-level access and above and under certain prerequisites, to change arbitrary user\u0027s passwords, including administrators, and leverage that to gain access to their accounts.",
  "id": "GHSA-hv8q-7rjw-5h3j",
  "modified": "2025-04-24T09:30:35Z",
  "published": "2025-04-24T09:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3793"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/buddy-press-force-password-change/trunk/bp-force-password-change.php#L93"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/e3048c4c-77b1-4778-a5d0-b532df777d06?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J3PG-9JG5-PJ7F

Vulnerability from github – Published: 2025-04-08 09:31 – Updated: 2025-04-08 09:31
VLAI
Details

A vulnerability has been identified in SENTRON 7KT PAC1260 Data Manager (All versions). The web interface of affected devices allows to change the login password without knowing the current password. In combination with a prepared CSRF attack (CVE-2024-41795) an unauthenticated attacker could be able to set the password to an attacker-controlled value.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-41796"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-620"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-08T09:15:20Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability has been identified in SENTRON 7KT PAC1260 Data Manager (All versions). The web interface of affected devices allows to change the login password without knowing the current password. In combination with a prepared CSRF attack (CVE-2024-41795) an unauthenticated attacker could be able to set the password to an attacker-controlled value.",
  "id": "GHSA-j3pg-9jg5-pj7f",
  "modified": "2025-04-08T09:31:12Z",
  "published": "2025-04-08T09:31:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41796"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-187636.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

Mitigation
Architecture and Design

When prompting for a password change, force the user to provide the original password in addition to the new password.

Mitigation
Architecture and Design

Do not use "forgotten password" functionality. But if you must, ensure that you are only providing information to the actual user, e.g. by using an email address or challenge question that the legitimate user already provided in the past; do not allow the current user to change this identity information until the correct password has been provided.

No CAPEC attack patterns related to this CWE.