CWE-639
AllowedAuthorization Bypass Through User-Controlled Key
Abstraction: Base · Status: Incomplete
The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
4004 vulnerabilities reference this CWE, most recent first.
GHSA-X398-2RGF-67P8
Vulnerability from github – Published: 2026-02-11 12:30 – Updated: 2026-02-11 12:30GitLab has remediated an issue in GitLab EE affecting all versions from 16.7 before 18.6.6, 18.7 before 18.7.4, and 18.8 before 18.8.4 that, under certain conditions could have allowed an authenticated user to access iteration data from private descendant groups by querying the iterations API endpoint.
{
"affected": [],
"aliases": [
"CVE-2026-1080"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-11T12:16:04Z",
"severity": "MODERATE"
},
"details": "GitLab has remediated an issue in GitLab EE affecting all versions from 16.7 before 18.6.6, 18.7 before 18.7.4, and 18.8 before 18.8.4 that, under certain conditions could have allowed an authenticated user to access iteration data from private descendant groups by querying the iterations API endpoint.",
"id": "GHSA-x398-2rgf-67p8",
"modified": "2026-02-11T12:30:22Z",
"published": "2026-02-11T12:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1080"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/3484568"
},
{
"type": "WEB",
"url": "https://about.gitlab.com/releases/2026/02/10/patch-release-gitlab-18-8-4-released"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/586477"
}
],
"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-X39X-RWWC-FP3F
Vulnerability from github – Published: 2024-11-09 06:30 – Updated: 2024-11-09 06:30The SKT Addons for Elementor plugin for WordPress is vulnerable to Information Exposure in all versions up to, and including, 3.3 via the Unfold widget due to insufficient restrictions on which posts can be included. This makes it possible for authenticated attackers, with Contributor-level access and above, to extract data from private or draft posts created by Elementor that they should not have access to.
{
"affected": [],
"aliases": [
"CVE-2024-10693"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-09T04:15:04Z",
"severity": "MODERATE"
},
"details": "The SKT Addons for Elementor plugin for WordPress is vulnerable to Information Exposure in all versions up to, and including, 3.3 via the Unfold widget due to insufficient restrictions on which posts can be included. This makes it possible for authenticated attackers, with Contributor-level access and above, to extract data from private or draft posts created by Elementor that they should not have access to.",
"id": "GHSA-x39x-rwwc-fp3f",
"modified": "2024-11-09T06:30:25Z",
"published": "2024-11-09T06:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10693"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3183804%40skt-addons-for-elementor\u0026new=3183804%40skt-addons-for-elementor\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/8accf552-f235-46dd-857b-330eef7765a0?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-X3QM-P8HR-3C3H
Vulnerability from github – Published: 2026-05-14 20:27 – Updated: 2026-05-19 16:00Summary
The API /api/v1/notes/{note_id} endpoint lacks proper authorization checks, allowing authenticated users to retrieve notes belonging to other users by guessing or enumerating UUIDs. This results in unauthorized disclosure of potentially sensitive or private user data.
Details
- if notes is enabled from UI (Settings >> General >> Features >> Notes (Beta))
- From API, attacker can access other user notes
- if notes is disabled from UI (Settings >> General >> Features >> Notes (Beta))
- Then attacker can enable the notes from /api/config and access other user notes
PoC
-
Step 1: Log in to the application as a valid user (User A).
-
Step 2: Intercept or inspect the response from the endpoint GET /api/config.
-
Step 3: Observe the field "enable_notes": false in the JSON response.
-
Step 4: Manually change "enable_notes" to true using browser DevTools or by intercepting and modifying the response via a proxy like Burp Suite. (Please note, the occurrence of this API comes twice, hence modification needs to be made twice as well.)
-
Step 5: Observe the loaded frontend application; the previously hidden notes form will now be visible.
- Step 6: Again, click on any note, intercept the request, and Replace the note_id in the URL with a different note ID known to belong to another user (e.g., by guessing or bruteforcing).
- Step 7: Send the modified request while remaining logged in as User A.
- Step 8: Observe that the server returns the content of another user's note, confirming unauthorized access.
Impact
- Unauthorized access to user-created notes
- Possible exposure of confidential or sensitive uploaded data
- Violation of user privacy and data isolation
- High risk of legal or compliance breaches in regulated environments
Resolution
Fixed in commit de3317e26, first released in v0.8.11 (Mar 2026). All per-id note endpoints (GET /api/v1/notes/{id}, POST /api/v1/notes/{id}/update, POST /api/v1/notes/{id}/access/update, deletion) now enforce ownership: the handler fetches the note, then requires the caller to be admin, the note owner, or have an AccessGrants grant for the appropriate permission (read for retrieval, write for mutation). A non-owner with no grant receives 403.
Users on >= 0.8.11 are not affected.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.8.10"
},
"package": {
"ecosystem": "PyPI",
"name": "open-webui"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.8.11"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-45666"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-14T20:27:56Z",
"nvd_published_at": "2026-05-15T22:16:56Z",
"severity": "MODERATE"
},
"details": "### Summary\nThe API /api/v1/notes/{note_id} endpoint lacks proper authorization checks, allowing authenticated users to retrieve notes belonging to other users by guessing or enumerating UUIDs. This results in unauthorized disclosure of potentially sensitive or private user data.\n\n### Details\n- if notes is enabled from UI (Settings \u003e\u003e General \u003e\u003e Features \u003e\u003e Notes (Beta))\n - From API, attacker can access other user notes\n- if notes is disabled from UI (Settings \u003e\u003e General \u003e\u003e Features \u003e\u003e Notes (Beta))\n - Then attacker can enable the notes from /api/config and access other user notes \n\n### PoC\n- Step 1: Log in to the application as a valid user (User A).\n\n\n- Step 2: Intercept or inspect the response from the endpoint GET /api/config.\n\n\n- Step 3: Observe the field \"enable_notes\": false in the JSON response.\n- Step 4: Manually change \"enable_notes\" to true using browser DevTools or by intercepting and modifying the response via a proxy like Burp Suite. (Please note, the occurrence of this API comes twice, hence modification needs to be made twice as well.)\n\n\n- Step 5: Observe the loaded frontend application; the previously hidden notes form will now be visible.\n\n\n\n\n- Step 6: Again, click on any note, intercept the request, and Replace the note_id in the URL with a different note ID known to belong to another user (e.g., by guessing or bruteforcing).\n- Step 7: Send the modified request while remaining logged in as User A.\n- Step 8: Observe that the server returns the content of another user\u0027s note, confirming unauthorized access.\n\n\n\n\n### Impact\n1. Unauthorized access to user-created notes\n2. Possible exposure of confidential or sensitive uploaded data\n3. Violation of user privacy and data isolation\n4. High risk of legal or compliance breaches in regulated environments\n\n## Resolution\n\nFixed in commit [de3317e26](https://github.com/open-webui/open-webui/commit/de3317e26bb67a2a7ea015a183bbd1d369880ebd), first released in **v0.8.11** (Mar 2026). All per-id note endpoints (`GET /api/v1/notes/{id}`, `POST /api/v1/notes/{id}/update`, `POST /api/v1/notes/{id}/access/update`, deletion) now enforce ownership: the handler fetches the note, then requires the caller to be admin, the note owner, or have an `AccessGrants` grant for the appropriate permission (`read` for retrieval, `write` for mutation). A non-owner with no grant receives 403.\n\nUsers on `\u003e= 0.8.11` are not affected.",
"id": "GHSA-x3qm-p8hr-3c3h",
"modified": "2026-05-19T16:00:32Z",
"published": "2026-05-14T20:27:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-x3qm-p8hr-3c3h"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45666"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/commit/de3317e26bb67a2a7ea015a183bbd1d369880ebd"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-webui/open-webui"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/releases/tag/v0.8.11"
}
],
"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": "Open WebUI has an Indirect Object Reference (IDOR) in user notes"
}
GHSA-X4G7-VJJ9-57Q3
Vulnerability from github – Published: 2022-05-24 16:58 – Updated: 2023-08-22 21:30An issue was discovered in zabbix.php?action=dashboard.view&dashboardid=1 in Zabbix through 4.4. An attacker can bypass the login page and access the dashboard page, and then create a Dashboard, Report, Screen, or Map without any Username/Password (i.e., anonymously). All created elements (Dashboard/Report/Screen/Map) are accessible by other users and by an admin.
{
"affected": [],
"aliases": [
"CVE-2019-17382"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-10-09T14:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in zabbix.php?action=dashboard.view\u0026dashboardid=1 in Zabbix through 4.4. An attacker can bypass the login page and access the dashboard page, and then create a Dashboard, Report, Screen, or Map without any Username/Password (i.e., anonymously). All created elements (Dashboard/Report/Screen/Map) are accessible by other users and by an admin.",
"id": "GHSA-x4g7-vjj9-57q3",
"modified": "2023-08-22T21:30:17Z",
"published": "2022-05-24T16:58:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17382"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2023/08/msg00027.html"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/47467"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-X4M5-4CW8-VC44
Vulnerability from github – Published: 2025-12-30 15:37 – Updated: 2026-01-05 22:35Summary
When a server calls an upstream service using different auth tokens, axios-cache-interceptor returns incorrect cached responses, leading to authorization bypass.
Details
The cache key is generated only from the URL, ignoring request headers like Authorization. When the server responds with Vary: Authorization (indicating the response varies by auth token), the library ignores this, causing all requests to share the same cache regardless of authorization.
Impact
Affected: Server-side applications (APIs, proxies, backend services) that:
- Use axios-cache-interceptor to cache requests to upstream services
- Handle requests from multiple users with different auth tokens
- Upstream services replies on
Varyto differentiate caches
Not affected: Browser/client-side applications (single user per browser session).
Services using different auth tokens to call upstream services will return incorrect cached data, bypassing authorization checks and leaking user data across different authenticated sessions.
Solution
After v1.11.1, automatic Vary header support is now enabled by default.
When server responds with Vary: Authorization, cache keys now include the authorization header value. Each user gets their own cache.
// v1.11.1+ (automatic, no config needed)
// User 123: key = hash(url + {authorization: 'Bearer 123'})
// User 456: key = hash(url + {authorization: 'Bearer 456'})
// ✓ Different caches, no poisoning
Remediation
Upgrade to v1.11.1 or later. No code changes required, protection is automatic
Proof of Concept
const http = require('node:http');
const axios = require('axios');
const { setupCache } = require('axios-cache-interceptor');
// Server that returns different responses based on Authorization
const server = http.createServer((req, res) => {
const auth = req.headers.authorization;
res.setHeader('Vary', 'Authorization');
if (auth === 'Bearer 123') {
res.write('Hello, user 123!');
} else if (auth === 'Bearer 456') {
res.write('Hello, user 456!');
} else {
res.write('Unknown');
}
res.end();
});
server.listen(5000);
// Client making requests with different tokens
const cachedAxios = setupCache(axios.create());
const server2 = http.createServer(async (_req, res) => {
const authHeader =
Math.random() < 0.5 ? 'Bearer 123' : 'Bearer 456';
const response = await cachedAxios.get('http://localhost:5000', {
headers: { Authorization: authHeader }
});
console.log({
response: response.data,
cached: response.cached,
auth: authHeader
});
res.write(response.data);
res.end();
});
server2.listen(5001);
// Trigger 10 requests
Promise.all(
Array.from({ length: 10 }, () =>
axios.get('http://localhost:5001').catch(console.error)
)
).finally(() => {
server.close();
server2.close();
});
All 10 responses return "Hello, user 123!" even when using "Bearer 456" - users receive each other's cached data.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "axios-cache-interceptor"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.11.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-69202"
],
"database_specific": {
"cwe_ids": [
"CWE-524",
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-30T15:37:55Z",
"nvd_published_at": "2025-12-29T20:15:42Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nWhen a server calls an upstream service using different auth tokens, axios-cache-interceptor returns incorrect cached responses, leading to authorization bypass.\n\n## Details\n\nThe cache key is generated only from the URL, ignoring request headers like `Authorization`. When the server responds with `Vary: Authorization` (indicating the response varies by auth token), the library ignores this, causing all requests to share the same cache regardless of authorization.\n\n## Impact\n\n**Affected:** Server-side applications (APIs, proxies, backend services) that:\n\n- Use axios-cache-interceptor to cache requests to upstream services\n- Handle requests from multiple users with different auth tokens\n- Upstream services replies on `Vary` to differentiate caches\n\n**Not affected:** Browser/client-side applications (single user per browser session).\n\nServices using different auth tokens to call upstream services will return incorrect cached data, bypassing authorization checks and leaking user data across different authenticated sessions.\n\n## Solution\n\nAfter `v1.11.1`, automatic `Vary` header support is now enabled by default.\n\nWhen server responds with `Vary: Authorization`, cache keys now include the authorization header value. Each user gets their own cache.\n\n```js\n// v1.11.1+ (automatic, no config needed)\n// User 123: key = hash(url + {authorization: \u0027Bearer 123\u0027})\n// User 456: key = hash(url + {authorization: \u0027Bearer 456\u0027})\n// \u2713 Different caches, no poisoning\n```\n\n## Remediation\n\nUpgrade to v1.11.1 or later. _No code changes required, protection is automatic_\n\n\n## Proof of Concept\n\n```js\nconst http = require(\u0027node:http\u0027);\nconst axios = require(\u0027axios\u0027);\nconst { setupCache } = require(\u0027axios-cache-interceptor\u0027);\n\n// Server that returns different responses based on Authorization\nconst server = http.createServer((req, res) =\u003e {\n const auth = req.headers.authorization;\n\n res.setHeader(\u0027Vary\u0027, \u0027Authorization\u0027);\n\n if (auth === \u0027Bearer 123\u0027) {\n res.write(\u0027Hello, user 123!\u0027);\n } else if (auth === \u0027Bearer 456\u0027) {\n res.write(\u0027Hello, user 456!\u0027);\n } else {\n res.write(\u0027Unknown\u0027);\n }\n\n res.end();\n});\n\nserver.listen(5000);\n\n// Client making requests with different tokens\nconst cachedAxios = setupCache(axios.create());\n\nconst server2 = http.createServer(async (_req, res) =\u003e {\n const authHeader =\n Math.random() \u003c 0.5 ? \u0027Bearer 123\u0027 : \u0027Bearer 456\u0027;\n\n const response = await cachedAxios.get(\u0027http://localhost:5000\u0027, {\n headers: { Authorization: authHeader }\n });\n\n console.log({\n response: response.data,\n cached: response.cached,\n auth: authHeader\n });\n res.write(response.data);\n res.end();\n});\n\nserver2.listen(5001);\n\n// Trigger 10 requests\nPromise.all(\n Array.from({ length: 10 }, () =\u003e\n axios.get(\u0027http://localhost:5001\u0027).catch(console.error)\n )\n).finally(() =\u003e {\n server.close();\n server2.close();\n});\n```\n\nAll 10 responses return \"Hello, user 123!\" even when using \"Bearer 456\" - users receive each other\u0027s cached data.",
"id": "GHSA-x4m5-4cw8-vc44",
"modified": "2026-01-05T22:35:17Z",
"published": "2025-12-30T15:37:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/arthurfiorette/axios-cache-interceptor/security/advisories/GHSA-x4m5-4cw8-vc44"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-69202"
},
{
"type": "WEB",
"url": "https://github.com/arthurfiorette/axios-cache-interceptor/commit/49a808059dfc081b9cc23d48f243d55dfce15f01"
},
{
"type": "PACKAGE",
"url": "https://github.com/arthurfiorette/axios-cache-interceptor"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:L/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "axios-cache-interceptor Vulnerable to Cache Poisoning via Ignored HTTP Vary Header"
}
GHSA-X4X7-V8WJ-3952
Vulnerability from github – Published: 2026-02-25 12:30 – Updated: 2026-02-25 12:30The WP Recipe Maker plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the 'ajax_search_recipes' and 'ajax_get_recipe' functions in all versions up to, and including, 10.2.3. This makes it possible for authenticated attackers, with Subscriber-level access and above, to retrieve sensitive recipe information including draft, pending, and private recipes that they shouldn't be able to access.
{
"affected": [],
"aliases": [
"CVE-2025-14742"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-25T10:16:18Z",
"severity": "MODERATE"
},
"details": "The WP Recipe Maker plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the \u0027ajax_search_recipes\u0027 and \u0027ajax_get_recipe\u0027 functions in all versions up to, and including, 10.2.3. This makes it possible for authenticated attackers, with Subscriber-level access and above, to retrieve sensitive recipe information including draft, pending, and private recipes that they shouldn\u0027t be able to access.",
"id": "GHSA-x4x7-v8wj-3952",
"modified": "2026-02-25T12:30:28Z",
"published": "2026-02-25T12:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14742"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/wp-recipe-maker/trunk/includes/public/class-wprm-recipe-manager.php#L161"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/wp-recipe-maker/trunk/includes/public/class-wprm-recipe-manager.php#L301"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/wp-recipe-maker/trunk/includes/public/class-wprm-recipe-manager.php#L46"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/wp-recipe-maker/trunk/includes/public/class-wprm-recipe-manager.php#L47"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3440361/wp-recipe-maker/trunk/includes/public/class-wprm-recipe-manager.php"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/10c17e74-dced-483e-bcaf-00ff5b11059c?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-X532-492Q-G257
Vulnerability from github – Published: 2026-04-23 21:31 – Updated: 2026-04-23 21:31A vulnerability in SpiceJet’s booking API allows unauthenticated users to query passenger name records (PNRs) without any access controls. Because PNR identifiers follow a predictable pattern, an attacker could systematically enumerate valid records and obtain associated passenger names. This flaw stems from missing authorization checks on an endpoint intended for authenticated profile access.
{
"affected": [],
"aliases": [
"CVE-2026-6375"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-23T21:16:06Z",
"severity": "HIGH"
},
"details": "A vulnerability in SpiceJet\u2019s booking API allows unauthenticated users to query passenger name records (PNRs) without any access controls. Because PNR identifiers follow a predictable pattern, an attacker could systematically enumerate valid records and obtain associated passenger names. This flaw stems from missing authorization checks on an endpoint intended for authenticated profile access.",
"id": "GHSA-x532-492q-g257",
"modified": "2026-04-23T21:31:24Z",
"published": "2026-04-23T21:31:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6375"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-113-04"
}
],
"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:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-X5MV-X4W6-8RGW
Vulnerability from github – Published: 2025-12-09 18:30 – Updated: 2026-04-23 18:31Authorization Bypass Through User-Controlled Key vulnerability in David Lingren Media Library Assistant media-library-assistant allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Media Library Assistant: from n/a through <= 3.30.
{
"affected": [],
"aliases": [
"CVE-2025-63065"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-09T16:18:12Z",
"severity": "MODERATE"
},
"details": "Authorization Bypass Through User-Controlled Key vulnerability in David Lingren Media Library Assistant media-library-assistant allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Media Library Assistant: from n/a through \u003c= 3.30.",
"id": "GHSA-x5mv-x4w6-8rgw",
"modified": "2026-04-23T18:31:43Z",
"published": "2025-12-09T18:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-63065"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/media-library-assistant/vulnerability/wordpress-media-library-assistant-plugin-3-30-broken-access-control-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/media-library-assistant/vulnerability/wordpress-media-library-assistant-plugin-3-30-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:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-X5RW-QVVP-5CGM
Vulnerability from github – Published: 2026-01-02 22:50 – Updated: 2026-01-02 22:50Summary
An Insecure Direct Object Reference vulnerability in the customer order reorder function allows any authenticated customer to add items from another customer's order to their own shopping cart by manipulating the order ID parameter. This exposes sensitive purchase information and enables potential fraud.
Details
The vulnerability exists in the reorder method within OrderController.php. Unlike other order-related functions like view, cancel, printInvoice that properly validate customer ownership, the reorder function retrieves orders using only the order ID without verifying that the order belongs to the authenticated customer.
Code location: packages/Webkul/Shop/src/Http/Controllers/Customer/Account/OrderController.php
Exposed Route: packages/Webkul/Shop/src/Routes/customer-routes.php
Route::get('reorder/{id}', 'reorder')->name('shop.customers.account.orders.reorder');
PoC
I. Create victim account and place an order. II. Login as attacker. III. Exploit IDOR and navigate like: http://target.xxx/customer/account/orders/reorder/1 IV. Check http://target.xxx/checkout/cart and verify exploitation. V. Victim's order items are now in Attacker's cart.
PoC via curl:
curl -c cookies.txt -X POST "http://target.xxx/customer/login" -d "email=attacker@evil.com&password=123qwe"
curl -b cookies.txt "http://target.xxx/customer/account/orders/reorder/1"
curl -b cookies.txt "http://target/api/checkout/cart"
Impact
- Information Disclosure: Attackers can discover what products other customers have purchased.
- Potential Fraud: Attackers could potentially exploit this for social engineering or targeted attacks.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "bagisto/bagisto"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.3.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-21447"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-02T22:50:47Z",
"nvd_published_at": "2026-01-02T21:15:58Z",
"severity": "HIGH"
},
"details": "### Summary\n\nAn Insecure Direct Object Reference vulnerability in the customer order reorder function allows any authenticated customer to add items from another customer\u0027s order to their own shopping cart by manipulating the order ID parameter. This exposes sensitive purchase information and enables potential fraud.\n\n### Details\n\nThe vulnerability exists in the reorder method within OrderController.php. Unlike other order-related functions like view, cancel, printInvoice that properly validate customer ownership, the reorder function retrieves orders using only the order ID without verifying that the order belongs to the authenticated customer.\n\nCode location: `packages/Webkul/Shop/src/Http/Controllers/Customer/Account/OrderController.php`\n\nExposed Route: `packages/Webkul/Shop/src/Routes/customer-routes.php`\n\n```php\nRoute::get(\u0027reorder/{id}\u0027, \u0027reorder\u0027)-\u003ename(\u0027shop.customers.account.orders.reorder\u0027);\n```\n\n### PoC\n\nI. Create victim account and place an order.\nII. Login as attacker.\nIII. Exploit IDOR and navigate like: http://target.xxx/customer/account/orders/reorder/1\nIV. Check http://target.xxx/checkout/cart and verify exploitation.\nV. Victim\u0027s order items are now in Attacker\u0027s cart.\n\n###\u00a0PoC via curl:\n\n```\ncurl -c cookies.txt -X POST \"http://target.xxx/customer/login\" -d \"email=attacker@evil.com\u0026password=123qwe\"\n\ncurl -b cookies.txt \"http://target.xxx/customer/account/orders/reorder/1\"\n\ncurl -b cookies.txt \"http://target/api/checkout/cart\"\n```\n\n### Impact\n\n- **Information Disclosure:** Attackers can discover what products other customers have purchased.\n- **Potential Fraud:** Attackers could potentially exploit this for social engineering or targeted attacks.",
"id": "GHSA-x5rw-qvvp-5cgm",
"modified": "2026-01-02T22:50:47Z",
"published": "2026-01-02T22:50:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/bagisto/bagisto/security/advisories/GHSA-x5rw-qvvp-5cgm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-21447"
},
{
"type": "WEB",
"url": "https://github.com/bagisto/bagisto/commit/b2b1cf62577245d03a68532478cffbe321df74d3"
},
{
"type": "PACKAGE",
"url": "https://github.com/bagisto/bagisto"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Bagisto has IDOR in Customer Order Reorder Functionality"
}
GHSA-X5V6-PJ28-CWWM
Vulnerability from github – Published: 2026-05-14 14:52 – Updated: 2026-06-09 13:09Summary
A Mass Assignment vulnerability exists in the tool update endpoint of FlowiseAI.
The endpoint allows authenticated users to modify server-controlled properties such as workspaceId, createdDate, and updatedDate when updating a tool resource.
Due to missing server-side validation and authorization checks, an attacker can manipulate the workspaceId field and reassign tools to arbitrary workspaces. This breaks tenant isolation in multi-workspace environments.
Details
The endpoint responsible for updating tools:
PUT /api/v1/tools/{toolId}
accepts a JSON request body containing tool metadata.
However, the server does not restrict which properties may be modified by the client. As a result, user-controlled request bodies can include additional fields that should normally be controlled only by the backend.
Server-controlled fields that can be manipulated include:
- workspaceId
- createdDate
- updatedDate
The request body is directly merged into the underlying database entity without proper DTO validation or authorization checks.
PoC
Authenticate to the Flowise interface.
Capture the request used to update a tool:
PUT /api/v1/tools/<TOOL_ID>
Content-Type: application/json
Modify the request body by injecting additional fields:
{
"name": "aaa",
"description": "bbb",
"color": "linear-gradient(rgb(109,215,45), rgb(136,170,134))",
"schema": "[]",
"func": "",
"iconSrc": "test",
"workspaceId": "11111111-2222-3333-4444-555555555555",
"createdDate": "1995-03-06T14:17:50.000Z",
"updatedDate": "1995-03-06T14:17:50.000Z"
}
Send the request.
Observe that the response includes the manipulated fields:
{
"workspaceId": "11111111-2222-3333-4444-555555555555",
"createdDate": "1995-03-06T14:17:50.000Z"
}
This confirms that client-controlled values are accepted and persisted by the server.
Impact
This vulnerability allows authenticated users to manipulate internal attributes of tool resources.
Confirmed impacts include:
- Cross-workspace reassignment of tools (workspaceId)
- Unauthorized modification of metadata (createdDate, updatedDate)
In multi-tenant deployments, this may allow an attacker to move tools between workspaces without authorization, breaking tenant isolation boundaries.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.1.1"
},
"package": {
"ecosystem": "npm",
"name": "flowise"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42862"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-639",
"CWE-915"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-14T14:52:40Z",
"nvd_published_at": "2026-06-08T16:16:39Z",
"severity": "HIGH"
},
"details": "### Summary\nA Mass Assignment vulnerability exists in the tool update endpoint of FlowiseAI.\n\nThe endpoint allows authenticated users to modify server-controlled properties such as workspaceId, createdDate, and updatedDate when updating a tool resource.\n\nDue to missing server-side validation and authorization checks, an attacker can manipulate the workspaceId field and reassign tools to arbitrary workspaces. This breaks tenant isolation in multi-workspace environments.\n\n### Details\nThe endpoint responsible for updating tools:\n\n**PUT /api/v1/tools/{toolId}**\n\naccepts a JSON request body containing tool metadata.\n\nHowever, the server does not restrict which properties may be modified by the client. As a result, user-controlled request bodies can include additional fields that should normally be controlled only by the backend.\n\nServer-controlled fields that can be manipulated include:\n\n1. workspaceId\n2. createdDate\n3. updatedDate\n\nThe request body is directly merged into the underlying database entity without proper DTO validation or authorization checks.\n\n### PoC\nAuthenticate to the Flowise interface.\n\nCapture the request used to update a tool:\n\n```http\nPUT /api/v1/tools/\u003cTOOL_ID\u003e\nContent-Type: application/json\n\nModify the request body by injecting additional fields:\n\n{\n \"name\": \"aaa\",\n \"description\": \"bbb\",\n \"color\": \"linear-gradient(rgb(109,215,45), rgb(136,170,134))\",\n \"schema\": \"[]\",\n \"func\": \"\",\n \"iconSrc\": \"test\",\n \"workspaceId\": \"11111111-2222-3333-4444-555555555555\",\n \"createdDate\": \"1995-03-06T14:17:50.000Z\",\n \"updatedDate\": \"1995-03-06T14:17:50.000Z\"\n}\n\n```\nSend the request.\n\nObserve that the response includes the manipulated fields:\n\n```json\n{\n \"workspaceId\": \"11111111-2222-3333-4444-555555555555\",\n \"createdDate\": \"1995-03-06T14:17:50.000Z\"\n}\n```\n\nThis confirms that client-controlled values are accepted and persisted by the server.\n\n### Impact\nThis vulnerability allows authenticated users to manipulate internal attributes of tool resources.\n\nConfirmed impacts include:\n\n- Cross-workspace reassignment of tools (workspaceId)\n- Unauthorized modification of metadata (createdDate, updatedDate)\n\nIn multi-tenant deployments, this may allow an attacker to move tools between workspaces without authorization, breaking tenant isolation boundaries.",
"id": "GHSA-x5v6-pj28-cwwm",
"modified": "2026-06-09T13:09:57Z",
"published": "2026-05-14T14:52:40Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-x5v6-pj28-cwwm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42862"
},
{
"type": "PACKAGE",
"url": "https://github.com/FlowiseAI/Flowise"
},
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/releases/tag/flowise%403.1.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "FlowiseAI has Mass Assignment in Tool Update Endpoint that Allows Cross-Workspace Resource Reassignment"
}
Mitigation
For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
Mitigation
Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.
Mitigation
Use encryption in order to make it more difficult to guess other legitimate values of the key or associate a digital signature with the key so that the server can verify that there has been no tampering.
No CAPEC attack patterns related to this CWE.