Common Weakness Enumeration

CWE-639

Allowed

Authorization Bypass Through User-Controlled Key

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.

3384 vulnerabilities reference this CWE, most recent first.

GHSA-68W5-W573-Q2R8

Vulnerability from github – Published: 2026-05-11 17:58 – Updated: 2026-05-19 16:09
VLAI
Summary
MantisBT Has Authorization Bypass in Global Profile Creation
Details

MantisBT allows a low-privileged authenticated user having add_profile_threshold to create a global profile despite not having manage_global_profile_threshold, by tampering with the user_id parameter in a valid profile creation request.

Impact

Authentication bypass

Patches

  • 3f952e68fa864e0e60abc3e84adecf3cfa84c75e

Workarounds

None

Credits

Thanks to Vishal Shukla for discovering and responsibly reporting the issues.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "mantisbt/mantisbt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.28.0"
            },
            {
              "fixed": "2.28.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33052"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-11T17:58:50Z",
    "nvd_published_at": "2026-05-19T02:16:15Z",
    "severity": "MODERATE"
  },
  "details": "MantisBT allows a low-privileged authenticated user having *add_profile_threshold* to create a global profile despite not having *manage_global_profile_threshold*, by tampering with the user_id parameter in a valid profile creation request.\n\n### Impact\nAuthentication bypass\n\n### Patches\n- 3f952e68fa864e0e60abc3e84adecf3cfa84c75e\n\n### Workarounds\nNone\n\n### Credits\nThanks to Vishal Shukla for discovering and responsibly reporting the issues.",
  "id": "GHSA-68w5-w573-q2r8",
  "modified": "2026-05-19T16:09:47Z",
  "published": "2026-05-11T17:58:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/mantisbt/mantisbt/security/advisories/GHSA-68w5-w573-q2r8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33052"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mantisbt/mantisbt/commit/3f952e68fa864e0e60abc3e84adecf3cfa84c75e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mantisbt/mantisbt"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mantisbt/mantisbt/releases/tag/release-2.28.2"
    },
    {
      "type": "WEB",
      "url": "https://mantisbt.org/bugs/view.php?id=36974"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "MantisBT Has Authorization Bypass in Global Profile Creation"
}

GHSA-6963-573W-VXVF

Vulnerability from github – Published: 2026-03-26 06:30 – Updated: 2026-03-26 06:30
VLAI
Details

The Elementor Website Builder plugin for WordPress is vulnerable to Incorrect Authorization to Sensitive Information Exposure in all versions up to, and including, 3.35.7. This is due to a logic error in the is_allowed_to_read_template() function permission check that treats non-published templates as readable without verifying edit capabilities. This makes it possible for authenticated attackers, with contributor-level access and above, to read private or draft Elementor template content via the 'template_id' supplied to the 'get_template_data' action of the 'elementor_ajax' endpoint.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-1206"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-26T06:16:09Z",
    "severity": "MODERATE"
  },
  "details": "The Elementor Website Builder plugin for WordPress is vulnerable to Incorrect Authorization to Sensitive Information Exposure in all versions up to, and including, 3.35.7. This is due to a logic error in the is_allowed_to_read_template() function permission check that treats non-published templates as readable without verifying edit capabilities. This makes it possible for authenticated attackers, with contributor-level access and above, to read private or draft Elementor template content via the \u0027template_id\u0027 supplied to the \u0027get_template_data\u0027 action of the \u0027elementor_ajax\u0027 endpoint.",
  "id": "GHSA-6963-573w-vxvf",
  "modified": "2026-03-26T06:30:21Z",
  "published": "2026-03-26T06:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1206"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3489160/elementor/trunk/includes/template-library/sources/local.php?old=3473768\u0026old_path=elementor%2Ftrunk%2Fincludes%2Ftemplate-library%2Fsources%2Flocal.php"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/a4420935-4952-4460-afc2-1c6df6965b3d?source=cve"
    }
  ],
  "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-69GG-PVP7-2FX5

Vulnerability from github – Published: 2026-07-01 09:30 – Updated: 2026-07-01 09:30
VLAI
Details

The Qi Blocks plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 1.4.9 via the 'page_id' parameter due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with author-level access and above, to modify the stored Qi Blocks styles of arbitrary posts, templates, or widgets they do not own — including site-wide surfaces via the reserved 'template' and 'widget' page_id values — enabling unauthorized frontend defacement, content hiding, and degradation of any page on the site. The endpoint's permission_callback checks only the generic edit_posts and publish_posts capabilities, meaning any user with the built-in Author role satisfies the check regardless of post ownership.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-10096"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-01T08:16:19Z",
    "severity": "MODERATE"
  },
  "details": "The Qi Blocks plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 1.4.9 via the \u0027page_id\u0027 parameter due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with author-level access and above, to modify the stored Qi Blocks styles of arbitrary posts, templates, or widgets they do not own \u2014 including site-wide surfaces via the reserved \u0027template\u0027 and \u0027widget\u0027 page_id values \u2014 enabling unauthorized frontend defacement, content hiding, and degradation of any page on the site. The endpoint\u0027s permission_callback checks only the generic edit_posts and publish_posts capabilities, meaning any user with the built-in Author role satisfies the check regardless of post ownership.",
  "id": "GHSA-69gg-pvp7-2fx5",
  "modified": "2026-07-01T09:30:25Z",
  "published": "2026-07-01T09:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10096"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/qi-blocks/tags/1.4.9/inc/admin/global-styles/class-qi-blocks-framework-global-styles.php#L134"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/qi-blocks/tags/1.4.9/inc/admin/global-styles/class-qi-blocks-framework-global-styles.php#L142"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/qi-blocks/tags/1.4.9/inc/admin/global-styles/class-qi-blocks-framework-global-styles.php#L82"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3572812%40qi-blocks\u0026new=3572812%40qi-blocks\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/64251fd4-1627-49d0-831f-5cb9898c38bf?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-6C6R-5XR4-CR5M

Vulnerability from github – Published: 2026-07-21 20:22 – Updated: 2026-07-21 20:22
VLAI
Summary
Gitea: Cross-repository issue/comment attachment re-linking can expose private attachment content
Details

Summary

Gitea's issue and comment attachment update paths accept attachment UUIDs without verifying that each attachment belongs to the target issue/comment repository. If an authenticated attacker knows a victim attachment UUID, they can re-link that attachment to an attacker-controlled issue or comment, causing later attachment access checks to use the attacker's repository authorization context.

Affected

  • Component: web issue/comment attachment handling.
  • Confirmed version: main commit a39b2775edcb3ba53def96794491b91335117d81 (v1.27.0-dev-352-ga39b2775ed).
  • Fixed in: not fixed at the time of validation.
  • Other versions: not exhaustively tested. The affected code path appears structurally similar to versions that contain the current issue/comment attachment update logic.

Description / Root Cause

files[] values from issue/comment edit flows are passed to updateAttachments in routers/web/repo/issue.go:589-629. That helper calls:

  • models/issues/issue_update.go:267-278 (UpdateIssueAttachments)
  • models/issues/comment.go:623-642 (UpdateCommentAttachments)

Both functions load attachments by UUID and update the attachment linkage, but neither validates that the attachment row's RepoID matches the repository of the target issue/comment. They also do not reject attachments already linked to a different issue/comment.

Attachment reads then use the linked issue/release repository to decide access:

  • services/repository/repository.go:185-207 returns the repository ID from IssueID or ReleaseID.
  • routers/web/repo/attachment.go:153-184 checks read permission on that linked repository.
  • routers/web/repo/attachment.go:216-224 opens and serves the file from the attachment's storage path after the linked-repository permission check succeeds.

For the global /attachments/{uuid} route in routers/web/web.go:872-876, there is no current repository context, so the early attach.RepoID mismatch check in ServeAttachment does not protect against this re-linking case.

A patched sibling path already demonstrates the intended invariant: models/repo/release.go:179-215 rejects release attachments whose RepoID differs from the release repository. That guard was introduced for CVE-2026-20736, but the issue/comment paths still lack an equivalent check.

Impact

An attacker who can edit an issue/comment in a repository they can read can move a known victim attachment UUID into that repository's authorization context. After the re-link, the attachment download path resolves access against the attacker-controlled repository while serving the original attachment file.

This can disclose private issue/comment attachments if the attacker has obtained the UUID through prior legitimate access, copied links, notification content, logs, browser history, or another exposure. The attack does not require write access to the victim repository.

Reproduction Summary

Full HTTP/E2E observation:

  • A local Gitea server was started with an isolated SQLite database.
  • A victim user created private repositories, private issues, and issue attachments containing unique marker strings.
  • An attacker user first attempted to download each victim attachment through /attachments/{uuid} and received 404.
  • The attacker then submitted the victim UUID through the real issue edit route in an attacker-controlled public repository.
  • The same attacker could then download the victim issue attachment through /attachments/{uuid} and received 200; the response body contained the unique issue marker.
  • The attacker repeated the flow through the real comment edit route and could download the second victim attachment with 200; the response body contained the unique comment marker.

Model-level issue-path behavior:

  • A fixture attachment with RepoID = 2 and IssueID = 4 was passed to UpdateIssueAttachments for attacker issue ID = 1, whose RepoID = 1.
  • The call succeeded.
  • The attachment row still had RepoID = 2, but its IssueID was changed to the attacker issue.
  • GetAttachmentLinkedTypeAndRepoID then resolved the attachment to attacker repository RepoID = 1.

Model-level comment-path behavior:

  • The same cross-repository attachment UUID was passed to UpdateCommentAttachments for attacker comment ID = 1.
  • The call succeeded.
  • The attachment row still had RepoID = 2, but its IssueID and CommentID were changed to the attacker's issue/comment.
  • The linked repository used for access checks became attacker repository RepoID = 1.

Negative control:

  • Existing release test TestAddReleaseAttachmentsRejectsDifferentRepo passes and confirms the release path rejects the same class of cross-repository attachment linkage.

Detailed verifier and step-by-step runbook are available on request.

Suggested Fix

Add repository and linkage validation before updating issue/comment attachments.

Recommended checks:

  • Load the target issue for UpdateIssueAttachments and derive its RepoID.
  • Load the target comment's issue for UpdateCommentAttachments and derive its RepoID.
  • Reject any attachment whose RepoID differs from the target issue repository.
  • Reject attachments already linked to a different issue/comment/release, except for attachments already linked to the same object being updated.
  • If caller context is available at the web/service layer, also require new unlinked attachments to belong to the current actor or to have been uploaded in the current edit session.
  • Preserve any legacy RepoID = 0 migration behavior only when it can be proven safe for the target repository.

Also consider a cleanup/audit query for existing inconsistent rows where attachment.issue_id != 0 and attachment.repo_id differs from the linked issue repository.

Regression Tests

Add tests that fail before the fix and pass after it:

  • UpdateIssueAttachments rejects an attachment whose RepoID differs from the target issue's RepoID.
  • UpdateCommentAttachments rejects an attachment whose RepoID differs from the target comment issue's RepoID.
  • Same-repository unlinked attachment linking still works for normal issue/comment editing.
  • Attachments already linked to a different issue/comment cannot be moved by passing their UUID in files[].
  • Existing release guard test remains passing.
Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.27.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-57886"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T20:22:58Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nGitea\u0027s issue and comment attachment update paths accept attachment UUIDs without verifying that each attachment belongs to the target issue/comment repository. If an authenticated attacker knows a victim attachment UUID, they can re-link that attachment to an attacker-controlled issue or comment, causing later attachment access checks to use the attacker\u0027s repository authorization context.\n\n## Affected\n\n- Component: web issue/comment attachment handling.\n- Confirmed version: `main` commit `a39b2775edcb3ba53def96794491b91335117d81` (`v1.27.0-dev-352-ga39b2775ed`).\n- Fixed in: not fixed at the time of validation.\n- Other versions: not exhaustively tested. The affected code path appears structurally similar to versions that contain the current issue/comment attachment update logic.\n\n## Description / Root Cause\n\n`files[]` values from issue/comment edit flows are passed to `updateAttachments` in `routers/web/repo/issue.go:589-629`. That helper calls:\n\n- `models/issues/issue_update.go:267-278` (`UpdateIssueAttachments`)\n- `models/issues/comment.go:623-642` (`UpdateCommentAttachments`)\n\nBoth functions load attachments by UUID and update the attachment linkage, but neither validates that the attachment row\u0027s `RepoID` matches the repository of the target issue/comment. They also do not reject attachments already linked to a different issue/comment.\n\nAttachment reads then use the linked issue/release repository to decide access:\n\n- `services/repository/repository.go:185-207` returns the repository ID from `IssueID` or `ReleaseID`.\n- `routers/web/repo/attachment.go:153-184` checks read permission on that linked repository.\n- `routers/web/repo/attachment.go:216-224` opens and serves the file from the attachment\u0027s storage path after the linked-repository permission check succeeds.\n\nFor the global `/attachments/{uuid}` route in `routers/web/web.go:872-876`, there is no current repository context, so the early `attach.RepoID` mismatch check in `ServeAttachment` does not protect against this re-linking case.\n\nA patched sibling path already demonstrates the intended invariant: `models/repo/release.go:179-215` rejects release attachments whose `RepoID` differs from the release repository. That guard was introduced for CVE-2026-20736, but the issue/comment paths still lack an equivalent check.\n\n## Impact\n\nAn attacker who can edit an issue/comment in a repository they can read can move a known victim attachment UUID into that repository\u0027s authorization context. After the re-link, the attachment download path resolves access against the attacker-controlled repository while serving the original attachment file.\n\nThis can disclose private issue/comment attachments if the attacker has obtained the UUID through prior legitimate access, copied links, notification content, logs, browser history, or another exposure. The attack does not require write access to the victim repository.\n\n## Reproduction Summary\n\nFull HTTP/E2E observation:\n\n- A local Gitea server was started with an isolated SQLite database.\n- A victim user created private repositories, private issues, and issue attachments containing unique marker strings.\n- An attacker user first attempted to download each victim attachment through `/attachments/{uuid}` and received `404`.\n- The attacker then submitted the victim UUID through the real issue edit route in an attacker-controlled public repository.\n- The same attacker could then download the victim issue attachment through `/attachments/{uuid}` and received `200`; the response body contained the unique issue marker.\n- The attacker repeated the flow through the real comment edit route and could download the second victim attachment with `200`; the response body contained the unique comment marker.\n\nModel-level issue-path behavior:\n\n- A fixture attachment with `RepoID = 2` and `IssueID = 4` was passed to `UpdateIssueAttachments` for attacker issue `ID = 1`, whose `RepoID = 1`.\n- The call succeeded.\n- The attachment row still had `RepoID = 2`, but its `IssueID` was changed to the attacker issue.\n- `GetAttachmentLinkedTypeAndRepoID` then resolved the attachment to attacker repository `RepoID = 1`.\n\nModel-level comment-path behavior:\n\n- The same cross-repository attachment UUID was passed to `UpdateCommentAttachments` for attacker comment `ID = 1`.\n- The call succeeded.\n- The attachment row still had `RepoID = 2`, but its `IssueID` and `CommentID` were changed to the attacker\u0027s issue/comment.\n- The linked repository used for access checks became attacker repository `RepoID = 1`.\n\nNegative control:\n\n- Existing release test `TestAddReleaseAttachmentsRejectsDifferentRepo` passes and confirms the release path rejects the same class of cross-repository attachment linkage.\n\nDetailed verifier and step-by-step runbook are available on request.\n\n## Suggested Fix\n\nAdd repository and linkage validation before updating issue/comment attachments.\n\nRecommended checks:\n\n- Load the target issue for `UpdateIssueAttachments` and derive its `RepoID`.\n- Load the target comment\u0027s issue for `UpdateCommentAttachments` and derive its `RepoID`.\n- Reject any attachment whose `RepoID` differs from the target issue repository.\n- Reject attachments already linked to a different issue/comment/release, except for attachments already linked to the same object being updated.\n- If caller context is available at the web/service layer, also require new unlinked attachments to belong to the current actor or to have been uploaded in the current edit session.\n- Preserve any legacy `RepoID = 0` migration behavior only when it can be proven safe for the target repository.\n\nAlso consider a cleanup/audit query for existing inconsistent rows where `attachment.issue_id != 0` and `attachment.repo_id` differs from the linked issue repository.\n\n## Regression Tests\n\nAdd tests that fail before the fix and pass after it:\n\n- `UpdateIssueAttachments` rejects an attachment whose `RepoID` differs from the target issue\u0027s `RepoID`.\n- `UpdateCommentAttachments` rejects an attachment whose `RepoID` differs from the target comment issue\u0027s `RepoID`.\n- Same-repository unlinked attachment linking still works for normal issue/comment editing.\n- Attachments already linked to a different issue/comment cannot be moved by passing their UUID in `files[]`.\n- Existing release guard test remains passing.",
  "id": "GHSA-6c6r-5xr4-cr5m",
  "modified": "2026-07-21T20:22:58Z",
  "published": "2026-07-21T20:22:58Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-6c6r-5xr4-cr5m"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/pull/38406"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/pull/38426"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/commit/de4b8277e9cb576f2315fb03b5ab6478b42a1d31"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/commit/f69e15afe7496cc62e96dab244629c69eb31a7bf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/releases/tag/v1.27.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gitea: Cross-repository issue/comment attachment re-linking can expose private attachment content"
}

GHSA-6CCC-8WGJ-7RF9

Vulnerability from github – Published: 2023-07-10 18:30 – Updated: 2024-04-04 05:53
VLAI
Details

The EventON WordPress plugin before 2.1.2 does not validate that the event_id parameter in its eventon_ics_download ajax action is a valid Event, allowing unauthenticated visitors to access any Post (including unpublished or protected posts) content via the ics export functionality by providing the numeric id of the post.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-3219"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-10T16:15:55Z",
    "severity": "MODERATE"
  },
  "details": "The EventON WordPress plugin before 2.1.2 does not validate that the event_id parameter in its eventon_ics_download ajax action is a valid Event, allowing unauthenticated visitors to access any Post (including unpublished or protected posts) content via the ics export functionality by providing the numeric id of the post.",
  "id": "GHSA-6ccc-8wgj-7rf9",
  "modified": "2024-04-04T05:53:33Z",
  "published": "2023-07-10T18:30:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3219"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/72d80887-0270-4987-9739-95b1a178c1fd"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/173992/WordPress-EventON-Calendar-4.4-Insecure-Direct-Object-Reference.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6CJ8-H4PG-P2JV

Vulnerability from github – Published: 2023-08-10 15:30 – Updated: 2024-04-04 06:48
VLAI
Details

Cacti before 1.2.6 allows IDOR (Insecure Direct Object Reference) for accessing any graph via a modified local_graph_id parameter to graph_xport.php. This is a different vulnerability than CVE-2019-16723.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-37543"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-10T15:15:09Z",
    "severity": "HIGH"
  },
  "details": "Cacti before 1.2.6 allows IDOR (Insecure Direct Object Reference) for accessing any graph via a modified local_graph_id parameter to graph_xport.php. This is a different vulnerability than CVE-2019-16723.",
  "id": "GHSA-6cj8-h4pg-p2jv",
  "modified": "2024-04-04T06:48:28Z",
  "published": "2023-08-10T15:30:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Cacti/cacti/security/advisories/GHSA-4x82-8w8m-w8hj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37543"
    },
    {
      "type": "WEB",
      "url": "https://medium.com/%40hussainfathy99/exciting-news-my-first-cve-discovery-cve-2023-37543-idor-vulnerability-in-cacti-bbb6c386afed"
    },
    {
      "type": "WEB",
      "url": "https://medium.com/@hussainfathy99/exciting-news-my-first-cve-discovery-cve-2023-37543-idor-vulnerability-in-cacti-bbb6c386afed"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6CQF-CFHV-659G

Vulnerability from github – Published: 2025-11-13 22:34 – Updated: 2026-02-03 17:23
VLAI
Summary
File Browser is Vulnerable to Insecure Direct Object Reference (IDOR) in Share Deletion Function
Details

Summary

It has been found an Insecure Direct Object Reference (IDOR) vulnerability in the FileBrowser application's share deletion functionality. This vulnerability allows any authenticated user with share permissions to delete other users' shared links without authorization checks.

The impact is significant as malicious actors can disrupt business operations by systematically removing shared files and links. This leads to denial of service for legitimate users, potential data loss in collaborative environments, and breach of data confidentiality agreements. In organizational settings, this could affect critical file sharing for projects, presentations, or document collaboration.

Details

Technical Analysis

The vulnerability exists in/http/share.go at lines 72-82. The shareDeleteHandler function processes deletion requests using only the share hash without comparing the link.UserID with the current authenticated user's ID (d.user.ID). This missing authorization check enables the vulnerability.

var shareDeleteHandler = withPermShare(func(_ http.ResponseWriter, r *http.Request, d *data) (int, error) {
    hash := strings.TrimSuffix(r.URL.Path, "/")
    hash = strings.TrimPrefix(hash, "/")

    if hash == "" {
        return http.StatusBadRequest, nil
    }

    err := d.store.Share.Delete(hash)  // Missing ownership validation
    return errToStatus(err), err
})

PoC

Reproduce Steps:

Prerequisites: Two authenticated user accounts (User A and User B) with share permissions

Step 1: User A creates a share link and obtains the share hash (e.g., MEEuZK-v)

Step 2: User B authenticates and obtains a valid JWT token

Step 3: User B sends DELETE request to /api/share/MEEuZK-v with their own JWT token

Step 4: Observe that User A's share is deleted without authorization

DELETE /api/share/MEEuZK-v HTTP/1.1 Host: filebrowser.local Content-Type: application/json

Impact

The impact is significant as malicious actors can disrupt business operations by systematically removing shared files and links. This leads to denial of service for legitimate users, potential data loss in collaborative environments, and breach of data confidentiality agreements. In organizational settings, this could affect critical file sharing for projects, presentations, or document collaboration.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/filebrowser/filebrowser/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.45.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-64523"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-11-13T22:34:51Z",
    "nvd_published_at": "2025-11-12T23:15:39Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nIt has been found an Insecure Direct Object Reference (IDOR) vulnerability in the FileBrowser application\u0027s share deletion functionality. This vulnerability allows any authenticated user with share permissions to delete other users\u0027 shared links without authorization checks.\n\nThe impact is significant as malicious actors can disrupt business operations by systematically removing shared files and links. This leads to denial of service for legitimate users, potential data loss in collaborative environments, and breach of data confidentiality agreements. In organizational settings, this could affect critical file sharing for projects, presentations, or document collaboration.\n\n### Details\n**Technical Analysis**\n\nThe vulnerability exists in` /http/share.go` at lines 72-82. The shareDeleteHandler function processes deletion requests using only the share hash without comparing the link.UserID with the current authenticated user\u0027s ID (d.user.ID). This missing authorization check enables the vulnerability.\n\n```\nvar shareDeleteHandler = withPermShare(func(_ http.ResponseWriter, r *http.Request, d *data) (int, error) {\n    hash := strings.TrimSuffix(r.URL.Path, \"/\")\n    hash = strings.TrimPrefix(hash, \"/\")\n\n    if hash == \"\" {\n        return http.StatusBadRequest, nil\n    }\n\n    err := d.store.Share.Delete(hash)  // Missing ownership validation\n    return errToStatus(err), err\n})\n```\n\n### PoC\n**Reproduce Steps:**\n\nPrerequisites: Two authenticated user accounts (User A and User B) with share permissions\n\nStep 1: User A creates a share link and obtains the share hash (e.g., MEEuZK-v)\n\nStep 2: User B authenticates and obtains a valid JWT token\n\nStep 3: User B sends DELETE request to /api/share/MEEuZK-v with their own JWT token\n\nStep 4: Observe that User A\u0027s share is deleted without authorization\n\nDELETE /api/share/MEEuZK-v HTTP/1.1\nHost: filebrowser.local\nContent-Type: application/json\n\n### Impact\n\nThe impact is significant as malicious actors can disrupt business operations by systematically removing shared files and links. This leads to denial of service for legitimate users, potential data loss in collaborative environments, and breach of data confidentiality agreements. In organizational settings, this could affect critical file sharing for projects, presentations, or document collaboration.",
  "id": "GHSA-6cqf-cfhv-659g",
  "modified": "2026-02-03T17:23:10Z",
  "published": "2025-11-13T22:34:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/filebrowser/filebrowser/security/advisories/GHSA-6cqf-cfhv-659g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64523"
    },
    {
      "type": "WEB",
      "url": "https://github.com/filebrowser/filebrowser/commit/291223b3cefe1e50fae8f73d70464b1dc25351a4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/filebrowser/filebrowser"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "File Browser is Vulnerable to Insecure Direct Object Reference (IDOR) in Share Deletion Function"
}

GHSA-6FPJ-MJQ4-FP9R

Vulnerability from github – Published: 2026-07-20 12:33 – Updated: 2026-07-20 12:33
VLAI
Details

SurrealDB versions before 3.1.0 contain an authorization bypass vulnerability where authenticated users can spoof composite record-id field values by writing to editable body fields. Attackers can bypass permission rules that gate access on id components like tenant isolation by setting same-named body fields to spoofed values that permission checks incorrectly read instead of the immutable id key.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-63745"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-20T12:19:44Z",
    "severity": "MODERATE"
  },
  "details": "SurrealDB versions before 3.1.0 contain an authorization bypass vulnerability where authenticated users can spoof composite record-id field values by writing to editable body fields. Attackers can bypass permission rules that gate access on id components like tenant isolation by setting same-named body fields to spoofed values that permission checks incorrectly read instead of the immutable id key.",
  "id": "GHSA-6fpj-mjq4-fp9r",
  "modified": "2026-07-20T12:33:09Z",
  "published": "2026-07-20T12:33:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/surrealdb/surrealdb/security/advisories/GHSA-6vg3-hgrw-p5gf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63745"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/surrealdb-before-authorization-bypass-via-composite-record-id"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-6FPQ-HHV8-HC9F

Vulnerability from github – Published: 2026-05-11 18:31 – Updated: 2026-05-11 21:31
VLAI
Details

HireFlow v1.2 is vulnerable to Incorrect Access Control. The application does not enforce object-level authorization on the /candidate/ and /interview/ endpoints. The route handlers retrieve records by the user-supplied ID without verifying that the requesting user is the owner or has an authorized role. Any authenticated user can access any other user's candidate profiles and interview notes by iterating the integer ID in the URL path, constituting a horizontal privilege escalation and full data breach of all records in the system.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-38568"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-11T18:16:32Z",
    "severity": "HIGH"
  },
  "details": "HireFlow v1.2 is vulnerable to Incorrect Access Control. The application does not enforce object-level authorization on the /candidate/\u003cid\u003e and /interview/\u003cid\u003e endpoints. The route handlers retrieve records by the user-supplied ID without verifying that the requesting user is the owner or has an authorized role. Any authenticated user can access any other user\u0027s candidate profiles and interview notes by iterating the integer ID in the URL path, constituting a horizontal privilege escalation and full data breach of all records in the system.",
  "id": "GHSA-6fpq-hhv8-hc9f",
  "modified": "2026-05-11T21:31:32Z",
  "published": "2026-05-11T18:31:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-38568"
    },
    {
      "type": "WEB",
      "url": "https://github.com/StratonWebDesigners/HireFlow"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hijackedamygdala/CVE-Disclosures/tree/main/HireFlow/CVE-2026-38568"
    },
    {
      "type": "WEB",
      "url": "https://www.sourcecodester.com/python/18688/hireflow-%E2%80%93-complete-interview-management-system.html"
    }
  ],
  "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"
    }
  ]
}

GHSA-6FW7-3Q8R-M5VJ

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

Summary

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

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

Due to missing server-side validation and authorization checks, an attacker can manipulate the workspaceId field and reassign variables to arbitrary workspaces.

This behavior may break tenant isolation in multi-workspace environments.

Details

The endpoint responsible for updating variables:

PUT /api/v1/variables/{variableId}

accepts a JSON request body containing the variable definition.

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

Server-controlled fields that can be manipulated include:

  • workspaceId
  • createdDate
  • updatedDate

These fields appear to be directly mapped to the database entity without strict input validation or authorization checks.

For example, the following request body was accepted by the server:

{
  "name": "aaa",
  "value": "bbbe",
  "type": "static",
  "createdDate": "2016-03-06T17:59:30.000Z",
  "updatedDate": "2016-03-06T18:00:17.000Z",
  "workspaceId": "11111111-2222-3333-4444-555555555555"
}

The server accepted the attacker-controlled workspaceId and metadata fields and persisted them.

PoC

Request

PUT /api/v1/variables/<VARIABLE_ID>
Content-Type: application/json

{
  "name": "aaa",
  "value": "bbbe",
  "type": "static",
  "createdDate": "2016-03-06T17:59:30.000Z",
  "updatedDate": "2016-03-06T18:00:17.000Z",
  "workspaceId": "11111111-2222-3333-4444-555555555555"
}

Response

{
  "id": "0a2b9f61-4a97-4ff8-b80d-00275ed18674",
  "name": "aaa",
  "value": "bbbe",
  "type": "static",
  "createdDate": "2016-03-06T17:59:30.000Z",
  "updatedDate": "2026-03-06T18:05:17.000Z",
  "workspaceId": "11111111-2222-3333-4444-555555555555"
}

This confirms that the backend accepts and persists attacker-controlled internal properties.

Impact

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

Possible impacts include:

  1. Cross-workspace reassignment of variables (workspaceId)
  2. Unauthorized modification of metadata (createdDate, updatedDate)
  3. Potential tenant isolation bypass in multi-workspace deployments

In multi-tenant environments, this may allow an attacker to move variables between workspaces without authorization.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.1.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "flowise"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42861"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-639",
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-14T14:52:24Z",
    "nvd_published_at": "2026-06-08T16:16:39Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nA Mass Assignment vulnerability exists in the variable update endpoint of FlowiseAI.\n\nThe endpoint allows authenticated users to modify server-controlled properties such as workspaceId, createdDate, and updatedDate when updating a variable resource.\n\nDue to missing server-side validation and authorization checks, an attacker can manipulate the workspaceId field and reassign variables to arbitrary workspaces.\n\nThis behavior may break tenant isolation in multi-workspace environments.\n\n### Details\nThe endpoint responsible for updating variables:\n\n**PUT /api/v1/variables/{variableId}**\n\naccepts a JSON request body containing the variable definition.\n\nHowever, the backend does not restrict which attributes can be modified by the client. As a result, user-controlled request bodies can include internal properties that should normally be controlled exclusively by the server.\n\nServer-controlled fields that can be manipulated include:\n\n- workspaceId\n- createdDate\n- updatedDate\n\nThese fields appear to be directly mapped to the database entity without strict input validation or authorization checks.\n\nFor example, the following request body was accepted by the server:\n\n```json\n{\n  \"name\": \"aaa\",\n  \"value\": \"bbbe\",\n  \"type\": \"static\",\n  \"createdDate\": \"2016-03-06T17:59:30.000Z\",\n  \"updatedDate\": \"2016-03-06T18:00:17.000Z\",\n  \"workspaceId\": \"11111111-2222-3333-4444-555555555555\"\n}\n```\n\nThe server accepted the attacker-controlled workspaceId and metadata fields and persisted them.\n\n### PoC\n**Request**\n\n```http\nPUT /api/v1/variables/\u003cVARIABLE_ID\u003e\nContent-Type: application/json\n\n{\n  \"name\": \"aaa\",\n  \"value\": \"bbbe\",\n  \"type\": \"static\",\n  \"createdDate\": \"2016-03-06T17:59:30.000Z\",\n  \"updatedDate\": \"2016-03-06T18:00:17.000Z\",\n  \"workspaceId\": \"11111111-2222-3333-4444-555555555555\"\n}\n```\n\n**Response**\n\n```json\n{\n  \"id\": \"0a2b9f61-4a97-4ff8-b80d-00275ed18674\",\n  \"name\": \"aaa\",\n  \"value\": \"bbbe\",\n  \"type\": \"static\",\n  \"createdDate\": \"2016-03-06T17:59:30.000Z\",\n  \"updatedDate\": \"2026-03-06T18:05:17.000Z\",\n  \"workspaceId\": \"11111111-2222-3333-4444-555555555555\"\n}\n```\n\nThis confirms that the backend accepts and persists attacker-controlled internal properties.\n\n### Impact\nThis vulnerability allows authenticated users to manipulate internal attributes of variable resources.\n\nPossible impacts include:\n\n1. Cross-workspace reassignment of variables (workspaceId)\n2. Unauthorized modification of metadata (createdDate, updatedDate)\n3. Potential tenant isolation bypass in multi-workspace deployments\n\nIn multi-tenant environments, this may allow an attacker to move variables between workspaces without authorization.",
  "id": "GHSA-6fw7-3q8r-m5vj",
  "modified": "2026-06-09T13:09:53Z",
  "published": "2026-05-14T14:52:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-6fw7-3q8r-m5vj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42861"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/FlowiseAI/Flowise"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/releases/tag/flowise%403.1.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "FlowiseAI has Mass Assignment in Variable Update Endpoint that Allows Cross-Workspace Resource Reassignment"
}
Mitigation
Architecture and Design

For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.

Mitigation
Architecture and Design Implementation

Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.

Mitigation
Architecture and Design

Use encryption in order to make it more difficult to guess other legitimate values of the key or associate a digital signature with the key so that the server can verify that there has been no tampering.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list