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.

3234 vulnerabilities reference this CWE, most recent first.

GHSA-6VG3-HGRW-P5GF

Vulnerability from github – Published: 2026-07-01 20:12 – Updated: 2026-07-01 20:12
VLAI
Summary
SurrealDB has an Authorization Bypass via Composite Record-id Paths
Details

An authenticated user could bypass permission rules that gated access on parts of a record's id — most commonly tenant-isolation rules of the form PERMISSIONS FOR select WHERE id.tenant = $auth.id.tenant. The same defect also let UNIQUE constraints defined on parts of an id admit duplicate entries.

When a query referenced part of a composite record id (id.tenant, id.uid, …), SurrealDB read the value from the record's editable body fields instead of from the immutable id key. Because the body is editable but the id is fixed at creation, an attacker with write access could set the body field to any value and have permission checks read that spoofed value.

Impact

What an attacker can do:

  • Read records hidden by permission rules of the form id.<field> = $auth.<...> (typically tenant- or scope-isolation boundaries) by writing the same-named field on a record they control to the spoofed value.
  • Cause UNIQUE constraints defined on id.<field> to silently admit duplicate entries, leaving the database with rows that violate the constraint.

What it can't do:

  • Cross namespace or database isolation boundaries. -Bypass field-level PERMISSIONS FOR update clauses that don't reference id.<field> paths.
  • Affect availability or crash the server.

Patches

The value-path resolver now special-cases Part::Field and Part::Value against RecordIdKey::Object, reading the named component directly from the id key without ever entering select_document. The Array-keyed special case (id[0], id[1], …) is unchanged.

  • Versions 3.1.0 and later are not affected.

Workarounds

Users unable to patch are advised to consider the following workarounds: - Avoid permission expressions that read id.<field> on Object-keyed record ids; gate on the full record id (id = $auth.id) or on a server-derived session value instead. - Avoid UNIQUE indexes on id.<field> until 3.1.0; use DEFINE INDEX ... ON FIELDS id UNIQUE (the full id) where possible.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "surrealdb"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-01T20:12:25Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "An authenticated user could bypass permission rules that gated access on parts of a record\u0027s id \u2014 most commonly tenant-isolation rules of the form `PERMISSIONS FOR select WHERE id.tenant = $auth.id.tenant`. The same defect also let UNIQUE constraints defined on parts of an id admit duplicate entries.\n\nWhen a query referenced part of a composite record id (`id.tenant`, `id.uid`, \u2026), SurrealDB read the value from the record\u0027s editable body fields instead of from the immutable id key. Because the body is editable but the id is fixed at creation, an attacker with write access could set the body field to any value and have permission checks read that spoofed value.\n\n### Impact\n\nWhat an attacker **can** do:\n\n- Read records hidden by permission rules of the form `id.\u003cfield\u003e = $auth.\u003c...\u003e` (typically tenant- or scope-isolation boundaries) by writing the same-named field on a record they control to the spoofed value.\n- Cause UNIQUE constraints defined on `id.\u003cfield\u003e` to silently admit duplicate entries, leaving the database with rows that violate the constraint.\n\nWhat it **can\u0027t** do:\n\n- Cross namespace or database isolation boundaries.\n-Bypass field-level `PERMISSIONS FOR` update clauses that don\u0027t reference `id.\u003cfield\u003e` paths.\n- Affect availability or crash the server.\n\n### Patches\n\nThe value-path resolver now special-cases `Part::Field` and `Part::Value` against `RecordIdKey::Object`, reading the named component directly from the id key without ever entering `select_document`. The Array-keyed special case (`id[0]`, `id[1]`, \u2026) is unchanged.\n\n- Versions 3.1.0 and later are not affected.\n\n### Workarounds\n\nUsers unable to patch are advised to consider the following workarounds:\n- Avoid permission expressions that read `id.\u003cfield\u003e` on Object-keyed record ids; gate on the full record id (`id = $auth.id`) or on a server-derived session value instead.\n- Avoid UNIQUE indexes on `id.\u003cfield\u003e` until 3.1.0; use `DEFINE INDEX ... ON FIELDS id UNIQUE` (the full id) where possible.",
  "id": "GHSA-6vg3-hgrw-p5gf",
  "modified": "2026-07-01T20:12:25Z",
  "published": "2026-07-01T20:12:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/surrealdb/surrealdb/security/advisories/GHSA-6vg3-hgrw-p5gf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/surrealdb/surrealdb/commit/1fcb19040bfffba92b3f69edb9b707d469e0027b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/surrealdb/surrealdb"
    }
  ],
  "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"
    }
  ],
  "summary": "SurrealDB has an Authorization Bypass via Composite Record-id Paths"
}

GHSA-6VPQ-PCM8-6PGW

Vulnerability from github – Published: 2022-05-24 17:39 – Updated: 2022-06-06 00:00
VLAI
Details

Adobe Bridge version 11.0 (and earlier) is affected by an out-of-bounds write vulnerability when parsing TTF files that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-21012"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-787",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-13T23:15:00Z",
    "severity": "HIGH"
  },
  "details": "Adobe Bridge version 11.0 (and earlier) is affected by an out-of-bounds write vulnerability when parsing TTF files that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.",
  "id": "GHSA-6vpq-pcm8-6pgw",
  "modified": "2022-06-06T00:00:35Z",
  "published": "2022-05-24T17:39:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21012"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/bridge/apsb21-07.html"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/magento/apsb21-08.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-6VQH-42FF-MF97

Vulnerability from github – Published: 2026-03-25 18:31 – Updated: 2026-04-01 18:36
VLAI
Details

Authorization bypass through User-Controlled key vulnerability in HYPR Server allows Privilege Escalation.This issue affects Server: from 9.5.2 before 10.7.2.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-2414"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-25T17:16:57Z",
    "severity": "MODERATE"
  },
  "details": "Authorization bypass through User-Controlled key vulnerability in HYPR Server allows Privilege Escalation.This issue affects Server: from 9.5.2 before 10.7.2.",
  "id": "GHSA-6vqh-42ff-mf97",
  "modified": "2026-04-01T18:36:32Z",
  "published": "2026-03-25T18:31:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2414"
    },
    {
      "type": "WEB",
      "url": "https://www.hypr.com/trust-center/security-advisories"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:P/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:U/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-6W2R-58CQ-54Q2

Vulnerability from github – Published: 2023-10-19 12:30 – Updated: 2024-04-04 08:47
VLAI
Details

A flaw in the TETRA authentication procecure allows a MITM adversary that can predict the MS challenge RAND2 to set session key DCK to zero.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-24400"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-807"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-19T10:15:08Z",
    "severity": "MODERATE"
  },
  "details": "A flaw in the TETRA authentication procecure allows a MITM adversary that can predict the MS challenge RAND2 to set session key DCK to zero.",
  "id": "GHSA-6w2r-58cq-54q2",
  "modified": "2024-04-04T08:47:11Z",
  "published": "2023-10-19T12:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24400"
    },
    {
      "type": "WEB",
      "url": "https://tetraburst.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6WHJ-7QMG-86QJ

Vulnerability from github – Published: 2026-02-02 17:31 – Updated: 2026-02-03 16:09
VLAI
Summary
Khoj has an IDOR in Notion OAuth Flow that Enables Index Poisoning
Details

Summary

An IDOR in the Notion OAuth callback allows an attacker to hijack any user's Notion integration by manipulating the state parameter. The callback endpoint accepts any user UUID without verifying the OAuth flow was initiated by that user, allowing attackers to replace victims' Notion configurations with their own, resulting in data poisoning and unauthorized access to the victim's Khoj search index.

This attack requires knowing the user's UUID which can be leaked through shared conversations where an AI generated image is present.

Details

When users share conversations which contain AI generated images, the file path for the image is constructed using the user's UUID. Knowing this UUID, an attacker is able to intercept the OAuth callback for Notion and replace the state parameter with the other user's UUID and sync notion onto their account.

PoC

The vulnerable line of code exists in src/khoj/routers/notion.py on the callback endpoint.

@notion_router.get("/auth/callback")
async def notion_auth_callback(request: Request, background_tasks: BackgroundTasks):
    code = request.query_params.get("code")
    state = request.query_params.get("state")  # <-- Attacker controlled
    if not code or not state:
        return Response("Missing code or state", status_code=400)

    user: KhojUser = await aget_user_by_uuid(state)  # <-- No verification!

    await NotionConfig.objects.filter(user=user).adelete()  # <-- Deletes victim's config

    # ... OAuth token exchange ...

    access_token = final_response.get("access_token")
    await NotionConfig.objects.acreate(token=access_token, user=user)  # <-- Stores attacker's token

To exploit is relatively easy. Once we know the victim's UUID, we simply initiate the Notion sync process on our own account and intercept the callback, replacing the state parameter with the victim's UUID.

Impact

Deletes user's existing Notion sync and replaces it with attacker-controlled Notion. Could allow for index poisoning. I'm not entirely sure what Khoj does with synced files but if it's being passed as context to an LLM then I can imagine there's potential here.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "khoj"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.0.0b25.dev3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-69207"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-02T17:31:33Z",
    "nvd_published_at": "2026-02-02T23:16:01Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nAn IDOR in the Notion OAuth callback allows an attacker to hijack any user\u0027s Notion integration by manipulating the state parameter. The callback endpoint accepts any user UUID without verifying the OAuth flow was initiated by that user, allowing attackers to replace victims\u0027 Notion configurations with their own, resulting in data poisoning and unauthorized access to the victim\u0027s Khoj search index.\n\nThis attack requires knowing the user\u0027s UUID which can be leaked through shared conversations where an AI generated image is present.\n\n### Details\nWhen users share conversations which contain AI generated images, the file path for the image is constructed using the user\u0027s UUID. Knowing this UUID, an attacker is able to intercept the OAuth callback for Notion and replace the `state` parameter with the other user\u0027s UUID and sync notion onto their account.\n\n### PoC\n\nThe vulnerable line of code exists in `src/khoj/routers/notion.py` on the callback endpoint.\n```python\n@notion_router.get(\"/auth/callback\")\nasync def notion_auth_callback(request: Request, background_tasks: BackgroundTasks):\n    code = request.query_params.get(\"code\")\n    state = request.query_params.get(\"state\")  # \u003c-- Attacker controlled\n    if not code or not state:\n        return Response(\"Missing code or state\", status_code=400)\n\n    user: KhojUser = await aget_user_by_uuid(state)  # \u003c-- No verification!\n\n    await NotionConfig.objects.filter(user=user).adelete()  # \u003c-- Deletes victim\u0027s config\n    \n    # ... OAuth token exchange ...\n    \n    access_token = final_response.get(\"access_token\")\n    await NotionConfig.objects.acreate(token=access_token, user=user)  # \u003c-- Stores attacker\u0027s token\n```\n\nTo exploit is relatively easy. Once we know the victim\u0027s UUID, we simply initiate the Notion sync process on our own account and intercept the callback, replacing the `state` parameter with the victim\u0027s UUID.\n\n### Impact\nDeletes user\u0027s existing Notion sync and replaces it with attacker-controlled Notion. Could allow for index poisoning. I\u0027m not entirely sure what Khoj does with synced files but if it\u0027s being passed as context to an LLM then I can imagine there\u0027s potential here.",
  "id": "GHSA-6whj-7qmg-86qj",
  "modified": "2026-02-03T16:09:54Z",
  "published": "2026-02-02T17:31:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/khoj-ai/khoj/security/advisories/GHSA-6whj-7qmg-86qj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-69207"
    },
    {
      "type": "WEB",
      "url": "https://github.com/khoj-ai/khoj/commit/1b7ccd141d47f365edeccc57d7316cb0913d748b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/khoj-ai/khoj"
    },
    {
      "type": "WEB",
      "url": "https://github.com/khoj-ai/khoj/releases/tag/2.0.0-beta.23"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Khoj has an IDOR in Notion OAuth Flow that Enables Index Poisoning"
}

GHSA-6WVP-RH8P-4Q7Q

Vulnerability from github – Published: 2024-09-25 09:30 – Updated: 2024-09-25 09:30
VLAI
Details

The WCFM – Frontend Manager for WooCommerce along with Bookings Subscription Listings Compatible plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 6.7.12 via the WCFM_Customers_Manage_Controller::processing function due to missing validation on the ID user controlled key. This makes it possible for authenticated attackers, with subscriber/customer-level access and above, to change the email address of administrator user accounts which allows them to reset the password and access the administrator account.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-8290"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-25T07:15:03Z",
    "severity": "HIGH"
  },
  "details": "The WCFM \u2013 Frontend Manager for WooCommerce along with Bookings Subscription Listings Compatible plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 6.7.12 via the WCFM_Customers_Manage_Controller::processing function due to missing validation on the ID user controlled key. This makes it possible for authenticated attackers, with subscriber/customer-level access and above, to change the email address of administrator user accounts which allows them to reset the password and access the administrator account.",
  "id": "GHSA-6wvp-rh8p-4q7q",
  "modified": "2024-09-25T09:30:46Z",
  "published": "2024-09-25T09:30:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8290"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wc-frontend-manager/tags/6.7.12/controllers/customers/wcfm-controller-customers-manage.php#L97"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3156433/wc-frontend-manager/trunk/controllers/customers/wcfm-controller-customers-manage.php"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/79172fe3-c0cf-48c4-8bc5-862c628c1a09?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6X8V-2FQ5-2229

Vulnerability from github – Published: 2026-06-18 13:07 – Updated: 2026-06-18 13:07
VLAI
Summary
ZITADEL: Cross-Tenant User Leakage via Recycled Identifiers
Details

Summary

A flaw in the user lifecycle enforcement allowed deleted users to retain their original organization/tenant association. Recreating a deleted user under a distinct organization can cause the new user instance to be incorrectly provisioned within the original organization if the previous ID would be used to recreate it.

Impact

When a user is created, the system maps the generated or provided ID to its target organization (Org A). When that user is subsequently deleted, a deletion event is appended to the stream, but the historical mapping of the resource owner within the event store's validation layer is not cleared.

If a new user is later provisioned in a different organization (Org B) using that exact same ID, the event store validation logic reads the stream's history, matches it to the original organization, and routes the new user's events to Org A instead of Org B.

This issue represents a localized multi-tenancy isolation anomaly rather than an easily exploitable attack vector. Because the new user instance is incorrectly routed and provisioned inside Org A instead of Org B, an administrator from Org A inadvertently gains full access to this new user record.

However, there is no technical mechanism for a malicious actor to force, automate, or target this behavior against a specific user or tenant. Because the scenario relies entirely on an accidental sequence of operational events and requires the recycling of a highly specific ID space, the practical security risk is exceptionally low.

Affected Versions

Systems running one of the following versions are affected:

  • 4.x: 4.0.0 through 4.15.1 (including RC versions)
  • 3.x: 3.0.0 through 3.4.11 (including RC versions)

Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by requiring the correct permission in case the verification flag is provided and only allows self-management of the email address, resp. phone number itself.

Workarounds

The recommended solution is to upgrade to a patched version.

Questions

If you have any questions or comments about this advisory, please email us at security@zitadel.com

Credits

Thanks to Charlie Graven from Famedly for reporting this vulnerability.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/zitadel/zitadel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.80.0-v2.20.0.20260615092437-6082e59d47c1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55670"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T13:07:34Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Summary\n\nA flaw in the user lifecycle enforcement allowed deleted users to retain their original organization/tenant association. Recreating a deleted user under a distinct organization can cause the new user instance to be incorrectly provisioned within the original organization if the previous ID would be used to recreate it.\n\n### Impact\n\nWhen a user is created, the system maps the generated or provided ID to its target organization (`Org A`). When that user is subsequently deleted, a deletion event is appended to the stream, but the historical mapping of the resource owner within the event store\u0027s validation layer is not cleared.\n\nIf a new user is later provisioned in a different organization (`Org B`) using that exact same ID, the event store validation logic reads the stream\u0027s history, matches it to the original organization, and routes the new user\u0027s events to `Org A` instead of `Org B`.\n\nThis issue represents a localized multi-tenancy isolation anomaly rather than an easily exploitable attack vector. Because the new user instance is incorrectly routed and provisioned inside `Org A` instead of `Org B`, an administrator from `Org A` inadvertently gains full access to this new user record.\n\nHowever, there is no technical mechanism for a malicious actor to force, automate, or target this behavior against a specific user or tenant. Because the scenario relies entirely on an accidental sequence of operational events and requires the recycling of a highly specific ID space, the practical security risk is exceptionally low.\n\n### Affected Versions\n\nSystems running one of the following versions are affected:\n\n* **4.x:** `4.0.0` through `4.15.1` (including RC versions)\n* **3.x:** `3.0.0` through `3.4.11` (including RC versions)\n\n### Patches\n\nThe vulnerability has been addressed in the latest releases. The patch resolves the issue by requiring the correct permission in case the verification flag is provided and only allows self-management of the email address, resp. phone number itself.\n\n- **4.x**: Upgrade to $\\ge$[4.15.2](https://github.com/zitadel/zitadel/releases/tag/v4.15.2)\n- **3.x**: Update to $\\ge$[4.15.2](https://github.com/zitadel/zitadel/releases/tag/v4.15.2)\n\n### Workarounds\n\nThe recommended solution is to upgrade to a patched version. \n\n### Questions\n\nIf you have any questions or comments about this advisory, please email us at [security@zitadel.com](mailto:security@zitadel.com)\n\n### Credits\n\nThanks to Charlie Graven from Famedly for reporting this vulnerability.",
  "id": "GHSA-6x8v-2fq5-2229",
  "modified": "2026-06-18T13:07:35Z",
  "published": "2026-06-18T13:07:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/security/advisories/GHSA-6x8v-2fq5-2229"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/commit/6082e59d47c17a9d54a6b0556b3f31559d7c620a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/zitadel/zitadel"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/releases/tag/v4.15.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": " ZITADEL: Cross-Tenant User Leakage via Recycled Identifiers"
}

GHSA-6XHQ-C535-QW5P

Vulnerability from github – Published: 2024-07-09 12:30 – Updated: 2024-07-09 12:30
VLAI
Details

A BOLA vulnerability in GET, PUT, DELETE /settings/{settingName} allows a low privileged user to fetch, modify or delete the settings of any user (including admin). This results in unauthorized access and unauthorized data manipulation.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-38053"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-09T11:15:11Z",
    "severity": "CRITICAL"
  },
  "details": "A BOLA vulnerability in GET, PUT, DELETE /settings/{settingName} allows a low privileged user to fetch, modify or delete the settings of any user (including admin). This results in unauthorized access and unauthorized data manipulation.",
  "id": "GHSA-6xhq-c535-qw5p",
  "modified": "2024-07-09T12:30:56Z",
  "published": "2024-07-09T12:30:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38053"
    },
    {
      "type": "WEB",
      "url": "https://github.com/alextselegidis/easyappointments"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6XR2-WW2P-M9PG

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

SAP Fiori applications using the posting library fail to properly configure security settings during the setup process, leaving them at default or inadequately defined. This vulnerability allows an attacker with low privileges to bypass access controls within the application, enabling them to potentially modify data. Confidentiality and Availability are not impacted.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-26660"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-11T01:15:35Z",
    "severity": "MODERATE"
  },
  "details": "SAP Fiori applications using the posting library fail to properly configure security settings during the setup process, leaving them at default or inadequately defined. This vulnerability allows an attacker with low privileges to bypass access controls within the application, enabling them to potentially modify data. Confidentiality and Availability are not impacted.",
  "id": "GHSA-6xr2-ww2p-m9pg",
  "modified": "2025-03-11T03:30:50Z",
  "published": "2025-03-11T03:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-26660"
    },
    {
      "type": "WEB",
      "url": "https://me.sap.com/notes/3557655"
    },
    {
      "type": "WEB",
      "url": "https://url.sap/sapsecuritypatchday"
    }
  ],
  "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-6XRG-C3GP-J55V

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

The Quick Featured Images plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 13.7.2 via the qfi_set_thumbnail and qfi_delete_thumbnail AJAX actions due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with Author-level access and above, to change or remove featured images of other user's posts.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-11176"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-15T06:15:38Z",
    "severity": "MODERATE"
  },
  "details": "The Quick Featured Images plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 13.7.2 via the qfi_set_thumbnail and qfi_delete_thumbnail AJAX actions due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with Author-level access and above, to change or remove featured images of other user\u0027s posts.",
  "id": "GHSA-6xrg-c3gp-j55v",
  "modified": "2025-10-15T06:31:09Z",
  "published": "2025-10-15T06:31:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11176"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/quick-featured-images/tags/13.7.2/admin/class-Quick_Featured_Images_Columns.php#L506"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026new=3376996%40quick-featured-images%2Ftrunk\u0026old=3271680%40quick-featured-images%2Ftrunk\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/4f9a1cfc-5e52-40da-bb9d-8f2b46d37c8c?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"
    }
  ]
}

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.