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.
14556 vulnerabilities reference this CWE, most recent first.
GHSA-8C4J-F57C-35CF
Vulnerability from github – Published: 2026-03-27 19:36 – Updated: 2026-03-27 21:52Vulnerability
IDOR in GET/PATCH/DELETE /api/v1/flow/{flow_id}
The _read_flow helper in src/backend/base/langflow/api/v1/flows.py branched on the AUTO_LOGIN setting to decide whether to filter by user_id. When AUTO_LOGIN was False (i.e., authentication was enabled), neither branch enforced an ownership check — the query returned any flow matching the given UUID regardless of who owned it.
This exposed any authenticated user to:
- Read any other user's flow, including embedded plaintext API keys
- Modify the logic of another user's AI agents
- Delete flows belonging to other users
The vulnerability was introduced by the conditional logic that was meant to accommodate public/example flows (those with user_id = NULL) under auto-login mode, but inadvertently left the authenticated path without an ownership filter.
Fix (PR #8956)
The fix removes the AUTO_LOGIN conditional entirely and unconditionally scopes the query to the requesting user:
- auth_settings = settings_service.auth_settings
- stmt = select(Flow).where(Flow.id == flow_id)
- if auth_settings.AUTO_LOGIN:
- stmt = stmt.where(
- (Flow.user_id == user_id) | (Flow.user_id == None) # noqa: E711
- )
+ stmt = select(Flow).where(Flow.id == flow_id).where(Flow.user_id == user_id)
All three operations — read, update, and delete — route through _read_flow, so the single change covers the full attack surface. A cross-user isolation test (test_read_flows_user_isolation) was added to prevent regression.
Acknowledgements
Langflow thanks the security researcher who responsibly disclosed this vulnerability:
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.5.0"
},
"package": {
"ecosystem": "PyPI",
"name": "langflow"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.5.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.5.0"
},
"package": {
"ecosystem": "PyPI",
"name": "langflow-base"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.5.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34046"
],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-27T19:36:23Z",
"nvd_published_at": "2026-03-27T21:17:27Z",
"severity": "HIGH"
},
"details": "## Vulnerability\n\n### IDOR in `GET/PATCH/DELETE /api/v1/flow/{flow_id}`\n\nThe `_read_flow` helper in `src/backend/base/langflow/api/v1/flows.py` branched on the `AUTO_LOGIN` setting to decide whether to filter by `user_id`. When `AUTO_LOGIN` was `False` (i.e., authentication was enabled), neither branch enforced an ownership check \u2014 the query returned any flow matching the given UUID regardless of who owned it.\n\nThis exposed any authenticated user to:\n\n- **Read** any other user\u0027s flow, including embedded plaintext API keys\n- **Modify** the logic of another user\u0027s AI agents\n- **Delete** flows belonging to other users\n\nThe vulnerability was introduced by the conditional logic that was meant to accommodate public/example flows (those with `user_id = NULL`) under auto-login mode, but inadvertently left the authenticated path without an ownership filter.\n\n---\n\n## Fix (PR #8956)\n\nThe fix removes the `AUTO_LOGIN` conditional entirely and unconditionally scopes the query to the requesting user:\n\n```diff\n- auth_settings = settings_service.auth_settings\n- stmt = select(Flow).where(Flow.id == flow_id)\n- if auth_settings.AUTO_LOGIN:\n- stmt = stmt.where(\n- (Flow.user_id == user_id) | (Flow.user_id == None) # noqa: E711\n- )\n+ stmt = select(Flow).where(Flow.id == flow_id).where(Flow.user_id == user_id)\n```\n\nAll three operations \u2014 read, update, and delete \u2014 route through `_read_flow`, so the single change covers the full attack surface. A cross-user isolation test (`test_read_flows_user_isolation`) was added to prevent regression.\n\n---\n\n## Acknowledgements\n\nLangflow thanks the security researcher who responsibly disclosed this vulnerability:\n\n- **[@chximn-dt](https://github.com/chximn-dt)**",
"id": "GHSA-8c4j-f57c-35cf",
"modified": "2026-03-27T21:52:39Z",
"published": "2026-03-27T19:36:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/langflow-ai/langflow/security/advisories/GHSA-8c4j-f57c-35cf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34046"
},
{
"type": "WEB",
"url": "https://github.com/langflow-ai/langflow/pull/8956"
},
{
"type": "PACKAGE",
"url": "https://github.com/langflow-ai/langflow"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Langflow: Authenticated Users Can Read, Modify, and Delete Any Flow via Missing Ownership Check"
}
GHSA-8C4X-5XX5-W877
Vulnerability from github – Published: 2022-05-24 19:08 – Updated: 2022-05-24 19:08SAP NetWeaver Guided Procedures (Administration Workset), versions - 7.10, 7.20, 7.30, 7.31, 7.40, 7.50, does not perform necessary authorization checks for an authenticated user, resulting in escalation of privileges. The impact of missing authorization could result to abuse of functionality restricted to a particular user group, and could allow unauthorized users to read, modify or delete restricted data.
{
"affected": [],
"aliases": [
"CVE-2021-33671"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-07-14T12:15:00Z",
"severity": "HIGH"
},
"details": "SAP NetWeaver Guided Procedures (Administration Workset), versions - 7.10, 7.20, 7.30, 7.31, 7.40, 7.50, does not perform necessary authorization checks for an authenticated user, resulting in escalation of privileges. The impact of missing authorization could result to abuse of functionality restricted to a particular user group, and could allow unauthorized users to read, modify or delete restricted data.",
"id": "GHSA-8c4x-5xx5-w877",
"modified": "2022-05-24T19:08:04Z",
"published": "2022-05-24T19:08:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33671"
},
{
"type": "WEB",
"url": "https://launchpad.support.sap.com/#/notes/3059446"
},
{
"type": "WEB",
"url": "https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=580617506"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-8C52-X9W7-VC95
Vulnerability from github – Published: 2025-11-18 19:02 – Updated: 2025-11-19 18:59Summary
A user with no view rights on a page may see the content of an office attachment displayed with the view file macro.
Details
If on a public page is displayed an office attachment from a restricted page, a user with no view rights on the restricted page can view the attachment content, no matter the display type used.
PoC
- Install and activate the Pro Macros application
- Create a page and limit the view rights for a test user
- Add an attachment to the restricted page
- Create a new public page
- Add the view file macro and select the attachment from the restricted page using any display type
- Login as the test user with restricted view rights
- The user will see the content despite having no view rights
Workarounds
None
Impact
Private data can be leaked if a user knows the reference to an attachment and has edit rights on a page.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.26.20"
},
"package": {
"ecosystem": "Maven",
"name": "com.xwiki.pro:xwiki-pro-macros-ui"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.27.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-65089"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2025-11-18T19:02:15Z",
"nvd_published_at": "2025-11-19T18:15:51Z",
"severity": "MODERATE"
},
"details": "### Summary\nA user with no view rights on a page may see the content of an office attachment displayed with the view file macro.\n\n### Details\nIf on a public page is displayed an office attachment from a restricted page, a user with no view rights on the restricted page can view the attachment content, no matter the display type used.\n\n### PoC\n1. Install and activate the Pro Macros application\n2. Create a page and limit the view rights for a test user\n3. Add an attachment to the restricted page\n4. Create a new public page\n5. Add the view file macro and select the attachment from the restricted page using any display type\n6. Login as the test user with restricted view rights\n7. The user will see the content despite having no view rights\n\n### Workarounds\nNone\n\n### Impact\nPrivate data can be leaked if a user knows the reference to an attachment and has edit rights on a page.",
"id": "GHSA-8c52-x9w7-vc95",
"modified": "2025-11-19T18:59:58Z",
"published": "2025-11-18T19:02:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xwikisas/xwiki-pro-macros/security/advisories/GHSA-8c52-x9w7-vc95"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-65089"
},
{
"type": "PACKAGE",
"url": "https://github.com/xwikisas/xwiki-pro-macros"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "XWiki view file macro: User can view content of office file without view rights on the attachment "
}
GHSA-8C5M-67FX-9Q72
Vulnerability from github – Published: 2023-07-06 19:24 – Updated: 2024-04-04 05:34The WordPress Shortcodes Plugin — Shortcodes Ultimate WordPress plugin before 5.12.8 does not validate the user meta to be retrieved via the user shortcode, allowing any authenticated users such as subscriber to retrieve arbitrary user meta (except the user_pass), such as the user email and activation key by default.
{
"affected": [],
"aliases": [
"CVE-2023-0911"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-03-20T16:15:00Z",
"severity": "MODERATE"
},
"details": "The WordPress Shortcodes Plugin \u2014 Shortcodes Ultimate WordPress plugin before 5.12.8 does not validate the user meta to be retrieved via the user shortcode, allowing any authenticated users such as subscriber to retrieve arbitrary user meta (except the user_pass), such as the user email and activation key by default.",
"id": "GHSA-8c5m-67fx-9q72",
"modified": "2024-04-04T05:34:44Z",
"published": "2023-07-06T19:24:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0911"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/35404d16-7213-4293-ac0d-926bd6c17444"
}
],
"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"
}
]
}
GHSA-8C6H-7G6X-M5X4
Vulnerability from github – Published: 2026-06-23 22:27 – Updated: 2026-06-23 22:27Missing Authorization in API CategoryController — CVE-2026-24421 fixed BackupController by adding userHasPermission(PermissionType::BACKUP). The same fix was NOT applied to 4 other write endpoints in the public API. All 4 only call hasValidToken() (shared API key) but never call userHasPermission(), allowing any API token holder to perform admin operations regardless of their user permissions.
Summary
CVE-2026-24421 fixed BackupController by adding: $this->userHasPermission(PermissionType::BACKUP);
The same fix was NOT applied to 4 other write endpoints in the public API. All 4 only call $this->hasValidToken() — which checks a shared API key header, NOT the individual user's role permissions.
Affected Endpoints
-
src/phpMyFAQ/Controller/Api/CategoryController.php → create() POST /api/v4.0/category Missing: userHasPermission(PermissionType::CATEGORY_ADD) Any API token holder can create categories regardless of user role.
-
src/phpMyFAQ/Controller/Api/FaqController.php → create() POST /api/v4.0/faq Missing: userHasPermission(PermissionType::FAQ_ADD) Any API token holder can create FAQ entries regardless of user role.
-
src/phpMyFAQ/Controller/Api/FaqController.php → update() PUT /api/v4.0/faq Missing: userHasPermission(PermissionType::FAQ_EDIT) Any API token holder can update any FAQ entry regardless of user role.
-
src/phpMyFAQ/Controller/Api/QuestionController.php → create() POST /api/v4.0/question Missing: permission check Any API token holder can create questions regardless of user role.
Root Cause
All 4 methods only call: $this->hasValidToken(); ← shared API key, not per-user
The fixed BackupController correctly calls: $this->userHasPermission(PermissionType::BACKUP);
PermissionType::CATEGORY_ADD, FAQ_ADD, FAQ_EDIT all exist in src/phpMyFAQ/Enums/PermissionType.php — they just are not being used.
Fix
Add userHasPermission() before the logic in each method:
// CategoryController.create()
$this->userHasPermission(PermissionType::CATEGORY_ADD);
// FaqController.create()
$this->userHasPermission(PermissionType::FAQ_ADD);
// FaqController.update()
$this->userHasPermission(PermissionType::FAQ_EDIT);
Reporter
CONTACT Santhoshini Ganta Github:@santhoshinipayload Email: santhoshinive75@gmail.com LinkedIn: http://linkedin.com/in/santhoshini-g-1440621ba
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "thorsten/phpmyfaq"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "phpmyfaq/phpmyfaq"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-49205"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-23T22:27:34Z",
"nvd_published_at": "2026-06-18T22:16:31Z",
"severity": "MODERATE"
},
"details": "Missing Authorization in API CategoryController \u2014 CVE-2026-24421 fixed BackupController by adding userHasPermission(PermissionType::BACKUP). The same fix was NOT applied to 4 other write endpoints in the public API. All 4 only call hasValidToken() (shared API key) but never call userHasPermission(), allowing any API token holder to perform admin operations regardless of their user permissions.\n\n## Summary\n\nCVE-2026-24421 fixed BackupController by adding: $this-\u003euserHasPermission(PermissionType::BACKUP);\n\nThe same fix was NOT applied to 4 other write endpoints in the public API. All 4 only call $this-\u003ehasValidToken() \u2014 which checks a shared API key header, NOT the individual user\u0027s role permissions.\n\n## Affected Endpoints\n\n1. src/phpMyFAQ/Controller/Api/CategoryController.php \u2192 create() POST /api/v4.0/category\nMissing: userHasPermission(PermissionType::CATEGORY_ADD)\nAny API token holder can create categories regardless of user role.\n\n2. src/phpMyFAQ/Controller/Api/FaqController.php \u2192 create() POST /api/v4.0/faq\n Missing: userHasPermission(PermissionType::FAQ_ADD)\n Any API token holder can create FAQ entries regardless of user role.\n\n3. src/phpMyFAQ/Controller/Api/FaqController.php \u2192 update() PUT /api/v4.0/faq\n Missing: userHasPermission(PermissionType::FAQ_EDIT)\n Any API token holder can update any FAQ entry regardless of user role.\n\n4. src/phpMyFAQ/Controller/Api/QuestionController.php \u2192 create() POST /api/v4.0/question\n Missing: permission check\n Any API token holder can create questions regardless of user role.\n\n## Root Cause\n\nAll 4 methods only call:\n $this-\u003ehasValidToken(); \u2190 shared API key, not per-user\n\nThe fixed BackupController correctly calls:\n $this-\u003euserHasPermission(PermissionType::BACKUP); \n\nPermissionType::CATEGORY_ADD, FAQ_ADD, FAQ_EDIT all exist in src/phpMyFAQ/Enums/PermissionType.php \u2014 they just are not being used.\n\n## Fix\n\nAdd userHasPermission() before the logic in each method:\n\n // CategoryController.create()\n $this-\u003euserHasPermission(PermissionType::CATEGORY_ADD);\n\n // FaqController.create()\n $this-\u003euserHasPermission(PermissionType::FAQ_ADD);\n\n // FaqController.update()\n $this-\u003euserHasPermission(PermissionType::FAQ_EDIT);\n\n## Reporter\n\nCONTACT\nSanthoshini Ganta\nGithub:@santhoshinipayload\nEmail: santhoshinive75@gmail.com\nLinkedIn: http://linkedin.com/in/santhoshini-g-1440621ba",
"id": "GHSA-8c6h-7g6x-m5x4",
"modified": "2026-06-23T22:27:34Z",
"published": "2026-06-23T22:27:34Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/thorsten/phpMyFAQ/security/advisories/GHSA-8c6h-7g6x-m5x4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49205"
},
{
"type": "WEB",
"url": "https://github.com/thorsten/phpMyFAQ/commit/d5c195b1ecf5dc30fb825d7eb50d22481c24cb07"
},
{
"type": "PACKAGE",
"url": "https://github.com/thorsten/phpMyFAQ"
}
],
"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"
}
],
"summary": "phpMyFAQ: Missing userHasPermission() in 4 API write endpoints (CVE-2026-24421 Incomplete Fix)"
}
GHSA-8C6J-52Q3-W3C5
Vulnerability from github – Published: 2024-04-30 03:30 – Updated: 2024-04-30 03:30The LeadConnector plugin for WordPress is vulnerable to unauthorized modification & loss of data due to a missing capability check on the lc_public_api_proxy() function in all versions up to, and including, 1.7. This makes it possible for unauthenticated attackers to delete arbitrary posts.
{
"affected": [],
"aliases": [
"CVE-2024-1371"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-30T03:15:06Z",
"severity": "MODERATE"
},
"details": "The LeadConnector plugin for WordPress is vulnerable to unauthorized modification \u0026 loss of data due to a missing capability check on the lc_public_api_proxy() function in all versions up to, and including, 1.7. This makes it possible for unauthenticated attackers to delete arbitrary posts.",
"id": "GHSA-8c6j-52q3-w3c5",
"modified": "2024-04-30T03:30:48Z",
"published": "2024-04-30T03:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1371"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/leadconnector/trunk/admin/class-lc-admin.php#L519"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3075667%40leadconnector\u0026new=3075667%40leadconnector\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/79e786ce-a3eb-40df-8dad-4c9c75243bec?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-8C7Q-86FQ-VVMH
Vulnerability from github – Published: 2026-05-26 13:30 – Updated: 2026-06-30 16:48A vulnerability in MLflow versions <=3.10.1.dev0 allows unauthorized access to multipart upload (MPU) endpoints when the --serve-artifacts mode is enabled. The authorization logic does not enforce resource-level permission checks for /mlflow-artifacts/mpu/* endpoints, enabling attackers to overwrite artifacts belonging to other users. This can lead to unauthorized cross-user writes, model supply chain poisoning, and arbitrary code execution when compromised models are loaded. The issue is resolved in version 3.10.0.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c 3.11.0rc0"
},
"package": {
"ecosystem": "PyPI",
"name": "mlflow"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.11.0rc1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-2651"
],
"database_specific": {
"cwe_ids": [
"CWE-1220",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-30T16:48:21Z",
"nvd_published_at": "2026-05-25T07:16:15Z",
"severity": "CRITICAL"
},
"details": "A vulnerability in MLflow versions \u003c=3.10.1.dev0 allows unauthorized access to multipart upload (MPU) endpoints when the `--serve-artifacts` mode is enabled. The authorization logic does not enforce resource-level permission checks for `/mlflow-artifacts/mpu/*` endpoints, enabling attackers to overwrite artifacts belonging to other users. This can lead to unauthorized cross-user writes, model supply chain poisoning, and arbitrary code execution when compromised models are loaded. The issue is resolved in version 3.10.0.",
"id": "GHSA-8c7q-86fq-vvmh",
"modified": "2026-06-30T16:48:21Z",
"published": "2026-05-26T13:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2651"
},
{
"type": "WEB",
"url": "https://github.com/mlflow/mlflow/commit/d7290811d8f3c95366d80109424edc1fb1ad966f"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-2651"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2481117"
},
{
"type": "PACKAGE",
"url": "https://github.com/mlflow/mlflow"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/65beb119-d3e0-4e03-af2f-fa98f78f83dc"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-2651.json"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "MLflow allows unauthorized access to multipart upload endpoints when the `--serve-artifacts` mode is enabled"
}
GHSA-8C7R-XV8H-MF68
Vulnerability from github – Published: 2025-04-03 15:31 – Updated: 2026-04-01 18:34Missing Authorization vulnerability in Web Ready Now WR Price List Manager For Woocommerce allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects WR Price List Manager For Woocommerce: from n/a through 1.0.8.
{
"affected": [],
"aliases": [
"CVE-2025-31794"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-03T14:15:39Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Web Ready Now WR Price List Manager For Woocommerce allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects WR Price List Manager For Woocommerce: from n/a through 1.0.8.",
"id": "GHSA-8c7r-xv8h-mf68",
"modified": "2026-04-01T18:34:27Z",
"published": "2025-04-03T15:31:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31794"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/wr-price-list-for-woocommerce/vulnerability/wordpress-wr-price-list-manager-for-woocommerce-plugin-1-0-8-arbitrary-content-deletion-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-8CF7-2X37-PGQ8
Vulnerability from github – Published: 2023-03-21 21:30 – Updated: 2023-03-30 21:30Missing MAC layer security in Silicon Labs Wi-SUN SDK v1.5.0 and earlier allows malicious node to route malicious messages through network.
{
"affected": [],
"aliases": [
"CVE-2023-1261"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-03-21T21:15:00Z",
"severity": "MODERATE"
},
"details": "Missing MAC layer security in Silicon Labs Wi-SUN SDK v1.5.0 and earlier allows malicious node to route malicious messages through network.",
"id": "GHSA-8cf7-2x37-pgq8",
"modified": "2023-03-30T21:30:22Z",
"published": "2023-03-21T21:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1261"
},
{
"type": "WEB",
"url": "https://community.silabs.com/sfc/servlet.shepherd/document/download/0698Y00000SMyfRQAT?operationContext=S1"
},
{
"type": "WEB",
"url": "https://github.com/SiliconLabs/gecko_sdk"
}
],
"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-8CH6-9X8R-R468
Vulnerability from github – Published: 2023-12-14 15:30 – Updated: 2023-12-14 15:30Sensitive information disclosure and manipulation due to missing authorization. The following products are affected: Acronis Cyber Protect Cloud Agent (Windows) before build 36943.
{
"affected": [],
"aliases": [
"CVE-2023-48676"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-14T14:15:43Z",
"severity": "LOW"
},
"details": "Sensitive information disclosure and manipulation due to missing authorization. The following products are affected: Acronis Cyber Protect Cloud Agent (Windows) before build 36943.",
"id": "GHSA-8ch6-9x8r-r468",
"modified": "2023-12-14T15:30:22Z",
"published": "2023-12-14T15:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-48676"
},
{
"type": "WEB",
"url": "https://security-advisory.acronis.com/advisories/SEC-5905"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
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.