GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-639

Allowed

Authorization 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:45
VLAI
Summary
OneUptime has WhatsApp Resend Verification Authorization Bypass
Details

Description

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

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 UserWhatsApp itemId belonging to the same project

Steps to Reproduce

  1. Set your attacker token:

bash export ATK="Bearer <attacker-access-token>"

  1. 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.userId equals 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.userId must match the authenticated user
  • Add per-item and per-user rate limiting for resends
Show details on source website

{
  "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:43
VLAI
Details

In Kanboard before 1.0.47, by altering form data, an authenticated user can remove columns from a private project of another user.

Show details on source website

{
  "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:32
VLAI
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' API tokens, perform actions on behalf of other tenants, and access their data.

Show details on source website

{
  "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:31
VLAI
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‑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.

Show details on source website

{
  "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:15
VLAI
Summary
Flowise has IDOR leading to Account Takeover and Enterprise Feature Bypass via SSO Configuration
Details

Summary

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:

  1. Overwrite the SSO configuration of any other organization.
  2. Enable "Enterprise-only" features (SSO/SAML) without a license.
  3. 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.
Show details on source website

{
  "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:31
VLAI
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.

Show details on source website

{
  "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:30
VLAI
Details

The 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.

Show details on source website

{
  "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:07
VLAI
Summary
Open WebUI BOLA: `search_knowledge_files` Allows Unauthorized Knowledge Base File Enumeration
Details

Summary

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 read permission for the target knowledge base in AccessGrants.
  • 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

  1. Create a private or restricted knowledge base as the victim user.

  2. Upload one or more files to that knowledge base.

  3. Confirm that the attacker user does not have access to the knowledge base.

  4. 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.

Show details on source website

{
  "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:30
VLAI
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's account information and privileges, leading to privilege escalation.

Show details on source website

{
  "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:25
VLAI
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.

Show details on source website

{
  "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
Architecture and Design

For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.

Mitigation
Architecture and Design Implementation

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
Architecture and Design

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.