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
19845 vulnerabilities reference this CWE, most recent first.
GHSA-6X4J-8954-5HXM
Vulnerability from github – Published: 2026-06-23 23:03 – Updated: 2026-06-23 23:03Impact
A user who can edit other users could reset a superadmin's 2FA.
Patches
Patched in 8.5.0
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "snipe/snipe-it"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.5.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-50550"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-23T23:03:20Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\nA user who can edit other users could reset a superadmin\u0027s 2FA.\n\n### Patches\nPatched in 8.5.0",
"id": "GHSA-6x4j-8954-5hxm",
"modified": "2026-06-23T23:03:20Z",
"published": "2026-06-23T23:03:20Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/grokability/snipe-it/security/advisories/GHSA-6x4j-8954-5hxm"
},
{
"type": "PACKAGE",
"url": "https://github.com/grokability/snipe-it"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:R/S:U/C:L/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Snipe-IT has a 2FA reset privilege bypass"
}
GHSA-6X5J-5M95-64XW
Vulnerability from github – Published: 2022-12-21 15:30 – Updated: 2022-12-21 15:30In getNearbyNotificationStreamingPolicy of DevicePolicyManagerService.java, there is a possible way to learn about the notification streaming policy of other users due to a permissions bypass. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-235822336
{
"affected": [],
"aliases": [
"CVE-2022-20510"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-16T16:15:00Z",
"severity": "MODERATE"
},
"details": "In getNearbyNotificationStreamingPolicy of DevicePolicyManagerService.java, there is a possible way to learn about the notification streaming policy of other users due to a permissions bypass. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-235822336",
"id": "GHSA-6x5j-5m95-64xw",
"modified": "2022-12-21T15:30:19Z",
"published": "2022-12-21T15:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20510"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2022-12-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-6X67-5CP9-C6CQ
Vulnerability from github – Published: 2022-05-24 16:53 – Updated: 2024-04-04 01:38SAP Kernel (ABAP Debugger), versions KRNL32NUC 7.21, 7.21EXT, 7.22, 7.22EXT, KRNL32UC 7.21, 7.21EXT, 7.22, 7.22EXT, KRNL64NUC 7.21, 7.21EXT, 7.22, 7.22EXT, 7.49, KRNL64UC 7.21, 7.21EXT, 7.22, 7.22EXT, 7.49, 7.73, KERNEL 7.21, 7.49, 7.53, 7.73, 7.75, 7.76, 7.77, allows a user to execute ?Go to statement? without possessing the authorization S_DEVELOP DEBUG 02, resulting in Missing Authorization Check
{
"affected": [],
"aliases": [
"CVE-2019-0349"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-08-14T15:15:00Z",
"severity": "HIGH"
},
"details": "SAP Kernel (ABAP Debugger), versions KRNL32NUC 7.21, 7.21EXT, 7.22, 7.22EXT, KRNL32UC 7.21, 7.21EXT, 7.22, 7.22EXT, KRNL64NUC 7.21, 7.21EXT, 7.22, 7.22EXT, 7.49, KRNL64UC 7.21, 7.21EXT, 7.22, 7.22EXT, 7.49, 7.73, KERNEL 7.21, 7.49, 7.53, 7.73, 7.75, 7.76, 7.77, allows a user to execute ?Go to statement? without possessing the authorization S_DEVELOP DEBUG 02, resulting in Missing Authorization Check",
"id": "GHSA-6x67-5cp9-c6cq",
"modified": "2024-04-04T01:38:54Z",
"published": "2022-05-24T16:53:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-0349"
},
{
"type": "WEB",
"url": "https://launchpad.support.sap.com/#/notes/2798743"
},
{
"type": "WEB",
"url": "https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=523998017"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6X7X-GCMF-7R8X
Vulnerability from github – Published: 2026-07-09 20:57 – Updated: 2026-07-09 20:57Summary
The {{erasespamedcomments}} wiki action (actions/EraseSpamedCommentsAction.php) accepts a suppr[] array from POST and deletes every wiki page whose tag appears in that array, with no authorization check anywhere in the action body or in the page-deletion path it invokes. Combined with YesWiki's allow-by-default action ACL model, any user who has page write access, which is the default for everyone (default_write_acl='*') on a fresh install can permanently delete arbitrary wiki pages, including the front page, admin pages, and pages owned by other users.
The action's delete() callee is PageManager::deleteOrphaned(), which despite its name does not check whether the target page is orphaned: it issues an unconditional DELETE against pages, links, acls, triples, referrers, and tags tables.
Details
Three issues compose the vulnerability.
actions/EraseSpamedCommentsAction.phpperforms no authorization check before processing$_POST['clean']/$_POST['suppr'][]inactions/EraseSpamedCommentsAction.php:
```php
public function run()
{
$wiki = &$this->wiki;
ob_start();
// ...
elseif (isset($_POST['clean'])) {
$deletedPages = '';
if (!empty($_POST['suppr'])) {
foreach ($_POST['suppr'] as $page) {
echo 'Effacement de : ' . $page . "
\n";
if ($wiki->services->get(PageController::class)->delete($page)) {
$deletedPages .= $page . ', ';
}
}
}
}
} ```
No UserIsAdmin(), no UserIsOwner(), no HasAccess('write', $page) per-target check, no CSRF token check.
- The default action ACL grants access to everyone in
includes/YesWiki.php:
php
$acl = empty($this->config['permissions'][$moduleType][$module])
? '*'
: $this->config['permissions'][$moduleType][$module];
php
if ($acl === null) { return true; }
return $this->CheckACL($acl, $user);
No shipped permissions map gates erasespamedcomments to admins, so Performer::CheckModuleACL('erasespamedcomments', 'action') returns true for anonymous users.
PageController::delete()andPageManager::deleteOrphaned()perform no authorization check and do not validate that the page is actually orphaned inincludes/controllers/PageController.php:38–48:
php
public function delete(string $tag): bool
{
if ($this->entryManager->isEntry($tag)) {
return $this->entryController->delete($tag);
} else {
$this->pageManager->deleteOrphaned($tag);
$this->wiki->LogAdministrativeAction(
$this->authController->getLoggedUserName(),
'Suppression de la page ->""' . $tag . '""'
);
return true;
}
}
in includes/services/PageManager.php:289–310:
php
public function deleteOrphaned($tag)
{
if ($this->securityController->isWikiHibernated()) { throw new \Exception(_t('WIKI_IN_HIBERNATION')); }
unset($this->ownersCache[$tag]);
if (in_array($tag, $this->pageCache)) { unset($this->pageCache[$tag]); }
$this->dbService->query("DELETE FROM ... WHERE tag='{$this->dbService->escape($tag)}' OR comment_on='{$this->dbService->escape($tag)}'");
$this->dbService->query("DELETE FROM ...links... WHERE from_tag='{$this->dbService->escape($tag)}' ");
$this->dbService->query("DELETE FROM ...acls... WHERE page_tag='{$this->dbService->escape($tag)}' ");
// ...further unconditional DELETEs across triples, referrers, tags
}
The companion isOrphaned() method (line 284) exists but is never called from deleteOrphaned(). The function name is misleading as it deletes any page, not just orphans.
PoC
Default fresh install where default_write_acl='*' (per includes/YesWikiInit.php:219), anonymous browsing.
- create a trigger page (anonymous)
POST /?wiki=SpamCleanup/edit HTTP/1.1
Host: target.example
Content-Type: application/x-www-form-urlencoded
body=%7B%7Berasespamedcomments%7D%7D&submit=1
This succeeds because the new page passes aclService->hasAccess('write', 'SpamCleanup') against default_write_acl='*'.
- trigger arbitrary page deletion (anonymous)
POST /?wiki=SpamCleanup HTTP/1.1
Host: target.example
Content-Type: application/x-www-form-urlencoded
clean=yes&suppr%5B0%5D=PagePrincipale&suppr%5B1%5D=AnotherTargetPage
Server response includes Effacement de : PagePrincipale and Effacement de : AnotherTargetPage. pages, links, acls, triples, referrers, and tags rows for those tags are deleted from the database.
Impact
Arbitrary page deletion, including the front page (PagePrincipale).
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "yeswiki/yeswiki"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.6.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-52766"
],
"database_specific": {
"cwe_ids": [
"CWE-276",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-09T20:57:25Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "### Summary\n\nThe `{{erasespamedcomments}}` wiki action (`actions/EraseSpamedCommentsAction.php`) accepts a `suppr[]` array from `POST` and deletes every wiki page whose tag appears in that array, with no authorization check anywhere in the action body or in the page-deletion path it invokes. Combined with YesWiki\u0027s allow-by-default action ACL model, any user who has page write access, which is the default for everyone (`default_write_acl=\u0027*\u0027`) on a fresh install can permanently delete arbitrary wiki pages, including the front page, admin pages, and pages owned by other users.\n\nThe action\u0027s `delete()` callee is `PageManager::deleteOrphaned()`, which despite its name does not check whether the target page is orphaned: it issues an unconditional `DELETE` against `pages`, `links`, `acls`, `triples`, `referrers`, and `tags` tables.\n\n### Details\n\nThree issues compose the vulnerability.\n\n1. `actions/EraseSpamedCommentsAction.php` performs no authorization check before processing `$_POST[\u0027clean\u0027]` / `$_POST[\u0027suppr\u0027][]` in `actions/EraseSpamedCommentsAction.php`:\n\n ```php\n public function run()\n {\n $wiki = \u0026$this-\u003ewiki;\n ob_start();\n // ...\n elseif (isset($_POST[\u0027clean\u0027])) { \n $deletedPages = \u0027\u0027;\n if (!empty($_POST[\u0027suppr\u0027])) { \n foreach ($_POST[\u0027suppr\u0027] as $page) {\n echo \u0027Effacement de : \u0027 . $page . \"\u003cbr /\u003e\\n\";\n if ($wiki-\u003eservices-\u003eget(PageController::class)-\u003edelete($page)) { \n $deletedPages .= $page . \u0027, \u0027;\n }\n }\n }\n \n }\n }\n ```\n\n No `UserIsAdmin()`, no `UserIsOwner()`, no `HasAccess(\u0027write\u0027, $page)` per-target check, no CSRF token check.\n\n2. The default action ACL grants access to everyone in `includes/YesWiki.php`:\n\n ```php\n $acl = empty($this-\u003econfig[\u0027permissions\u0027][$moduleType][$module])\n ? \u0027*\u0027\n : $this-\u003econfig[\u0027permissions\u0027][$moduleType][$module];\n ```\n\n ```php\n if ($acl === null) { return true; }\n return $this-\u003eCheckACL($acl, $user);\n ```\n\n No shipped `permissions` map gates `erasespamedcomments` to admins, so `Performer::CheckModuleACL(\u0027erasespamedcomments\u0027, \u0027action\u0027)` returns `true` for anonymous users.\n\n3. `PageController::delete()` and `PageManager::deleteOrphaned()` perform no authorization check and do not validate that the page is actually orphaned in `includes/controllers/PageController.php:38\u201348`:\n\n ```php\n public function delete(string $tag): bool\n {\n if ($this-\u003eentryManager-\u003eisEntry($tag)) {\n return $this-\u003eentryController-\u003edelete($tag);\n } else {\n $this-\u003epageManager-\u003edeleteOrphaned($tag);\n $this-\u003ewiki-\u003eLogAdministrativeAction(\n $this-\u003eauthController-\u003egetLoggedUserName(),\n \u0027Suppression de la page -\u003e\"\"\u0027 . $tag . \u0027\"\"\u0027\n );\n return true;\n }\n }\n ```\nin `includes/services/PageManager.php:289\u2013310`:\n ```php\n public function deleteOrphaned($tag)\n {\n if ($this-\u003esecurityController-\u003eisWikiHibernated()) { throw new \\Exception(_t(\u0027WIKI_IN_HIBERNATION\u0027)); }\n unset($this-\u003eownersCache[$tag]);\n if (in_array($tag, $this-\u003epageCache)) { unset($this-\u003epageCache[$tag]); }\n $this-\u003edbService-\u003equery(\"DELETE FROM ... WHERE tag=\u0027{$this-\u003edbService-\u003eescape($tag)}\u0027 OR comment_on=\u0027{$this-\u003edbService-\u003eescape($tag)}\u0027\");\n $this-\u003edbService-\u003equery(\"DELETE FROM ...links... WHERE from_tag=\u0027{$this-\u003edbService-\u003eescape($tag)}\u0027 \");\n $this-\u003edbService-\u003equery(\"DELETE FROM ...acls... WHERE page_tag=\u0027{$this-\u003edbService-\u003eescape($tag)}\u0027 \");\n // ...further unconditional DELETEs across triples, referrers, tags\n }\n ```\n\n The companion `isOrphaned()` method (line 284) exists but is never called from `deleteOrphaned()`. The function name is misleading as it deletes any page, not just orphans.\n\n### PoC\n\nDefault fresh install where `default_write_acl=\u0027*\u0027` (per `includes/YesWikiInit.php:219`), anonymous browsing.\n\n1. create a trigger page (anonymous)\n\n```http\nPOST /?wiki=SpamCleanup/edit HTTP/1.1\nHost: target.example\nContent-Type: application/x-www-form-urlencoded\n\nbody=%7B%7Berasespamedcomments%7D%7D\u0026submit=1\n```\n\nThis succeeds because the new page passes `aclService-\u003ehasAccess(\u0027write\u0027, \u0027SpamCleanup\u0027)` against `default_write_acl=\u0027*\u0027`.\n\n2. trigger arbitrary page deletion (anonymous)\n\n```http\nPOST /?wiki=SpamCleanup HTTP/1.1\nHost: target.example\nContent-Type: application/x-www-form-urlencoded\n\nclean=yes\u0026suppr%5B0%5D=PagePrincipale\u0026suppr%5B1%5D=AnotherTargetPage\n```\n\nServer response includes `Effacement de : PagePrincipale` and `Effacement de : AnotherTargetPage`. `pages`, `links`, `acls`, `triples`, `referrers`, and `tags` rows for those tags are deleted from the database.\n\n### Impact\n\n Arbitrary page deletion, including the front page (`PagePrincipale`).",
"id": "GHSA-6x7x-gcmf-7r8x",
"modified": "2026-07-09T20:57:25Z",
"published": "2026-07-09T20:57:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/YesWiki/yeswiki/security/advisories/GHSA-6x7x-gcmf-7r8x"
},
{
"type": "WEB",
"url": "https://github.com/YesWiki/yeswiki/commit/ed5b548a705c8091ba0282aaaba73ddda976abef"
},
{
"type": "PACKAGE",
"url": "https://github.com/YesWiki/yeswiki"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "YesWiki vulnerable to unauthenticated arbitrary page deletion via `{{erasespamedcomments}}` action"
}
GHSA-6X83-FCF5-R65G
Vulnerability from github – Published: 2026-03-11 12:31 – Updated: 2026-03-11 12:31WordPress core is vulnerable to unauthorized access in versions 6.9 through 6.9.1. The Notes feature (block-level collaboration annotations) was introduced in WordPress 6.9 to allow editorial comments directly on posts in the block editor. However, the REST API create_item_permissions_check() method in the comments controller did not verify that the authenticated user has edit_post permission on the target post when creating a note. This makes it possible for authenticated attackers with Subscriber-level access to create notes on any post, including posts authored by other users, private posts, and posts in any status.
{
"affected": [],
"aliases": [
"CVE-2026-3906"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-11T10:16:14Z",
"severity": "MODERATE"
},
"details": "WordPress core is vulnerable to unauthorized access in versions 6.9 through 6.9.1. The Notes feature (block-level collaboration annotations) was introduced in WordPress 6.9 to allow editorial comments directly on posts in the block editor. However, the REST API `create_item_permissions_check()` method in the comments controller did not verify that the authenticated user has `edit_post` permission on the target post when creating a note. This makes it possible for authenticated attackers with Subscriber-level access to create notes on any post, including posts authored by other users, private posts, and posts in any status.",
"id": "GHSA-6x83-fcf5-r65g",
"modified": "2026-03-11T12:31:22Z",
"published": "2026-03-11T12:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3906"
},
{
"type": "WEB",
"url": "https://core.trac.wordpress.org/browser/trunk/src/wp-includes/rest-api/endpoints/class-wp-rest-comments-controller.php#L562"
},
{
"type": "WEB",
"url": "https://core.trac.wordpress.org/changeset/61888"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/a69782f0-aa61-4049-8339-7f27f4b6c36b?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-6X85-FF3P-W5X2
Vulnerability from github – Published: 2024-10-16 09:30 – Updated: 2024-10-16 09:30The Paytium: Mollie payment forms & donations plugin for WordPress is vulnerable to unauthorized data modification due to a missing capability check on the update_profile_preference function in versions up to, and including, 4.3.7. This makes it possible for authenticated attackers with subscriber-level access to change plugin settings.
{
"affected": [],
"aliases": [
"CVE-2023-7288"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-16T07:15:13Z",
"severity": "MODERATE"
},
"details": "The Paytium: Mollie payment forms \u0026 donations plugin for WordPress is vulnerable to unauthorized data modification due to a missing capability check on the update_profile_preference function in versions up to, and including, 4.3.7. This makes it possible for authenticated attackers with subscriber-level access to change plugin settings.",
"id": "GHSA-6x85-ff3p-w5x2",
"modified": "2024-10-16T09:30:31Z",
"published": "2024-10-16T09:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-7288"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026new=2853869%40paytium%2Ftrunk\u0026old=2824314%40paytium%2Ftrunk\u0026sfp_email=\u0026sfph_mail=#file0"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/2e9bee86-f491-4f68-b10b-051e0fb1a67b?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:L",
"type": "CVSS_V3"
}
]
}
GHSA-6X92-6VX4-5FWR
Vulnerability from github – Published: 2026-08-20 18:42 – Updated: 2026-08-20 18:42Impact
The only authorization gate on the duplicate flow is PageAdmin.has_add_permission,
which checks user_can_add_page(user, site) / user_can_add_subpage(...) — i.e. “may
this user create a page at all”. Nothing checks the user’s relationship to the page being
copied:
cms/admin/forms.py—DuplicatePageForm.source = ModelChoiceField(queryset=Page.objects.all(), widget=HiddenInput())spans every page in the database, on every site.cms/admin/forms.py—AddPageForm.__init__returns early when thesourcewidget is hidden, so the queryset is never narrowed to the user’s site/subtree.cms/admin/forms.py—AddPageForm.clean()validates only URL uniqueness;sourceis never validated against the user.cms/admin/pageadmin.py—duplicate()seedssourcefrom the URL only on GET; on POST the value comes entirely from the request body.cms/admin/forms.py—AddPageForm.save()→from_source()performssource.copy(..., permissions=False)and copies every placeholder and all plugins ofsourceinto a new page on the attacker’s site. Becausepermissions=Falsedrops the source’s view restrictions, the resulting copy is fully readable by the attacker.
This crosses a real privilege boundary: a staff user restricted (via CMS_PERMISSION) to
their own site or subtree can exfiltrate the content of restricted pages and of pages
belonging to other tenants.
Read-back is trivial (verified): the copy is created on the attacker’s site and, because
copy(..., permissions=False) strips the source’s view restrictions, the new page is
unrestricted. user_can_view_page() then returns True for it (unrestricted +
PUBLIC_FOR), so the attacker — or even an anonymous visitor — can read the duplicated
content directly from the front end. No further permission on the new page is required.
Proof of concept
- Log in as a staff user
attackerwho has add page permission but no view/change permission on a target (secret / other-site) pageSECRET_ID. - Send (the URL
<id>only needs to be aPageContentthe attacker can already see — e.g. one of their own pages; the victim id goes in the POST body):
POST /admin/cms/pagecontent/<MY_OWN_PAGECONTENT_ID>/duplicate/ HTTP/1.1
Cookie: sessionid=<attacker session>
Content-Type: application/x-www-form-urlencoded
csrfmiddlewaretoken=...&title=x&slug=x&language=en&source=<SECRET_ID>
- A new, unrestricted page is created under the attacker’s site containing a verbatim copy of the secret page’s plugins, which the attacker can now preview/edit/read.
Patches
Enforce an object-level permission check on source:
class DuplicatePageForm(AddPageForm):
source = forms.ModelChoiceField(
queryset=Page.objects.all(),
required=True,
widget=forms.HiddenInput(),
)
def clean_source(self):
source = self.cleaned_data.get("source")
if source and not user_can_view_page(self._user, source):
raise ValidationError(_("You do not have permission to copy this page."))
return source
(user_can_view_page is imported from cms.utils.page_permissions.)
Workarounds
Until patched, restrict access to the cms.add_page permission to fully-trusted staff, or
disable the duplicate action for delegated/limited editors.
References
cms/admin/pageadmin.py—duplicate(),has_add_permission(),get_urls()cms/admin/forms.py—DuplicatePageForm,AddPageForm.__init__/clean/save/from_source- Regression tests:
cms/tests/test_forms.py::DuplicatePageFormSecurityTestCase
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.0.8"
},
"package": {
"ecosystem": "PyPI",
"name": "django-cms"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.0.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-63003"
],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-20T18:42:44Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Impact\n\nThe only authorization gate on the duplicate flow is `PageAdmin.has_add_permission`,\nwhich checks `user_can_add_page(user, site)` / `user_can_add_subpage(...)` \u2014 i.e. *\u201cmay\nthis user create a page at all\u201d*. Nothing checks the user\u2019s relationship to the page being\ncopied:\n\n- `cms/admin/forms.py` \u2014 `DuplicatePageForm.source = ModelChoiceField(queryset=Page.objects.all(), widget=HiddenInput())`\n spans **every page in the database, on every site**.\n- `cms/admin/forms.py` \u2014 `AddPageForm.__init__` returns early when the `source` widget is\n hidden, so the queryset is **never narrowed** to the user\u2019s site/subtree.\n- `cms/admin/forms.py` \u2014 `AddPageForm.clean()` validates only URL uniqueness; `source` is\n never validated against the user.\n- `cms/admin/pageadmin.py` \u2014 `duplicate()` seeds `source` from the URL **only on GET**; on\n POST the value comes entirely from the request body.\n- `cms/admin/forms.py` \u2014 `AddPageForm.save()` \u2192 `from_source()` performs\n `source.copy(..., permissions=False)` and copies **every placeholder and all plugins** of\n `source` into a new page on the attacker\u2019s site. Because `permissions=False` drops the\n source\u2019s view restrictions, the resulting copy is fully readable by the attacker.\n\nThis crosses a real privilege boundary: a staff user restricted (via `CMS_PERMISSION`) to\ntheir own site or subtree can exfiltrate the content of restricted pages and of pages\nbelonging to other tenants.\n\n**Read-back is trivial (verified):** the copy is created on the attacker\u2019s site and, because\n`copy(..., permissions=False)` strips the source\u2019s view restrictions, the new page is\n*unrestricted*. `user_can_view_page()` then returns `True` for it (unrestricted +\n`PUBLIC_FOR`), so the attacker \u2014 or even an anonymous visitor \u2014 can read the duplicated\ncontent directly from the front end. No further permission on the new page is required.\n\n## Proof of concept\n\n1. Log in as a staff user `attacker` who has *add page* permission but **no** view/change\n permission on a target (secret / other-site) page `SECRET_ID`.\n2. Send (the URL `\u003cid\u003e` only needs to be a `PageContent` the attacker can already see \u2014\n e.g. one of their own pages; the victim id goes in the POST body):\n\n```http\nPOST /admin/cms/pagecontent/\u003cMY_OWN_PAGECONTENT_ID\u003e/duplicate/ HTTP/1.1\nCookie: sessionid=\u003cattacker session\u003e\nContent-Type: application/x-www-form-urlencoded\n\ncsrfmiddlewaretoken=...\u0026title=x\u0026slug=x\u0026language=en\u0026source=\u003cSECRET_ID\u003e\n```\n\n3. A new, unrestricted page is created under the attacker\u2019s site containing a verbatim\n copy of the secret page\u2019s plugins, which the attacker can now preview/edit/read.\n\n## Patches \n\nEnforce an object-level permission check on `source`:\n\n```python\nclass DuplicatePageForm(AddPageForm):\n source = forms.ModelChoiceField(\n queryset=Page.objects.all(),\n required=True,\n widget=forms.HiddenInput(),\n )\n\n def clean_source(self):\n source = self.cleaned_data.get(\"source\")\n if source and not user_can_view_page(self._user, source):\n raise ValidationError(_(\"You do not have permission to copy this page.\"))\n return source\n```\n\n(`user_can_view_page` is imported from `cms.utils.page_permissions`.)\n\n## Workarounds\n\nUntil patched, restrict access to the `cms.add_page` permission to fully-trusted staff, or\ndisable the duplicate action for delegated/limited editors.\n\n## References\n\n- `cms/admin/pageadmin.py` \u2014 `duplicate()`, `has_add_permission()`, `get_urls()`\n- `cms/admin/forms.py` \u2014 `DuplicatePageForm`, `AddPageForm.__init__/clean/save/from_source`\n- Regression tests: `cms/tests/test_forms.py::DuplicatePageFormSecurityTestCase`",
"id": "GHSA-6x92-6vx4-5fwr",
"modified": "2026-08-20T18:42:44Z",
"published": "2026-08-20T18:42:44Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/django-cms/django-cms/security/advisories/GHSA-6x92-6vx4-5fwr"
},
{
"type": "WEB",
"url": "https://github.com/django-cms/django-cms/pull/8713"
},
{
"type": "WEB",
"url": "https://github.com/django-cms/django-cms/commit/3e1ccf7573eb1a74ebbbfaaa812c1f5cadf14e6c"
},
{
"type": "PACKAGE",
"url": "https://github.com/django-cms/django-cms"
},
{
"type": "WEB",
"url": "https://github.com/django-cms/django-cms/releases/tag/5.0.9"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "django CMS: Broken access control in page *Duplicate* allows reading the content of any page (cross-site / restriction bypass)"
}
GHSA-6X9P-4R67-5GJX
Vulnerability from github – Published: 2026-08-26 14:07 – Updated: 2026-08-26 14:07Summary
Budibase 3.39.7 allows a low-privilege authenticated published-app user with the built-in BASIC role to obtain arbitrary S3 pre-signed upload URLs backed by a workspace datasource's stored server-side credentials.
The affected endpoint is:
POST /api/attachments/:datasourceId/url
The caller can control:
bucket
key
and receives:
signedUrl
publicUrl
This lets a low-privilege published-app user mint S3 PUT URLs using server-side datasource credentials for attacker-chosen object destinations.
Steps:
- Log in as an admin user.
- Create a new app/workspace.
- In the development app context, create an S3 datasource with valid credentials.
- Publish the app.
- Create a low-privilege user with the built-in BASIC role on the published production app ID.
- Log in as that BASIC user.
- Send:
POST /api/attachments/<datasourceId>/url
with:
{"bucket":"foo","key":"bar"}
and the published app header:
x-budibase-app-id: <published_app_id>
Observe a successful response containing:
signedUrl
publicUrl
Observed result
The following behavior:
dev BASIC request: 403 User does not have permission app publish: SUCCESS prod BASIC request: 200 OK Example confirmed runtime values from the final successful run:
prodAppId: app_e6b4cdc6cd6949969a83ff11eee88c5a
datasourceId: datasource_0cec491b26a742468257c62382aa3284
publicUrl: https://foo.s3.eu-west-1.amazonaws.com/bar
The returned signedUrl contained standard AWS signing markers, including:
X-Amz-Credential=bb
X-Amz-Signature
X-Amz-Expires=900
Impact
A low-privilege published-app user who knows a valid datasource ID can mint S3 upload URLs backed by server-side datasource credentials and choose arbitrary destination bucket and key values.
Route definition
packages/server/src/api/routes/static.ts:45
Authorization logic
packages/server/src/middleware/authorized.ts
packages/server/src/middleware/resourceId.ts
Controller logic
packages/server/src/api/controllers/static/index.ts
Datasource lookup
packages/server/src/sdk/workspace/datasources/datasources.ts
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@budibase/server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "3.38.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54356"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-26T14:07:26Z",
"nvd_published_at": "2026-08-17T21:16:46Z",
"severity": "HIGH"
},
"details": "### Summary\nBudibase 3.39.7 allows a low-privilege authenticated published-app user with the built-in BASIC role to obtain arbitrary S3 pre-signed upload URLs backed by a workspace datasource\u0027s stored server-side credentials.\n\nThe affected endpoint is:\n\n`POST /api/attachments/:datasourceId/url`\n\nThe caller can control:\n```text\nbucket\nkey\n```\nand receives:\n```text\nsignedUrl\npublicUrl\n```\n\nThis lets a low-privilege published-app user mint S3 `PUT` URLs using server-side datasource credentials for attacker-chosen object destinations.\n\nSteps:\n\n1. Log in as an admin user.\n2. Create a new app/workspace.\n3. In the development app context, create an S3 datasource with valid credentials.\n4. Publish the app.\n5. Create a low-privilege user with the built-in BASIC role on the published production app ID.\n6. Log in as that BASIC user.\n7. Send:\n`POST /api/attachments/\u003cdatasourceId\u003e/url`\n\nwith:\n```json\n{\"bucket\":\"foo\",\"key\":\"bar\"}\n```\nand the published app header:\n```text\nx-budibase-app-id: \u003cpublished_app_id\u003e\n```\nObserve a successful response containing:\n```text\nsignedUrl\npublicUrl\n```\n\n### Observed result\n\nThe following behavior:\n\ndev BASIC request: 403 User does not have permission\napp publish: SUCCESS\nprod BASIC request: 200 OK\nExample confirmed runtime values from the final successful run:\n```text\nprodAppId: app_e6b4cdc6cd6949969a83ff11eee88c5a\ndatasourceId: datasource_0cec491b26a742468257c62382aa3284\npublicUrl: https://foo.s3.eu-west-1.amazonaws.com/bar\n```\nThe returned signedUrl contained standard AWS signing markers, including:\n```text\nX-Amz-Credential=bb\nX-Amz-Signature\nX-Amz-Expires=900\n```\n### Impact\n\nA low-privilege published-app user who knows a valid datasource ID can mint S3 upload URLs backed by server-side datasource credentials and choose arbitrary destination bucket and key values.\n\n### Route definition\n`packages/server/src/api/routes/static.ts:45`\nAuthorization logic\n`packages/server/src/middleware/authorized.ts`\n`packages/server/src/middleware/resourceId.ts`\nController logic\n`packages/server/src/api/controllers/static/index.ts`\nDatasource lookup\n`packages/server/src/sdk/workspace/datasources/datasources.ts`",
"id": "GHSA-6x9p-4r67-5gjx",
"modified": "2026-08-26T14:07:26Z",
"published": "2026-08-26T14:07:26Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Budibase/budibase/security/advisories/GHSA-6x9p-4r67-5gjx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54356"
},
{
"type": "PACKAGE",
"url": "https://github.com/Budibase/budibase"
},
{
"type": "WEB",
"url": "https://github.com/Budibase/budibase/releases/tag/3.41.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "Budibase authenticated arbitrary S3 signed upload URL issuance via `/api/attachments/:datasourceId/url`"
}
GHSA-6XF3-HR92-36VC
Vulnerability from github – Published: 2026-07-23 12:32 – Updated: 2026-07-23 12:32Unauthenticated Broken Access Control in Civi <= 2.2.4 versions.
{
"affected": [],
"aliases": [
"CVE-2026-65476"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-23T12:18:40Z",
"severity": "MODERATE"
},
"details": "Unauthenticated Broken Access Control in Civi \u003c= 2.2.4 versions.",
"id": "GHSA-6xf3-hr92-36vc",
"modified": "2026-07-23T12:32:28Z",
"published": "2026-07-23T12:32:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65476"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/theme/civi/vulnerability/wordpress-civi-theme-2-2-4-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-6XF8-9P5R-2VCR
Vulnerability from github – Published: 2026-07-07 12:31 – Updated: 2026-07-07 12:31Missing Authorization vulnerability in HAVELSAN Inc. Liman MYS allows Accessing Functionality Not Properly Constrained by ACLs.
This issue affects Liman MYS: before release.Master.1107.
{
"affected": [],
"aliases": [
"CVE-2026-11340"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-07T11:16:32Z",
"severity": "HIGH"
},
"details": "Missing Authorization vulnerability in HAVELSAN Inc. Liman MYS allows Accessing Functionality Not Properly Constrained by ACLs.\n\nThis issue affects Liman MYS: before release.Master.1107.",
"id": "GHSA-6xf8-9p5r-2vcr",
"modified": "2026-07-07T12:31:36Z",
"published": "2026-07-07T12:31:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-11340"
},
{
"type": "WEB",
"url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-26-0504"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H",
"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.