Common Weakness Enumeration

CWE-862

Allowed-with-Review

Missing Authorization

Abstraction: Class · Status: Incomplete

The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

19598 vulnerabilities reference this CWE, most recent first.

GHSA-44Q4-5M88-44QJ

Vulnerability from github – Published: 2023-07-06 21:15 – Updated: 2026-04-08 21:31
VLAI
Details

The WPCS – WordPress Currency Switcher Professional plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the save function in versions up to, and including, 1.1.9. This makes it possible for authenticated attackers, with subscriber-level permissions and above, to edit an arbitrary custom drop-down currency switcher.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-2557"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-09T06:16:09Z",
    "severity": "MODERATE"
  },
  "details": "The WPCS \u2013 WordPress Currency Switcher Professional plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the save function in versions up to, and including, 1.1.9. This makes it possible for authenticated attackers, with subscriber-level permissions and above, to edit an arbitrary custom drop-down currency switcher.",
  "id": "GHSA-44q4-5m88-44qj",
  "modified": "2026-04-08T21:31:55Z",
  "published": "2023-07-06T21:15:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2557"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/2911049/currency-switcher"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/d4c79242-5c89-40c0-abcc-c112f7a64a74?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-44QJ-CGHF-9P97

Vulnerability from github – Published: 2026-05-08 22:47 – Updated: 2026-06-08 23:47
VLAI
Summary
free5GC's SMF UPI POST /upi/v1/upNodesLinks exits the SMF process on overlapping UE pools (unauthenticated, reachable Fatalf)
Details

Summary

free5GC's SMF mounts the UPI management route group without inbound OAuth2 middleware (same root cause as free5gc/free5gc#887). The POST /upi/v1/upNodesLinks create-or-update handler accepts attacker-controlled JSON and passes it directly into UpNodesFromConfiguration(), which calls logger.InitLog.Fatalf(...) on several validation failures. One confirmed path is the UE-IP-pool overlap check: a single unauthenticated POST that adds a new UPF whose pool overlaps an existing UPF terminates the entire SMF process (docker ps shows Exited (1)), not just the goroutine. This is a stronger sink than free5gc/free5gc#905: that one panics inside the request goroutine and Gin recovers; this one calls Fatalf which is os.Exit(1)-equivalent and kills the whole SMF process, dropping all of SMF's SBI surface (PDU-session establishment, UE policy lookups, etc.) until the process is restarted.

Details

Validated against the SMF container in the official Docker compose lab. - Source repo tag: v4.2.1 - Running Docker image: free5gc/smf:v4.2.1 - Runtime SMF commit: 8385c00a - Docker validation date: 2026-03-22 local (container log timestamp 2026-03-21T23:47:07Z) - SMF endpoint: http://10.100.200.6:8000

The broader UPI auth gap (#887) lets the unauthenticated POST reach the create/update handler. From there:

Vulnerable handler dispatches into topology parsing:

POST /upi/v1/upNodesLinks
 -> UpNodesFromConfiguration()
   -> isOverlap(allUEIPPools)
     -> logger.InitLog.Fatalf("overlap cidr value between UPFs")

Code evidence (paths in free5gc/smf): - UPI group mounted WITHOUT auth middleware (preconditions for unauthenticated reachability): - NFs/smf/internal/sbi/server.go:76 - NFs/smf/internal/sbi/server.go:78 - Create-or-update handler accepts attacker JSON and forwards it to UpNodesFromConfiguration(): - NFs/smf/internal/sbi/api_upi.go:60 - NFs/smf/internal/sbi/api_upi.go:72 - Pool parsing (input from attacker JSON): - NFs/smf/internal/context/user_plane_information.go:413 - Overlap check that calls Fatalf: - NFs/smf/internal/context/user_plane_information.go:479

The same unauthenticated POST path also reaches sibling Fatalf calls for invalid-pool and static-pool-exclusion failures, so this is not a one-off code smell -- it is a class of attacker-reachable Fatalf call sites on a single unauthenticated handler: - NFs/smf/internal/context/user_plane_information.go:416 - NFs/smf/internal/context/user_plane_information.go:424 - NFs/smf/internal/context/user_plane_information.go:430

PoC

Reproduced end-to-end against the running SMF at http://10.100.200.6:8000.

  1. Trigger: unauthenticated POST that adds a UPF with a UE pool overlapping the default UPF (10.60.0.0/16):
curl -i -X POST http://10.100.200.6:8000/upi/v1/upNodesLinks \
  -H 'Content-Type: application/json' \
  --data '{"links":[{"A":"gNB1","B":"UPF-OVERLAP-20260322"}],"upNodes":{"UPF-OVERLAP-20260322":{"type":"UPF","nodeID":"198.51.100.20","addr":"198.51.100.20","sNssaiUpfInfos":[{"sNssai":{"sst":1,"sd":"010203"},"dnnUpfInfoList":[{"dnn":"internet","pools":[{"cidr":"10.60.0.0/16"}]}]}]}}}'

Client-side observation (server died mid-request, no HTTP response written):

curl: (52) Empty reply from server
  1. Confirm the SMF container exited:
docker ps -a --filter name=smf --format '{{.Names}}\t{{.Status}}'
smf    Exited (1) 9 seconds ago
  1. SMF container logs (docker logs --tail 80 smf) show the FATA line that terminated the process:
[FATA][SMF][Init] overlap cidr value between UPFs

Impact

Unauthenticated process-kill DoS on the SMF management plane.

  1. Missing inbound authentication (CWE-306) and authorization (CWE-862) on the UPI route group makes the trigger reachable to any off-path network attacker who can reach SMF on the SBI -- no token, no UE state needed. The same-instance nsmf-oam returning 401 (see free5gc/free5gc#887) proves OAuth middleware is wired in for other SMF route groups and only missing on UPI.
  2. Reachable assertion / fail-fast (CWE-617): topology parsing calls logger.InitLog.Fatalf(...) on attacker-influenced validation failures. Fatalf is os.Exit(1)-equivalent -- it skips Gin's recovery, the deferred handlers, and kills the whole SMF process. This is materially worse than the related panic-DoS in free5gc/free5gc#905, which Gin recovers from at the goroutine level.

Any party that can reach SMF on the SBI can: - Send one unauthenticated POST with an overlapping UE pool and immediately terminate the SMF process, dropping all of SMF's SBI surface (PDU-session establishment, UE policy interactions) until SMF is restarted. - Repeat the trigger after every restart to sustain the outage. - Use sibling Fatalf paths (invalid-pool, static-pool exclusion) to sustain the same DoS even if the overlap check is hardened in isolation, because the underlying defect is using Fatalf for request-time validation on an unauthenticated handler.

No Confidentiality impact (the crash returns no data to the attacker). No persistent Integrity impact (the topology updates are in-memory and are lost when SMF dies). The whole impact concentrates in Availability: complete loss of SMF service via a single unauthenticated request.

Affected: free5gc v4.2.1.

Upstream issue: https://github.com/free5gc/free5gc/issues/906 Upstream fix: https://github.com/free5gc/smf/pull/203

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/free5gc/smf"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.4.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44321"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306",
      "CWE-617",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-08T22:47:24Z",
    "nvd_published_at": "2026-05-27T17:16:37Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nfree5GC\u0027s SMF mounts the `UPI` management route group without inbound OAuth2 middleware (same root cause as free5gc/free5gc#887). The `POST /upi/v1/upNodesLinks` create-or-update handler accepts attacker-controlled JSON and passes it directly into `UpNodesFromConfiguration()`, which calls `logger.InitLog.Fatalf(...)` on several validation failures. One confirmed path is the UE-IP-pool overlap check: a single unauthenticated POST that adds a new UPF whose pool overlaps an existing UPF terminates the entire SMF process (`docker ps` shows `Exited (1)`), not just the goroutine. This is a stronger sink than free5gc/free5gc#905: that one panics inside the request goroutine and Gin recovers; this one calls `Fatalf` which is `os.Exit(1)`-equivalent and kills the whole SMF process, dropping all of SMF\u0027s SBI surface (PDU-session establishment, UE policy lookups, etc.) until the process is restarted.\n\n### Details\nValidated against the SMF container in the official Docker compose lab.\n- Source repo tag: `v4.2.1`\n- Running Docker image: `free5gc/smf:v4.2.1`\n- Runtime SMF commit: `8385c00a`\n- Docker validation date: 2026-03-22 local (container log timestamp `2026-03-21T23:47:07Z`)\n- SMF endpoint: `http://10.100.200.6:8000`\n\nThe broader `UPI` auth gap (#887) lets the unauthenticated POST reach the create/update handler. From there:\n\nVulnerable handler dispatches into topology parsing:\n```\nPOST /upi/v1/upNodesLinks\n -\u003e UpNodesFromConfiguration()\n   -\u003e isOverlap(allUEIPPools)\n     -\u003e logger.InitLog.Fatalf(\"overlap cidr value between UPFs\")\n```\n\nCode evidence (paths in `free5gc/smf`):\n- UPI group mounted WITHOUT auth middleware (preconditions for unauthenticated reachability):\n  - `NFs/smf/internal/sbi/server.go:76`\n  - `NFs/smf/internal/sbi/server.go:78`\n- Create-or-update handler accepts attacker JSON and forwards it to `UpNodesFromConfiguration()`:\n  - `NFs/smf/internal/sbi/api_upi.go:60`\n  - `NFs/smf/internal/sbi/api_upi.go:72`\n- Pool parsing (input from attacker JSON):\n  - `NFs/smf/internal/context/user_plane_information.go:413`\n- Overlap check that calls `Fatalf`:\n  - `NFs/smf/internal/context/user_plane_information.go:479`\n\nThe same unauthenticated POST path also reaches sibling `Fatalf` calls for invalid-pool and static-pool-exclusion failures, so this is not a one-off code smell -- it is a class of attacker-reachable `Fatalf` call sites on a single unauthenticated handler:\n- `NFs/smf/internal/context/user_plane_information.go:416`\n- `NFs/smf/internal/context/user_plane_information.go:424`\n- `NFs/smf/internal/context/user_plane_information.go:430`\n\n### PoC\nReproduced end-to-end against the running SMF at `http://10.100.200.6:8000`.\n\n1. Trigger: unauthenticated POST that adds a UPF with a UE pool overlapping the default UPF (`10.60.0.0/16`):\n```\ncurl -i -X POST http://10.100.200.6:8000/upi/v1/upNodesLinks \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  --data \u0027{\"links\":[{\"A\":\"gNB1\",\"B\":\"UPF-OVERLAP-20260322\"}],\"upNodes\":{\"UPF-OVERLAP-20260322\":{\"type\":\"UPF\",\"nodeID\":\"198.51.100.20\",\"addr\":\"198.51.100.20\",\"sNssaiUpfInfos\":[{\"sNssai\":{\"sst\":1,\"sd\":\"010203\"},\"dnnUpfInfoList\":[{\"dnn\":\"internet\",\"pools\":[{\"cidr\":\"10.60.0.0/16\"}]}]}]}}}\u0027\n```\n\nClient-side observation (server died mid-request, no HTTP response written):\n```\ncurl: (52) Empty reply from server\n```\n\n2. Confirm the SMF container exited:\n```\ndocker ps -a --filter name=smf --format \u0027{{.Names}}\\t{{.Status}}\u0027\n```\n```\nsmf    Exited (1) 9 seconds ago\n```\n\n3. SMF container logs (`docker logs --tail 80 smf`) show the `FATA` line that terminated the process:\n```\n[FATA][SMF][Init] overlap cidr value between UPFs\n```\n\n### Impact\nUnauthenticated process-kill DoS on the SMF management plane.\n\n1. Missing inbound authentication (CWE-306) and authorization (CWE-862) on the `UPI` route group makes the trigger reachable to any off-path network attacker who can reach SMF on the SBI -- no token, no UE state needed. The same-instance `nsmf-oam` returning `401` (see free5gc/free5gc#887) proves OAuth middleware is wired in for other SMF route groups and only missing on UPI.\n2. Reachable assertion / fail-fast (CWE-617): topology parsing calls `logger.InitLog.Fatalf(...)` on attacker-influenced validation failures. `Fatalf` is `os.Exit(1)`-equivalent -- it skips Gin\u0027s recovery, the deferred handlers, and kills the whole SMF process. This is materially worse than the related panic-DoS in free5gc/free5gc#905, which Gin recovers from at the goroutine level.\n\nAny party that can reach SMF on the SBI can:\n- Send one unauthenticated POST with an overlapping UE pool and immediately terminate the SMF process, dropping all of SMF\u0027s SBI surface (PDU-session establishment, UE policy interactions) until SMF is restarted.\n- Repeat the trigger after every restart to sustain the outage.\n- Use sibling `Fatalf` paths (invalid-pool, static-pool exclusion) to sustain the same DoS even if the overlap check is hardened in isolation, because the underlying defect is using `Fatalf` for request-time validation on an unauthenticated handler.\n\nNo Confidentiality impact (the crash returns no data to the attacker). No persistent Integrity impact (the topology updates are in-memory and are lost when SMF dies). The whole impact concentrates in Availability: complete loss of SMF service via a single unauthenticated request.\n\nAffected: free5gc v4.2.1.\n\nUpstream issue: https://github.com/free5gc/free5gc/issues/906\nUpstream fix: https://github.com/free5gc/smf/pull/203",
  "id": "GHSA-44qj-cghf-9p97",
  "modified": "2026-06-08T23:47:19Z",
  "published": "2026-05-08T22:47:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/free5gc/security/advisories/GHSA-44qj-cghf-9p97"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44321"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/free5gc/issues/906"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/smf/pull/203"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/smf/commit/e0974e07ddab44a67d36a563cca383b2449e33e5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/free5gc/free5gc"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "free5GC\u0027s SMF UPI POST /upi/v1/upNodesLinks exits the SMF process on overlapping UE pools (unauthenticated, reachable Fatalf)"
}

GHSA-44RW-4CH6-Q486

Vulnerability from github – Published: 2024-05-02 15:30 – Updated: 2026-04-28 21:35
VLAI
Details

Missing Authorization vulnerability in Kestrel WooCommerce AWeber Newsletter Subscription.This issue affects WooCommerce AWeber Newsletter Subscription: from n/a through 4.0.2.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-33944"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-02T13:15:26Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in Kestrel WooCommerce AWeber Newsletter Subscription.This issue affects WooCommerce AWeber Newsletter Subscription: from n/a through 4.0.2.",
  "id": "GHSA-44rw-4ch6-q486",
  "modified": "2026-04-28T21:35:01Z",
  "published": "2024-05-02T15:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-33944"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/woocommerce-aweber-newsletter-subscription/wordpress-woocommerce-aweber-newsletter-subscription-plugin-4-0-1-unauthenticated-access-token-change-reset-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:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-44RX-344J-CCV5

Vulnerability from github – Published: 2026-03-13 21:31 – Updated: 2026-03-13 21:31
VLAI
Details

Missing Authorization vulnerability in YMC Filter & Grids ymc-smart-filter allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Filter & Grids: from n/a through <= 3.5.1.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-32397"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-13T19:54:55Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in YMC Filter \u0026 Grids ymc-smart-filter allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Filter \u0026 Grids: from n/a through \u003c= 3.5.1.",
  "id": "GHSA-44rx-344j-ccv5",
  "modified": "2026-03-13T21:31:49Z",
  "published": "2026-03-13T21:31:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32397"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/ymc-smart-filter/vulnerability/wordpress-filter-grids-plugin-3-5-1-broken-access-control-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-44V6-7FXQ-VGF4

Vulnerability from github – Published: 2026-08-28 16:39 – Updated: 2026-08-28 16:39
VLAI
Summary
Vikunja has an incomplete fix for CVE-2026-35595: Write-only user can detach shared project from parent hierarchy via parent_project_id=0
Details

Summary

The fix for CVE-2026-35595 (project re-parenting privilege escalation) only gates reparent operations when parent_project_id > 0. A user with Write (but not Admin) permission on a shared child project can detach it from its parent by sending parent_project_id: 0, bypassing the Admin requirement. This severs the recursive CTE permission inheritance chain, potentially disrupting the project hierarchy and affecting inherited access for other collaborators.

Affected component

  • Package: go-vikunja/vikunja
  • Affected versions: v2.3.0 and later (including latest unstable v2.3.0-246-9852aff4). The fix for CVE-2026-35595 was introduced in v2.3.0 but left the detach-to-root case unpatched. Fixed in 2.4.0.
  • Tested on: Vikunja v2.3.0 (Docker image vikunja/vikunja:2.3.0) AND latest unstable (vikunja/vikunja:unstable, v2.3.0-246-9852aff4 built 2026-04-27)

Technical detail

Vulnerable code

File: pkg/models/project.go (lines 1009-1041)

// GHSA-2vq4-854f-5c72 / CVE-2026-35595: the recursive permission CTE
// cascades Admin from any owned ancestor, so moving a shared child
// under an attacker-owned root grants Admin on the child. Require
// Admin on both sides of a reparent.
//
// Only gate on non-zero ParentProjectID: the generic update handler
// binds a fresh struct, so an omitted parent_project_id is
// indistinguishable from an explicit 0. Detach-to-root is therefore
// out of scope here -- a proper fix needs a pointer field.
if project.ParentProjectID > 0 {
    // ... Admin check (lines 1019-1041) -- SKIPPED when ParentProjectID == 0
}

File: pkg/models/project_permissions.go (line 145)

if p.ParentProjectID != 0 && p.ParentProjectID != ol.ParentProjectID {
    // reparent permission check -- SKIPPED when ParentProjectID == 0
}

File: pkg/models/project.go (line 1065)

colsToUpdate := []string{
    "title", "is_archived", "identifier", "hex_color",
    "parent_project_id",  // <-- ALWAYS included, writes 0 to DB
    "position",
}

Why it's exploitable

  1. The generic web handler (pkg/web/handler/update.go:37) creates a fresh empty Project{} struct -- ParentProjectID defaults to Go's zero value (0).
  2. When JSON body contains "parent_project_id": 0, the struct has ParentProjectID == 0.
  3. CanUpdate at line 145: ParentProjectID != 0 is false -- reparent check skipped -- falls through to CanWrite which succeeds (attacker has Write).
  4. UpdateProject at line 1018: ParentProjectID > 0 is false -- Admin gate skipped entirely.
  5. xorm writes parent_project_id = 0 because "parent_project_id" is always in colsToUpdate with Cols().
  6. The project is detached from its parent hierarchy.

Precondition checklist

  • [x] Attacker has authenticated account
  • [x] Attacker has Write permission on a child project (via direct share or team membership)
  • [x] The target project has a non-zero parent_project_id (it's a child of another project)
  • [x] Default Vikunja configuration (no special setup needed)

Reproduction

Prerequisites: Two users (victim = project owner, attacker = Write-only collaborator), a parent project, and a child project shared with the attacker at Write permission.

  1. Authenticate as attacker:
TOKEN=$(curl -s -X POST http://localhost:3456/api/v1/login \
  -H 'Content-Type: application/json' \
  -d '{"username":"user_a","password":"UserAPassword1!"}' | jq -r '.token')
  1. Verify attacker does NOT have Admin (delete should return 403):
curl -s -o /dev/null -w '%{http_code}' -X DELETE http://localhost:3456/api/v1/projects/4 \
  -H "Authorization: Bearer $TOKEN"
# Expected: 403
  1. Exploit -- detach project from parent:
curl -s -X POST http://localhost:3456/api/v1/projects/4 \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"title":"Sensitive Child Project","parent_project_id":0}'
  1. Verify detachment:
curl -s http://localhost:3456/api/v1/projects/4 \
  -H "Authorization: Bearer $TOKEN" | jq '.parent_project_id'
# Returns: 0 (was: 3)

Evidence (3 independent runs)

Run parent_project_id BEFORE DELETE attempt (proves no Admin) parent_project_id AFTER Result
1 3 (child of project 3) HTTP 403 Forbidden null (detached to root) CONFIRMED
2 3 (child of project 3) HTTP 403 Forbidden null (detached to root) CONFIRMED
3 3 (child of project 3) HTTP 403 Forbidden null (detached to root) CONFIRMED

Note: "null (detached to root)" means parent_project_id was set to 0 in the database, making the project a root-level project with no parent.

Impact

  • Unauthorized hierarchy modification: A user with only Write permission can detach a child project from its parent, which should require Admin permission (as established by the CVE-2026-35595 fix for non-zero reparents).
  • Permission inheritance disruption: The recursive CTE permission model traverses parent_project_id upward. Detaching a project severs this chain, potentially causing other collaborators who inherited access through the parent to lose their permissions on the detached project.
  • Organizational disruption: The project moves from a structured hierarchy to a root-level project, breaking the owner's intended organizational structure.

Suggested fix

Use a pointer field *int64 for ParentProjectID to distinguish between "field omitted" (nil) and "explicitly set to 0" (detach). The fix commit itself acknowledges this at project.go:1017: "a proper fix needs a pointer field."

Alternatively, add a dedicated detach boolean field or a separate API endpoint for detaching projects, with its own Admin permission check.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.vikunja.io/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.3.0"
            },
            {
              "fixed": "2.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55064"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-28T16:39:08Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe fix for CVE-2026-35595 (project re-parenting privilege escalation) only gates reparent operations when `parent_project_id \u003e 0`. A user with Write (but not Admin) permission on a shared child project can detach it from its parent by sending `parent_project_id: 0`, bypassing the Admin requirement. This severs the recursive CTE permission inheritance chain, potentially disrupting the project hierarchy and affecting inherited access for other collaborators.\n\n## Affected component\n\n- **Package:** go-vikunja/vikunja\n- **Affected versions:** v2.3.0 and later (including latest unstable v2.3.0-246-9852aff4). The fix for CVE-2026-35595 was introduced in v2.3.0 but left the detach-to-root case unpatched. Fixed in 2.4.0.\n- **Tested on:** Vikunja v2.3.0 (Docker image vikunja/vikunja:2.3.0) AND latest unstable (vikunja/vikunja:unstable, v2.3.0-246-9852aff4 built 2026-04-27)\n\n## Technical detail\n\n### Vulnerable code\n\n**File: `pkg/models/project.go` (lines 1009-1041)**\n```go\n// GHSA-2vq4-854f-5c72 / CVE-2026-35595: the recursive permission CTE\n// cascades Admin from any owned ancestor, so moving a shared child\n// under an attacker-owned root grants Admin on the child. Require\n// Admin on both sides of a reparent.\n//\n// Only gate on non-zero ParentProjectID: the generic update handler\n// binds a fresh struct, so an omitted parent_project_id is\n// indistinguishable from an explicit 0. Detach-to-root is therefore\n// out of scope here -- a proper fix needs a pointer field.\nif project.ParentProjectID \u003e 0 {\n    // ... Admin check (lines 1019-1041) -- SKIPPED when ParentProjectID == 0\n}\n```\n\n**File: `pkg/models/project_permissions.go` (line 145)**\n```go\nif p.ParentProjectID != 0 \u0026\u0026 p.ParentProjectID != ol.ParentProjectID {\n    // reparent permission check -- SKIPPED when ParentProjectID == 0\n}\n```\n\n**File: `pkg/models/project.go` (line 1065)**\n```go\ncolsToUpdate := []string{\n    \"title\", \"is_archived\", \"identifier\", \"hex_color\",\n    \"parent_project_id\",  // \u003c-- ALWAYS included, writes 0 to DB\n    \"position\",\n}\n```\n\n### Why it\u0027s exploitable\n\n1. The generic web handler (`pkg/web/handler/update.go:37`) creates a fresh empty `Project{}` struct -- `ParentProjectID` defaults to Go\u0027s zero value (0).\n2. When JSON body contains `\"parent_project_id\": 0`, the struct has `ParentProjectID == 0`.\n3. `CanUpdate` at line 145: `ParentProjectID != 0` is false -- reparent check skipped -- falls through to `CanWrite` which succeeds (attacker has Write).\n4. `UpdateProject` at line 1018: `ParentProjectID \u003e 0` is false -- Admin gate skipped entirely.\n5. xorm writes `parent_project_id = 0` because `\"parent_project_id\"` is always in `colsToUpdate` with `Cols()`.\n6. The project is detached from its parent hierarchy.\n\n### Precondition checklist\n\n- [x] Attacker has authenticated account\n- [x] Attacker has Write permission on a child project (via direct share or team membership)\n- [x] The target project has a non-zero parent_project_id (it\u0027s a child of another project)\n- [x] Default Vikunja configuration (no special setup needed)\n\n### Reproduction\n\n**Prerequisites:** Two users (victim = project owner, attacker = Write-only collaborator), a parent project, and a child project shared with the attacker at Write permission.\n\n1. Authenticate as attacker:\n```bash\nTOKEN=$(curl -s -X POST http://localhost:3456/api/v1/login \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"username\":\"user_a\",\"password\":\"UserAPassword1!\"}\u0027 | jq -r \u0027.token\u0027)\n```\n\n2. Verify attacker does NOT have Admin (delete should return 403):\n```bash\ncurl -s -o /dev/null -w \u0027%{http_code}\u0027 -X DELETE http://localhost:3456/api/v1/projects/4 \\\n  -H \"Authorization: Bearer $TOKEN\"\n# Expected: 403\n```\n\n3. Exploit -- detach project from parent:\n```bash\ncurl -s -X POST http://localhost:3456/api/v1/projects/4 \\\n  -H \"Authorization: Bearer $TOKEN\" \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"title\":\"Sensitive Child Project\",\"parent_project_id\":0}\u0027\n```\n\n4. Verify detachment:\n```bash\ncurl -s http://localhost:3456/api/v1/projects/4 \\\n  -H \"Authorization: Bearer $TOKEN\" | jq \u0027.parent_project_id\u0027\n# Returns: 0 (was: 3)\n```\n\n### Evidence (3 independent runs)\n\n| Run | parent_project_id BEFORE | DELETE attempt (proves no Admin) | parent_project_id AFTER | Result |\n|-----|--------------------------|----------------------------------|-------------------------|--------|\n| 1 | 3 (child of project 3) | HTTP 403 Forbidden | null (detached to root) | CONFIRMED |\n| 2 | 3 (child of project 3) | HTTP 403 Forbidden | null (detached to root) | CONFIRMED |\n| 3 | 3 (child of project 3) | HTTP 403 Forbidden | null (detached to root) | CONFIRMED |\n\n*Note: \"null (detached to root)\" means `parent_project_id` was set to `0` in the database, making the project a root-level project with no parent.*\n\n## Impact\n\n- **Unauthorized hierarchy modification:** A user with only Write permission can detach a child project from its parent, which should require Admin permission (as established by the CVE-2026-35595 fix for non-zero reparents).\n- **Permission inheritance disruption:** The recursive CTE permission model traverses `parent_project_id` upward. Detaching a project severs this chain, potentially causing other collaborators who inherited access through the parent to lose their permissions on the detached project.\n- **Organizational disruption:** The project moves from a structured hierarchy to a root-level project, breaking the owner\u0027s intended organizational structure.\n\n## Suggested fix\n\nUse a pointer field `*int64` for `ParentProjectID` to distinguish between \"field omitted\" (nil) and \"explicitly set to 0\" (detach). The fix commit itself acknowledges this at `project.go:1017`: \"a proper fix needs a pointer field.\"\n\nAlternatively, add a dedicated `detach` boolean field or a separate API endpoint for detaching projects, with its own Admin permission check.",
  "id": "GHSA-44v6-7fxq-vgf4",
  "modified": "2026-08-28T16:39:08Z",
  "published": "2026-08-28T16:39:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-44v6-7fxq-vgf4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-vikunja/vikunja"
    }
  ],
  "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": "Vikunja has an incomplete fix for CVE-2026-35595: Write-only user can detach shared project from parent hierarchy via parent_project_id=0"
}

GHSA-44W3-4X9P-XMFF

Vulnerability from github – Published: 2025-01-26 12:30 – Updated: 2025-01-26 12:30
VLAI
Details

The Zox News theme for WordPress is vulnerable to unauthorized modification of data that can lead to privilege escalation due to a missing capability check on the 'backup_options' and 'restore_options' function in all versions up to, and including, 3.16.0. This makes it possible for authenticated attackers, with Subscriber-level access and above, to update arbitrary options on the WordPress site. This can be leveraged to update the default role for registration to administrator and enable user registration for attackers to gain administrative user access to a vulnerable site.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-11936"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-26T12:15:28Z",
    "severity": "HIGH"
  },
  "details": "The Zox News theme for WordPress is vulnerable to unauthorized modification of data that can lead to privilege escalation due to a missing capability check on the \u0027backup_options\u0027 and \u0027restore_options\u0027 function in all versions up to, and including, 3.16.0. This makes it possible for authenticated attackers, with Subscriber-level access and above, to update arbitrary options on the WordPress site. This can be leveraged to update the default role for registration to administrator and enable user registration for attackers to gain administrative user access to a vulnerable site.",
  "id": "GHSA-44w3-4x9p-xmff",
  "modified": "2025-01-26T12:30:31Z",
  "published": "2025-01-26T12:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-11936"
    },
    {
      "type": "WEB",
      "url": "https://themeforest.net/item/zox-news-professional-wordpress-news-magazine-theme/20381541"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/3f061e7f-6a87-4d4a-9b4e-8234883f2ebc?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-44W7-GH9C-4QVR

Vulnerability from github – Published: 2022-05-24 16:43 – Updated: 2023-12-14 15:46
VLAI
Summary
Missing permission check in Jenkins XebiaLabs XL Deploy Plugin
Details

A missing permission check in Jenkins XebiaLabs XL Deploy Plugin in the Credential#doValidateUserNamePassword form validation method allows attackers with Overall/Read permission to initiate a connection to an attacker-specified server.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.xebialabs.deployit.ci:deployit-plugin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.5.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-10305"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-12-14T15:46:32Z",
    "nvd_published_at": "2019-04-18T17:29:00Z",
    "severity": "MODERATE"
  },
  "details": "A missing permission check in Jenkins XebiaLabs XL Deploy Plugin in the Credential#doValidateUserNamePassword form validation method allows attackers with Overall/Read permission to initiate a connection to an attacker-specified server.",
  "id": "GHSA-44w7-gh9c-4qvr",
  "modified": "2023-12-14T15:46:32Z",
  "published": "2022-05-24T16:43:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10305"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/xldeploy-plugin/commit/5acf9d797fe0afb4defa7c1d5e198103fcdb6989"
    },
    {
      "type": "WEB",
      "url": "https://jenkins.io/security/advisory/2019-04-17/#SECURITY-983"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/108045"
    }
  ],
  "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"
    }
  ],
  "summary": "Missing permission check in Jenkins XebiaLabs XL Deploy Plugin"
}

GHSA-44WG-W993-P987

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

GeoVision GV-LPC2211 V1.13 allows a Guest user to overwrite device configuration and replace the administrator password through SSVR.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-88271"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-10T09:17:04Z",
    "severity": "HIGH"
  },
  "details": "GeoVision GV-LPC2211 V1.13 allows a Guest user to overwrite device configuration and replace the administrator password through SSVR.",
  "id": "GHSA-44wg-w993-p987",
  "modified": "2026-09-10T09:31:35Z",
  "published": "2026-09-10T09:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-88271"
    },
    {
      "type": "WEB",
      "url": "https://www.geovision.com.tw/cyber_security.php"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-44WP-G8F4-F4V5

Vulnerability from github – Published: 2026-06-23 22:16 – Updated: 2026-06-23 22:16
VLAI
Summary
Filament: Unauthenticated temporary file upload on auth pages
Details

Any schema can contain a file upload form field, so Filament applies Livewire's WithFileUploads trait to the Livewire component the schema is embedded in. However, some schemas, such as the panel login form, do not require file uploads, and exposing unauthenticated temporary file uploads on these components is not an acceptable risk. On these components, an unauthenticated attacker could upload arbitrary files to the application's temporary storage, which could be abused to exhaust disk space or inflate storage costs.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.11.4"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "filament/filament"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.11.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.6.4"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "filament/filament"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0"
            },
            {
              "fixed": "5.6.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.3.51"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "filament/filament"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.3.52"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48500"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-23T22:16:58Z",
    "nvd_published_at": "2026-06-22T22:16:47Z",
    "severity": "MODERATE"
  },
  "details": "Any schema can contain a file upload form field, so Filament applies Livewire\u0027s `WithFileUploads` trait to the Livewire component the schema is embedded in. However, some schemas, such as the panel login form, do not require file uploads, and exposing unauthenticated temporary file uploads on these components is not an acceptable risk. On these components, an unauthenticated attacker could upload arbitrary files to the application\u0027s temporary storage, which could be abused to exhaust disk space or inflate storage costs.",
  "id": "GHSA-44wp-g8f4-f4v5",
  "modified": "2026-06-23T22:16:58Z",
  "published": "2026-06-23T22:16:58Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/filamentphp/filament/security/advisories/GHSA-44wp-g8f4-f4v5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48500"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/filamentphp/filament"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Filament: Unauthenticated temporary file upload on auth pages"
}

GHSA-4528-GX3Q-G73R

Vulnerability from github – Published: 2026-08-25 06:31 – Updated: 2026-08-25 06:31
VLAI
Details

The InfusedWoo Pro plugin for WordPress is vulnerable to Privilege Escalation via Account Takeover in all versions up to, and including, 5.1.17. This is due to a missing capability check in the ajax_iwar_preview_email() function, which uses is_admin() as its only authorization check and allows low-privilege users to render email preview merge fields for an arbitrary email address. This makes it possible for authenticated attackers, with subscriber-level access and above, to generate and retrieve a valid password reset link for any WordPress user, including administrators, enabling account takeover.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-19892"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-25T04:18:10Z",
    "severity": "HIGH"
  },
  "details": "The InfusedWoo Pro plugin for WordPress is vulnerable to Privilege Escalation via Account Takeover in all versions up to, and including, 5.1.17. This is due to a missing capability check in the `ajax_iwar_preview_email()` function, which uses `is_admin()` as its only authorization check and allows low-privilege users to render email preview merge fields for an arbitrary email address. This makes it possible for authenticated attackers, with subscriber-level access and above, to generate and retrieve a valid password reset link for any WordPress user, including administrators, enabling account takeover.",
  "id": "GHSA-4528-gx3q-g73r",
  "modified": "2026-08-25T06:31:32Z",
  "published": "2026-08-25T06:31:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-19892"
    },
    {
      "type": "WEB",
      "url": "https://downloads.infusedwoo.com/updater/iw5.php?changelog"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/207fc33b-ccf6-4c39-976d-41e6a89ad1ec?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Architecture and Design
  • Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
  • Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Architecture and Design

Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Mitigation MIT-4.4
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
Architecture and Design
  • For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
  • One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
System Configuration Installation

Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

CAPEC-665: Exploitation of Thunderbolt Protection Flaws

An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.