CWE-862
Allowed-with-ReviewMissing Authorization
Abstraction: Class · Status: Incomplete
The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
18003 vulnerabilities reference this CWE, most recent first.
GHSA-RMC6-76F7-WWPM
Vulnerability from github – Published: 2025-05-19 21:30 – Updated: 2026-04-01 18:35Missing Authorization vulnerability in Crocoblock JetElements For Elementor allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects JetElements For Elementor: from n/a through 2.7.4.1.
{
"affected": [],
"aliases": [
"CVE-2025-39447"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-19T19:15:49Z",
"severity": "HIGH"
},
"details": "Missing Authorization vulnerability in Crocoblock JetElements For Elementor allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects JetElements For Elementor: from n/a through 2.7.4.1.",
"id": "GHSA-rmc6-76f7-wwpm",
"modified": "2026-04-01T18:35:13Z",
"published": "2025-05-19T21:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39447"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/jet-elements/vulnerability/wordpress-jetelements-for-elementor-2-7-4-1-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:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-RMF2-688X-24H9
Vulnerability from github – Published: 2026-09-09 06:31 – Updated: 2026-09-09 18:31The WPLP Cookie Consent WordPress plugin before 4.4.2 does not have any authorisation or CSRF checks when storing visitor consent state, and the code that does so runs on every front-end page load, allowing unauthenticated attackers to overwrite a site-wide option with arbitrary data.
{
"affected": [],
"aliases": [
"CVE-2026-82184"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-09T06:17:17Z",
"severity": "MODERATE"
},
"details": "The WPLP Cookie Consent WordPress plugin before 4.4.2 does not have any authorisation or CSRF checks when storing visitor consent state, and the code that does so runs on every front-end page load, allowing unauthenticated attackers to overwrite a site-wide option with arbitrary data.",
"id": "GHSA-rmf2-688x-24h9",
"modified": "2026-09-09T18:31:57Z",
"published": "2026-09-09T06:31:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-82184"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/54f2da44-84c2-4c56-88f3-615ae4054ecb"
}
],
"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-RMGM-2RQ2-74RF
Vulnerability from github – Published: 2026-09-08 21:34 – Updated: 2026-09-10 18:31In isCallerAllowed of WalletContextualLocationsService.kt, there is a possible way to get wallet information due to a missing permission check. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.
{
"affected": [],
"aliases": [
"CVE-2026-0054"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-08T19:17:49Z",
"severity": "LOW"
},
"details": "In isCallerAllowed of WalletContextualLocationsService.kt, there is a possible way to get wallet information due to a missing permission check. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.",
"id": "GHSA-rmgm-2rq2-74rf",
"modified": "2026-09-10T18:31:32Z",
"published": "2026-09-08T21:34:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-0054"
},
{
"type": "WEB",
"url": "https://source.android.com/docs/security/bulletin/2026/2026-09-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-RMH4-WJ7H-4CPW
Vulnerability from github – Published: 2024-06-11 15:31 – Updated: 2024-06-11 15:31Missing Authorization vulnerability in weDevs weDocs.This issue affects weDocs: from n/a through 2.1.4.
{
"affected": [],
"aliases": [
"CVE-2024-34442"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-11T14:15:11Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in weDevs weDocs.This issue affects weDocs: from n/a through 2.1.4.",
"id": "GHSA-rmh4-wj7h-4cpw",
"modified": "2024-06-11T15:31:14Z",
"published": "2024-06-11T15:31:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34442"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/wedocs/wordpress-wedocs-plugin-2-1-4-broken-access-control-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-RMJJ-8R22-RWHV
Vulnerability from github – Published: 2024-02-29 03:33 – Updated: 2024-02-29 03:33The ImageRecycle pdf & image compression plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the stopOptimizeAll function in all versions up to, and including, 3.1.13. This makes it possible for authenticated attackers, with subscriber-level access and above, to modify image optimization settings.
{
"affected": [],
"aliases": [
"CVE-2024-1090"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-29T01:43:39Z",
"severity": "MODERATE"
},
"details": "The ImageRecycle pdf \u0026 image compression plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the stopOptimizeAll function in all versions up to, and including, 3.1.13. This makes it possible for authenticated attackers, with subscriber-level access and above, to modify image optimization settings.",
"id": "GHSA-rmjj-8r22-rwhv",
"modified": "2024-02-29T03:33:16Z",
"published": "2024-02-29T03:33:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1090"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3031424/imagerecycle-pdf-image-compression"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/f3fae909-5564-4e0a-9114-edd0e45865e5?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-RMJQ-8JC4-XXP7
Vulnerability from github – Published: 2025-12-16 09:31 – Updated: 2026-01-20 15:32Missing Authorization vulnerability in CatFolders CatFolders catfolders allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects CatFolders: from n/a through <= 2.5.3.
{
"affected": [],
"aliases": [
"CVE-2025-66120"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-16T09:15:56Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in CatFolders CatFolders catfolders allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects CatFolders: from n/a through \u003c= 2.5.3.",
"id": "GHSA-rmjq-8jc4-xxp7",
"modified": "2026-01-20T15:32:14Z",
"published": "2025-12-16T09:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66120"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/catfolders/vulnerability/wordpress-catfolders-plugin-2-5-3-broken-access-control-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/catfolders/vulnerability/wordpress-catfolders-plugin-2-5-3-broken-access-control-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-RMM7-R7WR-XPFG
Vulnerability from github – Published: 2025-01-14 16:00 – Updated: 2025-01-14 21:20Impact
NOTE: The Realtime WYSIWYG Editor extension was experimental, and thus not recommended, in the versions affected by this vulnerability. It has become enabled by default, and thus recommended, starting with XWiki 16.9.0.
A user with only edit right can join a realtime editing session where others, that where already there or that may join later, have script or programming access rights. This user can then insert script rendering macros that are executed for those users in the realtime session that have script or programming rights. The inserted scripts can be used to gain more access rights.
Here's an example that works with XWiki 15.10.9+ and 16.2.0+:
- the attacker starts editing a wiki page in realtime (for which they have edit right)
- another user, with script or programming access right joins the editing session (e.g. by clicking on a link / URL provided by the attacker)
- the attacker inserts a script rendering macro, say
{{velocity}}I can run scripts{{/velocity}}, in the edited content, using the WYSIWYG editor UI - the edited content is reloaded for both the attacker and the other user, in order to render the inserted macro
- the attacker gets a rendering error message
- the other user sees "I can run scripts"
The attacker can obviously use more advanced scripts to gain access rights.
Before XWiki 15.10.9 and 16.2.0 the edited content was not re-rendered for all the users in the editing sesesion, but only for the user that inserted the macro. This means that in order to reproduce the problem the other user had to insert or update a macro or save and view the content.
Patches
This vulnerability has been patched in XWiki 15.10.12, 16.4.1 and 16.6.0-rc-1.
Workarounds
To avoid this vulnerability you can:
- either disable the realtime WYSIWYG editing by disabling the
xwiki-realtimeCKEditor plugin from the WYSIWYG editor administration section - or uninstall the Realtime WYSIWYG Editor extension (org.xwiki.platform:xwiki-platform-realtime-wysiwyg-ui)
References
- https://jira.xwiki.org/browse/XWIKI-21949
For more information
If you have any questions or comments about this advisory:
- Open an issue in Jira XWiki.org
- Email us at Security Mailing List
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-realtime-wysiwyg-ui"
},
"ranges": [
{
"events": [
{
"introduced": "13.9-rc-1"
},
{
"fixed": "15.10.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-realtime-wysiwyg-ui"
},
"ranges": [
{
"events": [
{
"introduced": "16.0.0-rc-1"
},
{
"fixed": "16.4.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-realtime-wysiwyg-ui"
},
"ranges": [
{
"events": [
{
"introduced": "16.5.0-rc-1"
},
{
"fixed": "16.6.0-rc-1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-23025"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2025-01-14T16:00:36Z",
"nvd_published_at": "2025-01-14T18:16:05Z",
"severity": "CRITICAL"
},
"details": "### Impact\n\nNOTE: The [Realtime WYSIWYG Editor](https://extensions.xwiki.org/xwiki/bin/view/Extension/Realtime%20WYSIWYG%20Editor/) extension was **experimental**, and thus **not recommended**, in the versions affected by this vulnerability. It has become enabled by default, and thus recommended, starting with XWiki 16.9.0.\n\nA user with only **edit right** can join a realtime editing session where others, that where already there or that may join later, have **script** or **programming** access rights. This user can then insert **script rendering macros** that are executed for those users in the realtime session that have script or programming rights. The inserted scripts can be used to gain more access rights.\n\nHere\u0027s an example that works with XWiki 15.10.9+ and 16.2.0+:\n\n* the attacker starts editing a wiki page in realtime (for which they have edit right)\n* another user, with script or programming access right joins the editing session (e.g. by clicking on a link / URL provided by the attacker)\n* the attacker inserts a script rendering macro, say ``{{velocity}}I can run scripts{{/velocity}}``, in the edited content, using the WYSIWYG editor UI\n* the edited content is reloaded for both the attacker and the other user, in order to render the inserted macro\n * the attacker gets a rendering error message\n * the other user sees \"I can run scripts\"\n\nThe attacker can obviously use more advanced scripts to gain access rights.\n\nBefore XWiki 15.10.9 and 16.2.0 the edited content was not re-rendered for all the users in the editing sesesion, but only for the user that inserted the macro. This means that in order to reproduce the problem the other user had to insert or update a macro or save and view the content.\n\n### Patches\n\nThis vulnerability has been patched in XWiki 15.10.12, 16.4.1 and 16.6.0-rc-1.\n\n### Workarounds\n\nTo avoid this vulnerability you can:\n\n* either disable the realtime WYSIWYG editing by disabling the ``xwiki-realtime`` CKEditor plugin from [the WYSIWYG editor administration section](https://extensions.xwiki.org/xwiki/bin/view/Extension/CKEditor+Integration#HAdministrationSection)\n* or uninstall the [Realtime WYSIWYG Editor](https://extensions.xwiki.org/xwiki/bin/view/Extension/Realtime%20WYSIWYG%20Editor/) extension (org.xwiki.platform:xwiki-platform-realtime-wysiwyg-ui)\n\n### References\n\n* https://jira.xwiki.org/browse/XWIKI-21949\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n* Open an issue in [Jira XWiki.org](https://jira.xwiki.org/)\n* Email us at [Security Mailing List](mailto:security@xwiki.org)",
"id": "GHSA-rmm7-r7wr-xpfg",
"modified": "2025-01-14T21:20:22Z",
"published": "2025-01-14T16:00:36Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-rmm7-r7wr-xpfg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23025"
},
{
"type": "WEB",
"url": "https://extensions.xwiki.org/xwiki/bin/view/Extension/CKEditor+Integration#HAdministrationSection"
},
{
"type": "WEB",
"url": "https://extensions.xwiki.org/xwiki/bin/view/Extension/Realtime%20WYSIWYG%20Editor"
},
{
"type": "PACKAGE",
"url": "https://github.com/xwiki/xwiki-platform"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-21949"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "XWiki Realtime WYSIWYG Editor extension allows privilege escalation (PR) through realtime WYSIWYG editing"
}
GHSA-RMMJ-G3W6-W438
Vulnerability from github – Published: 2024-04-08 03:30 – Updated: 2024-11-27 18:34In Network Adapter Service, there is a possible missing permission check. This could lead to local denial of service with no additional execution privileges needed
{
"affected": [],
"aliases": [
"CVE-2023-52352"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-08T03:15:08Z",
"severity": "MODERATE"
},
"details": "In Network Adapter Service, there is a possible missing permission check. This could lead to local denial of service with no additional execution privileges needed",
"id": "GHSA-rmmj-g3w6-w438",
"modified": "2024-11-27T18:34:00Z",
"published": "2024-04-08T03:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52352"
},
{
"type": "WEB",
"url": "https://www.unisoc.com/en_us/secy/announcementDetail/1777143682512781313"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-RMPF-5WH7-3VP5
Vulnerability from github – Published: 2025-12-18 09:30 – Updated: 2026-01-20 15:32Missing Authorization vulnerability in ThemeAtelier IDonatePro idonate-pro allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects IDonatePro: from n/a through <= 2.1.11.
{
"affected": [],
"aliases": [
"CVE-2025-60045"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-18T08:16:03Z",
"severity": "HIGH"
},
"details": "Missing Authorization vulnerability in ThemeAtelier IDonatePro idonate-pro allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects IDonatePro: from n/a through \u003c= 2.1.11.",
"id": "GHSA-rmpf-5wh7-3vp5",
"modified": "2026-01-20T15:32:25Z",
"published": "2025-12-18T09:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-60045"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/idonate-pro/vulnerability/wordpress-idonatepro-plugin-2-1-11-broken-access-control-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/idonate-pro/vulnerability/wordpress-idonatepro-plugin-2-1-11-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:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-RMPJ-3X5M-9M5F
Vulnerability from github – Published: 2026-03-16 21:18 – Updated: 2026-03-20 21:19Summary
The documents and files module in Admidio does not verify whether the current user has permission to delete folders or files. The folder_delete and file_delete action handlers in modules/documents-files.php only perform a VIEW authorization check (getFolderForDownload / getFileForDownload) before calling delete(), and they never validate a CSRF token. Because the target UUIDs are read from $_GET, deletion can be triggered by a plain HTTP GET request. When the module is in public mode (documents_files_module_enabled = 1) and a folder is marked public (fol_public = true), an unauthenticated attacker can permanently destroy the entire document library. Even when the module requires login, any user with view-only access can delete content they are only permitted to read.
Details
Module Access Check
File: D:/bugcrowd/admidio/repo/modules/documents-files.php, lines 72-76
The module only blocks unauthenticated access when the setting is 2 (members-only). When the setting is 1 (public), no login is required to reach any action handler:
if ($gSettingsManager->getInt('documents_files_module_enabled') === 0) {
throw new Exception('SYS_MODULE_DISABLED');
} elseif ($gSettingsManager->getInt('documents_files_module_enabled') === 2 && !$gValidLogin) {
throw new Exception('SYS_NO_RIGHTS');
}
Vulnerable Code Path 1: Folder Deletion
File: D:/bugcrowd/admidio/repo/modules/documents-files.php, lines 122-133
case 'folder_delete':
if ($getFolderUUID === '') {
throw new Exception('SYS_INVALID_PAGE_VIEW');
} else {
$folder = new Folder($gDb);
$folder->getFolderForDownload($getFolderUUID); // VIEW check only
$folder->delete(); // no CSRF token, no upload/admin check
echo json_encode(array('status' => 'success'));
}
break;
The target UUID is read exclusively from $_GET at line 64:
$getFolderUUID = admFuncVariableIsValid($_GET, 'folder_uuid', 'uuid', ...);
Vulnerable Code Path 2: File Deletion
File: D:/bugcrowd/admidio/repo/modules/documents-files.php, lines 150-161
case 'file_delete':
if ($getFileUUID === '') {
throw new Exception('SYS_INVALID_PAGE_VIEW');
} else {
$file = new File($gDb);
$file->getFileForDownload($getFileUUID); // VIEW check only
$file->delete(); // no CSRF token, no upload/admin check
echo json_encode(array('status' => 'success'));
}
break;
Same pattern as folder_delete. The file UUID is also read from $_GET (line 69).
getFolderForDownload Grants VIEW Access to Public Folders Without Login
File: D:/bugcrowd/admidio/repo/src/Documents/Entity/Folder.php, lines 432-438
// If the folder is public (and the file is not locked) => allow
if ($this->getValue('fol_public') && !$this->getValue('fol_locked')) {
return true;
}
This is the correct check for granting VIEW access to public folders. It is not an appropriate gate for a destructive delete operation.
Contrast with Other Write Operations (Properly Protected)
All other write operations in documents-files.php route through DocumentsService, which validates the CSRF token via getFormObject($_POST['adm_csrf_token']) before any mutation (DocumentsService.php lines 278, 332, 386, 448). The delete cases bypass this service entirely and receive no equivalent protection.
Folder::delete() Is Recursive and Permanent
File: D:/bugcrowd/admidio/repo/src/Documents/Entity/Folder.php, lines 213-259
Folder::delete() recursively removes all sub-folders and files from both the database and the physical filesystem. There is no soft-delete or trash mechanism. A single call to folder_delete on the root folder permanently destroys the entire document library.
UI Shows Delete Buttons Only to Authorized Users (Not Enforced Server-Side)
File: D:/bugcrowd/admidio/repo/src/UI/Presenter/DocumentsPresenter.php, lines 546, 589
The presenter renders delete action links only when the user has upload rights (hasUploadRight()). This client-side restriction is not enforced server-side. Any HTTP client can send the GET request directly.
PoC
Scenario 1: Unauthenticated deletion of a public folder (zero credentials required)
Prerequisites: documents_files_module_enabled = 1, target folder has fol_public = true.
Step 1: Discover folder UUIDs by fetching the public document list (no login needed):
curl "https://TARGET/adm_program/modules/documents-files.php?mode=list"
Step 2: Delete the entire folder tree permanently:
curl "https://TARGET/adm_program/modules/documents-files.php?mode=folder_delete&folder_uuid=<FOLDER_UUID>"
Expected response: {"status":"success"}
The folder, all its sub-folders, and all their files are permanently removed from the database and filesystem. No authentication or token is required.
Scenario 2: Authenticated view-only member deletes any accessible file
Prerequisites: documents_files_module_enabled = 2 (members-only). Attacker has a regular member account with view rights to the target folder but no upload rights.
curl "https://TARGET/adm_program/modules/documents-files.php?mode=file_delete&file_uuid=<FILE_UUID>" \
-H "Cookie: ADMIDIO_SESSION_ID=<view_only_session>"
Expected response: {"status":"success"}
Scenario 3: Cross-site GET CSRF via image tag
Because deletion uses a plain GET request with no token, an attacker can embed the following in any HTML email or web page. When a logged-in Admidio member views the page, their browser fetches the URL with the session cookie attached:
<img src="https://TARGET/adm_program/modules/documents-files.php?mode=folder_delete&folder_uuid=<UUID>" width="1" height="1">
Impact
- Unauthenticated Data Destruction: When the module is in public mode and any folder is marked public, an unauthenticated remote attacker can permanently delete any or all documents and folders. No credentials or tokens are required.
- Privilege Escalation (View to Delete): Any logged-in member with view-only access can delete content they are only permitted to read, bypassing the
hasUploadRight()permission boundary. - Cross-Site CSRF: Because UUIDs appear in page URLs visible to authenticated users, an attacker can embed a GET-based CSRF payload in phishing content to trigger deletion on behalf of any victim.
- No Recovery Path:
Folder::delete()andFile::delete()are permanent operations. The only recovery is from a database and filesystem backup. - Full Organizational Impact: Deletion of the root documents folder recursively removes the entire document library of the organization.
Recommended Fix
Fix 1: Add authorization check and CSRF token validation to both delete handlers
case 'folder_delete':
SecurityUtils::validateCsrfToken($_POST['adm_csrf_token']);
if ($getFolderUUID === '') {
throw new Exception('SYS_INVALID_PAGE_VIEW');
}
$folder = new Folder($gDb);
$folder->getFolderForDownload($getFolderUUID);
if (!$gCurrentUser->isAdministratorDocumentsFiles() && !$folder->hasUploadRight()) {
throw new Exception('SYS_NO_RIGHTS');
}
$folder->delete();
echo json_encode(array('status' => 'success'));
break;
case 'file_delete':
SecurityUtils::validateCsrfToken($_POST['adm_csrf_token']);
if ($getFileUUID === '') {
throw new Exception('SYS_INVALID_PAGE_VIEW');
}
$file = new File($gDb);
$file->getFileForDownload($getFileUUID);
$parentFolder = new Folder($gDb);
$parentFolder->readDataById((int)$file->getValue('fil_fol_id'));
if (!$gCurrentUser->isAdministratorDocumentsFiles() && !$parentFolder->hasUploadRight()) {
throw new Exception('SYS_NO_RIGHTS');
}
$file->delete();
echo json_encode(array('status' => 'success'));
break;
Fix 2: Move folder_uuid and file_uuid to POST parameters for delete operations
Reading the UUID from $_GET enables GET-based CSRF. Moving to $_POST and validating the CSRF token together closes both issues simultaneously.
{
"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-32817"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-16T21:18:10Z",
"nvd_published_at": "2026-03-20T02:16:35Z",
"severity": "CRITICAL"
},
"details": "## Summary\n\nThe documents and files module in Admidio does not verify whether the current user has permission to delete folders or files. The `folder_delete` and `file_delete` action handlers in `modules/documents-files.php` only perform a VIEW authorization check (`getFolderForDownload` / `getFileForDownload`) before calling `delete()`, and they never validate a CSRF token. Because the target UUIDs are read from `$_GET`, deletion can be triggered by a plain HTTP GET request. When the module is in public mode (`documents_files_module_enabled = 1`) and a folder is marked public (`fol_public = true`), an unauthenticated attacker can permanently destroy the entire document library. Even when the module requires login, any user with view-only access can delete content they are only permitted to read.\n\n## Details\n\n### Module Access Check\n\nFile: `D:/bugcrowd/admidio/repo/modules/documents-files.php`, lines 72-76\n\nThe module only blocks unauthenticated access when the setting is 2 (members-only). When the setting is 1 (public), no login is required to reach any action handler:\n\n```php\nif ($gSettingsManager-\u003egetInt(\u0027documents_files_module_enabled\u0027) === 0) {\n throw new Exception(\u0027SYS_MODULE_DISABLED\u0027);\n} elseif ($gSettingsManager-\u003egetInt(\u0027documents_files_module_enabled\u0027) === 2 \u0026\u0026 !$gValidLogin) {\n throw new Exception(\u0027SYS_NO_RIGHTS\u0027);\n}\n```\n\n### Vulnerable Code Path 1: Folder Deletion\n\nFile: `D:/bugcrowd/admidio/repo/modules/documents-files.php`, lines 122-133\n\n```php\ncase \u0027folder_delete\u0027:\n if ($getFolderUUID === \u0027\u0027) {\n throw new Exception(\u0027SYS_INVALID_PAGE_VIEW\u0027);\n } else {\n $folder = new Folder($gDb);\n $folder-\u003egetFolderForDownload($getFolderUUID); // VIEW check only\n\n $folder-\u003edelete(); // no CSRF token, no upload/admin check\n echo json_encode(array(\u0027status\u0027 =\u003e \u0027success\u0027));\n }\n break;\n```\n\nThe target UUID is read exclusively from `$_GET` at line 64:\n\n```php\n$getFolderUUID = admFuncVariableIsValid($_GET, \u0027folder_uuid\u0027, \u0027uuid\u0027, ...);\n```\n\n### Vulnerable Code Path 2: File Deletion\n\nFile: `D:/bugcrowd/admidio/repo/modules/documents-files.php`, lines 150-161\n\n```php\ncase \u0027file_delete\u0027:\n if ($getFileUUID === \u0027\u0027) {\n throw new Exception(\u0027SYS_INVALID_PAGE_VIEW\u0027);\n } else {\n $file = new File($gDb);\n $file-\u003egetFileForDownload($getFileUUID); // VIEW check only\n\n $file-\u003edelete(); // no CSRF token, no upload/admin check\n echo json_encode(array(\u0027status\u0027 =\u003e \u0027success\u0027));\n }\n break;\n```\n\nSame pattern as `folder_delete`. The file UUID is also read from `$_GET` (line 69).\n\n### getFolderForDownload Grants VIEW Access to Public Folders Without Login\n\nFile: `D:/bugcrowd/admidio/repo/src/Documents/Entity/Folder.php`, lines 432-438\n\n```php\n// If the folder is public (and the file is not locked) =\u003e allow\nif ($this-\u003egetValue(\u0027fol_public\u0027) \u0026\u0026 !$this-\u003egetValue(\u0027fol_locked\u0027)) {\n return true;\n}\n```\n\nThis is the correct check for granting VIEW access to public folders. It is not an appropriate gate for a destructive delete operation.\n\n### Contrast with Other Write Operations (Properly Protected)\n\nAll other write operations in `documents-files.php` route through `DocumentsService`, which validates the CSRF token via `getFormObject($_POST[\u0027adm_csrf_token\u0027])` before any mutation (DocumentsService.php lines 278, 332, 386, 448). The delete cases bypass this service entirely and receive no equivalent protection.\n\n### Folder::delete() Is Recursive and Permanent\n\nFile: `D:/bugcrowd/admidio/repo/src/Documents/Entity/Folder.php`, lines 213-259\n\n`Folder::delete()` recursively removes all sub-folders and files from both the database and the physical filesystem. There is no soft-delete or trash mechanism. A single call to `folder_delete` on the root folder permanently destroys the entire document library.\n\n### UI Shows Delete Buttons Only to Authorized Users (Not Enforced Server-Side)\n\nFile: `D:/bugcrowd/admidio/repo/src/UI/Presenter/DocumentsPresenter.php`, lines 546, 589\n\nThe presenter renders delete action links only when the user has upload rights (`hasUploadRight()`). This client-side restriction is not enforced server-side. Any HTTP client can send the GET request directly.\n\n## PoC\n\n**Scenario 1: Unauthenticated deletion of a public folder (zero credentials required)**\n\nPrerequisites: `documents_files_module_enabled = 1`, target folder has `fol_public = true`.\n\nStep 1: Discover folder UUIDs by fetching the public document list (no login needed):\n\n```\ncurl \"https://TARGET/adm_program/modules/documents-files.php?mode=list\"\n```\n\nStep 2: Delete the entire folder tree permanently:\n\n```\ncurl \"https://TARGET/adm_program/modules/documents-files.php?mode=folder_delete\u0026folder_uuid=\u003cFOLDER_UUID\u003e\"\n```\n\nExpected response: `{\"status\":\"success\"}`\n\nThe folder, all its sub-folders, and all their files are permanently removed from the database and filesystem. No authentication or token is required.\n\n**Scenario 2: Authenticated view-only member deletes any accessible file**\n\nPrerequisites: `documents_files_module_enabled = 2` (members-only). Attacker has a regular member account with view rights to the target folder but no upload rights.\n\n```\ncurl \"https://TARGET/adm_program/modules/documents-files.php?mode=file_delete\u0026file_uuid=\u003cFILE_UUID\u003e\" \\\n -H \"Cookie: ADMIDIO_SESSION_ID=\u003cview_only_session\u003e\"\n```\n\nExpected response: `{\"status\":\"success\"}`\n\n**Scenario 3: Cross-site GET CSRF via image tag**\n\nBecause deletion uses a plain GET request with no token, an attacker can embed the following in any HTML email or web page. When a logged-in Admidio member views the page, their browser fetches the URL with the session cookie attached:\n\n```html\n\u003cimg src=\"https://TARGET/adm_program/modules/documents-files.php?mode=folder_delete\u0026folder_uuid=\u003cUUID\u003e\" width=\"1\" height=\"1\"\u003e\n```\n\n## Impact\n\n- **Unauthenticated Data Destruction:** When the module is in public mode and any folder is marked public, an unauthenticated remote attacker can permanently delete any or all documents and folders. No credentials or tokens are required.\n- **Privilege Escalation (View to Delete):** Any logged-in member with view-only access can delete content they are only permitted to read, bypassing the `hasUploadRight()` permission boundary.\n- **Cross-Site CSRF:** Because UUIDs appear in page URLs visible to authenticated users, an attacker can embed a GET-based CSRF payload in phishing content to trigger deletion on behalf of any victim.\n- **No Recovery Path:** `Folder::delete()` and `File::delete()` are permanent operations. The only recovery is from a database and filesystem backup.\n- **Full Organizational Impact:** Deletion of the root documents folder recursively removes the entire document library of the organization.\n\n## Recommended Fix\n\n### Fix 1: Add authorization check and CSRF token validation to both delete handlers\n\n```php\ncase \u0027folder_delete\u0027:\n SecurityUtils::validateCsrfToken($_POST[\u0027adm_csrf_token\u0027]);\n if ($getFolderUUID === \u0027\u0027) {\n throw new Exception(\u0027SYS_INVALID_PAGE_VIEW\u0027);\n }\n $folder = new Folder($gDb);\n $folder-\u003egetFolderForDownload($getFolderUUID);\n if (!$gCurrentUser-\u003eisAdministratorDocumentsFiles() \u0026\u0026 !$folder-\u003ehasUploadRight()) {\n throw new Exception(\u0027SYS_NO_RIGHTS\u0027);\n }\n $folder-\u003edelete();\n echo json_encode(array(\u0027status\u0027 =\u003e \u0027success\u0027));\n break;\n\ncase \u0027file_delete\u0027:\n SecurityUtils::validateCsrfToken($_POST[\u0027adm_csrf_token\u0027]);\n if ($getFileUUID === \u0027\u0027) {\n throw new Exception(\u0027SYS_INVALID_PAGE_VIEW\u0027);\n }\n $file = new File($gDb);\n $file-\u003egetFileForDownload($getFileUUID);\n $parentFolder = new Folder($gDb);\n $parentFolder-\u003ereadDataById((int)$file-\u003egetValue(\u0027fil_fol_id\u0027));\n if (!$gCurrentUser-\u003eisAdministratorDocumentsFiles() \u0026\u0026 !$parentFolder-\u003ehasUploadRight()) {\n throw new Exception(\u0027SYS_NO_RIGHTS\u0027);\n }\n $file-\u003edelete();\n echo json_encode(array(\u0027status\u0027 =\u003e \u0027success\u0027));\n break;\n```\n\n### Fix 2: Move folder_uuid and file_uuid to POST parameters for delete operations\n\nReading the UUID from `$_GET` enables GET-based CSRF. Moving to `$_POST` and validating the CSRF token together closes both issues simultaneously.",
"id": "GHSA-rmpj-3x5m-9m5f",
"modified": "2026-03-20T21:19:26Z",
"published": "2026-03-16T21:18:10Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Admidio/admidio/security/advisories/GHSA-rmpj-3x5m-9m5f"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32817"
},
{
"type": "PACKAGE",
"url": "https://github.com/Admidio/admidio"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Admidio is Missing Authorization and CSRF Protection on Document and Folder Deletion"
}
Mitigation
- Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
- Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Mitigation MIT-4.4
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
- For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
- One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
CAPEC-665: Exploitation of Thunderbolt Protection Flaws
An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.