Common Weakness Enumeration

CWE-639

Allowed

Authorization Bypass Through User-Controlled Key

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

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.

3206 vulnerabilities reference this CWE, most recent first.

GHSA-XVRF-3569-2X76

Vulnerability from github – Published: 2024-04-24 12:30 – Updated: 2025-02-04 18:30
VLAI
Details

Authorization Bypass Through User-Controlled Key vulnerability in Metagauss ProfileGrid.This issue affects ProfileGrid : from n/a through 5.7.9.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-32772"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-24T11:15:47Z",
    "severity": "MODERATE"
  },
  "details": "Authorization Bypass Through User-Controlled Key vulnerability in Metagauss ProfileGrid.This issue affects ProfileGrid : from n/a through 5.7.9.",
  "id": "GHSA-xvrf-3569-2x76",
  "modified": "2025-02-04T18:30:45Z",
  "published": "2024-04-24T12:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32772"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/profilegrid-user-profiles-groups-and-communities/wordpress-profilegrid-plugin-5-7-9-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-XWQ8-FRCG-77Q8

Vulnerability from github – Published: 2026-06-01 14:24 – Updated: 2026-06-01 14:24
VLAI
Summary
praisonai-platform: Issue endpoints accept any issue_id without workspace ownership check, cross-workspace read/update/delete IDOR
Details

Summary

Type: Insecure Direct Object Reference. The issue CRUD endpoints (GET / PATCH / DELETE /workspaces/{workspace_id}/issues/{issue_id}) gate access on require_workspace_member(workspace_id) only, then resolve issue_id through IssueService.get(issue_id) which is a primary-key lookup with no workspace constraint. A user who is a member of any workspace W1 can read, modify, or delete issues that belong to a different workspace W2. File: src/praisonai-platform/praisonai_platform/services/issue_service.py, lines 72-156; route handlers at src/praisonai-platform/praisonai_platform/api/routes/issues.py, lines 82-137. Root cause: the route extracts workspace_id from the URL path, uses it solely for the membership gate, then calls IssueService.get(issue_id) / IssueService.update(issue_id, ...) / IssueService.delete(issue_id) without re-checking which workspace the issue actually belongs to. IssueService.get runs a single-key lookup; update and delete call self.get(issue_id) first and then mutate the returned row, inheriting the same gap. The MemberService in this same codebase uses a composite (workspace_id, user_id) key, proving the author knows the safe pattern; it was simply not applied to the issue, agent, project, comment, or label services.

Affected Code

File 1: src/praisonai-platform/praisonai_platform/services/issue_service.py, lines 72-75 and 97-156.

class IssueService:
    ...

    async def get(self, issue_id: str) -> Optional[Issue]:
        """Get issue by ID."""
        return await self._session.get(Issue, issue_id)             # <-- BUG: no workspace_id predicate

    async def update(
        self,
        issue_id: str,
        title: Optional[str] = None,
        ...
    ) -> Optional[Issue]:
        issue = await self.get(issue_id)                            # <-- inherits the same gap
        if issue is None:
            return None
        ...
        return issue

    async def delete(self, issue_id: str) -> bool:
        issue = await self.get(issue_id)                            # <-- inherits the same gap
        if issue is None:
            return False
        await self._session.delete(issue)
        await self._session.flush()
        return True

File 2: src/praisonai-platform/praisonai_platform/api/routes/issues.py, lines 82-137.

@router.get("/{issue_id}", response_model=IssueResponse)
async def get_issue(
    workspace_id: str,
    issue_id: str,
    user: AuthIdentity = Depends(require_workspace_member),         # only checks membership in workspace_id
    session: AsyncSession = Depends(get_db),
):
    svc = IssueService(session)
    issue = await svc.get(issue_id)                                 # <-- workspace_id never threaded through
    if issue is None:
        raise HTTPException(status_code=404, detail="Issue not found")
    return IssueResponse.model_validate(issue)


@router.patch("/{issue_id}", response_model=IssueResponse)
async def update_issue(
    workspace_id: str,
    issue_id: str,
    body: IssueUpdate,
    user: AuthIdentity = Depends(require_workspace_member),
    session: AsyncSession = Depends(get_db),
):
    svc = IssueService(session)
    issue = await svc.update(                                       # <-- writes to any issue in the DB
        issue_id, title=body.title, description=body.description,
        status=body.status, priority=body.priority,
        assignee_type=body.assignee_type, assignee_id=body.assignee_id,
        project_id=body.project_id,
    )
    ...

delete_issue (lines 127-137) repeats the pattern.

Why it's wrong: workspace_id from the route is used solely as a membership predicate ("are you in some workspace W?"), never as a resource-ownership predicate ("is the issue you are addressing actually inside W?"). The standard FastAPI/SQLAlchemy fix is to make the resource-lookup query include the workspace constraint and treat absence as 404, so a foreign-workspace issue is indistinguishable from a non-existent one. The update_issue handler additionally allows the attacker to overwrite project_id, which can re-assign the foreign issue to an unrelated project the attacker also does not own — escalating the scope of the write primitive.

Exploit Chain

  1. Attacker registers a workspace W_attacker (where they are a member) and harvests a target issue UUID I_T from any side channel: the activity feed (activity.py:log records issue_id=...), comment threads, error messages, exported issue dumps, issue mentions in agent prompts, or operator screenshots. Issue IDs are uuid4 strings but they are not secret. State: attacker holds I_T.
  2. Attacker authenticates and POSTs Authorization: Bearer <attacker_jwt> to GET /workspaces/W_attacker/issues/I_T. require_workspace_member(W_attacker, attacker) passes (attacker is a member of W_attacker). State: control flow enters get_issue with workspace_id=W_attacker, issue_id=I_T.
  3. IssueService.get(I_T) runs session.get(Issue, "I_T"), which is SELECT * FROM issues WHERE id = 'I_T' LIMIT 1 with no workspace_id = 'W_attacker' filter. The row is returned in full — including title, description (often confidential bug-report content, customer PII, embedded credentials, or internal roadmap data), status, priority, assignee_id, created_by, and project_id. State: response body is the JSON-serialised foreign issue.
  4. Attacker repeats with PATCH /workspaces/W_attacker/issues/I_T and a body of {"description": "<reset>", "status": "closed", "project_id": "<arbitrary>"}. update_issue calls svc.update(I_T, ...) which loads the target row and mutates the listed fields. State: the foreign workspace's issue is silently re-described, re-statused, and re-projected.
  5. Attacker calls DELETE /workspaces/W_attacker/issues/I_T to destroy the target issue. IssueService.delete loads the row and calls session.delete(). State: target issue is gone from the foreign workspace.
  6. Final state: any attacker with one workspace-member token can enumerate, exfiltrate, rewrite, and delete every issue in the multi-tenant deployment given the issue UUIDs (which leak through the side channels above). The act_svc.log(workspace_id, "issue.updated", "issue", issue.id, ...) call at line 118 records the event under W_attacker rather than W_target, so the foreign workspace's audit trail does not record the tampering — making detection harder.

Security Impact

Severity: sec-high. CVSS 8.1: network attack, low complexity, low privileges (any workspace member), no user interaction, scope unchanged, high confidentiality (full issue body including any embedded secrets), high integrity (arbitrary writes including project re-assignment), low availability (DELETE wipes target issues). Attacker capability: with one workspace-member token plus a harvested issue UUID, an attacker reads the target issue's title, description, status, priority, assignee_id, and project_id; rewrites any of those fields (silent edit, false closure, malicious re-assignment); re-projects the issue to an unrelated project to confuse triagers; or deletes the issue altogether to destroy evidence of customer reports. Preconditions: praisonai-platform is deployed multi-tenant; the attacker has any membership token; the target issue's UUID is known or guessable (UUIDs leak through activity feeds, comment threads, error messages, exported dumps, and operator screenshots). Differential: source-inspection-verified end-to-end. The asymmetry between IssueService.get(issue_id) (no workspace check) and MemberService.get(workspace_id, user_id) (composite key check) in the same codebase confirms the pattern. With the suggested fix below applied, IssueService.get(workspace_id, issue_id) returns None for foreign-workspace issues, the route handler returns 404, and the foreign data is indistinguishable from a missing record.

Suggested Fix

Make every single-row resource lookup take the workspace predicate; treat foreign-workspace rows as 404.

--- a/src/praisonai-platform/praisonai_platform/services/issue_service.py
+++ b/src/praisonai-platform/praisonai_platform/services/issue_service.py
@@ -69,9 +69,12 @@ class IssueService:
         await self._session.flush()
         return issue

-    async def get(self, issue_id: str) -> Optional[Issue]:
-        """Get issue by ID."""
-        return await self._session.get(Issue, issue_id)
+    async def get(self, workspace_id: str, issue_id: str) -> Optional[Issue]:
+        """Get issue by ID, scoped to a workspace."""
+        stmt = select(Issue).where(
+            Issue.id == issue_id, Issue.workspace_id == workspace_id
+        )
+        return (await self._session.execute(stmt)).scalar_one_or_none()

     async def update(
         self,
+        workspace_id: str,
         issue_id: str,
         ...
     ) -> Optional[Issue]:
-        issue = await self.get(issue_id)
+        issue = await self.get(workspace_id, issue_id)
         ...

-    async def delete(self, issue_id: str) -> bool:
+    async def delete(self, workspace_id: str, issue_id: str) -> bool:
-        issue = await self.get(issue_id)
+        issue = await self.get(workspace_id, issue_id)

Update the route handlers in routes/issues.py to thread workspace_id through. The same pattern (single-key resource lookup gated only by workspace-member check) exists in AgentService, ProjectService, CommentService, and LabelService; each is a separate exploitable IDOR and should be filed as its own advisory so each gets a CVE.

Severity
8.3 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "praisonai-platform"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47415"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-01T14:24:12Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\n**Type:** Insecure Direct Object Reference. The issue CRUD endpoints (`GET / PATCH / DELETE /workspaces/{workspace_id}/issues/{issue_id}`) gate access on `require_workspace_member(workspace_id)` only, then resolve `issue_id` through `IssueService.get(issue_id)` which is a primary-key lookup with no workspace constraint. A user who is a member of any workspace `W1` can read, modify, or delete issues that belong to a different workspace `W2`.\n**File:** `src/praisonai-platform/praisonai_platform/services/issue_service.py`, lines 72-156; route handlers at `src/praisonai-platform/praisonai_platform/api/routes/issues.py`, lines 82-137.\n**Root cause:** the route extracts `workspace_id` from the URL path, uses it solely for the membership gate, then calls `IssueService.get(issue_id)` / `IssueService.update(issue_id, ...)` / `IssueService.delete(issue_id)` without re-checking which workspace the issue actually belongs to. `IssueService.get` runs a single-key lookup; `update` and `delete` call `self.get(issue_id)` first and then mutate the returned row, inheriting the same gap. The `MemberService` in this same codebase uses a composite `(workspace_id, user_id)` key, proving the author knows the safe pattern; it was simply not applied to the issue, agent, project, comment, or label services.\n\n## Affected Code\n\n**File 1:** `src/praisonai-platform/praisonai_platform/services/issue_service.py`, lines 72-75 and 97-156.\n\n```python\nclass IssueService:\n    ...\n\n    async def get(self, issue_id: str) -\u003e Optional[Issue]:\n        \"\"\"Get issue by ID.\"\"\"\n        return await self._session.get(Issue, issue_id)             # \u003c-- BUG: no workspace_id predicate\n\n    async def update(\n        self,\n        issue_id: str,\n        title: Optional[str] = None,\n        ...\n    ) -\u003e Optional[Issue]:\n        issue = await self.get(issue_id)                            # \u003c-- inherits the same gap\n        if issue is None:\n            return None\n        ...\n        return issue\n\n    async def delete(self, issue_id: str) -\u003e bool:\n        issue = await self.get(issue_id)                            # \u003c-- inherits the same gap\n        if issue is None:\n            return False\n        await self._session.delete(issue)\n        await self._session.flush()\n        return True\n```\n\n**File 2:** `src/praisonai-platform/praisonai_platform/api/routes/issues.py`, lines 82-137.\n\n```python\n@router.get(\"/{issue_id}\", response_model=IssueResponse)\nasync def get_issue(\n    workspace_id: str,\n    issue_id: str,\n    user: AuthIdentity = Depends(require_workspace_member),         # only checks membership in workspace_id\n    session: AsyncSession = Depends(get_db),\n):\n    svc = IssueService(session)\n    issue = await svc.get(issue_id)                                 # \u003c-- workspace_id never threaded through\n    if issue is None:\n        raise HTTPException(status_code=404, detail=\"Issue not found\")\n    return IssueResponse.model_validate(issue)\n\n\n@router.patch(\"/{issue_id}\", response_model=IssueResponse)\nasync def update_issue(\n    workspace_id: str,\n    issue_id: str,\n    body: IssueUpdate,\n    user: AuthIdentity = Depends(require_workspace_member),\n    session: AsyncSession = Depends(get_db),\n):\n    svc = IssueService(session)\n    issue = await svc.update(                                       # \u003c-- writes to any issue in the DB\n        issue_id, title=body.title, description=body.description,\n        status=body.status, priority=body.priority,\n        assignee_type=body.assignee_type, assignee_id=body.assignee_id,\n        project_id=body.project_id,\n    )\n    ...\n```\n\n`delete_issue` (lines 127-137) repeats the pattern.\n\n**Why it\u0027s wrong:** `workspace_id` from the route is used solely as a membership predicate (\"are you in some workspace W?\"), never as a resource-ownership predicate (\"is the issue you are addressing actually inside W?\"). The standard FastAPI/SQLAlchemy fix is to make the resource-lookup query include the workspace constraint and treat absence as 404, so a foreign-workspace issue is indistinguishable from a non-existent one. The `update_issue` handler additionally allows the attacker to overwrite `project_id`, which can re-assign the foreign issue to an unrelated project the attacker also does not own \u2014 escalating the scope of the write primitive.\n\n## Exploit Chain\n\n1. Attacker registers a workspace `W_attacker` (where they are a member) and harvests a target issue UUID `I_T` from any side channel: the activity feed (`activity.py:log` records `issue_id=...`), comment threads, error messages, exported issue dumps, issue mentions in agent prompts, or operator screenshots. Issue IDs are uuid4 strings but they are not secret. State: attacker holds `I_T`.\n2. Attacker authenticates and POSTs `Authorization: Bearer \u003cattacker_jwt\u003e` to `GET /workspaces/W_attacker/issues/I_T`. `require_workspace_member(W_attacker, attacker)` passes (attacker is a member of `W_attacker`). State: control flow enters `get_issue` with `workspace_id=W_attacker, issue_id=I_T`.\n3. `IssueService.get(I_T)` runs `session.get(Issue, \"I_T\")`, which is `SELECT * FROM issues WHERE id = \u0027I_T\u0027 LIMIT 1` with no `workspace_id = \u0027W_attacker\u0027` filter. The row is returned in full \u2014 including `title`, `description` (often confidential bug-report content, customer PII, embedded credentials, or internal roadmap data), `status`, `priority`, `assignee_id`, `created_by`, and `project_id`. State: response body is the JSON-serialised foreign issue.\n4. Attacker repeats with `PATCH /workspaces/W_attacker/issues/I_T` and a body of `{\"description\": \"\u003creset\u003e\", \"status\": \"closed\", \"project_id\": \"\u003carbitrary\u003e\"}`. `update_issue` calls `svc.update(I_T, ...)` which loads the target row and mutates the listed fields. State: the foreign workspace\u0027s issue is silently re-described, re-statused, and re-projected.\n5. Attacker calls `DELETE /workspaces/W_attacker/issues/I_T` to destroy the target issue. `IssueService.delete` loads the row and calls `session.delete()`. State: target issue is gone from the foreign workspace.\n6. Final state: any attacker with one workspace-member token can enumerate, exfiltrate, rewrite, and delete every issue in the multi-tenant deployment given the issue UUIDs (which leak through the side channels above). The `act_svc.log(workspace_id, \"issue.updated\", \"issue\", issue.id, ...)` call at line 118 records the event under `W_attacker` rather than `W_target`, so the foreign workspace\u0027s audit trail does not record the tampering \u2014 making detection harder.\n\n## Security Impact\n\n**Severity:** sec-high. CVSS 8.1: network attack, low complexity, low privileges (any workspace member), no user interaction, scope unchanged, high confidentiality (full issue body including any embedded secrets), high integrity (arbitrary writes including project re-assignment), low availability (DELETE wipes target issues).\n**Attacker capability:** with one workspace-member token plus a harvested issue UUID, an attacker reads the target issue\u0027s `title`, `description`, `status`, `priority`, `assignee_id`, and `project_id`; rewrites any of those fields (silent edit, false closure, malicious re-assignment); re-projects the issue to an unrelated project to confuse triagers; or deletes the issue altogether to destroy evidence of customer reports.\n**Preconditions:** `praisonai-platform` is deployed multi-tenant; the attacker has any membership token; the target issue\u0027s UUID is known or guessable (UUIDs leak through activity feeds, comment threads, error messages, exported dumps, and operator screenshots).\n**Differential:** source-inspection-verified end-to-end. The asymmetry between `IssueService.get(issue_id)` (no workspace check) and `MemberService.get(workspace_id, user_id)` (composite key check) in the same codebase confirms the pattern. With the suggested fix below applied, `IssueService.get(workspace_id, issue_id)` returns `None` for foreign-workspace issues, the route handler returns 404, and the foreign data is indistinguishable from a missing record.\n\n## Suggested Fix\n\nMake every single-row resource lookup take the workspace predicate; treat foreign-workspace rows as 404.\n\n```diff\n--- a/src/praisonai-platform/praisonai_platform/services/issue_service.py\n+++ b/src/praisonai-platform/praisonai_platform/services/issue_service.py\n@@ -69,9 +69,12 @@ class IssueService:\n         await self._session.flush()\n         return issue\n\n-    async def get(self, issue_id: str) -\u003e Optional[Issue]:\n-        \"\"\"Get issue by ID.\"\"\"\n-        return await self._session.get(Issue, issue_id)\n+    async def get(self, workspace_id: str, issue_id: str) -\u003e Optional[Issue]:\n+        \"\"\"Get issue by ID, scoped to a workspace.\"\"\"\n+        stmt = select(Issue).where(\n+            Issue.id == issue_id, Issue.workspace_id == workspace_id\n+        )\n+        return (await self._session.execute(stmt)).scalar_one_or_none()\n\n     async def update(\n         self,\n+        workspace_id: str,\n         issue_id: str,\n         ...\n     ) -\u003e Optional[Issue]:\n-        issue = await self.get(issue_id)\n+        issue = await self.get(workspace_id, issue_id)\n         ...\n\n-    async def delete(self, issue_id: str) -\u003e bool:\n+    async def delete(self, workspace_id: str, issue_id: str) -\u003e bool:\n-        issue = await self.get(issue_id)\n+        issue = await self.get(workspace_id, issue_id)\n```\n\nUpdate the route handlers in `routes/issues.py` to thread `workspace_id` through. The same pattern (single-key resource lookup gated only by workspace-member check) exists in `AgentService`, `ProjectService`, `CommentService`, and `LabelService`; each is a separate exploitable IDOR and should be filed as its own advisory so each gets a CVE.",
  "id": "GHSA-xwq8-frcg-77q8",
  "modified": "2026-06-01T14:24:12Z",
  "published": "2026-06-01T14:24:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-xwq8-frcg-77q8"
    },
    {
      "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:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "praisonai-platform: Issue endpoints accept any issue_id without workspace ownership check, cross-workspace read/update/delete IDOR"
}

GHSA-XXCG-MCHR-FPH7

Vulnerability from github – Published: 2025-09-16 15:32 – Updated: 2026-06-05 15:32
VLAI
Details

Authorization Bypass Through User-Controlled Key vulnerability with user privileges in ArgusTech BILGER allows Exploitation of Trusted Identifiers.This issue affects BILGER: before 2.4.6.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-5518"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-16T08:15:43Z",
    "severity": "MODERATE"
  },
  "details": "Authorization Bypass Through User-Controlled Key vulnerability with user privileges in ArgusTech BILGER allows Exploitation of Trusted Identifiers.This issue affects BILGER: before 2.4.6.",
  "id": "GHSA-xxcg-mchr-fph7",
  "modified": "2026-06-05T15:32:04Z",
  "published": "2025-09-16T15:32:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5518"
    },
    {
      "type": "WEB",
      "url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-25-0250"
    },
    {
      "type": "WEB",
      "url": "https://www.usom.gov.tr/bildirim/tr-25-0250"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XXCH-MF4J-QCVJ

Vulnerability from github – Published: 2023-03-24 06:30 – Updated: 2025-02-20 00:32
VLAI
Details

Dino before 0.2.3, 0.3.x before 0.3.2, and 0.4.x before 0.4.2 allows attackers to modify the personal bookmark store via a crafted message. The attacker can change the display of group chats or force a victim to join a group chat; the victim may then be tricked into disclosing sensitive information.

Severity
7.1 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-28686"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-03-24T04:15:00Z",
    "severity": "HIGH"
  },
  "details": "Dino before 0.2.3, 0.3.x before 0.3.2, and 0.4.x before 0.4.2 allows attackers to modify the personal bookmark store via a crafted message. The attacker can change the display of group chats or force a victim to join a group chat; the victim may then be tricked into disclosing sensitive information.",
  "id": "GHSA-xxch-mf4j-qcvj",
  "modified": "2025-02-20T00:32:02Z",
  "published": "2023-03-24T06:30:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28686"
    },
    {
      "type": "WEB",
      "url": "https://dino.im/security/cve-2023-28686"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/BQLCEUZS5GPHUQMS7C6W2NS3PHYUFHYF"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GOH6NYTLPM52MDIR2IRVUR3REDVWZV6N"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IIWXAK656EHSRIRUHLPBE3AX2I4TMH7M"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/BQLCEUZS5GPHUQMS7C6W2NS3PHYUFHYF"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GOH6NYTLPM52MDIR2IRVUR3REDVWZV6N"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/IIWXAK656EHSRIRUHLPBE3AX2I4TMH7M"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2023/dsa-5379"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XXPJ-Q764-9R6Q

Vulnerability from github – Published: 2026-06-05 16:22 – Updated: 2026-06-05 16:22
VLAI
Summary
NocoDB: Missing Ownership Check in MCP Attachment Read
Details

Summary

A low-privilege MCP token holder with knowledge of an attachment path could read any file in shared storage, including attachments belonging to other bases and workspaces, because the MCP readAttachment tool did not verify the file's ownership.

Details

The MCP readAttachment tool accepts caller-supplied path/url values and streams the file via the storage adapter. The handler now looks up the path in nc_file_references and requires a non-deleted row whose base_id matches the caller's MCP context before streaming; otherwise it returns Attachment is not accessible from this MCP context. The lookup tolerates both download/uploads/... and uploads/... styles.

Impact

Arbitrary read against shared storage scoped to attachments the caller's MCP context should not see. Exploitation requires an MCP token and a known attachment path.

Credit

This issue was reported by @helwor-01.

Severity
2.3 (Low)
CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.05.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "nocodb"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.05.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47388"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-05T16:22:28Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Summary\nA low-privilege MCP token holder with knowledge of an attachment path could read any\nfile in shared storage, including attachments belonging to other bases and workspaces,\nbecause the MCP `readAttachment` tool did not verify the file\u0027s ownership.\n\n### Details\nThe MCP `readAttachment` tool accepts caller-supplied `path`/`url` values and streams\nthe file via the storage adapter. The handler now looks up the path in\n`nc_file_references` and requires a non-deleted row whose `base_id` matches the\ncaller\u0027s MCP context before streaming; otherwise it returns\n`Attachment is not accessible from this MCP context`. The lookup tolerates both\n`download/uploads/...` and `uploads/...` styles.\n\n### Impact\nArbitrary read against shared storage scoped to attachments the caller\u0027s MCP context\nshould not see. Exploitation requires an MCP token and a known attachment path.\n\n### Credit\nThis issue was reported by [@helwor-01](https://github.com/helwor-01).",
  "id": "GHSA-xxpj-q764-9r6q",
  "modified": "2026-06-05T16:22:29Z",
  "published": "2026-06-05T16:22:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nocodb/nocodb/security/advisories/GHSA-xxpj-q764-9r6q"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nocodb/nocodb"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nocodb/nocodb/releases/tag/2026.05.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "NocoDB: Missing Ownership Check in MCP Attachment Read"
}

GHSA-XXWR-WV9G-7JW3

Vulnerability from github – Published: 2025-05-21 17:19 – Updated: 2025-05-21 19:05
VLAI
Summary
The femanager TYPO3 extension allows Insecure Direct Object Reference
Details

Insecure Direct Object Reference (IDOR) in the femanager TYPO3 extension allows attackers to view frontend user data via a user parameter in the newAction of the newController.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N/E:F/RL:O/RC:C
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "in2code/femanager"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "8.2.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "in2code/femanager"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "in2code/femanager"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "in2code/femanager"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.5.0"
            },
            {
              "fixed": "5.5.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-48202"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-425",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-05-21T17:19:30Z",
    "nvd_published_at": "2025-05-21T16:15:32Z",
    "severity": "MODERATE"
  },
  "details": "Insecure Direct Object Reference (IDOR) in the femanager TYPO3 extension allows attackers to view frontend user data via a user parameter in the newAction of the newController.",
  "id": "GHSA-xxwr-wv9g-7jw3",
  "modified": "2025-05-21T19:05:14Z",
  "published": "2025-05-21T17:19:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48202"
    },
    {
      "type": "WEB",
      "url": "https://github.com/in2code-de/femanager/commit/54851f8f60254bd8060bdf7bc16d56f4de7bd828"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/in2code/femanager/CVE-2025-48202.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/in2code-de/femanager"
    },
    {
      "type": "WEB",
      "url": "https://typo3.org/security/advisory/typo3-ext-sa-2025-006"
    }
  ],
  "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/E:F/RL:O/RC:C",
      "type": "CVSS_V3"
    }
  ],
  "summary": "The femanager TYPO3 extension allows Insecure Direct Object Reference"
}
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.

← Back to the CWE list