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.
4206 vulnerabilities reference this CWE, most recent first.
GHSA-CW6X-MW64-Q6PV
Vulnerability from github – Published: 2026-03-10 01:15 – Updated: 2026-03-10 18:45Description
The resend-verification-code endpoint allows any authenticated user to trigger a verification code resend for any UserWhatsApp record by ID. Ownership is not validated (unlike the verify endpoint).
Affected Source
- Endpoint: UserWhatsAppAPI.ts
- Service: UserWhatsAppService.ts
- Verify ownership (present in verify endpoint for comparison): UserWhatsAppAPI.ts
Full Code Lines (UserWhatsAppAPI.ts)
Resend path (authorization gap):
this.router.post(
`${new this.entityType()
.getCrudApiPath()
?.toString()}/resend-verification-code`,
UserMiddleware.getUserMiddleware,
async (req: ExpressRequest, res: ExpressResponse, next: NextFunction) => {
try {
req = req as OneUptimeRequest;
if (!req.body.itemId) {
return Response.sendErrorResponse(
req,
res,
new BadDataException("Invalid item ID"),
);
}
await this.service.resendVerificationCode(req.body.itemId);
return Response.sendEmptySuccessResponse(req, res);
} catch (err) {
return next(err);
}
},
);
Verify path (ownership check present):
if (
item.userId?.toString() !==
(req as OneUptimeRequest)?.userAuthorization?.userId?.toString()
) {
return Response.sendErrorResponse(
req,
res,
new BadDataException("Invalid user ID"),
);
}
Prerequisites
- Valid attacker account with access to a project
- Attacker access token
- A victim’s
UserWhatsAppitemId belonging to the same project
Steps to Reproduce
- Set your attacker token:
bash
export ATK="Bearer <attacker-access-token>"
- Trigger resend for the victim’s item:
bash
curl -s -X POST \
-H "Content-Type: application/json" \
-H "Authorization: $ATK" \
-d '{"itemId":"<victim-userwhatsapp-id>"}' \
http://<host>/api/user-whats-app/resend-verification-code
Expected/Observed Behavior
- HTTP 200 with
{}body and a new verification code sent to the victim’s phone - No checks confirm that
item.userIdequals the authenticated user’s ID for the resend path
Impact
- Spam/DoS against victims’ phone numbers, social engineering pressure, and potential lockout flows due to repeated resends
Recommended Fix
- Enforce ownership:
item.userIdmust match the authenticated user - Add per-item and per-user rate limiting for resends
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@oneuptime/common"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "10.0.21"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-30959"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-307",
"CWE-639",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-10T01:15:30Z",
"nvd_published_at": "2026-03-10T18:18:55Z",
"severity": "MODERATE"
},
"details": "### Description \n The resend-verification-code endpoint allows any authenticated user to trigger a verification code resend for any `UserWhatsApp` record by ID. Ownership is not validated (unlike the verify endpoint).\n\n### Affected Source \n- Endpoint: [UserWhatsAppAPI.ts](https://github.com/OneUptime/oneuptime/Common/Server/API/UserWhatsAppAPI.ts#L129-L153) \n- Service: [UserWhatsAppService.ts](https://github.com/OneUptime/oneuptime/Common/Server/API/UserWhatsAppAPI.ts#L129-L153) \n- Verify ownership (present in verify endpoint for comparison): [UserWhatsAppAPI.ts](https://github.com/OneUptime/oneuptime/Common/Server/API/UserWhatsAppAPI.ts#L78-L87)\n\n\n### Full Code Lines (UserWhatsAppAPI.ts)\n\nResend path (authorization gap):\n\n```ts\n this.router.post(\n `${new this.entityType()\n .getCrudApiPath()\n ?.toString()}/resend-verification-code`,\n UserMiddleware.getUserMiddleware,\n async (req: ExpressRequest, res: ExpressResponse, next: NextFunction) =\u003e {\n try {\n req = req as OneUptimeRequest;\n\n if (!req.body.itemId) {\n return Response.sendErrorResponse(\n req,\n res,\n new BadDataException(\"Invalid item ID\"),\n );\n }\n\n await this.service.resendVerificationCode(req.body.itemId);\n\n return Response.sendEmptySuccessResponse(req, res);\n } catch (err) {\n return next(err);\n }\n },\n );\n```\n\nVerify path (ownership check present):\n\n```ts\n if (\n item.userId?.toString() !==\n (req as OneUptimeRequest)?.userAuthorization?.userId?.toString()\n ) {\n return Response.sendErrorResponse(\n req,\n res,\n new BadDataException(\"Invalid user ID\"),\n );\n }\n```\n\n## Prerequisites\n- Valid attacker account with access to a project\n- Attacker access token\n- A victim\u2019s `UserWhatsApp` itemId belonging to the same project\n\n## Steps to Reproduce\n1. Set your attacker token:\n\n ```bash\n export ATK=\"Bearer \u003cattacker-access-token\u003e\"\n ```\n\n2. Trigger resend for the victim\u2019s item:\n\n ```bash\n curl -s -X POST \\\n -H \"Content-Type: application/json\" \\\n -H \"Authorization: $ATK\" \\\n -d \u0027{\"itemId\":\"\u003cvictim-userwhatsapp-id\u003e\"}\u0027 \\\n http://\u003chost\u003e/api/user-whats-app/resend-verification-code\n ```\n\n## Expected/Observed Behavior\n- HTTP 200 with `{}` body and a new verification code sent to the victim\u2019s phone\n- No checks confirm that `item.userId` equals the authenticated user\u2019s ID for the resend path\n\n## Impact\n- Spam/DoS against victims\u2019 phone numbers, social engineering pressure, and potential lockout flows due to repeated resends\n\n## Recommended Fix\n- Enforce ownership: `item.userId` must match the authenticated user\n- Add per-item and per-user rate limiting for resends",
"id": "GHSA-cw6x-mw64-q6pv",
"modified": "2026-03-10T18:45:24Z",
"published": "2026-03-10T01:15:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/OneUptime/oneuptime/security/advisories/GHSA-cw6x-mw64-q6pv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30959"
},
{
"type": "PACKAGE",
"url": "https://github.com/OneUptime/oneuptime"
},
{
"type": "WEB",
"url": "https://github.com/OneUptime/oneuptime/releases/tag/10.0.21"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L",
"type": "CVSS_V4"
}
],
"summary": "OneUptime has WhatsApp Resend Verification Authorization Bypass"
}
GHSA-CW84-6HC4-GW56
Vulnerability from github – Published: 2022-05-13 01:43 – Updated: 2022-05-13 01:43In Kanboard before 1.0.47, by altering form data, an authenticated user can remove columns from a private project of another user.
{
"affected": [],
"aliases": [
"CVE-2017-15196"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-10-11T01:32:00Z",
"severity": "MODERATE"
},
"details": "In Kanboard before 1.0.47, by altering form data, an authenticated user can remove columns from a private project of another user.",
"id": "GHSA-cw84-6hc4-gw56",
"modified": "2022-05-13T01:43:39Z",
"published": "2022-05-13T01:43:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-15196"
},
{
"type": "WEB",
"url": "https://github.com/kanboard/kanboard/commit/074f6c104f3e49401ef0065540338fc2d4be79f0"
},
{
"type": "WEB",
"url": "https://github.com/kanboard/kanboard/commit/3e0f14ae2b0b5a44bd038a472f17eac75f538524"
},
{
"type": "WEB",
"url": "https://kanboard.net/news/version-1.0.47"
},
{
"type": "WEB",
"url": "http://openwall.com/lists/oss-security/2017/10/04/9"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-CWC2-3F9G-PHM3
Vulnerability from github – Published: 2025-03-20 12:32 – Updated: 2025-03-20 12:32A vulnerability in infiniflow/ragflow version RAGFlow-0.13.0 allows for partial account takeover via insecure data querying. The issue arises from the way tenant IDs are handled in the application. If a user has access to multiple tenants, they can manipulate their tenant access to query and access API tokens of other tenants. This vulnerability affects the following endpoints: /v1/system/token_list, /v1/system/new_token, /v1/api/token_list, /v1/api/new_token, and /v1/api/rm. An attacker can exploit this to access other tenants' API tokens, perform actions on behalf of other tenants, and access their data.
{
"affected": [],
"aliases": [
"CVE-2024-12880"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-20T10:15:31Z",
"severity": "HIGH"
},
"details": "A vulnerability in infiniflow/ragflow version RAGFlow-0.13.0 allows for partial account takeover via insecure data querying. The issue arises from the way tenant IDs are handled in the application. If a user has access to multiple tenants, they can manipulate their tenant access to query and access API tokens of other tenants. This vulnerability affects the following endpoints: /v1/system/token_list, /v1/system/new_token, /v1/api/token_list, /v1/api/new_token, and /v1/api/rm. An attacker can exploit this to access other tenants\u0027 API tokens, perform actions on behalf of other tenants, and access their data.",
"id": "GHSA-cwc2-3f9g-phm3",
"modified": "2025-03-20T12:32:44Z",
"published": "2025-03-20T12:32:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-12880"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/c41c7eaa-554a-408c-96be-9dba56113970"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CWC3-87MF-4GGW
Vulnerability from github – Published: 2026-09-11 00:31 – Updated: 2026-09-11 00:31Concrete CMS 9.5.2 and below is vulnerable to an authorization bypass (IDOR) because the frontend calendar lightbox endpoint (/ccm/calendar/view_event/{bID}/{occurrence_id}) does not verify that the caller is permitted to view the calendar that owns the requested event occurrence. The controller loads the occurrence directly from an attacker‑supplied, sequential identifier without confirming that it belongs to the calendar configured on the referenced block. An unauthenticated visitor who can render any public calendar block with lightbox properties enabled could therefore supply an arbitrary occurrence identifier and disclose event metadata — title, date, description, page link, and configured event attributes — from calendars they are not permitted to view. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 6.3 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N. Thanks riodrwn for reporting.
{
"affected": [],
"aliases": [
"CVE-2026-18121"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-11T00:17:28Z",
"severity": "MODERATE"
},
"details": "Concrete CMS 9.5.2 and below is vulnerable to an authorization bypass (IDOR) because the frontend calendar lightbox endpoint (/ccm/calendar/view_event/{bID}/{occurrence_id}) does not verify that the caller is permitted to view the calendar that owns the requested event occurrence. The controller loads the occurrence directly from an attacker\u2011supplied, sequential identifier without confirming that it belongs to the calendar configured on the referenced block. An unauthenticated visitor who can render any public calendar block with lightbox properties enabled could therefore supply an arbitrary occurrence identifier and disclose event metadata \u2014 title, date, description, page link, and configured event attributes \u2014 from calendars they are not permitted to view. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 6.3 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N. Thanks riodrwn for reporting.",
"id": "GHSA-cwc3-87mf-4ggw",
"modified": "2026-09-11T00:31:16Z",
"published": "2026-09-11T00:31:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-18121"
},
{
"type": "WEB",
"url": "https://documentation.concretecms.org/developers/introduction/version-history/953-release-notes"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/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-CWC3-P92J-G7QM
Vulnerability from github – Published: 2026-03-06 22:20 – Updated: 2026-03-09 13:15Summary
The Flowise platform has a critical Insecure Direct Object Reference (IDOR) vulnerability combined with a Business Logic Flaw in the PUT /api/v1/loginmethod endpoint.
While the endpoint requires authentication, it fails to validate if the authenticated user has ownership or administrative rights over the target organizationId. This allows any low-privileged user (including "Free" plan users) to:
- Overwrite the SSO configuration of any other organization.
- Enable "Enterprise-only" features (SSO/SAML) without a license.
- Perform Account Takeover by redirecting the authentication flow.
Details
The backend accepts the organizationId parameter from the JSON body and updates the database record corresponding to that ID. There is no middleware or logic check to ensure request.user.organizationId === body.organizationId.
PoC
Prerequisites: 1. The attacker creates a standard "Free" account and obtains a valid JWT token (Cookie/Header). 2. The attacker identifies the target organizationId (e.g., bd2b74e0-e0cd-4bb5-ba98-3cc2ae683d5d).
Step-by-Step Exploitation: The attacker sends the following PUT request to overwrite the victim's Google SSO configuration.
Request:
PUT /api/v1/loginmethod HTTP/2
Host: cloud.flowiseai.com
Cookie: token=<ATTACKER_JWT_TOKEN>
Content-Type: application/json
Accept: application/json
{
"organizationId": "bd2b74e0-e0cd-4bb5-ba98-3cc2ae683d5d",
"userId": "6ab311fa-0d0a-4bd6-996e-4ae721377fb2",
"providers": [
{
"providerLabel": "Google",
"providerName": "google",
"config": {
"clientID": "ATTACKER_MALICIOUS_CLIENT_ID",
"clientSecret": "ATTACKER_MALICIOUS_SECRET"
},
"status": "enable"
}
]
}
Response: The server responds with 200 OK, confirming the modification has been applied to the victim's organization context.
{
"status": "OK",
"organizationId": "bd2b74e0-e0cd-4bb5-ba98-3cc2ae683d5d"
}
Impact
- Account Takeover: An attacker can replace a victim organization's legitimate OAuth credentials (e.g., Google Client ID) with their own malicious application credentials. When victim employees try to log in via SSO, they are authenticated against the attacker's application, potentially allowing the attacker to hijack sessions or steal credentials.
- License Control Bypass: Users on the "Free" tier can illicitly enable and configure SSO providers (Azure, Okta, etc.), which are features strictly restricted to the "Enterprise" plan.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.0.12"
},
"package": {
"ecosystem": "npm",
"name": "flowise"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.13"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-30823"
],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-06T22:20:50Z",
"nvd_published_at": "2026-03-07T06:16:10Z",
"severity": "HIGH"
},
"details": "### Summary\nThe Flowise platform has a critical Insecure Direct Object Reference (IDOR) vulnerability combined with a Business Logic Flaw in the PUT /api/v1/loginmethod endpoint.\n\nWhile the endpoint requires authentication, it fails to validate if the authenticated user has ownership or administrative rights over the target organizationId. This allows any low-privileged user (including \"Free\" plan users) to:\n\n1. Overwrite the SSO configuration of any other organization.\n2. Enable \"Enterprise-only\" features (SSO/SAML) without a license.\n3. Perform Account Takeover by redirecting the authentication flow.\n\n### Details\nThe backend accepts the organizationId parameter from the JSON body and updates the database record corresponding to that ID. There is no middleware or logic check to ensure request.user.organizationId === body.organizationId.\n\n### PoC\nPrerequisites:\n1. The attacker creates a standard \"Free\" account and obtains a valid JWT token (Cookie/Header).\n2. The attacker identifies the target organizationId (e.g., bd2b74e0-e0cd-4bb5-ba98-3cc2ae683d5d).\n\n**Step-by-Step Exploitation**: The attacker sends the following PUT request to overwrite the victim\u0027s Google SSO configuration.\n\n**Request**:\n\n```http\nPUT /api/v1/loginmethod HTTP/2\nHost: cloud.flowiseai.com\nCookie: token=\u003cATTACKER_JWT_TOKEN\u003e\nContent-Type: application/json\nAccept: application/json\n\n{\n \"organizationId\": \"bd2b74e0-e0cd-4bb5-ba98-3cc2ae683d5d\",\n \"userId\": \"6ab311fa-0d0a-4bd6-996e-4ae721377fb2\", \n \"providers\": [\n {\n \"providerLabel\": \"Google\",\n \"providerName\": \"google\",\n \"config\": {\n \"clientID\": \"ATTACKER_MALICIOUS_CLIENT_ID\",\n \"clientSecret\": \"ATTACKER_MALICIOUS_SECRET\"\n },\n \"status\": \"enable\"\n }\n ]\n}\n```\n\n**Response**: The server responds with 200 OK, confirming the modification has been applied to the victim\u0027s organization context.\n\n```json\n{\n \"status\": \"OK\",\n \"organizationId\": \"bd2b74e0-e0cd-4bb5-ba98-3cc2ae683d5d\"\n}\n```\n\n### Impact\n\n- **Account Takeover**: An attacker can replace a victim organization\u0027s legitimate OAuth credentials (e.g., Google Client ID) with their own malicious application credentials. When victim employees try to log in via SSO, they are authenticated against the attacker\u0027s application, potentially allowing the attacker to hijack sessions or steal credentials.\n- **License Control Bypass**: Users on the \"Free\" tier can illicitly enable and configure SSO providers (Azure, Okta, etc.), which are features strictly restricted to the \"Enterprise\" plan.",
"id": "GHSA-cwc3-p92j-g7qm",
"modified": "2026-03-09T13:15:47Z",
"published": "2026-03-06T22:20:50Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-cwc3-p92j-g7qm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30823"
},
{
"type": "PACKAGE",
"url": "https://github.com/FlowiseAI/Flowise"
},
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/releases/tag/flowise%403.0.13"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Flowise has IDOR leading to Account Takeover and Enterprise Feature Bypass via SSO Configuration"
}
GHSA-CWR5-3CMP-8877
Vulnerability from github – Published: 2026-08-10 12:31 – Updated: 2026-08-10 12:31An improper authorization vulnerability in fosrl/pangolin through v1.20.0 allows an authenticated remote attacker to authenticate to any resource in any organization by reusing an access token issued for a different resource.
{
"affected": [],
"aliases": [
"CVE-2026-72564"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-10T11:17:28Z",
"severity": "CRITICAL"
},
"details": "An improper authorization vulnerability in fosrl/pangolin through v1.20.0 allows an authenticated remote attacker to authenticate to any resource in any organization by reusing an access token issued for a different resource.",
"id": "GHSA-cwr5-3cmp-8877",
"modified": "2026-08-10T12:31:52Z",
"published": "2026-08-10T12:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72564"
},
{
"type": "WEB",
"url": "https://github.com/fosrl/pangolin"
},
{
"type": "WEB",
"url": "https://github.com/fosrl/pangolin/blob/main/server/routers/resource/authWithAccessToken.ts"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-CWWG-J94X-J72R
Vulnerability from github – Published: 2024-11-16 03:30 – Updated: 2024-11-16 03:30The Popularis Extra plugin for WordPress is vulnerable to Information Exposure in all versions up to, and including, 1.2.7 via the 'elementor-template' shortcode 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 via Elementor that they should not have access to.
{
"affected": [],
"aliases": [
"CVE-2024-10795"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-16T03:15:14Z",
"severity": "MODERATE"
},
"details": "The Popularis Extra plugin for WordPress is vulnerable to Information Exposure in all versions up to, and including, 1.2.7 via the \u0027elementor-template\u0027 shortcode 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 via Elementor that they should not have access to.",
"id": "GHSA-cwwg-j94x-j72r",
"modified": "2024-11-16T03:30:31Z",
"published": "2024-11-16T03:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10795"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3185542%40popularis-extra\u0026new=3185542%40popularis-extra\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/1b5de554-1d2f-4932-9f93-1333b07edeba?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-CX9V-4QJ2-JRW6
Vulnerability from github – Published: 2026-06-17 14:31 – Updated: 2026-07-20 21:07Summary
Open WebUI has a Broken Object Level Authorization (BOLA) vulnerability in the builtin search_knowledge_files tool.
When native function calling is enabled and the selected model has no attached knowledge bases, an authenticated user can call search_knowledge_files with an arbitrary knowledge_id. The function then returns file metadata from that knowledge base without checking whether the user has read access.
This allows unauthorized enumeration of private or restricted knowledge base files.
Details
The vulnerable code is in:
backend/open_webui/tools/builtin.py
Affected function:
async def search_knowledge_files(
query: str,
knowledge_id: Optional[str] = None,
count: int = 5,
skip: int = 0,
__request__: Request = None,
__user__: dict = None,
__model_knowledge__: Optional[list[dict]] = None,
) -> str:
In the "No attached knowledge" branch, when knowledge_id is provided, the function directly calls:
result = await Knowledges.search_files_by_id(
knowledge_id=knowledge_id,
user_id=user_id,
filter={"query": query},
skip=skip,
limit=count,
)
This code path does not verify that the current user is authorized to access the specified knowledge base.
The missing check is inconsistent with other nearby code paths. For example, the attached-knowledge branch in the same function checks whether the user is an admin, the owner of the knowledge base, or has explicit read access through AccessGrants:
if not (
user_role == "admin"
or knowledge.user_id == user_id
or await AccessGrants.has_access(
user_id=user_id,
resource_type="knowledge",
resource_id=knowledge.id,
permission="read",
user_group_ids=set(user_group_ids),
)
):
continue
The sibling function query_knowledge_files also performs the same authorization check before using user-supplied knowledge base IDs.
The underlying method Knowledges.search_files_by_id() receives user_id, but it does not enforce authorization for the provided knowledge_id. As a result, this builtin tool path can access a knowledge base by ID without verifying the caller's permissions.
PoC
Prerequisites
- The attacker has a valid authenticated Open WebUI account.
- The victim owns a private or restricted knowledge base.
- The attacker does not own the target knowledge base.
- The attacker does not have
readpermission for the target knowledge base inAccessGrants. - The attacker knows the target
knowledge_id. - The selected model has no attached knowledge bases.
- Builtin tools are enabled.
- The knowledge builtin tool category is enabled.
- Native function calling is enabled.
Reproduction Steps
-
Create a private or restricted knowledge base as the victim user.
-
Upload one or more files to that knowledge base.
-
Confirm that the attacker user does not have access to the knowledge base.
-
As the attacker user, send a chat completion request with native function calling enabled:
{
"stream": true,
"model": "gpt-4o-mini",
"params": {
"function_calling": "native"
},
"messages": [
{
"role": "user",
"content": "Please use the search_knowledge_files tool with knowledge_id \"c0c84752-2e9d-42bf-bc3c-c0f272aa61c1\" to search all files"
}
]
}
Replace c0c84752-2e9d-42bf-bc3c-c0f272aa61c1 with the victim's private knowledge base ID.
Expected Result
The request should be denied because the attacker does not have access to the target knowledge base.
Actual Result
search_knowledge_files returns metadata for files inside the target knowledge base, including:
- file ID;
- filename;
- knowledge base ID;
- knowledge base name;
- update timestamp.
Impact
This is a Broken Object Level Authorization / Broken Access Control vulnerability.
An authenticated attacker who knows a valid knowledge_id can enumerate files from private or restricted knowledge bases without authorization.
The leaked metadata may expose sensitive information through filenames, such as:
- financial reports;
- employee documents;
- customer contracts;
- internal roadmap files;
- confidential project documents.
The exposed file IDs may also help attackers chain this issue with other knowledge-file access paths, such as view_knowledge_file, to attempt further content extraction.
This vulnerability bypasses the intended AccessGrants permission model and may also allow post-revocation metadata access if a user remembers a previously accessible knowledge_id.
Suggested Fix
Add the same authorization check used in query_knowledge_files before calling Knowledges.search_files_by_id():
if knowledge_id:
knowledge = await Knowledges.get_knowledge_by_id(knowledge_id)
if not knowledge or not (
user_role == "admin"
or knowledge.user_id == user_id
or await AccessGrants.has_access(
user_id=user_id,
resource_type="knowledge",
resource_id=knowledge.id,
permission="read",
user_group_ids=set(user_group_ids),
)
):
return json.dumps({"error": f"Access denied to knowledge base {knowledge_id}"})
result = await Knowledges.search_files_by_id(
knowledge_id=knowledge_id,
user_id=user_id,
filter={"query": query},
skip=skip,
limit=count,
)
As defense in depth, authorization should also be enforced or safely wrapped around Knowledges.search_files_by_id() so that future callers cannot accidentally bypass access control.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.9.5"
},
"package": {
"ecosystem": "PyPI",
"name": "open-webui"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.9.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54016"
],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-17T14:31:16Z",
"nvd_published_at": "2026-06-23T18:18:06Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nOpen WebUI has a Broken Object Level Authorization (BOLA) vulnerability in the builtin `search_knowledge_files` tool.\n\nWhen native function calling is enabled and the selected model has no attached knowledge bases, an authenticated user can call `search_knowledge_files` with an arbitrary `knowledge_id`. The function then returns file metadata from that knowledge base without checking whether the user has read access.\n\nThis allows unauthorized enumeration of private or restricted knowledge base files.\n\n## Details\n\nThe vulnerable code is in:\n\n`backend/open_webui/tools/builtin.py`\n\nAffected function:\n\n```python\nasync def search_knowledge_files(\n query: str,\n knowledge_id: Optional[str] = None,\n count: int = 5,\n skip: int = 0,\n __request__: Request = None,\n __user__: dict = None,\n __model_knowledge__: Optional[list[dict]] = None,\n) -\u003e str:\n```\n\nIn the \"No attached knowledge\" branch, when `knowledge_id` is provided, the function directly calls:\n\n```python\nresult = await Knowledges.search_files_by_id(\n knowledge_id=knowledge_id,\n user_id=user_id,\n filter={\"query\": query},\n skip=skip,\n limit=count,\n)\n```\n\nThis code path does not verify that the current user is authorized to access the specified knowledge base.\n\nThe missing check is inconsistent with other nearby code paths. For example, the attached-knowledge branch in the same function checks whether the user is an admin, the owner of the knowledge base, or has explicit read access through `AccessGrants`:\n\n```python\nif not (\n user_role == \"admin\"\n or knowledge.user_id == user_id\n or await AccessGrants.has_access(\n user_id=user_id,\n resource_type=\"knowledge\",\n resource_id=knowledge.id,\n permission=\"read\",\n user_group_ids=set(user_group_ids),\n )\n):\n continue\n```\n\nThe sibling function `query_knowledge_files` also performs the same authorization check before using user-supplied knowledge base IDs.\n\nThe underlying method `Knowledges.search_files_by_id()` receives `user_id`, but it does not enforce authorization for the provided `knowledge_id`. As a result, this builtin tool path can access a knowledge base by ID without verifying the caller\u0027s permissions.\n\n## PoC\n\n### Prerequisites\n\n- The attacker has a valid authenticated Open WebUI account.\n- The victim owns a private or restricted knowledge base.\n- The attacker does not own the target knowledge base.\n- The attacker does not have `read` permission for the target knowledge base in `AccessGrants`.\n- The attacker knows the target `knowledge_id`.\n- The selected model has no attached knowledge bases.\n- Builtin tools are enabled.\n- The knowledge builtin tool category is enabled.\n- Native function calling is enabled.\n\n### Reproduction Steps\n\n1. Create a private or restricted knowledge base as the victim user.\n\n2. Upload one or more files to that knowledge base.\n\n3. Confirm that the attacker user does not have access to the knowledge base.\n\n4. As the attacker user, send a chat completion request with native function calling enabled:\n\n```json\n{\n \"stream\": true,\n \"model\": \"gpt-4o-mini\",\n \"params\": {\n \"function_calling\": \"native\"\n },\n \"messages\": [\n {\n \"role\": \"user\",\n \"content\": \"Please use the search_knowledge_files tool with knowledge_id \\\"c0c84752-2e9d-42bf-bc3c-c0f272aa61c1\\\" to search all files\"\n }\n ]\n}\n```\n\nReplace `c0c84752-2e9d-42bf-bc3c-c0f272aa61c1` with the victim\u0027s private knowledge base ID.\n\n### Expected Result\n\nThe request should be denied because the attacker does not have access to the target knowledge base.\n\n### Actual Result\n\n`search_knowledge_files` returns metadata for files inside the target knowledge base, including:\n\n- file ID;\n- filename;\n- knowledge base ID;\n- knowledge base name;\n- update timestamp.\n\n## Impact\n\nThis is a Broken Object Level Authorization / Broken Access Control vulnerability.\n\nAn authenticated attacker who knows a valid `knowledge_id` can enumerate files from private or restricted knowledge bases without authorization.\n\nThe leaked metadata may expose sensitive information through filenames, such as:\n\n- financial reports;\n- employee documents;\n- customer contracts;\n- internal roadmap files;\n- confidential project documents.\n\nThe exposed file IDs may also help attackers chain this issue with other knowledge-file access paths, such as `view_knowledge_file`, to attempt further content extraction.\n\nThis vulnerability bypasses the intended `AccessGrants` permission model and may also allow post-revocation metadata access if a user remembers a previously accessible `knowledge_id`.\n\n## Suggested Fix\n\nAdd the same authorization check used in `query_knowledge_files` before calling `Knowledges.search_files_by_id()`:\n\n```python\nif knowledge_id:\n knowledge = await Knowledges.get_knowledge_by_id(knowledge_id)\n\n if not knowledge or not (\n user_role == \"admin\"\n or knowledge.user_id == user_id\n or await AccessGrants.has_access(\n user_id=user_id,\n resource_type=\"knowledge\",\n resource_id=knowledge.id,\n permission=\"read\",\n user_group_ids=set(user_group_ids),\n )\n ):\n return json.dumps({\"error\": f\"Access denied to knowledge base {knowledge_id}\"})\n\n result = await Knowledges.search_files_by_id(\n knowledge_id=knowledge_id,\n user_id=user_id,\n filter={\"query\": query},\n skip=skip,\n limit=count,\n )\n```\n\nAs defense in depth, authorization should also be enforced or safely wrapped around `Knowledges.search_files_by_id()` so that future callers cannot accidentally bypass access control.",
"id": "GHSA-cx9v-4qj2-jrw6",
"modified": "2026-07-20T21:07:24Z",
"published": "2026-06-17T14:31:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-cx9v-4qj2-jrw6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54016"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-cx9v-4qj2-jrw6"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-webui/open-webui"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/open-webui/PYSEC-2026-2721.yaml"
},
{
"type": "WEB",
"url": "https://pypi.org/project/open-webui"
}
],
"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"
}
],
"summary": "Open WebUI BOLA: `search_knowledge_files` Allows Unauthorized Knowledge Base File Enumeration"
}
GHSA-CXPG-8FRP-CV2X
Vulnerability from github – Published: 2024-12-31 03:30 – Updated: 2024-12-31 03:30The QOCA aim from Quanta Computer has an Authorization Bypass Through User-Controlled Key vulnerability. By controlling the user ID parameter, remote attackers with regular privileges could access certain features as any user, modify any user's account information and privileges, leading to privilege escalation.
{
"affected": [],
"aliases": [
"CVE-2024-13040"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-31T02:15:06Z",
"severity": "HIGH"
},
"details": "The QOCA aim from Quanta Computer has an Authorization Bypass Through User-Controlled Key vulnerability. By controlling the user ID parameter, remote attackers with regular privileges could access certain features as any user, modify any user\u0027s account information and privileges, leading to privilege escalation.",
"id": "GHSA-cxpg-8frp-cv2x",
"modified": "2024-12-31T03:30:33Z",
"published": "2024-12-31T03:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-13040"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/en/cp-139-8337-7899f-2.html"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/tw/cp-132-8336-aa03b-1.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CXR4-643W-MFV3
Vulnerability from github – Published: 2024-11-15 18:30 – Updated: 2024-11-22 04:25java_shop 1.0 is vulnerable to Incorrect Access Control, which allows attackers to obtain sensitive information of users with different IDs by modifying the ID parameter.
{
"affected": [],
"aliases": [
"CVE-2024-50651"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-15T16:15:36Z",
"severity": "MODERATE"
},
"details": "java_shop 1.0 is vulnerable to Incorrect Access Control, which allows attackers to obtain sensitive information of users with different IDs by modifying the ID parameter.",
"id": "GHSA-cxr4-643w-mfv3",
"modified": "2024-11-22T04:25:02Z",
"published": "2024-11-15T18:30:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50651"
},
{
"type": "WEB",
"url": "https://github.com/Yllxx03/CVE/blob/main/java_shop/BrokenAccessControl.md"
},
{
"type": "WEB",
"url": "https://github.com/Yllxx03/CVE/tree/main/CVE-2024-50651"
}
],
"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"
}
]
}
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.