Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

7172 vulnerabilities reference this CWE, most recent first.

GHSA-FPG6-XQJ4-J7WF

Vulnerability from github – Published: 2022-05-13 01:18 – Updated: 2022-12-06 21:53
VLAI
Summary
Jenkins Jira Plugin Incorrect Authorization vulnerability
Details

An improper authorization vulnerability exists in Jenkins Jira Plugin 3.0.1 and earlier in JiraSite.java that allows attackers with Overall/Read access to have Jenkins connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins. In version 3.0.2, this form validation method requires POST requests and Overall/Administer (for globally defined sites) or Item/Configure permissions (for sites defined for a folder).

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.0.1"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:jira"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2018-1000412"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-12-06T21:53:38Z",
    "nvd_published_at": "2019-01-09T23:29:00Z",
    "severity": "MODERATE"
  },
  "details": "An improper authorization vulnerability exists in Jenkins Jira Plugin 3.0.1 and earlier in JiraSite.java that allows attackers with Overall/Read access to have Jenkins connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins. In version 3.0.2, this form validation method requires POST requests and Overall/Administer (for globally defined sites) or Item/Configure permissions (for sites defined for a folder).",
  "id": "GHSA-fpg6-xqj4-j7wf",
  "modified": "2022-12-06T21:53:38Z",
  "published": "2022-05-13T01:18:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1000412"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/jira-plugin/commit/612a6ef06dbd5a63bea0b128142c726e96195eda"
    },
    {
      "type": "WEB",
      "url": "https://jenkins.io/security/advisory/2018-09-25/#SECURITY-1029"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/106532"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jenkins Jira Plugin Incorrect Authorization vulnerability"
}

GHSA-FPGR-MG9W-X2HM

Vulnerability from github – Published: 2022-03-29 00:01 – Updated: 2022-04-05 00:00
VLAI
Details

An issue has been discovered in GitLab CE/EE affecting all versions starting from 12.10 before 14.6.5, all versions starting from 14.7 before 14.7.4, all versions starting from 14.8 before 14.8.2. An unauthorised user was able to steal runner registration tokens through an information disclosure vulnerability using quick actions commands.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-0735"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-03-28T19:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "An issue has been discovered in GitLab CE/EE affecting all versions starting from 12.10 before 14.6.5, all versions starting from 14.7 before 14.7.4, all versions starting from 14.8 before 14.8.2. An unauthorised user was able to steal runner registration tokens through an information disclosure vulnerability using quick actions commands.",
  "id": "GHSA-fpgr-mg9w-x2hm",
  "modified": "2022-04-05T00:00:47Z",
  "published": "2022-03-29T00:01:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0735"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-0735.json"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/353529"
    }
  ],
  "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"
    }
  ]
}

GHSA-FPH2-GPV2-73CW

Vulnerability from github – Published: 2022-05-24 19:04 – Updated: 2022-07-13 00:01
VLAI
Details

Insufficient policy enforcement in Content Security Policy in Google Chrome prior to 91.0.4472.77 allowed a remote attacker to bypass content security policy via a crafted HTML page.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-30532"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-07T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Insufficient policy enforcement in Content Security Policy in Google Chrome prior to 91.0.4472.77 allowed a remote attacker to bypass content security policy via a crafted HTML page.",
  "id": "GHSA-fph2-gpv2-73cw",
  "modified": "2022-07-13T00:01:22Z",
  "published": "2022-05-24T19:04:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-30532"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2021/05/stable-channel-update-for-desktop_25.html"
    },
    {
      "type": "WEB",
      "url": "https://crbug.com/1117687"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ETMZL6IHCTCTREEL434BQ4THQ7EOHJ43"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/PAT6EOXVQFE6JFMFQF4IKAOUQSHMHL54"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202107-06"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FPH2-R4QG-9576

Vulnerability from github – Published: 2026-03-20 20:44 – Updated: 2026-03-30 13:51
VLAI
Summary
Parse Server's LiveQuery bypasses CLP pointer permission enforcement
Details

Impact

Parse Server's LiveQuery WebSocket interface does not enforce Class-Level Permission (CLP) pointer permissions (readUserFields and pointerFields). Any authenticated user can subscribe to LiveQuery events and receive real-time updates for all objects in classes protected by pointer permissions, regardless of whether the pointer fields on those objects point to the subscribing user. This bypasses the intended read access control, allowing unauthorized access to potentially sensitive data that is correctly restricted via the REST API.

Patches

The LiveQuery server now enforces pointer permissions on each event. After the existing check passes (which defers pointer permissions by design), the fix checks whether any configured pointer field on the object points to the subscribing user. Events for objects that don't match are silently skipped, consistent with how ACL mismatches are handled.

Workarounds

Use ACLs on individual objects to restrict read access instead of relying solely on CLP pointer permissions. ACLs are enforced by LiveQuery.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "parse-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0"
            },
            {
              "fixed": "9.6.0-alpha.42"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "parse-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.6.53"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33421"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-20T20:44:36Z",
    "nvd_published_at": "2026-03-24T19:16:53Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nParse Server\u0027s LiveQuery WebSocket interface does not enforce Class-Level Permission (CLP) pointer permissions (`readUserFields` and `pointerFields`). Any authenticated user can subscribe to LiveQuery events and receive real-time updates for all objects in classes protected by pointer permissions, regardless of whether the pointer fields on those objects point to the subscribing user. This bypasses the intended read access control, allowing unauthorized access to potentially sensitive data that is correctly restricted via the REST API.\n\n### Patches\n\nThe LiveQuery server now enforces pointer permissions on each event. After the existing check passes (which defers pointer permissions by design), the fix checks whether any configured pointer field on the object points to the subscribing user. Events for objects that don\u0027t match are silently skipped, consistent with how ACL mismatches are handled.\n\n### Workarounds\n\nUse ACLs on individual objects to restrict read access instead of relying solely on CLP pointer permissions. ACLs are enforced by LiveQuery.",
  "id": "GHSA-fph2-r4qg-9576",
  "modified": "2026-03-30T13:51:19Z",
  "published": "2026-03-20T20:44:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/security/advisories/GHSA-fph2-r4qg-9576"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33421"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/pull/10250"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/pull/10252"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/commit/6c3317aca6eb618ac48f999021ae3ef7766ad1ea"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/commit/976dad109f3fe3fbd0a3a35ef62e7a5d35eb0bee"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/parse-community/parse-server"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Parse Server\u0027s LiveQuery bypasses CLP pointer permission enforcement"
}

GHSA-FPMQ-9J97-CQ2C

Vulnerability from github – Published: 2022-05-24 17:40 – Updated: 2025-05-30 18:30
VLAI
Details

An improper authorization vulnerability exists in Star Practice Management Web version 2019.2.0.6, allowing an unauthorized user to access Launcher Configuration Panel.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-28402"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-29T07:15:00Z",
    "severity": "HIGH"
  },
  "details": "An improper authorization vulnerability exists in Star Practice Management Web version 2019.2.0.6, allowing an unauthorized user to access Launcher Configuration Panel.",
  "id": "GHSA-fpmq-9j97-cq2c",
  "modified": "2025-05-30T18:30:39Z",
  "published": "2022-05-24T17:40:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28402"
    },
    {
      "type": "WEB",
      "url": "https://cds.thalesgroup.com/en/tcs-cert/CVE-2020-28402"
    },
    {
      "type": "WEB",
      "url": "https://excellium-services.com/cert-xlm-advisory/CVE-2020-28402"
    },
    {
      "type": "WEB",
      "url": "https://www.starpracticemanagement.com"
    }
  ],
  "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-FPPQ-F2M6-XV5C

Vulnerability from github – Published: 2025-02-11 18:31 – Updated: 2025-02-28 17:44
VLAI
Summary
Improper Authorization vulnerability in Magento and Adobe Commerce
Details

Adobe Commerce versions 2.4.8-beta1, 2.4.7-p3, 2.4.6-p8, 2.4.5-p10, 2.4.4-p11 and earlier are affected by an Improper Authorization vulnerability that could result in Privilege escalation. An attacker could leverage this vulnerability to bypass security measures and gain unauthorized access. Exploitation of this issue does not require user interaction. A successful attacker can abuse this to achieve session takeover, increasing the confidentiality and integrity impact as high.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.8-beta1"
            },
            {
              "fixed": "2.4.8-beta2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.7-beta1"
            },
            {
              "fixed": "2.4.7-p4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.6-p1"
            },
            {
              "fixed": "2.4.6-p9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.5-p1"
            },
            {
              "fixed": "2.4.5-p11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.4.4-p12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/project-community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-24434"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-02-12T17:52:02Z",
    "nvd_published_at": "2025-02-11T18:15:46Z",
    "severity": "CRITICAL"
  },
  "details": "Adobe Commerce versions 2.4.8-beta1, 2.4.7-p3, 2.4.6-p8, 2.4.5-p10, 2.4.4-p11 and earlier are affected by an Improper Authorization vulnerability that could result in Privilege escalation. An attacker could leverage this vulnerability to bypass security measures and gain unauthorized access. Exploitation of this issue does not require user interaction. A successful attacker can abuse this to achieve session takeover, increasing the confidentiality and integrity impact as high.",
  "id": "GHSA-fppq-f2m6-xv5c",
  "modified": "2025-02-28T17:44:35Z",
  "published": "2025-02-11T18:31:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24434"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/magento/magento2"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/magento/apsb25-08.html"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Improper Authorization vulnerability in Magento and Adobe Commerce"
}

GHSA-FPRF-R6RV-XG99

Vulnerability from github – Published: 2026-10-09 20:57 – Updated: 2026-10-09 20:57
VLAI
Summary
Vikunja: Saved filter creation with an empty filter string recalculates task positions across all tenants
Details

Summary

In Vikunja v2.6.0 the task position recalculation that runs when a saved filter view is created fails open when the requesting user has no accessible projects. Instead of aborting, the search that feeds the recalculation loses its project scope entirely and returns every task in the instance. The server then writes one task_positions row per task per view (four views per filter) into views owned by the requesting user, including rows that reference tasks of other tenants the user can never see. Any authenticated user can trigger this. The impact is a cross-tenant integrity violation, a single-request write amplification primitive that scales with instance size, and a violation of the invariant stated in the fix for GHSA-w39f-h553-h2mx that position writes are scoped by project read access.

Details

Vikunja computes kanban and list ordering in a shared task_positions table keyed by (task_id, project_view_id). When a saved filter is created, SavedFilter.Create (pkg/models/saved_filters.go:130) calls CreateDefaultViewsForProject (pkg/models/project_view.go:816) which, for every default view it creates, calls RecalculateTaskPositions with addExistingTasksToView = true (pkg/models/project_view.go:447).

RecalculateTaskPositions (pkg/models/task_position.go:312) builds a TaskCollection and, for filter views (view.ProjectID < -1), resets the project scope to zero and injects the saved filter's filter string. The scope of the subsequent search is derived from getRelevantProjectsFromCollection (pkg/models/task_collection.go:188), which for ProjectID == 0 returns exactly the projects the requesting user can access.

Inside dbTaskSearcher.Search (pkg/models/task_search.go), the WHERE clause is assembled at line 632:

cond := builder.And(builder.Or(projectIDCond, favoritesCond), where, filterCond)

projectIDCond is only set when len(opts.projectIDs) > 0 and favoritesCond only when the caller opted into the favorites arm, which RecalculateTaskPositions never does. With zero accessible projects, an empty filter string (which produces no filter condition in getTaskFiltersFromFilterString) and no search string, all four children of the builder.And are invalid. go-xorm's condition builders silently drop invalid children, so the query becomes SELECT ... FROM tasks with no WHERE clause at all.

The result is written back unconditionally: the function deletes the view's position rows and bulk-inserts one row per returned task per view. Because the filter creation path runs this for four default views, one request writes 4 x total_task_count rows, every one of them referencing tasks the requesting user has no relationship with, including tasks in other users' private projects.

Reaching the zero-project precondition does not require any bug beyond this one. UpdateUserGeneralSettings (pkg/models/user_settings.go:105) assigns default_project_id from the request body without validating that the referenced project exists or belongs to the caller. A user can therefore point their default project at any project id, which unblocks deleting their own Inbox (deletion is refused only while the Inbox is the default project, error 3012 in pkg/models/error.go:482). After the Inbox is gone, getRawProjectsForUser returns an empty list.

Two neighboring controls confirm the intended invariant exists elsewhere and is enforced in sibling paths. The event-driven filter update path gates candidate filters on the filter owner's access to each task's project (matchTasksToViewsOfFilter, introduced by commit b1ad4063e7), and the fix for GHSA-w39f-h553-h2mx validates position target views. The recalculation path on filter creation has no equivalent gate and contradicts the advisory statement that recalculation "aborts on its own project read-access check".

PoC

vikunja-filter-empty-scope-cross-tenant-positions-PoC.zip

The attached archive contains deployment/deploy.sh (local Vikunja v2.6.0 on loopback with SQLite) and poc/poc.sh, which performs the full sequence:

  1. Victim registers, creates a private project and a task.
  2. Attacker registers, sets default_project_id to the victim's project via PUT /api/v2/user/settings/general, deletes their own Inbox, and now has zero accessible projects.
  3. Control: GET /api/v2/projects/{victim} returns 403.
  4. Attacker creates a saved filter with {"filter":"","filter_include_nulls":true}.
  5. Verification: direct SQLite inspection shows task_positions rows referencing the victim's task in all four of the attacker's filter views.
  6. Control: GET /api/v2/projects/{filter_pseudo_project}/tasks returns 0 items, so the written rows are not readable back through collection endpoints.

Result: 10 checks passed on two consecutive runs, each from a wiped database.

Impact

An authenticated user, even one with no project access at all, causes the server to persist cross-tenant references: rows pointing at arbitrary other users' tasks are written into views the attacker controls. Task content is not exposed through the documented read paths (verified), so this is an integrity and availability issue rather than a direct disclosure:

  • Cross-tenant integrity violation. The task_positions state of the attacker's views now encodes other tenants' objects, against the access model the rest of the code enforces.
  • Write amplification and denial of service. One cheap request performs a full-table scan plus 4 x N inserts, where N is the number of tasks in the instance. On an instance with 100,000 tasks that is 400,000 rows per request, and the request can be repeated without bound. CPU, IO and storage costs scale with instance size while attacker cost stays constant.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.vikunja.io/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0-rc0"
            },
            {
              "last_affected": "2.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-09T20:57:38Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nIn Vikunja v2.6.0 the task position recalculation that runs when a saved filter view is created fails open when the requesting user has no accessible projects. Instead of aborting, the search that feeds the recalculation loses its project scope entirely and returns every task in the instance. The server then writes one `task_positions` row per task per view (four views per filter) into views owned by the requesting user, including rows that reference tasks of other tenants the user can never see. Any authenticated user can trigger this. The impact is a cross-tenant integrity violation, a single-request write amplification primitive that scales with instance size, and a violation of the invariant stated in the fix for GHSA-w39f-h553-h2mx that position writes are scoped by project read access.\n\n### Details\n\nVikunja computes kanban and list ordering in a shared `task_positions` table keyed by `(task_id, project_view_id)`. When a saved filter is created, `SavedFilter.Create` (`pkg/models/saved_filters.go:130`) calls `CreateDefaultViewsForProject` (`pkg/models/project_view.go:816`) which, for every default view it creates, calls `RecalculateTaskPositions` with `addExistingTasksToView = true` (`pkg/models/project_view.go:447`).\n\n`RecalculateTaskPositions` (`pkg/models/task_position.go:312`) builds a `TaskCollection` and, for filter views (`view.ProjectID \u003c -1`), resets the project scope to zero and injects the saved filter\u0027s filter string. The scope of the subsequent search is derived from `getRelevantProjectsFromCollection` (`pkg/models/task_collection.go:188`), which for `ProjectID == 0` returns exactly the projects the requesting user can access.\n\nInside `dbTaskSearcher.Search` (`pkg/models/task_search.go`), the WHERE clause is assembled at line 632:\n\n```go\ncond := builder.And(builder.Or(projectIDCond, favoritesCond), where, filterCond)\n```\n\n`projectIDCond` is only set when `len(opts.projectIDs) \u003e 0` and `favoritesCond` only when the caller opted into the favorites arm, which `RecalculateTaskPositions` never does. With zero accessible projects, an empty filter string (which produces no filter condition in `getTaskFiltersFromFilterString`) and no search string, all four children of the `builder.And` are invalid. go-xorm\u0027s condition builders silently drop invalid children, so the query becomes `SELECT ... FROM tasks` with no WHERE clause at all.\n\nThe result is written back unconditionally: the function deletes the view\u0027s position rows and bulk-inserts one row per returned task per view. Because the filter creation path runs this for four default views, one request writes `4 x total_task_count` rows, every one of them referencing tasks the requesting user has no relationship with, including tasks in other users\u0027 private projects.\n\nReaching the zero-project precondition does not require any bug beyond this one. `UpdateUserGeneralSettings` (`pkg/models/user_settings.go:105`) assigns `default_project_id` from the request body without validating that the referenced project exists or belongs to the caller. A user can therefore point their default project at any project id, which unblocks deleting their own Inbox (deletion is refused only while the Inbox is the default project, error 3012 in `pkg/models/error.go:482`). After the Inbox is gone, `getRawProjectsForUser` returns an empty list.\n\nTwo neighboring controls confirm the intended invariant exists elsewhere and is enforced in sibling paths. The event-driven filter update path gates candidate filters on the filter owner\u0027s access to each task\u0027s project (`matchTasksToViewsOfFilter`, introduced by commit `b1ad4063e7`), and the fix for GHSA-w39f-h553-h2mx validates position target views. The recalculation path on filter creation has no equivalent gate and contradicts the advisory statement that recalculation \"aborts on its own project read-access check\".\n\n### PoC\n\n\u003e [vikunja-filter-empty-scope-cross-tenant-positions-PoC.zip](https://github.com/user-attachments/files/32740623/vikunja-filter-empty-scope-cross-tenant-positions-PoC.zip)\n\nThe attached archive contains `deployment/deploy.sh` (local Vikunja v2.6.0 on loopback with SQLite) and `poc/poc.sh`, which performs the full sequence:\n\n1. Victim registers, creates a private project and a task.\n2. Attacker registers, sets `default_project_id` to the victim\u0027s project via `PUT /api/v2/user/settings/general`, deletes their own Inbox, and now has zero accessible projects.\n3. Control: `GET /api/v2/projects/{victim}` returns 403.\n4. Attacker creates a saved filter with `{\"filter\":\"\",\"filter_include_nulls\":true}`.\n5. Verification: direct SQLite inspection shows `task_positions` rows referencing the victim\u0027s task in all four of the attacker\u0027s filter views.\n6. Control: `GET /api/v2/projects/{filter_pseudo_project}/tasks` returns 0 items, so the written rows are not readable back through collection endpoints.\n\nResult: 10 checks passed on two consecutive runs, each from a wiped database.\n\n### Impact\n\nAn authenticated user, even one with no project access at all, causes the server to persist cross-tenant references: rows pointing at arbitrary other users\u0027 tasks are written into views the attacker controls. Task content is not exposed through the documented read paths (verified), so this is an integrity and availability issue rather than a direct disclosure:\n\n- Cross-tenant integrity violation. The `task_positions` state of the attacker\u0027s views now encodes other tenants\u0027 objects, against the access model the rest of the code enforces.\n- Write amplification and denial of service. One cheap request performs a full-table scan plus `4 x N` inserts, where N is the number of tasks in the instance. On an instance with 100,000 tasks that is 400,000 rows per request, and the request can be repeated without bound. CPU, IO and storage costs scale with instance size while attacker cost stays constant.",
  "id": "GHSA-fprf-r6rv-xg99",
  "modified": "2026-10-09T20:57:38Z",
  "published": "2026-10-09T20:57:38Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-fprf-r6rv-xg99"
    },
    {
      "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Vikunja: Saved filter creation with an empty filter string recalculates task positions across all tenants"
}

GHSA-FPRX-PPQR-8WGF

Vulnerability from github – Published: 2026-03-16 15:30 – Updated: 2026-03-16 15:30
VLAI
Details

Mattermost versions 11.3.x <= 11.3.0, 11.2.x <= 11.2.2, 10.11.x <= 10.11.10 fail to restrict plugin installation on CI test instances with default admin credentials which allows an unauthenticated attacker to achieve remote code execution and exfiltrate sensitive configuration data including AWS and SMTP credentials via uploading a malicious plugin after changing the import directory. Mattermost Advisory ID: MMSA-2025-00528

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-2462"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-16T14:19:30Z",
    "severity": "MODERATE"
  },
  "details": "Mattermost versions 11.3.x \u003c= 11.3.0, 11.2.x \u003c= 11.2.2, 10.11.x \u003c= 10.11.10 fail to restrict plugin installation on CI test instances with default admin credentials which allows an unauthenticated attacker to achieve remote code execution and exfiltrate sensitive configuration data including AWS and SMTP credentials via uploading a malicious plugin after changing the import directory. Mattermost Advisory ID: MMSA-2025-00528",
  "id": "GHSA-fprx-ppqr-8wgf",
  "modified": "2026-03-16T15:30:43Z",
  "published": "2026-03-16T15:30:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2462"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FPRX-W866-M96J

Vulnerability from github – Published: 2022-05-24 19:02 – Updated: 2025-03-31 12:30
VLAI
Details

ownCloud 10.7 has an incorrect access control vulnerability, leading to remote information disclosure. Due to a bug in the related API endpoint, the attacker can enumerate all users in a single request by entering three whitespaces. Secondary, the retrieval of all users on a large instance could cause higher than average load on the instance.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-29659"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-05-20T13:15:00Z",
    "severity": "MODERATE"
  },
  "details": "ownCloud 10.7 has an incorrect access control vulnerability, leading to remote information disclosure. Due to a bug in the related API endpoint, the attacker can enumerate all users in a single request by entering three whitespaces. Secondary, the retrieval of all users on a large instance could cause higher than average load on the instance.",
  "id": "GHSA-fprx-w866-m96j",
  "modified": "2025-03-31T12:30:44Z",
  "published": "2022-05-24T19:02:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29659"
    },
    {
      "type": "WEB",
      "url": "https://doc.owncloud.com/server/admin_manual/release_notes.html"
    },
    {
      "type": "WEB",
      "url": "https://owncloud.com/security-advisories/cve-2021-29659"
    }
  ],
  "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-FPW7-8GJC-JWQJ

Vulnerability from github – Published: 2025-01-22 18:31 – Updated: 2025-03-20 19:39
VLAI
Summary
Cache confusion in Jenkins Eiffel Broadcaster Plugin
Details

The Jenkins Eiffel Broadcaster Plugin allows events published to RabbitMQ to be signed using certificate credentials. To improve performance, the plugin caches some data from the credential.

Eiffel Broadcaster Plugin 2.8.0 through 2.10.2 (both inclusive) uses the credential ID as the cache key. This allows attackers able to create a credential with the same ID as a legitimate one in a different credentials store, to sign an event published to RabbitMQ with the legitimate certificate credentials.

Eiffel Broadcaster Plugin 2.10.3 removes the cache.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.axis.jenkins.plugins.eiffel:eiffel-broadcaster"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.8.0"
            },
            {
              "fixed": "2.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-24400"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-276",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-01-22T19:26:49Z",
    "nvd_published_at": "2025-01-22T17:15:13Z",
    "severity": "MODERATE"
  },
  "details": "The Jenkins Eiffel Broadcaster Plugin allows events published to RabbitMQ to be signed using certificate credentials. To improve performance, the plugin caches some data from the credential.\n\nEiffel Broadcaster Plugin 2.8.0 through 2.10.2 (both inclusive) uses the credential ID as the cache key. This allows attackers able to create a credential with the same ID as a legitimate one in a different credentials store, to sign an event published to RabbitMQ with the legitimate certificate credentials.\n\nEiffel Broadcaster Plugin 2.10.3 removes the cache.",
  "id": "GHSA-fpw7-8gjc-jwqj",
  "modified": "2025-03-20T19:39:06Z",
  "published": "2025-01-22T18:31:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24400"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/eiffel-broadcaster-plugin"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2025-01-22/#SECURITY-3485"
    }
  ],
  "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": "Cache confusion in Jenkins Eiffel Broadcaster Plugin "
}

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.

No CAPEC attack patterns related to this CWE.