Common Weakness Enumeration

CWE-862

Allowed-with-Review

Missing Authorization

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

14985 vulnerabilities reference this CWE, most recent first.

GHSA-G375-5WMP-XR78

Vulnerability from github – Published: 2026-03-16 21:18 – Updated: 2026-03-20 21:15
VLAI
Summary
Admidio is Missing Authorization on Forum Topic and Post Deletion
Details

Summary

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;
Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "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:25
VLAI
Summary
Mattermost server allows authenticated user to delete arbitrary post
Details

Mattermost 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.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
5.3 (Medium)
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
Show details on source website
To clipboard 

{
  "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-G3C3-Q2FM-F7G4

Vulnerability from github – Published: 2026-05-01 15:30 – Updated: 2026-05-01 15:30
VLAI
Details

The 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.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "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:30
VLAI
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.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "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:31
VLAI
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.

Severity
5.4 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "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-G3FG-M5V4-28J4

Vulnerability from github – Published: 2025-12-09 18:30 – Updated: 2026-01-20 15:32
VLAI
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 <= 1.16.7.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

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

GHSA-G3GR-PMRC-H9X8

Vulnerability from github – Published: 2024-02-28 09:30 – Updated: 2024-02-28 09:30
VLAI
Details

The Page Duplicator plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the duplicate_dat_page() function in all versions up to, and including, 0.1.1. This makes it possible for unauthenticated attackers to duplicate arbitrary posts and pages.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-1368"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-28T09:15:42Z",
    "severity": "MODERATE"
  },
  "details": "The Page Duplicator plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the duplicate_dat_page() function in all versions up to, and including, 0.1.1. This makes it possible for unauthenticated attackers to duplicate arbitrary posts and pages.",
  "id": "GHSA-g3gr-pmrc-h9x8",
  "modified": "2024-02-28T09:30:39Z",
  "published": "2024-02-28T09:30:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1368"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wp-page-duplicator/trunk/page-duplicator.php#L136"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/bcc10e91-4810-4a0d-919c-de3e87137f76?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-G3HJ-MF85-679G

Vulnerability from github – Published: 2026-03-29 15:41 – Updated: 2026-03-29 15:41
VLAI
Summary
AVideo: IDOR in uploadPoster.php Allows Any Authenticated User to Overwrite Scheduled Live Stream Posters and Trigger False Socket Notifications
Details

Summary

The plugin/Live/uploadPoster.php endpoint allows any authenticated user to overwrite the poster image for any scheduled live stream by supplying an arbitrary live_schedule_id. The endpoint only checks User::isLogged() but never verifies that the authenticated user owns the targeted schedule. After overwriting the poster, the endpoint broadcasts a socketLiveOFFCallback notification containing the victim's broadcast key and user ID to all connected WebSocket clients.

Details

The vulnerable endpoint at plugin/Live/uploadPoster.php accepts a live_schedule_id from $_REQUEST and uses it to determine poster file paths and trigger socket notifications without ownership validation.

Entry point — attacker-controlled input (line 11-12):

$live_servers_id = intval($_REQUEST['live_servers_id']);
$live_schedule_id = intval($_REQUEST['live_schedule_id']);

Insufficient auth check (line 14-17):

if (!User::isLogged()) {
    $obj->msg = 'You cant edit this file';
    die(json_encode($obj));
}

This only verifies the user is logged in. There is no check that User::getId() matches the schedule owner's users_id.

Poster path resolved by ID alone (line 40-42):

$paths = Live_schedule::getPosterPaths($live_schedule_id, 0);
$obj->file = str_replace($global['systemRootPath'], '', $paths['path']);
$obj->fileThumbs = str_replace($global['systemRootPath'], '', $paths['path_thumbs']);

getPosterPaths() is a static method that constructs file paths purely from the numeric ID with no authorization.

Attacker's file overwrites victim's poster (line 48):

if (!move_uploaded_file($_FILES['file_data']['tmp_name'], $tmpDestination)) {

Broadcast to all WebSocket clients (line 67-73):

if (!empty($live_schedule_id)) {
    $ls = new Live_schedule($live_schedule_id);
    $array = setLiveKey($ls->getKey(), $ls->getLive_servers_id());
    $array['users_id'] = $ls->getUsers_id();
    $array['stats'] = getStatsNotifications(true);
    Live::notifySocketStats("socketLiveOFFCallback", $array);
}

The Live_schedule constructor (inherited from ObjectYPT) loads data by ID with no auth checks. Live::notifySocketStats() calls sendSocketMessageToAll() which broadcasts to every connected WebSocket client.

Notably, the parallel endpoints DO have ownership checks: - plugin/Live/view/Live_schedule/uploadPoster.php (line 18-21) checks $row->getUsers_id() != User::getId() - plugin/Live/uploadPoster.json.php (line 24-27) checks User::isAdmin() || $row->getUsers_id() == User::getId()

This proves the missing check in uploadPoster.php is an oversight, not by-design.

PoC

# Step 1: Log in as a low-privilege user to get a session cookie
curl -c cookies.txt -X POST 'https://target.com/objects/login.json.php' \
  -d 'user=attacker@example.com&pass=attackerpassword'

# Step 2: Overwrite the poster for live_schedule_id=1 (owned by a different user)
curl -b cookies.txt \
  -F 'file_data=@malicious.jpg' \
  -F 'live_schedule_id=1' \
  -F 'live_servers_id=0' \
  'https://target.com/plugin/Live/uploadPoster.php'

# Expected: 403 or ownership error
# Actual: {} (success) — poster overwritten, socketLiveOFFCallback broadcast sent

# Step 3: Verify the poster was replaced
curl -o - 'https://target.com/videos/live_schedule_posters/schedule_1.jpg' | file -
# Output confirms attacker's image now serves as the victim's poster

# The socketLiveOFFCallback broadcast (received by all WebSocket clients) contains:
# { "key": "<victim_broadcast_key>", "users_id": <victim_user_id>, "stats": {...} }

Schedule IDs are sequential integers and can be enumerated trivially.

Impact

  1. Content tampering: Any authenticated user can overwrite poster images on any scheduled live stream. This enables defacement or phishing (e.g., replacing a poster with a malicious redirect image).
  2. False offline notifications: The socketLiveOFFCallback broadcast misleads all connected viewers into thinking the victim's stream went offline, disrupting the victim's audience.
  3. Information disclosure: The broadcast leaks the victim's users_id and broadcast key to all connected WebSocket clients.
  4. Enumerable targets: Schedule IDs are sequential integers, so an attacker can trivially enumerate and target all scheduled streams.

Recommended Fix

Add an ownership check after the login verification at line 17 in plugin/Live/uploadPoster.php:

if (!User::isLogged()) {
    $obj->msg = 'You cant edit this file';
    die(json_encode($obj));
}

// Add ownership check for scheduled live streams
if (!empty($live_schedule_id)) {
    $ls = new Live_schedule($live_schedule_id);
    if ($ls->getUsers_id() != User::getId() && !User::isAdmin()) {
        $obj->msg = 'Not authorized';
        die(json_encode($obj));
    }
}

This mirrors the existing authorization pattern already used in uploadPoster.json.php (line 24) and view/Live_schedule/uploadPoster.php (line 18).

Severity
5.4 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "wwbn/avideo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "26.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34247"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-29T15:41:44Z",
    "nvd_published_at": "2026-03-27T17:16:30Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe `plugin/Live/uploadPoster.php` endpoint allows any authenticated user to overwrite the poster image for any scheduled live stream by supplying an arbitrary `live_schedule_id`. The endpoint only checks `User::isLogged()` but never verifies that the authenticated user owns the targeted schedule. After overwriting the poster, the endpoint broadcasts a `socketLiveOFFCallback` notification containing the victim\u0027s broadcast key and user ID to all connected WebSocket clients.\n\n## Details\n\nThe vulnerable endpoint at `plugin/Live/uploadPoster.php` accepts a `live_schedule_id` from `$_REQUEST` and uses it to determine poster file paths and trigger socket notifications without ownership validation.\n\n**Entry point \u2014 attacker-controlled input (line 11-12):**\n```php\n$live_servers_id = intval($_REQUEST[\u0027live_servers_id\u0027]);\n$live_schedule_id = intval($_REQUEST[\u0027live_schedule_id\u0027]);\n```\n\n**Insufficient auth check (line 14-17):**\n```php\nif (!User::isLogged()) {\n    $obj-\u003emsg = \u0027You cant edit this file\u0027;\n    die(json_encode($obj));\n}\n```\n\nThis only verifies the user is logged in. There is no check that `User::getId()` matches the schedule owner\u0027s `users_id`.\n\n**Poster path resolved by ID alone (line 40-42):**\n```php\n$paths = Live_schedule::getPosterPaths($live_schedule_id, 0);\n$obj-\u003efile = str_replace($global[\u0027systemRootPath\u0027], \u0027\u0027, $paths[\u0027path\u0027]);\n$obj-\u003efileThumbs = str_replace($global[\u0027systemRootPath\u0027], \u0027\u0027, $paths[\u0027path_thumbs\u0027]);\n```\n\n`getPosterPaths()` is a static method that constructs file paths purely from the numeric ID with no authorization.\n\n**Attacker\u0027s file overwrites victim\u0027s poster (line 48):**\n```php\nif (!move_uploaded_file($_FILES[\u0027file_data\u0027][\u0027tmp_name\u0027], $tmpDestination)) {\n```\n\n**Broadcast to all WebSocket clients (line 67-73):**\n```php\nif (!empty($live_schedule_id)) {\n    $ls = new Live_schedule($live_schedule_id);\n    $array = setLiveKey($ls-\u003egetKey(), $ls-\u003egetLive_servers_id());\n    $array[\u0027users_id\u0027] = $ls-\u003egetUsers_id();\n    $array[\u0027stats\u0027] = getStatsNotifications(true);\n    Live::notifySocketStats(\"socketLiveOFFCallback\", $array);\n}\n```\n\nThe `Live_schedule` constructor (inherited from `ObjectYPT`) loads data by ID with no auth checks. `Live::notifySocketStats()` calls `sendSocketMessageToAll()` which broadcasts to every connected WebSocket client.\n\n**Notably, the parallel endpoints DO have ownership checks:**\n- `plugin/Live/view/Live_schedule/uploadPoster.php` (line 18-21) checks `$row-\u003egetUsers_id() != User::getId()`\n- `plugin/Live/uploadPoster.json.php` (line 24-27) checks `User::isAdmin() || $row-\u003egetUsers_id() == User::getId()`\n\nThis proves the missing check in `uploadPoster.php` is an oversight, not by-design.\n\n## PoC\n\n```bash\n# Step 1: Log in as a low-privilege user to get a session cookie\ncurl -c cookies.txt -X POST \u0027https://target.com/objects/login.json.php\u0027 \\\n  -d \u0027user=attacker@example.com\u0026pass=attackerpassword\u0027\n\n# Step 2: Overwrite the poster for live_schedule_id=1 (owned by a different user)\ncurl -b cookies.txt \\\n  -F \u0027file_data=@malicious.jpg\u0027 \\\n  -F \u0027live_schedule_id=1\u0027 \\\n  -F \u0027live_servers_id=0\u0027 \\\n  \u0027https://target.com/plugin/Live/uploadPoster.php\u0027\n\n# Expected: 403 or ownership error\n# Actual: {} (success) \u2014 poster overwritten, socketLiveOFFCallback broadcast sent\n\n# Step 3: Verify the poster was replaced\ncurl -o - \u0027https://target.com/videos/live_schedule_posters/schedule_1.jpg\u0027 | file -\n# Output confirms attacker\u0027s image now serves as the victim\u0027s poster\n\n# The socketLiveOFFCallback broadcast (received by all WebSocket clients) contains:\n# { \"key\": \"\u003cvictim_broadcast_key\u003e\", \"users_id\": \u003cvictim_user_id\u003e, \"stats\": {...} }\n```\n\nSchedule IDs are sequential integers and can be enumerated trivially.\n\n## Impact\n\n1. **Content tampering:** Any authenticated user can overwrite poster images on any scheduled live stream. This enables defacement or phishing (e.g., replacing a poster with a malicious redirect image).\n2. **False offline notifications:** The `socketLiveOFFCallback` broadcast misleads all connected viewers into thinking the victim\u0027s stream went offline, disrupting the victim\u0027s audience.\n3. **Information disclosure:** The broadcast leaks the victim\u0027s `users_id` and broadcast key to all connected WebSocket clients.\n4. **Enumerable targets:** Schedule IDs are sequential integers, so an attacker can trivially enumerate and target all scheduled streams.\n\n## Recommended Fix\n\nAdd an ownership check after the login verification at line 17 in `plugin/Live/uploadPoster.php`:\n\n```php\nif (!User::isLogged()) {\n    $obj-\u003emsg = \u0027You cant edit this file\u0027;\n    die(json_encode($obj));\n}\n\n// Add ownership check for scheduled live streams\nif (!empty($live_schedule_id)) {\n    $ls = new Live_schedule($live_schedule_id);\n    if ($ls-\u003egetUsers_id() != User::getId() \u0026\u0026 !User::isAdmin()) {\n        $obj-\u003emsg = \u0027Not authorized\u0027;\n        die(json_encode($obj));\n    }\n}\n```\n\nThis mirrors the existing authorization pattern already used in `uploadPoster.json.php` (line 24) and `view/Live_schedule/uploadPoster.php` (line 18).",
  "id": "GHSA-g3hj-mf85-679g",
  "modified": "2026-03-29T15:41:44Z",
  "published": "2026-03-29T15:41:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-g3hj-mf85-679g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34247"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/commit/5fcb3bdf59f26d65e203cfbc8a685356ba300b60"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/WWBN/AVideo"
    }
  ],
  "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"
    }
  ],
  "summary": "AVideo: IDOR in uploadPoster.php Allows Any Authenticated User to Overwrite Scheduled Live Stream Posters and Trigger False Socket Notifications"
}

GHSA-G3HQ-7735-4X6V

Vulnerability from github – Published: 2026-02-25 21:31 – Updated: 2026-02-25 21:31
VLAI
Details

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 17.7 before 18.7.5, 18.8 before 18.8.5, and 18.9 before 18.9.1 that could have allowed an unauthorized user with Developer-role permissions to set pipeline variables for manually triggered jobs under certain conditions.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-14103"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-25T20:20:07Z",
    "severity": "MODERATE"
  },
  "details": "GitLab has remediated an issue in GitLab CE/EE affecting all versions from 17.7 before 18.7.5, 18.8 before 18.8.5, and 18.9 before 18.9.1 that could have allowed an unauthorized user with Developer-role permissions to set pipeline variables for manually triggered jobs under certain conditions.",
  "id": "GHSA-g3hq-7735-4x6v",
  "modified": "2026-02-25T21:31:19Z",
  "published": "2026-02-25T21:31:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14103"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/3448317"
    },
    {
      "type": "WEB",
      "url": "https://about.gitlab.com/releases/2026/02/25/patch-release-gitlab-18-9-1-released"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/583053"
    }
  ],
  "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-G3JJ-PMJ9-C2V3

Vulnerability from github – Published: 2026-07-13 12:35 – Updated: 2026-07-13 12:35
VLAI
Details

Missing Authorization vulnerability in vowelweb VW Wedding vw-wedding allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects VW Wedding: from n/a through <= 1.3.7.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-57776"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-13T10:16:41Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in vowelweb VW Wedding vw-wedding allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects VW Wedding: from n/a through \u003c= 1.3.7.",
  "id": "GHSA-g3jj-pmj9-c2v3",
  "modified": "2026-07-13T12:35:04Z",
  "published": "2026-07-13T12:35:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-57776"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Theme/vw-wedding/vulnerability/wordpress-vw-wedding-theme-1-3-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:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Architecture and Design
  • 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
Architecture and Design

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
Architecture and Design

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
Architecture and Design
  • 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
System Configuration Installation

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.

← Back to the CWE list