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.

5491 vulnerabilities reference this CWE, most recent first.

GHSA-5JVJ-HXMH-6H6J

Vulnerability from github – Published: 2026-03-29 15:46 – Updated: 2026-04-10 17:26
VLAI
Summary
OpenClaw: Gateway HTTP Session History Route Bypasses Operator Read Scope
Details

Summary

Gateway HTTP Session History Route Bypasses Operator Read Scope

Affected Packages / Versions

  • Package: openclaw
  • Affected versions: <= 2026.3.24
  • First patched version: 2026.3.25
  • Latest published npm version at verification time: 2026.3.24

Details

The HTTP /sessions/:sessionKey/history route previously authenticated bearer tokens but skipped the same operator.read check used by chat.history over WebSocket. Commit 1c45123231516fa50f8cf8522ba5ff2fb2ca7aea makes HTTP callers declare operator scopes and rejects history reads that do not include operator.read.

Verified vulnerable on tag v2026.3.24 and fixed on main by commit 1c45123231516fa50f8cf8522ba5ff2fb2ca7aea.

Fix Commit(s)

  • 1c45123231516fa50f8cf8522ba5ff2fb2ca7aea
Severity
5.3 (Medium)
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
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.3.24"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.25"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-35657"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-29T15:46:40Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nGateway HTTP Session History Route Bypasses Operator Read Scope\n\n## Affected Packages / Versions\n\n- Package: `openclaw`\n- Affected versions: `\u003c= 2026.3.24`\n- First patched version: `2026.3.25`\n- Latest published npm version at verification time: `2026.3.24`\n\n## Details\n\nThe HTTP `/sessions/:sessionKey/history` route previously authenticated bearer tokens but skipped the same `operator.read` check used by `chat.history` over WebSocket. Commit `1c45123231516fa50f8cf8522ba5ff2fb2ca7aea` makes HTTP callers declare operator scopes and rejects history reads that do not include `operator.read`.\n\nVerified vulnerable on tag `v2026.3.24` and fixed on `main` by commit `1c45123231516fa50f8cf8522ba5ff2fb2ca7aea`.\n\n## Fix Commit(s)\n\n- `1c45123231516fa50f8cf8522ba5ff2fb2ca7aea`",
  "id": "GHSA-5jvj-hxmh-6h6j",
  "modified": "2026-04-10T17:26:09Z",
  "published": "2026-03-29T15:46:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-5jvj-hxmh-6h6j"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/1c45123231516fa50f8cf8522ba5ff2fb2ca7aea"
    },
    {
      "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:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Gateway HTTP Session History Route Bypasses Operator Read Scope"
}

GHSA-5JX9-W35F-VP65

Vulnerability from github – Published: 2026-05-29 22:51 – Updated: 2026-05-29 22:51
VLAI
Summary
praisonai-platform: Label endpoints' unchecked label_id/issue_id enable cross-workspace label IDOR (edit, delete, link)
Details

Summary

Type: Insecure Direct Object Reference. Five label endpoints — PATCH /workspaces/{workspace_id}/labels/{label_id}, DELETE .../labels/{label_id}, POST .../issues/{issue_id}/labels/{label_id}, DELETE .../issues/{issue_id}/labels/{label_id}, GET .../issues/{issue_id}/labels — gate access on require_workspace_member(workspace_id) only and pass URL-supplied label_id and issue_id straight through to LabelService without verifying either belongs to the workspace. File: src/praisonai-platform/praisonai_platform/services/label_service.py, lines 35-100; route handlers at src/praisonai-platform/praisonai_platform/api/routes/labels.py, lines 42-106. Root cause: identical pattern to the agent / issue / project / comment IDORs in this codebase: the route's workspace_id is used as a membership predicate but never threaded through to the service layer. LabelService.get(label_id) runs session.get(IssueLabel, label_id) with no workspace filter; update/delete inherit the gap; add_to_issue(issue_id, label_id) and remove_from_issue(issue_id, label_id) write/delete association rows without verifying either ID belongs to the membership-checked workspace; list_for_issue(issue_id) reads them.

Affected Code

File 1: src/praisonai-platform/praisonai_platform/services/label_service.py, lines 35-100.

class LabelService:
    ...

    async def get(self, label_id: str) -> Optional[IssueLabel]:
        return await self._session.get(IssueLabel, label_id)         # <-- BUG: no workspace_id predicate

    async def update(
        self,
        label_id: str,
        ...
    ) -> Optional[IssueLabel]:
        label = await self.get(label_id)                             # <-- inherits the gap
        ...

    async def delete(self, label_id: str) -> bool:
        label = await self.get(label_id)                             # <-- inherits the gap
        ...

    async def add_to_issue(self, issue_id: str, label_id: str) -> None:
        # writes a row in issue_label association table; no workspace check on either id

    async def remove_from_issue(self, issue_id: str, label_id: str) -> None:
        # deletes from association table; no workspace check on either id

    async def list_for_issue(self, issue_id: str) -> list[IssueLabel]:
        # reads from association table; no workspace check on issue_id

File 2: src/praisonai-platform/praisonai_platform/api/routes/labels.py, lines 42-106.

@router.patch("/labels/{label_id}", response_model=LabelResponse)
async def update_label(workspace_id: str, label_id: str, body: LabelUpdate, ...):
    svc = LabelService(session)
    label = await svc.update(label_id, body.name, body.color)        # <-- writes any label in the DB
    ...

@router.delete("/labels/{label_id}", ...)
async def delete_label(workspace_id: str, label_id: str, ...):
    deleted = await svc.delete(label_id)                             # <-- deletes any label in the DB
    ...

@router.post("/issues/{issue_id}/labels/{label_id}", ...)
async def add_label_to_issue(workspace_id: str, issue_id: str, label_id: str, ...):
    await svc.add_to_issue(issue_id, label_id)                       # <-- attaches any label to any issue cross-workspace

@router.delete("/issues/{issue_id}/labels/{label_id}", ...)
async def remove_label_from_issue(workspace_id: str, issue_id: str, label_id: str, ...):
    await svc.remove_from_issue(issue_id, label_id)                  # <-- detaches any label from any issue cross-workspace

@router.get("/issues/{issue_id}/labels", ...)
async def list_issue_labels(workspace_id: str, issue_id: str, ...):
    labels = await svc.list_for_issue(issue_id)                      # <-- reads label assignments for any issue

Why it's wrong: the workspace_id URL segment is treated as a UI hint; the actual label_id and issue_id lookups query the database without a workspace constraint. The MemberService in this same codebase uses a composite key correctly; the label service does not. The add_to_issue and remove_from_issue paths are particularly nasty because they touch two unverified IDs at once: an attacker can attach a foreign workspace's label to a foreign workspace's issue (or detach the legitimate labels), corrupting both sides of an association the attacker has no business touching.

Exploit Chain

  1. Attacker registers a workspace W_attacker (member) and harvests a foreign-workspace label_id L_T and a foreign-workspace issue_id I_T. Both leak via list_labels responses (which include label IDs — but only for W_attacker; for the target the IDs come from issue records that include label associations, activity feeds, exported dumps, error messages). State: attacker holds L_T and I_T.
  2. Attacker authenticates and sends PATCH /workspaces/W_attacker/labels/L_T with {"name": "<deleted>", "color": "#000000"}. require_workspace_member(W_attacker, attacker) passes. LabelService.update(L_T, ...) loads the foreign label and renames it. State: every issue across the foreign workspace that bears this label now displays the attacker-chosen name and colour.
  3. Attacker sends DELETE /workspaces/W_attacker/labels/L_T. LabelService.delete(L_T) deletes the foreign label, dropping every issue-label association row that referenced it (cascade or orphan, depending on schema). State: foreign workspace's labels are gone or corrupted.
  4. Attacker sends POST /workspaces/W_attacker/issues/I_T/labels/L_T2 to attach foreign label L_T2 to foreign issue I_T. LabelService.add_to_issue(I_T, L_T2) writes the association row regardless of either ID's workspace. State: the foreign issue now carries an arbitrary attacker-chosen label, which surfaces in every filter/search/board view in the foreign workspace's UI.
  5. Attacker sends DELETE /workspaces/W_attacker/issues/I_T/labels/L_legit to strip the legitimate label off the foreign issue. State: triagers can no longer find the issue via label filters.
  6. Attacker sends GET /workspaces/W_attacker/issues/I_T/labels to read the current label set on any foreign issue. State: the attacker fingerprints the foreign workspace's triage taxonomy.
  7. Final state: with one workspace-member token plus harvested foreign IDs, the attacker rewrites and deletes other workspaces' labels, attaches/detaches arbitrary labels on other workspaces' issues, and reads triage state across the deployment.

Security Impact

Severity: sec-moderate. CVSS 6.3: network attack, low complexity, low privileges, no user interaction, scope unchanged. The integrity damage is high (rename/delete of foreign labels is permanent and silent; cross-workspace label-attachment corrupts UI filters), confidentiality is low (label names are not the most sensitive field but do leak triage taxonomy), availability low (foreign workspaces may lose triage visibility into their own issues until the labels are restored). Attacker capability: rename and delete any label in the multi-tenant deployment; attach any label to any issue; detach any label from any issue; list label assignments for any issue. Combined with the companion IssueService IDOR (separate advisory), the attacker can also modify the underlying issue, making the cross-workspace tampering very difficult to detect. Preconditions: praisonai-platform is deployed multi-tenant; the attacker has any membership token; target IDs are known or guessable. Differential: source-inspection-verified end-to-end. The asymmetry between LabelService.list_for_workspace(workspace_id) (correctly workspace-scoped) and LabelService.get(label_id) / add_to_issue(issue_id, label_id) (no workspace check) confirms the gap. With the suggested fix below, label and issue IDs that do not belong to the membership-checked workspace return 404, and the attacker cannot touch them.

Suggested Fix

Make every single-row label lookup take the workspace predicate; verify both issue_id and label_id belong to workspace_id for the association routes.

--- a/src/praisonai-platform/praisonai_platform/services/label_service.py
+++ b/src/praisonai-platform/praisonai_platform/services/label_service.py
@@ -33,7 +33,12 @@ class LabelService:
         return label

-    async def get(self, label_id: str) -> Optional[IssueLabel]:
-        return await self._session.get(IssueLabel, label_id)
+    async def get(self, workspace_id: str, label_id: str) -> Optional[IssueLabel]:
+        stmt = select(IssueLabel).where(
+            IssueLabel.id == label_id,
+            IssueLabel.workspace_id == workspace_id,
+        )
+        return (await self._session.execute(stmt)).scalar_one_or_none()

-    async def add_to_issue(self, issue_id: str, label_id: str) -> None:
+    async def add_to_issue(self, workspace_id: str, issue_id: str, label_id: str) -> None:
+        # Verify both ids belong to workspace_id before writing the association row.

Then update the route handlers in routes/labels.py to thread workspace_id through every call. The same single-key-lookup pattern is filed separately for AgentService, IssueService, ProjectService, and CommentService — each is its own exploitable IDOR.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.1.2"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "praisonai-platform"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47414"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-29T22:51:07Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\n**Type:** Insecure Direct Object Reference. Five label endpoints \u2014 `PATCH /workspaces/{workspace_id}/labels/{label_id}`, `DELETE .../labels/{label_id}`, `POST .../issues/{issue_id}/labels/{label_id}`, `DELETE .../issues/{issue_id}/labels/{label_id}`, `GET .../issues/{issue_id}/labels` \u2014 gate access on `require_workspace_member(workspace_id)` only and pass URL-supplied `label_id` and `issue_id` straight through to `LabelService` without verifying either belongs to the workspace.\n**File:** `src/praisonai-platform/praisonai_platform/services/label_service.py`, lines 35-100; route handlers at `src/praisonai-platform/praisonai_platform/api/routes/labels.py`, lines 42-106.\n**Root cause:** identical pattern to the agent / issue / project / comment IDORs in this codebase: the route\u0027s `workspace_id` is used as a membership predicate but never threaded through to the service layer. `LabelService.get(label_id)` runs `session.get(IssueLabel, label_id)` with no workspace filter; `update`/`delete` inherit the gap; `add_to_issue(issue_id, label_id)` and `remove_from_issue(issue_id, label_id)` write/delete association rows without verifying either ID belongs to the membership-checked workspace; `list_for_issue(issue_id)` reads them.\n\n## Affected Code\n\n**File 1:** `src/praisonai-platform/praisonai_platform/services/label_service.py`, lines 35-100.\n\n```python\nclass LabelService:\n    ...\n\n    async def get(self, label_id: str) -\u003e Optional[IssueLabel]:\n        return await self._session.get(IssueLabel, label_id)         # \u003c-- BUG: no workspace_id predicate\n\n    async def update(\n        self,\n        label_id: str,\n        ...\n    ) -\u003e Optional[IssueLabel]:\n        label = await self.get(label_id)                             # \u003c-- inherits the gap\n        ...\n\n    async def delete(self, label_id: str) -\u003e bool:\n        label = await self.get(label_id)                             # \u003c-- inherits the gap\n        ...\n\n    async def add_to_issue(self, issue_id: str, label_id: str) -\u003e None:\n        # writes a row in issue_label association table; no workspace check on either id\n\n    async def remove_from_issue(self, issue_id: str, label_id: str) -\u003e None:\n        # deletes from association table; no workspace check on either id\n\n    async def list_for_issue(self, issue_id: str) -\u003e list[IssueLabel]:\n        # reads from association table; no workspace check on issue_id\n```\n\n**File 2:** `src/praisonai-platform/praisonai_platform/api/routes/labels.py`, lines 42-106.\n\n```python\n@router.patch(\"/labels/{label_id}\", response_model=LabelResponse)\nasync def update_label(workspace_id: str, label_id: str, body: LabelUpdate, ...):\n    svc = LabelService(session)\n    label = await svc.update(label_id, body.name, body.color)        # \u003c-- writes any label in the DB\n    ...\n\n@router.delete(\"/labels/{label_id}\", ...)\nasync def delete_label(workspace_id: str, label_id: str, ...):\n    deleted = await svc.delete(label_id)                             # \u003c-- deletes any label in the DB\n    ...\n\n@router.post(\"/issues/{issue_id}/labels/{label_id}\", ...)\nasync def add_label_to_issue(workspace_id: str, issue_id: str, label_id: str, ...):\n    await svc.add_to_issue(issue_id, label_id)                       # \u003c-- attaches any label to any issue cross-workspace\n\n@router.delete(\"/issues/{issue_id}/labels/{label_id}\", ...)\nasync def remove_label_from_issue(workspace_id: str, issue_id: str, label_id: str, ...):\n    await svc.remove_from_issue(issue_id, label_id)                  # \u003c-- detaches any label from any issue cross-workspace\n\n@router.get(\"/issues/{issue_id}/labels\", ...)\nasync def list_issue_labels(workspace_id: str, issue_id: str, ...):\n    labels = await svc.list_for_issue(issue_id)                      # \u003c-- reads label assignments for any issue\n```\n\n**Why it\u0027s wrong:** the `workspace_id` URL segment is treated as a UI hint; the actual `label_id` and `issue_id` lookups query the database without a workspace constraint. The `MemberService` in this same codebase uses a composite key correctly; the label service does not. The `add_to_issue` and `remove_from_issue` paths are particularly nasty because they touch *two* unverified IDs at once: an attacker can attach a foreign workspace\u0027s label to a foreign workspace\u0027s issue (or detach the legitimate labels), corrupting both sides of an association the attacker has no business touching.\n\n## Exploit Chain\n\n1. Attacker registers a workspace `W_attacker` (member) and harvests a foreign-workspace `label_id` `L_T` and a foreign-workspace `issue_id` `I_T`. Both leak via `list_labels` responses (which include label IDs \u2014 but only for `W_attacker`; for the target the IDs come from issue records that include label associations, activity feeds, exported dumps, error messages). State: attacker holds `L_T` and `I_T`.\n2. Attacker authenticates and sends `PATCH /workspaces/W_attacker/labels/L_T` with `{\"name\": \"\u003cdeleted\u003e\", \"color\": \"#000000\"}`. `require_workspace_member(W_attacker, attacker)` passes. `LabelService.update(L_T, ...)` loads the foreign label and renames it. State: every issue across the foreign workspace that bears this label now displays the attacker-chosen name and colour.\n3. Attacker sends `DELETE /workspaces/W_attacker/labels/L_T`. `LabelService.delete(L_T)` deletes the foreign label, dropping every issue-label association row that referenced it (cascade or orphan, depending on schema). State: foreign workspace\u0027s labels are gone or corrupted.\n4. Attacker sends `POST /workspaces/W_attacker/issues/I_T/labels/L_T2` to attach foreign label `L_T2` to foreign issue `I_T`. `LabelService.add_to_issue(I_T, L_T2)` writes the association row regardless of either ID\u0027s workspace. State: the foreign issue now carries an arbitrary attacker-chosen label, which surfaces in every filter/search/board view in the foreign workspace\u0027s UI.\n5. Attacker sends `DELETE /workspaces/W_attacker/issues/I_T/labels/L_legit` to strip the legitimate label off the foreign issue. State: triagers can no longer find the issue via label filters.\n6. Attacker sends `GET /workspaces/W_attacker/issues/I_T/labels` to read the current label set on any foreign issue. State: the attacker fingerprints the foreign workspace\u0027s triage taxonomy.\n7. Final state: with one workspace-member token plus harvested foreign IDs, the attacker rewrites and deletes other workspaces\u0027 labels, attaches/detaches arbitrary labels on other workspaces\u0027 issues, and reads triage state across the deployment.\n\n## Security Impact\n\n**Severity:** sec-moderate. CVSS 6.3: network attack, low complexity, low privileges, no user interaction, scope unchanged. The integrity damage is high (rename/delete of foreign labels is permanent and silent; cross-workspace label-attachment corrupts UI filters), confidentiality is low (label names are not the most sensitive field but do leak triage taxonomy), availability low (foreign workspaces may lose triage visibility into their own issues until the labels are restored).\n**Attacker capability:** rename and delete any label in the multi-tenant deployment; attach any label to any issue; detach any label from any issue; list label assignments for any issue. Combined with the companion `IssueService` IDOR (separate advisory), the attacker can also modify the underlying issue, making the cross-workspace tampering very difficult to detect.\n**Preconditions:** `praisonai-platform` is deployed multi-tenant; the attacker has any membership token; target IDs are known or guessable.\n**Differential:** source-inspection-verified end-to-end. The asymmetry between `LabelService.list_for_workspace(workspace_id)` (correctly workspace-scoped) and `LabelService.get(label_id) / add_to_issue(issue_id, label_id)` (no workspace check) confirms the gap. With the suggested fix below, label and issue IDs that do not belong to the membership-checked workspace return 404, and the attacker cannot touch them.\n\n## Suggested Fix\n\nMake every single-row label lookup take the workspace predicate; verify both `issue_id` and `label_id` belong to `workspace_id` for the association routes.\n\n```diff\n--- a/src/praisonai-platform/praisonai_platform/services/label_service.py\n+++ b/src/praisonai-platform/praisonai_platform/services/label_service.py\n@@ -33,7 +33,12 @@ class LabelService:\n         return label\n\n-    async def get(self, label_id: str) -\u003e Optional[IssueLabel]:\n-        return await self._session.get(IssueLabel, label_id)\n+    async def get(self, workspace_id: str, label_id: str) -\u003e Optional[IssueLabel]:\n+        stmt = select(IssueLabel).where(\n+            IssueLabel.id == label_id,\n+            IssueLabel.workspace_id == workspace_id,\n+        )\n+        return (await self._session.execute(stmt)).scalar_one_or_none()\n\n-    async def add_to_issue(self, issue_id: str, label_id: str) -\u003e None:\n+    async def add_to_issue(self, workspace_id: str, issue_id: str, label_id: str) -\u003e None:\n+        # Verify both ids belong to workspace_id before writing the association row.\n```\n\nThen update the route handlers in `routes/labels.py` to thread `workspace_id` through every call. The same single-key-lookup pattern is filed separately for `AgentService`, `IssueService`, `ProjectService`, and `CommentService` \u2014 each is its own exploitable IDOR.",
  "id": "GHSA-5jx9-w35f-vp65",
  "modified": "2026-05-29T22:51:07Z",
  "published": "2026-05-29T22:51:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-5jx9-w35f-vp65"
    },
    {
      "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:L/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "praisonai-platform: Label endpoints\u0027 unchecked label_id/issue_id enable cross-workspace label IDOR (edit, delete, link)"
}

GHSA-5M2R-V35X-JHHX

Vulnerability from github – Published: 2025-10-27 03:30 – Updated: 2025-11-13 12:31
VLAI
Details

Authorization Bypass Through User-Controlled Key vulnerability in mediavine Create by Mediavine mediavine-create allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Create by Mediavine: from n/a through <= 1.9.14.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-62893"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-27T02:15:48Z",
    "severity": "HIGH"
  },
  "details": "Authorization Bypass Through User-Controlled Key vulnerability in mediavine Create by Mediavine mediavine-create allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Create by Mediavine: from n/a through \u003c= 1.9.14.",
  "id": "GHSA-5m2r-v35x-jhhx",
  "modified": "2025-11-13T12:31:28Z",
  "published": "2025-10-27T03:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62893"
    },
    {
      "type": "WEB",
      "url": "https://vdp.patchstack.com/database/Wordpress/Plugin/mediavine-create/vulnerability/wordpress-create-by-mediavine-plugin-1-9-14-insecure-direct-object-references-idor-vulnerability"
    },
    {
      "type": "WEB",
      "url": "https://vdp.patchstack.com/database/Wordpress/Plugin/mediavine-create/vulnerability/wordpress-create-by-mediavine-plugin-1-9-14-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:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5M34-QPJQ-HJHF

Vulnerability from github – Published: 2024-01-17 21:30 – Updated: 2024-01-17 21:30
VLAI
Details

Insecure Direct Object Reference vulnerabilities were discovered in the Avaya Aura Experience Portal Manager which may allow partial information disclosure to an authenticated non-privileged user. Affected versions include 8.0.x and 8.1.x, prior to 8.1.2 patch 0402. Versions prior to 8.0 are end of manufacturer support.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-7031"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-17T19:15:08Z",
    "severity": "MODERATE"
  },
  "details": "Insecure Direct Object Reference vulnerabilities were discovered in the Avaya Aura Experience Portal Manager which may allow partial information disclosure to an authenticated non-privileged user. Affected versions include 8.0.x and 8.1.x, prior to 8.1.2 patch 0402. Versions prior to 8.0 are end of manufacturer support.",
  "id": "GHSA-5m34-qpjq-hjhf",
  "modified": "2024-01-17T21:30:20Z",
  "published": "2024-01-17T21:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-7031"
    },
    {
      "type": "WEB",
      "url": "https://support.avaya.com/css/public/documents/101088063"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5MV2-W7GR-RP48

Vulnerability from github – Published: 2023-02-17 12:30 – Updated: 2026-06-01 15:30
VLAI
Details

Improper Input Validation, Authorization Bypass Through User-Controlled Key vulnerability in Kron Tech Single Connect on Windows allows Privilege Abuse. This issue affects Single Connect: 2.16.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-0882"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-17T10:15:00Z",
    "severity": "HIGH"
  },
  "details": "Improper Input Validation, Authorization Bypass Through User-Controlled Key vulnerability in Kron Tech Single Connect on Windows allows Privilege Abuse. This issue affects Single Connect: 2.16.",
  "id": "GHSA-5mv2-w7gr-rp48",
  "modified": "2026-06-01T15:30:28Z",
  "published": "2023-02-17T12:30:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0882"
    },
    {
      "type": "WEB",
      "url": "https://docs.krontech.com/singleconnect-2-16/update-patch-rdp-proxy-idor-vulnerability"
    },
    {
      "type": "WEB",
      "url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-23-0092"
    },
    {
      "type": "WEB",
      "url": "https://www.usom.gov.tr/bildirim/tr-23-0092"
    }
  ],
  "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-5MVV-43FH-86FQ

Vulnerability from github – Published: 2026-07-30 06:32 – Updated: 2026-07-30 21:31
VLAI
Details

The Eventin WordPress plugin before 4.1.16 does not properly authorize order creation and accepts an attacker-supplied order status, allowing unauthenticated users to create orders marked as paid without completing any payment.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-13178"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-30T06:24:59Z",
    "severity": "HIGH"
  },
  "details": "The Eventin  WordPress plugin before 4.1.16 does not properly authorize order creation and accepts an attacker-supplied order status, allowing unauthenticated users to create orders marked as paid without completing any payment.",
  "id": "GHSA-5mvv-43fh-86fq",
  "modified": "2026-07-30T21:31:43Z",
  "published": "2026-07-30T06:32:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-13178"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/09d6135f-b38c-4cfe-8a9f-5d79552c720c"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5P7F-47WP-86C5

Vulnerability from github – Published: 2022-05-13 01:50 – Updated: 2022-05-13 01:50
VLAI
Details

In Monstra CMS 3.0.4, an attacker with 'Editor' privileges can change the password of the administrator via an admin/index.php?id=users&action=edit&user_id=1, Insecure Direct Object Reference (IDOR).

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

{
  "affected": [],
  "aliases": [
    "CVE-2018-16608"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-09-10T13:29:00Z",
    "severity": "HIGH"
  },
  "details": "In Monstra CMS 3.0.4, an attacker with \u0027Editor\u0027 privileges can change the password of the administrator via an admin/index.php?id=users\u0026action=edit\u0026user_id=1, Insecure Direct Object Reference (IDOR).",
  "id": "GHSA-5p7f-47wp-86c5",
  "modified": "2022-05-13T01:50:23Z",
  "published": "2022-05-13T01:50:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-16608"
    },
    {
      "type": "WEB",
      "url": "https://github.com/monstra-cms/monstra/issues/453"
    }
  ],
  "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"
    }
  ]
}

GHSA-5P7V-X4Q4-6428

Vulnerability from github – Published: 2026-07-21 09:31 – Updated: 2026-07-21 18:31
VLAI
Details

The Academy LMS WordPress plugin before 3.8.1 does not verify ownership of a user-supplied user identifier in several of its lesson AJAX handlers, allowing authenticated users with subscriber-level access to read and modify other users' lesson notes and mark other users' lesson content as completed.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-14184"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-21T07:16:34Z",
    "severity": "MODERATE"
  },
  "details": "The Academy LMS WordPress plugin before 3.8.1 does not verify ownership of a user-supplied user identifier in several of its lesson AJAX handlers, allowing authenticated users with subscriber-level access to read and modify other users\u0027 lesson notes and mark other users\u0027 lesson content as completed.",
  "id": "GHSA-5p7v-x4q4-6428",
  "modified": "2026-07-21T18:31:00Z",
  "published": "2026-07-21T09:31:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-14184"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/56a5b91b-1e1a-429d-b9e9-a1a107183124"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5P8J-X73F-MFW4

Vulnerability from github – Published: 2026-09-05 15:30 – Updated: 2026-09-05 15:30
VLAI
Details

SiYuan versions before v3.8.2 contain an information disclosure vulnerability in the getAttributeViewKeysByID endpoint that allows publish readers to enumerate private attribute view key definitions without verifying parent database visibility. Attackers can access the endpoint to retrieve complete key schemas including sensitive field names and relation definitions from hidden databases.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
5.3 (Medium)
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
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-86191"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-05T13:18:14Z",
    "severity": "MODERATE"
  },
  "details": "SiYuan versions before v3.8.2 contain an information disclosure vulnerability in the getAttributeViewKeysByID endpoint that allows publish readers to enumerate private attribute view key definitions without verifying parent database visibility. Attackers can access the endpoint to retrieve complete key schemas including sensitive field names and relation definitions from hidden databases.",
  "id": "GHSA-5p8j-x73f-mfw4",
  "modified": "2026-09-05T15:30:25Z",
  "published": "2026-09-05T15:30:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/siyuan-note/siyuan/security/advisories/GHSA-j4qq-w6qx-6839"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-86191"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/siyuan-before-3.8.2-private-attribute-view-key-enumeration"
    }
  ],
  "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"
    },
    {
      "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:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-5PG6-M483-7VRG

Vulnerability from github – Published: 2026-08-28 16:52 – Updated: 2026-08-28 16:52
VLAI
Summary
Vikunja has cross-tenant IDOR in kanban move-task endpoint via unauthorized body task_id
Details

Summary

The kanban endpoint POST /api/v1/projects/{project}/views/{view}/buckets/{bucket}/tasks moves a task into a bucket. The task is identified by task_id in the request body. The endpoint's authorization check (TaskBucket.CanUpdate) only verifies that the caller may update the project/view/bucket named in the URL — it never checks any permission on task_id.

Any authenticated user can therefore supply another user's task ID (task IDs are a global, sequential integer space) against a kanban bucket in their own project. The server loads that victim task with no authorization check, returns its full contents in the response, and — when the target bucket is a "done" bucket — writes to the victim task's row.

This is the same vulnerability class Vikunja has already remediated for task relations (CVE-2026-33676), task attachments (CVE-2026-33678), task comments (CVE-2026-33313) and CalDAV task read (CVE-2026-35598). TaskBucket is the task-child operation that was missed.

Root cause

1. task_id is body-controlled and never permission-checked

pkg/models/kanban_task_bucket.go:32:

type TaskBucket struct {
    BucketID      int64 `... json:"bucket_id" param:"bucket"`
    TaskID        int64 `... json:"task_id"`              // body-bound only — no param tag
    ProjectViewID int64 `... json:"project_view_id" param:"view"`
    ProjectID     int64 `xorm:"-" json:"-" param:"project"`
    ...
}

The web handler UpdateWeb (pkg/web/handler/update.go) populates the struct via ctx.Bind, which binds both URL path params (param: tags) and the JSON body. BucketID, ProjectViewID, ProjectID come from the trusted URL; TaskID comes entirely from the attacker-controlled body.

2. CanUpdate authorizes the URL, not the task

pkg/models/kanban_task_bucket.go:52:

func (b *TaskBucket) CanUpdate(s *xorm.Session, a web.Auth) (bool, error) {
    bucket := Bucket{ID: b.BucketID, ProjectID: b.ProjectID, ProjectViewID: b.ProjectViewID}
    return bucket.canDoBucket(s, a)
}

canDoBucket (pkg/models/kanban_permissions.go:46) resolves the bucket/view and ends in Project{ID: pv.ProjectID}.CanUpdate(s, a) — a permission check on the project from the URL. b.TaskID is never referenced. The attacker owns that project, so the check passes.

3. The task is loaded and mutated with no authorization

updateTaskBucket (pkg/models/kanban_task_bucket.go:119):

task := &Task{ID: b.TaskID}
err = task.ReadOne(s, a)            // loads ANY task by ID — no permission check

Task.ReadOne (pkg/models/tasks.go:1967) calls GetTaskByIDSimple + addMoreInfoToTasks; it performs no authorization (authorization normally lives in the separate Task.CanRead, which this internal call path bypasses).

  • Read: the fully populated victim task is assigned to b.Task (line 227) and returned by the Update handler in the response "task" field.

  • Write: if the target bucket is the view's done bucket (view.DoneBucketID == b.BucketID && !task.Done, line 141), the handler sets task.Done = true and persists it to the victim's task row:

    _, err = s.Where("id = ?", task.ID). Cols("done", "due_date", "start_date", "end_date", "done_at"). Update(task)

Proof of Concept

The attacker is any normal authenticated user. They first create their own kanban project/view/bucket (free for every user), then:

POST /api/v1/projects/{ATTACKER_PROJECT}/views/{ATTACKER_VIEW}/buckets/{ATTACKER_BUCKET}/tasks HTTP/1.1
Host: TARGET
Authorization: Bearer {ATTACKER_JWT}
Content-Type: application/json

{"task_id": {VICTIM_TASK_ID}}

The 200 response body contains the victim task in full under "task" — title, description, dates, assignees, labels, attachment list, reactions. Task IDs are a global sequential counter, so iterating task_id enumerates every task on the instance.

If ATTACKER_BUCKET is the done bucket of ATTACKER_VIEW, the same request also flips the victim task to done (done = true, done_at set).

Impact

Any authenticated low-privilege user can:

  • Read any task on the instance by sequential ID, across every other user, project and organization — a full cross-tenant information disclosure of task titles, descriptions, assignees, labels and attachment metadata.
  • Modify any task's done state, marking arbitrary victims' tasks done (or clearing it) and altering done_at.

Vikunja's permission model is built specifically to isolate projects between users; this endpoint defeats that isolation. It is the same impact and class that warranted CVEs for task relations, attachments and comments.

Suggested fix

In TaskBucket.CanUpdate, after the bucket/project check, also verify the caller's permission on the body-supplied task — mirroring the remediation already applied to task relations and attachments:

task := &Task{ID: b.TaskID}
canUpdateTask, err := task.CanUpdate(s, a)
if err != nil || !canUpdateTask {
    return false, err
}

(Use CanRead if moving a readable-but-not-writable task into a bucket is intended; CanUpdate is the safer default since the operation can change the task's done state.)

References

  • CWE-639 Authorization Bypass Through User-Controlled Key
  • CWE-284 Improper Access Control
  • OWASP A01:2021 Broken Access Control
  • CVE-2026-33676, CVE-2026-33678, CVE-2026-33313, CVE-2026-35598 — the same missing-authorization-on-task-child class, already remediated; this report is the un-remediated TaskBucket sibling.

Additional notes

  • The v2 API is affected too. The same endpoint is exposed under /api/v2/..., and both versions route through the shared model TaskBucket.CanUpdate / updateTaskBucket in pkg/models/kanban_task_bucket.go. A model-level fix closes v1 and v2 simultaneously; the regression test should assert both.

  • Two fix altitudes. The minimal fix checks the body-supplied task_id in TaskBucket.CanUpdate (task.CanUpdate/CanRead). A broader fix makes Task.ReadOne itself permission-aware, which also hardens other internal call paths that rely on it — higher blast radius, weigh accordingly.

  • Side effects of the cross-tenant write confirmed across reports: flipping done rewrites done_at/due_date/start_date/end_date, inserts a task_buckets row, propagates done-state to other kanban views with a done bucket in the victim's project, and triggers updateDone rescheduling for repeating tasks.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.3.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "code.vikunja.io/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55066"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-28T16:52:16Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe kanban endpoint `POST /api/v1/projects/{project}/views/{view}/buckets/{bucket}/tasks`\nmoves a task into a bucket. The task is identified by `task_id` in the **request\nbody**. The endpoint\u0027s authorization check (`TaskBucket.CanUpdate`) only verifies\nthat the caller may update the *project/view/bucket named in the URL* \u2014 it never\nchecks any permission on `task_id`.\n\nAny authenticated user can therefore supply another user\u0027s task ID (task IDs are\na global, sequential integer space) against a kanban bucket in their **own**\nproject. The server loads that victim task with no authorization check, returns\nits full contents in the response, and \u2014 when the target bucket is a \"done\"\nbucket \u2014 writes to the victim task\u0027s row.\n\nThis is the same vulnerability class Vikunja has already remediated for task\nrelations (CVE-2026-33676), task attachments (CVE-2026-33678), task comments\n(CVE-2026-33313) and CalDAV task read (CVE-2026-35598). `TaskBucket` is the\ntask-child operation that was missed.\n\n---\n\n## Root cause\n\n### 1. `task_id` is body-controlled and never permission-checked\n\n`pkg/models/kanban_task_bucket.go:32`:\n\n    type TaskBucket struct {\n        BucketID      int64 `... json:\"bucket_id\" param:\"bucket\"`\n        TaskID        int64 `... json:\"task_id\"`              // body-bound only \u2014 no param tag\n        ProjectViewID int64 `... json:\"project_view_id\" param:\"view\"`\n        ProjectID     int64 `xorm:\"-\" json:\"-\" param:\"project\"`\n        ...\n    }\n\nThe web handler `UpdateWeb` (`pkg/web/handler/update.go`) populates the struct via\n`ctx.Bind`, which binds both URL path params (`param:` tags) **and** the JSON body.\n`BucketID`, `ProjectViewID`, `ProjectID` come from the trusted URL; `TaskID` comes\nentirely from the attacker-controlled body.\n\n### 2. `CanUpdate` authorizes the URL, not the task\n\n`pkg/models/kanban_task_bucket.go:52`:\n\n    func (b *TaskBucket) CanUpdate(s *xorm.Session, a web.Auth) (bool, error) {\n        bucket := Bucket{ID: b.BucketID, ProjectID: b.ProjectID, ProjectViewID: b.ProjectViewID}\n        return bucket.canDoBucket(s, a)\n    }\n\n`canDoBucket` (`pkg/models/kanban_permissions.go:46`) resolves the bucket/view and\nends in `Project{ID: pv.ProjectID}.CanUpdate(s, a)` \u2014 a permission check on the\n**project from the URL**. `b.TaskID` is never referenced. The attacker owns that\nproject, so the check passes.\n\n### 3. The task is loaded and mutated with no authorization\n\n`updateTaskBucket` (`pkg/models/kanban_task_bucket.go:119`):\n\n    task := \u0026Task{ID: b.TaskID}\n    err = task.ReadOne(s, a)            // loads ANY task by ID \u2014 no permission check\n\n`Task.ReadOne` (`pkg/models/tasks.go:1967`) calls `GetTaskByIDSimple` +\n`addMoreInfoToTasks`; it performs no authorization (authorization normally lives\nin the separate `Task.CanRead`, which this internal call path bypasses).\n\n- **Read:** the fully populated victim task is assigned to `b.Task` (line 227) and\n  returned by the `Update` handler in the response `\"task\"` field.\n- **Write:** if the target bucket is the view\u0027s done bucket\n  (`view.DoneBucketID == b.BucketID \u0026\u0026 !task.Done`, line 141), the handler sets\n  `task.Done = true` and persists it to the victim\u0027s task row:\n\n      _, err = s.Where(\"id = ?\", task.ID).\n          Cols(\"done\", \"due_date\", \"start_date\", \"end_date\", \"done_at\").\n          Update(task)\n\n---\n\n## Proof of Concept\n\nThe attacker is any normal authenticated user. They first create their own kanban\nproject/view/bucket (free for every user), then:\n\n    POST /api/v1/projects/{ATTACKER_PROJECT}/views/{ATTACKER_VIEW}/buckets/{ATTACKER_BUCKET}/tasks HTTP/1.1\n    Host: TARGET\n    Authorization: Bearer {ATTACKER_JWT}\n    Content-Type: application/json\n\n    {\"task_id\": {VICTIM_TASK_ID}}\n\nThe `200` response body contains the victim task in full under `\"task\"` \u2014 title,\ndescription, dates, assignees, labels, attachment list, reactions. Task IDs are a\nglobal sequential counter, so iterating `task_id` enumerates every task on the\ninstance.\n\nIf `ATTACKER_BUCKET` is the done bucket of `ATTACKER_VIEW`, the same request also\nflips the victim task to done (`done = true`, `done_at` set).\n\n---\n\n## Impact\n\nAny authenticated low-privilege user can:\n\n- **Read any task on the instance** by sequential ID, across every other user,\n  project and organization \u2014 a full cross-tenant information disclosure of task\n  titles, descriptions, assignees, labels and attachment metadata.\n- **Modify any task\u0027s done state**, marking arbitrary victims\u0027 tasks done (or\n  clearing it) and altering `done_at`.\n\nVikunja\u0027s permission model is built specifically to isolate projects between\nusers; this endpoint defeats that isolation. It is the same impact and class that\nwarranted CVEs for task relations, attachments and comments.\n\n---\n\n## Suggested fix\n\nIn `TaskBucket.CanUpdate`, after the bucket/project check, also verify the caller\u0027s\npermission on the body-supplied task \u2014 mirroring the remediation already applied\nto task relations and attachments:\n\n    task := \u0026Task{ID: b.TaskID}\n    canUpdateTask, err := task.CanUpdate(s, a)\n    if err != nil || !canUpdateTask {\n        return false, err\n    }\n\n(Use `CanRead` if moving a readable-but-not-writable task into a bucket is intended;\n`CanUpdate` is the safer default since the operation can change the task\u0027s done\nstate.)\n\n---\n\n## References\n\n- CWE-639 Authorization Bypass Through User-Controlled Key\n- CWE-284 Improper Access Control\n- OWASP A01:2021 Broken Access Control\n- CVE-2026-33676, CVE-2026-33678, CVE-2026-33313, CVE-2026-35598 \u2014 the same\n  missing-authorization-on-task-child class, already remediated; this report is\n  the un-remediated `TaskBucket` sibling.\n\n## Additional notes\n\n- **The v2 API is affected too.** The same endpoint is exposed under `/api/v2/...`,\n  and both versions route through the shared model `TaskBucket.CanUpdate` /\n  `updateTaskBucket` in `pkg/models/kanban_task_bucket.go`. A model-level fix\n  closes v1 and v2 simultaneously; the regression test should assert both.\n\n- **Two fix altitudes.** The minimal fix checks the body-supplied `task_id` in\n  `TaskBucket.CanUpdate` (`task.CanUpdate`/`CanRead`). A broader fix makes\n  `Task.ReadOne` itself permission-aware, which also hardens other internal call\n  paths that rely on it \u2014 higher blast radius, weigh accordingly.\n\n- Side effects of the cross-tenant write confirmed across reports: flipping `done`\n  rewrites `done_at`/`due_date`/`start_date`/`end_date`, inserts a `task_buckets`\n  row, propagates done-state to other kanban views with a done bucket in the\n  victim\u0027s project, and triggers `updateDone` rescheduling for repeating tasks.",
  "id": "GHSA-5pg6-m483-7vrg",
  "modified": "2026-08-28T16:52:16Z",
  "published": "2026-08-28T16:52:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-5pg6-m483-7vrg"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/pull/3239"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/commit/36cdc2ce2be0b8ccc74227d178b92047d59cd65f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-vikunja/vikunja"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/releases/tag/v2.4.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Vikunja has cross-tenant IDOR in kanban move-task endpoint via unauthorized body task_id"
}
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