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.

3245 vulnerabilities reference this CWE, most recent first.

GHSA-29WG-MP5P-VW26

Vulnerability from github – Published: 2026-04-27 15:30 – Updated: 2026-04-27 15:30
VLAI
Details

Authenticated user can bypass authorization in Ribblr - Crochet & Knitting iOS application

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-15626"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-27T14:16:21Z",
    "severity": "MODERATE"
  },
  "details": "Authenticated user can bypass authorization in Ribblr - Crochet \u0026 Knitting iOS application",
  "id": "GHSA-29wg-mp5p-vw26",
  "modified": "2026-04-27T15:30:52Z",
  "published": "2026-04-27T15:30:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-15626"
    },
    {
      "type": "WEB",
      "url": "https://ribblr.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/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:Y/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-29XR-58G9-8QFQ

Vulnerability from github – Published: 2025-12-30 00:32 – Updated: 2026-04-01 18:36
VLAI
Details

Authorization Bypass Through User-Controlled Key vulnerability in Crocoblock JetPopup allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects JetPopup: from n/a through 2.0.20.1.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-68502"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-29T22:15:42Z",
    "severity": "MODERATE"
  },
  "details": "Authorization Bypass Through User-Controlled Key vulnerability in Crocoblock JetPopup allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects JetPopup: from n/a through 2.0.20.1.",
  "id": "GHSA-29xr-58g9-8qfq",
  "modified": "2026-04-01T18:36:24Z",
  "published": "2025-12-30T00:32:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68502"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/jet-popup/vulnerability/wordpress-jetpopup-plugin-2-0-20-1-insecure-direct-object-references-idor-vulnerability?_s_id=cve"
    },
    {
      "type": "WEB",
      "url": "https://vdp.patchstack.com/database/wordpress/plugin/jet-popup/vulnerability/wordpress-jetpopup-plugin-2-0-20-1-insecure-direct-object-references-idor-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2CC2-MCJJ-R4MP

Vulnerability from github – Published: 2023-10-16 21:30 – Updated: 2024-04-04 08:41
VLAI
Details

The ActivityPub WordPress plugin before 1.0.0 does not ensure that post contents to be displayed are public and belong to the plugin, allowing any authenticated user, such as subscriber to retrieve the content of arbitrary post (such as draft and private) via an IDOR vector. Password protected posts are not affected by this issue.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-3707"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-16T20:15:14Z",
    "severity": "MODERATE"
  },
  "details": "The ActivityPub WordPress plugin before 1.0.0 does not ensure that post contents to be displayed are public and belong to the plugin, allowing any authenticated user, such as subscriber to retrieve the content of arbitrary post (such as draft and private) via an IDOR vector. Password protected posts are not affected by this issue.",
  "id": "GHSA-2cc2-mcjj-r4mp",
  "modified": "2024-04-04T08:41:17Z",
  "published": "2023-10-16T21:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3707"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/541bbe4c-3295-4073-901d-763556269f48"
    }
  ],
  "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-2CH6-X3G4-7759

Vulnerability from github – Published: 2026-03-03 23:19 – Updated: 2026-03-03 23:19
VLAI
Summary
OpenClaw's commands.allowFrom sender authorization accepted conversation identifiers via ctx.From
Details

Summary

commands.allowFrom is documented as a sender authorization allowlist for commands/directives, but command authorization could include ctx.From (conversation identity) as a sender candidate.

When commands.allowFrom contained conversation-like identifiers (for example Discord channel:<id> or WhatsApp group JIDs), command/directive authorization could be granted to participants in that conversation instead of only the intended sender identity.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Affected versions: <= 2026.2.22-2
  • Patched version: 2026.2.23 (released)

Details

Root cause: resolveSenderCandidates() in src/auto-reply/command-auth.ts always included ctx.From in candidate evaluation used by commands.allowFrom authorization checks.

ctx.From is sender-like in some direct-message contexts, but conversation-like in channel/group/thread contexts. This mixed principal handling allowed conversation identifiers to satisfy sender-only authorization.

Impact

In affected versions, command/directive authorization could become broader than intended when operators configured commands.allowFrom with conversation identifiers, allowing unintended users in that conversation to run command-only/directive-only flows.

Fix

Main branch now treats commands.allowFrom as sender-only: - ctx.From is no longer included as a general sender candidate. - ctx.From is only used as fallback when sender fields are absent and the value is not conversation-shaped. - Regression tests were added for conversation-id denial and direct-message fallback preservation.

Fix Commit(s)

  • 08e2aa44e78a9c946d97bea62304e6f533b8fa8e

Release Process Note

patched_versions is pre-set to the released version (2026.2.23). This advisory now reflects released fix version 2026.2.23.

OpenClaw thanks @jiseoung for reporting.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.23"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-03T23:19:46Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n`commands.allowFrom` is documented as a sender authorization allowlist for commands/directives, but command authorization could include `ctx.From` (conversation identity) as a sender candidate.\n\nWhen `commands.allowFrom` contained conversation-like identifiers (for example Discord `channel:\u003cid\u003e` or WhatsApp group JIDs), command/directive authorization could be granted to participants in that conversation instead of only the intended sender identity.\n\n### Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Affected versions: `\u003c= 2026.2.22-2`\n- Patched version: `2026.2.23` (released)\n\n### Details\nRoot cause: `resolveSenderCandidates()` in `src/auto-reply/command-auth.ts` always included `ctx.From` in candidate evaluation used by `commands.allowFrom` authorization checks.\n\n`ctx.From` is sender-like in some direct-message contexts, but conversation-like in channel/group/thread contexts. This mixed principal handling allowed conversation identifiers to satisfy sender-only authorization.\n\n### Impact\nIn affected versions, command/directive authorization could become broader than intended when operators configured `commands.allowFrom` with conversation identifiers, allowing unintended users in that conversation to run command-only/directive-only flows.\n\n### Fix\nMain branch now treats `commands.allowFrom` as sender-only:\n- `ctx.From` is no longer included as a general sender candidate.\n- `ctx.From` is only used as fallback when sender fields are absent and the value is not conversation-shaped.\n- Regression tests were added for conversation-id denial and direct-message fallback preservation.\n\n### Fix Commit(s)\n- `08e2aa44e78a9c946d97bea62304e6f533b8fa8e`\n\n### Release Process Note\n`patched_versions` is pre-set to the released version (`2026.2.23`). This advisory now reflects released fix version `2026.2.23`.\n\nOpenClaw thanks @jiseoung for reporting.",
  "id": "GHSA-2ch6-x3g4-7759",
  "modified": "2026-03-03T23:19:46Z",
  "published": "2026-03-03T23:19:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-2ch6-x3g4-7759"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/08e2aa44e78a9c946d97bea62304e6f533b8fa8e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw\u0027s commands.allowFrom sender authorization accepted conversation identifiers via ctx.From"
}

GHSA-2CHW-CHR5-J5H8

Vulnerability from github – Published: 2024-12-14 06:30 – Updated: 2024-12-14 06:30
VLAI
Details

The Shortcodes for Elementor plugin for WordPress is vulnerable to Information Exposure in all versions up to, and including, 1.0.4 via the 'SHORTCODE_ELEMENTOR' 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 and draft posts created with Elementor that they should not have access to.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-10690"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-14T06:15:19Z",
    "severity": "MODERATE"
  },
  "details": "The Shortcodes for Elementor plugin for WordPress is vulnerable to Information Exposure in all versions up to, and including, 1.0.4 via the \u0027SHORTCODE_ELEMENTOR\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 and draft posts created with Elementor that they should not have access to.",
  "id": "GHSA-2chw-chr5-j5h8",
  "modified": "2024-12-14T06:30:48Z",
  "published": "2024-12-14T06:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10690"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3207001%40shortcode-elementor\u0026new=3207001%40shortcode-elementor\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/5debe121-6373-4b56-8441-f0d4a5920089?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-2F7Q-533Q-P67M

Vulnerability from github – Published: 2023-10-03 12:30 – Updated: 2024-04-04 08:07
VLAI
Details

The QSige login SSO does not have an access control mechanism to verify whether the user requesting a resource has sufficient permissions to do so. As a prerequisite, it is necessary to log into the application.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-4101"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-03T12:15:10Z",
    "severity": "MODERATE"
  },
  "details": "The QSige login SSO does not have an access control mechanism to verify whether the user requesting a resource has sufficient permissions to do so. As a prerequisite, it is necessary to log into the application.",
  "id": "GHSA-2f7q-533q-p67m",
  "modified": "2024-04-04T08:07:45Z",
  "published": "2023-10-03T12:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4101"
    },
    {
      "type": "WEB",
      "url": "https://www.incibe.es/en/incibe-cert/notices/aviso/multiple-vulnerabilities-idm-sistemas-qsige"
    }
  ],
  "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-2FGH-JJH6-CVR4

Vulnerability from github – Published: 2024-12-20 15:30 – Updated: 2024-12-20 18:31
VLAI
Details

Path Traversal and Insecure Direct Object Reference (IDOR) vulnerabilities in the eSignaViewer component in eSigna product versions 1.0 to 1.5 on all platforms allow an unauthenticated attacker to access arbitrary files in the document system via manipulation of file paths and object identifiers.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-12014"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-20T13:15:19Z",
    "severity": "LOW"
  },
  "details": "Path Traversal and Insecure Direct Object Reference (IDOR) vulnerabilities in the eSignaViewer component in eSigna product versions 1.0 to 1.5 on all platforms allow an unauthenticated attacker to access arbitrary files in the document system via manipulation of file paths and object identifiers.",
  "id": "GHSA-2fgh-jjh6-cvr4",
  "modified": "2024-12-20T18:31:32Z",
  "published": "2024-12-20T15:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-12014"
    },
    {
      "type": "WEB",
      "url": "https://edgewatch.com/vulnerability-advisories/path-traversal-and-idor-vulnerabilities-in-esignaviewer-allow-unauthorized-file-access"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:A/VC:L/VI:N/VA:N/SC:L/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-2FHR-F6Q6-C4P2

Vulnerability from github – Published: 2022-05-24 16:52 – Updated: 2023-09-25 19:27
VLAI
Summary
Magento 2 Community Edition Access Control Bypass
Details

An access control bypass vulnerability exists in Magento 2.1 prior to 2.1.18, Magento 2.2 prior to 2.2.9, Magento 2.3 prior to 2.3.2. An unauthenticated user can bypass access controls via REST API calls to assign themselves to an arbitrary company, thereby gaining read access to potentially confidental information.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.1.0"
            },
            {
              "fixed": "2.1.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.2.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.3.0"
            },
            {
              "fixed": "2.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-7950"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-07-17T18:42:33Z",
    "nvd_published_at": "2019-08-02T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "An access control bypass vulnerability exists in Magento 2.1 prior to 2.1.18, Magento 2.2 prior to 2.2.9, Magento 2.3 prior to 2.3.2. An unauthenticated user can bypass access controls via REST API calls to assign themselves to an arbitrary company, thereby gaining read access to potentially confidental information.",
  "id": "GHSA-2fhr-f6q6-c4p2",
  "modified": "2023-09-25T19:27:52Z",
  "published": "2022-05-24T16:52:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-7950"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/magento/product-community-edition/CVE-2019-7950.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/magento/magento2"
    },
    {
      "type": "WEB",
      "url": "https://magento.com/security/patches/magento-2.3.2-2.2.9-and-2.1.18-security-update-13"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20211206084839/https://magento.com/security/patches/magento-2.3.2-2.2.9-and-2.1.18-security-update-13"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Magento 2 Community Edition Access Control Bypass"
}

GHSA-2FJ9-FC6X-HGW7

Vulnerability from github – Published: 2025-04-30 15:30 – Updated: 2025-04-30 15:30
VLAI
Details

A vulnerability classified as critical was found in Weitong Mall 1.0.0. This vulnerability affects unknown code of the file /queryTotal of the component Product Statistics Handler. The manipulation of the argument isDelete with the input 1 leads to improper access controls. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-4119"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-266",
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-30T14:15:31Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability classified as critical was found in Weitong Mall 1.0.0. This vulnerability affects unknown code of the file /queryTotal of the component Product Statistics Handler. The manipulation of the argument isDelete with the input 1 leads to improper access controls. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.",
  "id": "GHSA-2fj9-fc6x-hgw7",
  "modified": "2025-04-30T15:30:49Z",
  "published": "2025-04-30T15:30:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-4119"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.306604"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.306604"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.560778"
    },
    {
      "type": "WEB",
      "url": "https://www.cnblogs.com/aibot/p/18830908"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/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-2FJJ-QQG8-FG7X

Vulnerability from github – Published: 2026-06-18 14:48 – Updated: 2026-06-18 14:48
VLAI
Summary
praisonai-platform: Authorization Bypass Through User-Controlled Key
Details

Summary

The issue create and update endpoints in praisonai-platform accept a project_id in the request body and persist it without validating that the project belongs to the URL workspace. A user who is a member of workspace W_B (and has no access to workspace W_A) can create issues that reference a project owned by W_A. Because ProjectService.get_stats() aggregates issues by project_id with no workspace constraint, those foreign issues are then counted in the victim's own legitimate view of their project statistics. This is a cross-tenant integrity violation reachable by an outsider.

This is distinct from the path-parameter IDOR family fixed in 0.1.4 (CVE-2026-47415, CVE-2026-47418, CVE-2026-47419). Those fixes scoped object references supplied in the URL path. This report concerns an object reference supplied in the request body at write time, which the 0.1.4 fixes did not cover.

Version 0.1.4 fixed a set of path-parameter IDORs by threading workspace_id into the service-layer lookups (get / update / delete) and by adding the helpers ensure_resource_in_workspace() and require_issue_in_workspace() in api/deps.py. Those helpers are applied to object references that arrive in the URL path. They are not applied to object references that arrive in the request body on create or update.

Details

api/routes/issues.py, create_issue passes the body's project_id straight through with no workspace validation:

@router.post("/", response_model=IssueResponse, status_code=201)
async def create_issue(workspace_id: str, body: IssueCreate,
                       user=Depends(require_workspace_member), session=Depends(get_db)):
    svc = IssueService(session)
    issue = await svc.create(
        workspace_id=workspace_id,
        title=body.title,
        creator_id=user.id,
        project_id=body.project_id,        # attacker-controlled, not validated against workspace_id
        ...
    )

services/issue_service.py, create persists it as-is:

issue = Issue(
    workspace_id=workspace_id,
    project_id=project_id,                 # no check that project_id belongs to workspace_id
    ...
)

services/issue_service.py, update has the identical gap on the update path:

if project_id is not None:
    issue.project_id = project_id          # re-parent to any project, no workspace check

services/project_service.py, get_stats aggregates by project_id only:

async def get_stats(self, project_id: str) -> dict:
    stmt = (
        select(Issue.status, func.count(Issue.id))
        .where(Issue.project_id == project_id)   # no workspace_id constraint
        .group_by(Issue.status)
    )
    ...

Note that the read path is not directly vulnerable. The stats route scopes the project first, so a cross-workspace stats read returns 404:

@router.get("/{project_id}/stats")
async def project_stats(workspace_id, project_id, user=Depends(require_workspace_member), ...):
    project = await svc.get(project_id, workspace_id=workspace_id)   # 404 for a foreign project
    if project is None:
        raise HTTPException(404, "Project not found")
    return await svc.get_stats(project_id)

The pollution therefore enters through the write side (issue create/update accepting a foreign project_id) and surfaces in the victim's own legitimate read of their project statistics.

Proof of concept

Two unrelated users:

  • Alice, member of workspace W_A, owns project P_A.
  • Bob, member of workspace W_B only. Bob has no access to W_A (every direct call to W_A resources returns 403).

Steps:

  1. Alice's project P_A has one in-progress issue. GET /workspaces/W_A/projects/P_A/stats returns {"total": 1, "by_status": {"in_progress": 1}}.

  2. Bob creates issues in his own workspace that reference Alice's project. Repeat 7 times: ```http POST /workspaces/W_B/issues Authorization: Bearer Content-Type: application/json

{"title": "x", "project_id": "P_A", "status": "done"} `` Each returns 201. Each issue is stored withworkspace_id = W_Bandproject_id = P_A`.

  1. Alice reads her own project stats: GET /workspaces/W_A/projects/P_A/stats now returns {"total": 8, "by_status": {"done": 7, "in_progress": 1}}.

Bob is not a member of W_A, yet data he wrote appears in Alice's project dashboard.

Impact

An unauthorized outsider can inflate or skew the issue counts shown in any workspace's project-statistics view, given only the target project_id (a UUID that can be harvested or guessed). The effect is limited to the statistics aggregation; it does not expose the victim's issue contents to the attacker and does not appear in the victim's workspace-scoped issue list. The same unvalidated write path also accepts cross-workspace parent_issue_id and assignee_id values, which have no aggregation read endpoint today but represent the same dangling cross-workspace reference class and should be fixed together.

Suggested fix

On both issue create and update, validate that any body-supplied object reference resolves within the URL workspace before persisting, reusing the existing pattern:

if body.project_id is not None:
    project = await ProjectService(session).get(body.project_id, workspace_id=workspace_id)
    if project is None:
        raise HTTPException(404, "Project not found")

Apply the same check to parent_issue_id (via require_issue_in_workspace) and to assignee_id. As defense in depth, scope get_stats so it only counts issues whose workspace_id matches the project's workspace.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "praisonai-platform"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.1.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T14:48:35Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe issue create and update endpoints in `praisonai-platform` accept a `project_id` in the request body and persist it without validating that the project belongs to the URL workspace. A user who is a member of workspace `W_B` (and has no access to workspace `W_A`) can create issues that reference a project owned by `W_A`. Because `ProjectService.get_stats()` aggregates issues by `project_id` with no workspace constraint, those foreign issues are then counted in the victim\u0027s own legitimate view of their project statistics. This is a cross-tenant integrity violation reachable by an outsider.\n\nThis is distinct from the path-parameter IDOR family fixed in 0.1.4 (CVE-2026-47415, CVE-2026-47418, CVE-2026-47419). Those fixes scoped object references supplied in the URL path. This report concerns an object reference supplied in the request body at write time, which the 0.1.4 fixes did not cover.\n\nVersion 0.1.4 fixed a set of path-parameter IDORs by threading `workspace_id` into the service-layer lookups (`get` / `update` / `delete`) and by adding the helpers `ensure_resource_in_workspace()` and `require_issue_in_workspace()` in `api/deps.py`. Those helpers are applied to object references that arrive in the URL path. They are not applied to object references that arrive in the request body on create or update.\n\n## Details\n\n`api/routes/issues.py`, `create_issue` passes the body\u0027s `project_id` straight through with no workspace validation:\n\n```python\n@router.post(\"/\", response_model=IssueResponse, status_code=201)\nasync def create_issue(workspace_id: str, body: IssueCreate,\n                       user=Depends(require_workspace_member), session=Depends(get_db)):\n    svc = IssueService(session)\n    issue = await svc.create(\n        workspace_id=workspace_id,\n        title=body.title,\n        creator_id=user.id,\n        project_id=body.project_id,        # attacker-controlled, not validated against workspace_id\n        ...\n    )\n```\n\n`services/issue_service.py`, `create` persists it as-is:\n\n```python\nissue = Issue(\n    workspace_id=workspace_id,\n    project_id=project_id,                 # no check that project_id belongs to workspace_id\n    ...\n)\n```\n\n`services/issue_service.py`, `update` has the identical gap on the update path:\n\n```python\nif project_id is not None:\n    issue.project_id = project_id          # re-parent to any project, no workspace check\n```\n\n`services/project_service.py`, `get_stats` aggregates by `project_id` only:\n\n```python\nasync def get_stats(self, project_id: str) -\u003e dict:\n    stmt = (\n        select(Issue.status, func.count(Issue.id))\n        .where(Issue.project_id == project_id)   # no workspace_id constraint\n        .group_by(Issue.status)\n    )\n    ...\n```\n\nNote that the read path is not directly vulnerable. The stats route scopes the project first, so a cross-workspace stats read returns 404:\n\n```python\n@router.get(\"/{project_id}/stats\")\nasync def project_stats(workspace_id, project_id, user=Depends(require_workspace_member), ...):\n    project = await svc.get(project_id, workspace_id=workspace_id)   # 404 for a foreign project\n    if project is None:\n        raise HTTPException(404, \"Project not found\")\n    return await svc.get_stats(project_id)\n```\n\nThe pollution therefore enters through the write side (issue create/update accepting a foreign `project_id`) and surfaces in the victim\u0027s own legitimate read of their project statistics.\n\n## Proof of concept\n\nTwo unrelated users:\n\n- Alice, member of workspace `W_A`, owns project `P_A`.\n- Bob, member of workspace `W_B` only. Bob has no access to `W_A` (every direct call to `W_A` resources returns 403).\n\nSteps:\n\n1. Alice\u0027s project `P_A` has one in-progress issue.\n   `GET /workspaces/W_A/projects/P_A/stats` returns `{\"total\": 1, \"by_status\": {\"in_progress\": 1}}`.\n\n2. Bob creates issues in his own workspace that reference Alice\u0027s project. Repeat 7 times:\n   ```http\n   POST /workspaces/W_B/issues\n   Authorization: Bearer \u003cBob\u0027s token\u003e\n   Content-Type: application/json\n\n   {\"title\": \"x\", \"project_id\": \"P_A\", \"status\": \"done\"}\n   ```\n   Each returns 201. Each issue is stored with `workspace_id = W_B` and `project_id = P_A`.\n\n3. Alice reads her own project stats:\n   `GET /workspaces/W_A/projects/P_A/stats` now returns\n   `{\"total\": 8, \"by_status\": {\"done\": 7, \"in_progress\": 1}}`.\n\nBob is not a member of `W_A`, yet data he wrote appears in Alice\u0027s project dashboard.\n\n## Impact\n\nAn unauthorized outsider can inflate or skew the issue counts shown in any workspace\u0027s project-statistics view, given only the target `project_id` (a UUID that can be harvested or guessed). The effect is limited to the statistics aggregation; it does not expose the victim\u0027s issue contents to the attacker and does not appear in the victim\u0027s workspace-scoped issue list. The same unvalidated write path also accepts cross-workspace `parent_issue_id` and `assignee_id` values, which have no aggregation read endpoint today but represent the same dangling cross-workspace reference class and should be fixed together.\n\n## Suggested fix\n\nOn both issue create and update, validate that any body-supplied object reference resolves within the URL workspace before persisting, reusing the existing pattern:\n\n```python\nif body.project_id is not None:\n    project = await ProjectService(session).get(body.project_id, workspace_id=workspace_id)\n    if project is None:\n        raise HTTPException(404, \"Project not found\")\n```\n\nApply the same check to `parent_issue_id` (via `require_issue_in_workspace`) and to `assignee_id`. As defense in depth, scope `get_stats` so it only counts issues whose `workspace_id` matches the project\u0027s workspace.",
  "id": "GHSA-2fjj-qqg8-fg7x",
  "modified": "2026-06-18T14:48:35Z",
  "published": "2026-06-18T14:48:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-2fjj-qqg8-fg7x"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MervinPraison/PraisonAI"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "praisonai-platform: Authorization Bypass Through User-Controlled Key"
}

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.