CWE-862
Weakness Allowed-with-ReviewMissing Authorization
Abstraction: Class · Status: Incomplete
The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
Dimensions
- Behavior-Property: Missing
- Behavior-Type: Authorization
Mapping guidance
This CWE entry is a Class and might have Base-level children that would be more appropriate
Examine children of this entry to see if there is a better fit
Relationships and members
Modes of introduction
OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Authorization weaknesses may arise when a single-user application is ported to a multi-user environment.
A developer may introduce authorization weaknesses because of a lack of understanding about the underlying technologies. For example, a developer may assume that attackers cannot modify certain inputs such as headers or cookies.
Detection methods
Automated Static Analysis
Automated static analysis is useful for detecting commonly-used idioms for authorization. A tool may be able to analyze related configuration files, such as .htaccess in Apache web servers, or detect the usage of commonly-used authorization libraries.
Generally, automated static analysis tools have difficulty detecting custom authorization schemes. In addition, the software's design may include some functionality that is accessible to any user and does not require an authorization check; an automated technique that detects the absence of authorization may report false positives.
Effectiveness: Limited
Automated Dynamic Analysis
Automated dynamic analysis may find many or all possible interfaces that do not require authorization, but manual analysis is required to determine if the lack of authorization violates business logic.
Manual Analysis
This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session.
Specifically, manual static analysis is useful for evaluating the correctness of custom authorization mechanisms.
Effectiveness: Moderate
These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules. However, manual efforts might not achieve desired code coverage within limited time constraints.
Manual Static Analysis - Binary or Bytecode
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies
Effectiveness: SOAR Partial
Dynamic Analysis with Automated Results Interpretation
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Web Application Scanner
Web Services Scanner
Database Scanners
Effectiveness: SOAR Partial
Dynamic Analysis with Manual Results Interpretation
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Host Application Interface Scanner
Fuzz Tester
Framework-based Fuzzer
Effectiveness: SOAR Partial
Manual Static Analysis - Source Code
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Focused Manual Spotcheck - Focused manual analysis of source
Manual Source Code Review (not inspections)
Effectiveness: SOAR Partial
Automated Static Analysis - Source Code
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Source code Weakness Analyzer
Context-configured Source Code Weakness Analyzer
Effectiveness: SOAR Partial
Architecture or Design Review
According to SOAR [REF-1479], the following detection techniques may be useful:
Highly cost effective:
Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
Formal Methods / Correct-By-Construction
Effectiveness: High
Notes
Terminology
Assuming a user with a given identity, authorization is the process of determining whether that user can access a given resource, based on the user's privileges and any permissions or other access-control specifications that apply to the resource.
Content history
Suggested mappings to ISA/IEC 62443.
Provided diagram to improve CWE usability
updated Demonstrative_Examples, Related_Attack_Patterns, Relationships
updated Potential_Mitigations, References, Relationships
updated Demonstrative_Examples, Observed_Examples, References, Relationships
updated Potential_Mitigations
updated Relationships
updated Detection_Factors
updated Relationships
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships
updated References
updated Relationships
updated Relationships
updated Relationships
updated Relationships
updated Alternate_Terms, Observed_Examples
updated Observed_Examples, Related_Attack_Patterns, Relationships
updated Relationships
updated Relationships
updated Observed_Examples
updated Description, Potential_Mitigations
updated References, Relationships, Taxonomy_Mappings
updated Mapping_Notes, Relationships, Taxonomy_Mappings
updated Common_Consequences, Description, Diagram, Relationships, Terminology_Notes
updated Applicable_Platforms, Detection_Factors, Observed_Examples, References
updated Applicable_Platforms, Relationships, Weakness_Ordinalities
updated Applicable_Platforms, Observed_Examples, Relationships
updated Applicable_Platforms, Dimensions, References, Relationships, Taxonomy_Mappings
20048 vulnerabilities reference this CWE, most recent first.
GHSA-H47X-P4XP-XQJF
Vulnerability from github – Published: 2026-04-04 09:30 – Updated: 2026-04-04 09:30The Kadence Blocks — Page Builder Toolkit for Gutenberg Editor plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 3.6.3. This is due to the plugin not properly verifying that a user has the upload_files capability in the process_pattern REST API endpoint. This makes it possible for authenticated attackers, with contributor level access and above, to upload images to the WordPress Media Library by supplying remote image URLs that the server downloads and creates as media attachments.
{
"affected": [],
"aliases": [
"CVE-2026-2826"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-04T09:16:20Z",
"severity": "MODERATE"
},
"details": "The Kadence Blocks \u2014 Page Builder Toolkit for Gutenberg Editor plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 3.6.3. This is due to the plugin not properly verifying that a user has the `upload_files` capability in the `process_pattern` REST API endpoint. This makes it possible for authenticated attackers, with contributor level access and above, to upload images to the WordPress Media Library by supplying remote image URLs that the server downloads and creates as media attachments.",
"id": "GHSA-h47x-p4xp-xqjf",
"modified": "2026-04-04T09:30:25Z",
"published": "2026-04-04T09:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2826"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/kadence-blocks/tags/3.6.4/includes/class-kadence-blocks-prebuilt-library-rest-api.php#L1224"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/5f91df7e-5d9d-4a3a-9afc-d771106a0be6?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-H486-M22J-4M8R
Vulnerability from github – Published: 2026-07-31 09:31 – Updated: 2026-07-31 18:32The Support Genix WordPress plugin before 1.4.48 does not properly authorize access to support-ticket attachment downloads, allowing unauthenticated users who obtain the stored attachment file name to download other users' private ticket attachments.
{
"affected": [],
"aliases": [
"CVE-2026-14862"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-31T07:16:25Z",
"severity": "LOW"
},
"details": "The Support Genix WordPress plugin before 1.4.48 does not properly authorize access to support-ticket attachment downloads, allowing unauthenticated users who obtain the stored attachment file name to download other users\u0027 private ticket attachments.",
"id": "GHSA-h486-m22j-4m8r",
"modified": "2026-07-31T18:32:17Z",
"published": "2026-07-31T09:31:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-14862"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/ef1c6fd5-e62c-4951-a0ba-0e61edb1e795"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-H49H-J7PC-4P78
Vulnerability from github – Published: 2024-12-09 15:31 – Updated: 2026-04-23 15:33Missing Authorization vulnerability in NerdPress Social Pug allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Social Pug: from n/a through 1.30.0.
{
"affected": [],
"aliases": [
"CVE-2023-49193"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-09T13:15:35Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in NerdPress Social Pug allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Social Pug: from n/a through 1.30.0.",
"id": "GHSA-h49h-j7pc-4p78",
"modified": "2026-04-23T15:33:37Z",
"published": "2024-12-09T15:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-49193"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/social-pug/vulnerability/wordpress-grow-social-plugin-1-20-3-broken-access-control-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-H49J-3QG4-9JXW
Vulnerability from github – Published: 2025-05-19 15:31 – Updated: 2026-04-01 18:35Missing Authorization vulnerability in Ninja Team GDPR CCPA Compliance Support allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects GDPR CCPA Compliance Support: from n/a through 2.7.3.
{
"affected": [],
"aliases": [
"CVE-2025-48260"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-19T15:15:29Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Ninja Team GDPR CCPA Compliance Support allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects GDPR CCPA Compliance Support: from n/a through 2.7.3.",
"id": "GHSA-h49j-3qg4-9jxw",
"modified": "2026-04-01T18:35:09Z",
"published": "2025-05-19T15:31:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48260"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/ninja-gdpr-compliance/vulnerability/wordpress-gdpr-ccpa-compliance-support-2-7-3-broken-access-control-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-H49P-FP2P-3R5W
Vulnerability from github – Published: 2025-07-09 00:30 – Updated: 2025-07-09 00:30The WCFM – Frontend Manager for WooCommerce along with Bookings Subscription Listings Compatible plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the wcfm_redirect_to_setup function in all versions up to, and including, 6.7.16. This makes it possible for unauthenticated attackers to view and modify the plugin settings, including payment details and API keys
{
"affected": [],
"aliases": [
"CVE-2025-3780"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-09T00:15:39Z",
"severity": "MODERATE"
},
"details": "The WCFM \u2013 Frontend Manager for WooCommerce along with Bookings Subscription Listings Compatible plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the wcfm_redirect_to_setup function in all versions up to, and including, 6.7.16. This makes it possible for unauthenticated attackers to view and modify the plugin settings, including payment details and API keys",
"id": "GHSA-h49p-fp2p-3r5w",
"modified": "2025-07-09T00:30:34Z",
"published": "2025-07-09T00:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3780"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/wc-frontend-manager/tags/6.7.16/core/class-wcfm-admin.php#L74"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/wc-frontend-manager/tags/6.7.16/core/class-wcfm-admin.php#L81"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/26a82493-a6a5-4d8e-8322-942925a54cc3?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-H4CG-H27H-8RJ3
Vulnerability from github – Published: 2024-05-02 18:30 – Updated: 2026-04-08 18:33The ShopLentor – WooCommerce Builder for Elementor & Gutenberg +10 Modules – All in One Solution (formerly WooLentor) plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the 'woolentor_template_store' function in all versions up to, and including, 2.8.1. This makes it possible for authenticated attackers, with contributor access and above to access the nonce used to access this function and set a blank template as the default template.
{
"affected": [],
"aliases": [
"CVE-2023-7067"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-02T17:15:09Z",
"severity": "MODERATE"
},
"details": "The ShopLentor \u2013 WooCommerce Builder for Elementor \u0026 Gutenberg +10 Modules \u2013 All in One Solution (formerly WooLentor) plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the \u0027woolentor_template_store\u0027 function in all versions up to, and including, 2.8.1. This makes it possible for authenticated attackers, with contributor access and above to access the nonce used to access this function and set a blank template as the default template.",
"id": "GHSA-h4cg-h27h-8rj3",
"modified": "2026-04-08T18:33:00Z",
"published": "2024-05-02T18:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-7067"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3044764/woolentor-addons/trunk?contextall=1\u0026old=3037382\u0026old_path=%2Fwoolentor-addons%2Ftrunk"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/860c2339-b2a9-4a4e-a186-07a5fb042b06?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-H4FJ-2WFG-59CW
Vulnerability from github – Published: 2025-10-24 12:30 – Updated: 2025-10-24 12:30The ZoloBlocks – Gutenberg Block Editor Plugin with Advanced Blocks, Dynamic Content, Templates & Patterns plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the update_popup_status() function in all versions up to, and including, 2.3.11. This makes it possible for unauthenticated attackers to enable/disable popups.
{
"affected": [],
"aliases": [
"CVE-2025-12134"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-24T10:15:38Z",
"severity": "MODERATE"
},
"details": "The ZoloBlocks \u2013 Gutenberg Block Editor Plugin with Advanced Blocks, Dynamic Content, Templates \u0026 Patterns plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the update_popup_status() function in all versions up to, and including, 2.3.11. This makes it possible for unauthenticated attackers to enable/disable popups.",
"id": "GHSA-h4fj-2wfg-59cw",
"modified": "2025-10-24T12:30:51Z",
"published": "2025-10-24T12:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12134"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3377160"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/da9f89a2-f816-4445-8aea-11b622451ee9?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-H4GG-P9RV-RCG5
Vulnerability from github – Published: 2026-11-06 18:35 – Updated: 2026-11-06 18:35Grida through 0.0.24 contains a missing authorization vulnerability in the Forms file-preview API routes that allows unauthenticated attackers to read other organizations' form response files. Attackers can use form and field IDs exposed in public form payloads with a chosen path parameter to obtain service-role signed URLs for attachments and connected Supabase bucket objects.
{
"affected": [],
"aliases": [
"CVE-2026-123623"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-11-06T16:17:54Z",
"severity": "HIGH"
},
"details": "Grida through 0.0.24 contains a missing authorization vulnerability in the Forms file-preview API routes that allows unauthenticated attackers to read other organizations\u0027 form response files. Attackers can use form and field IDs exposed in public form payloads with a chosen path parameter to obtain service-role signed URLs for attachments and connected Supabase bucket objects.",
"id": "GHSA-h4gg-p9rv-rcg5",
"modified": "2026-11-06T18:35:11Z",
"published": "2026-11-06T18:35:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-123623"
},
{
"type": "WEB",
"url": "https://github.com/gridaco/grida/issues/1107"
},
{
"type": "WEB",
"url": "https://github.com/gridaco/grida/pull/1108"
},
{
"type": "WEB",
"url": "https://github.com/gridaco/grida/commit/05f5a54c31a6662942a42b50e34a329ab3642fe1"
},
{
"type": "WEB",
"url": "https://github.com/gridaco/grida"
},
{
"type": "WEB",
"url": "https://github.com/gridaco/grida/blob/v0.0.24/editor/app/(api)/private/editor/%5Bform_id%5D/fields/%5Bfield_id%5D/file/preview/src/route.ts#L27-L101"
},
{
"type": "WEB",
"url": "https://hackmd.io/@hieund/grida-forms-file-preview-missing-authz"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/grida-through-0.0.24-missing-authorization-in-forms-file-preview-api"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/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"
}
]
}
GHSA-H4HF-V6W5-897X
Vulnerability from github – Published: 2026-07-24 21:54 – Updated: 2026-07-24 21:54Summary
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.
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"}
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.
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.
{
"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-H4JV-2HJR-9F5X
Vulnerability from github – Published: 2026-10-21 06:31 – Updated: 2026-10-21 12:31The Productive Commerce WordPress plugin before 1.1.49 does not perform a capability check in one of its AJAX actions and exposes the nonce that guards it on every admin-area page, allowing any authenticated user such as a subscriber to activate arbitrary Productive Commerce WordPress plugin before 1.1.49 already installed on the site.
{
"affected": [],
"aliases": [
"CVE-2026-109926"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-21T06:16:47Z",
"severity": "MODERATE"
},
"details": "The Productive Commerce WordPress plugin before 1.1.49 does not perform a capability check in one of its AJAX actions and exposes the nonce that guards it on every admin-area page, allowing any authenticated user such as a subscriber to activate arbitrary Productive Commerce WordPress plugin before 1.1.49 already installed on the site.",
"id": "GHSA-h4jv-2hjr-9f5x",
"modified": "2026-10-21T12:31:04Z",
"published": "2026-10-21T06:31:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-109926"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/a85ad939-3eb3-470b-a938-d0bfff1ee24f"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
- Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
- Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Mitigation MIT-4.4
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
- For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
- One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
CAPEC-665: Exploitation of Thunderbolt Protection Flaws
An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.