CWE-639
Weakness AllowedAuthorization 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.
It is likely that an attacker would have to be an authenticated user in the system. However, the authorization process would not properly check the data access operation to ensure that the authenticated user performing the operation has sufficient entitlements to perform the requested data access, hence bypassing any other authorization checks present in the system.
For example, attackers can look at places where user specific data is retrieved (e.g. search screens) and determine whether the key for the item being looked up is controllable externally. The key may be a hidden field in the HTML form field, might be passed as a URL parameter or as an unencrypted cookie variable, then in each of these cases it will be possible to tamper with the key value.
Mapping guidance
This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
Relationships and members
Modes of introduction
REALIZATION: This weakness is caused during implementation of an architectural security tactic.
Retrieval of a user record occurs in the system based on some key value that is under user control. The key would typically identify a user-related record stored in the system and would be used to lookup that record for presentation to the user.
One manifestation of this weakness is when a system uses sequential or otherwise easily-guessable session IDs that would allow one user to easily switch to another user's session and read/modify their data.
Detection methods
Automated Static Analysis
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Effectiveness: High
Notes
Maintenance
As of CWE 4.20, the relationship between IDOR and BOLA needs to be investigated more closely, including research into how these terms are used in the industry. The CWE team suspects that IDOR can be a part of BOLA, but BOLA expands on the weakness inherent to IDOR in that it is not only about objects that are being directly referenced.
Content history
Suggested corrections to use of IDOR versus BOLA
updated Common_Consequences, Relationships, Type
updated Description
updated Relationships
updated Relationships
updated Common_Consequences
updated Relationships
updated Alternate_Terms, Applicable_Platforms, Description, Name, Potential_Mitigations, Relationships
updated Common_Consequences, Relationships
updated Relationships
updated Alternate_Terms, Common_Consequences
updated Relationships
updated Relationships
updated Description, Enabling_Factors_for_Exploitation, Modes_of_Introduction, Relationships
updated Relationships
updated Relationships
updated Relationships
updated Alternate_Terms
updated Relationships
updated Alternate_Terms
updated Relationships
updated Detection_Factors, Relationships
updated Mapping_Notes
updated Observed_Examples
updated Demonstrative_Examples
updated References, Relationships, Weakness_Ordinalities
updated Alternate_Terms, Maintenance_Notes, References
updated Description, Modes_of_Introduction, Time_of_Introduction
5706 vulnerabilities reference this CWE, most recent first.
GHSA-3PGC-7JF3-5X5G
Vulnerability from github – Published: 2022-05-24 16:52 – Updated: 2024-02-12 11:32An Insecure Direct Object Reference (IDOR) vulnerability exists in the order processing workflow of Magento 2.1 prior to 2.1.18, Magento 2.2 prior to 2.2.9, Magento 2.3 prior to 2.3.2. This can lead to unauthorized access to order details.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"ranges": [
{
"events": [
{
"introduced": "2.1"
},
{
"fixed": "2.1.18"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"ranges": [
{
"events": [
{
"introduced": "2.2"
},
{
"fixed": "2.2.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"ranges": [
{
"events": [
{
"introduced": "2.3"
},
{
"fixed": "2.3.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-7890"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2023-07-17T20:40:16Z",
"nvd_published_at": "2019-08-02T22:15:00Z",
"severity": "HIGH"
},
"details": "An Insecure Direct Object Reference (IDOR) vulnerability exists in the order processing workflow of Magento 2.1 prior to 2.1.18, Magento 2.2 prior to 2.2.9, Magento 2.3 prior to 2.3.2. This can lead to unauthorized access to order details.",
"id": "GHSA-3pgc-7jf3-5x5g",
"modified": "2024-02-12T11:32:11Z",
"published": "2022-05-24T16:52:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-7890"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/magento/product-community-edition/CVE-2019-7890.yaml"
},
{
"type": "WEB",
"url": "https://magento.com/security/patches/magento-2.3.2-2.2.9-and-2.1.18-security-update-23"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20220121051916/https://magento.com/security/patches/magento-2.3.2-2.2.9-and-2.1.18-security-update-23"
}
],
"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:L",
"type": "CVSS_V3"
}
],
"summary": "Magento 2 Community Edition IDOR Vulnerability"
}
GHSA-3PJ4-PJ2W-P8P4
Vulnerability from github – Published: 2026-10-26 12:32 – Updated: 2026-10-26 12:32Authorization Bypass Through User-Controlled Key vulnerability in WProyal Royal Elementor Addons royal-elementor-addons allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Royal Elementor Addons: from n/a through 1.7.1069.
{
"affected": [],
"aliases": [
"CVE-2026-97255"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-26T10:16:53Z",
"severity": "MODERATE"
},
"details": "Authorization Bypass Through User-Controlled Key vulnerability in WProyal Royal Elementor Addons royal-elementor-addons allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Royal Elementor Addons: from n/a through 1.7.1069.",
"id": "GHSA-3pj4-pj2w-p8p4",
"modified": "2026-10-26T12:32:30Z",
"published": "2026-10-26T12:32:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97255"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/royal-elementor-addons/vulnerability/wordpress-royal-elementor-addons-plugin-1-7-1069-insecure-direct-object-references-idor-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-3PRP-9GF7-4RXX
Vulnerability from github – Published: 2026-04-17 21:34 – Updated: 2026-04-24 21:01Summary
A Mass Assignment vulnerability in the DocumentStore creation endpoint allows authenticated users to control the primary key (id) and internal state fields of DocumentStore entities.
Because the service uses repository.save() with a client-supplied primary key, the POST create endpoint behaves as an implicit UPSERT operation. This enables overwriting existing DocumentStore objects.
In multi-workspace or multi-tenant deployments, this can lead to cross-workspace object takeover and broken object-level authorization (IDOR), allowing an attacker to reassign or modify DocumentStore objects belonging to other workspaces.
Details
The DocumentStore entity defines a globally unique primary key:
@PrimaryGeneratedColumn('uuid')
id: string
The create logic is implemented as:
const documentStore = repo.create(newDocumentStore)
const dbResponse = await repo.save(documentStore)
Here is no DTO allowlist or field filtering before persistence. The entire request body is mapped directly to the entity. TypeORM save() behavior:
- If the primary key (id) exists → UPDATE
- If not → INSERT
Because id is accepted from the client, the create endpoint effectively functions as an UPSERT endpoint.
This allows an authenticated user to submit:
{
"id": "<existing_store_id>",
"name": "modified",
"description": "modified",
"status": "SYNC",
"embeddingConfig": "...",
"vectorStoreConfig": "...",
"recordManagerConfig": "..."
}
If a DocumentStore with the supplied id already exists, save() performs an UPDATE rather than creating a new record.
Importantly:
The primary key is globally unique (uuid) It is not composite with workspaceId The create path does not enforce ownership validation before calling save() This introduces a broken object-level authorization risk.
If an attacker can obtain or enumerate a valid DocumentStore UUID belonging to another workspace, they can: Submit a POST create request with that UUID. Trigger an UPDATE on the existing record. Potentially overwrite fields including workspaceId, effectively reassigning the object to their own workspace.
Because the service layer does not verify that the existing record belongs to the caller’s workspace before updating, this may result in cross-workspace object takeover.
Additionally, several service functions retrieve DocumentStore entities by id without consistently scoping by workspaceId, increasing the risk of IDOR if controller-level protections are bypassed or misconfigured.
PoC
- Create a normal DocumentStore in Workspace A.
- Capture its id from the API response.
- From Workspace B (or another authenticated context), submit:
POST /api/v1/document-store
Content-Type: application/json
{
"id": "<id_from_workspace_A>",
"name": "hijacked",
"description": "hijacked"
}
Because the service uses repository.save() with a client-supplied primary key:
- The existing record is updated.
- The object may become reassigned depending on how workspaceId is handled at controller level.
- If workspaceId is overwritten during the create flow, the store is effectively migrated to the attacker’s workspace.
- This demonstrates object takeover via UPSERT semantics on a create endpoint.
Impact
This vulnerability enables:
- Mass Assignment on server-managed fields
- Overwrite of existing objects via implicit UPSERT behavior
- Broken Object Level Authorization (BOLA)
- Potential cross-workspace object takeover in multi-tenant deployments
- In a SaaS or shared-workspace environment, an attacker who can obtain or guess a valid UUID may modify or reassign DocumentStore objects belonging to other tenants.
Because DocumentStore objects control embedding providers, vector store configuration, and record management logic, successful takeover can affect data indexing, retrieval, and AI workflow execution.
This represents a high-risk authorization flaw in multi-tenant environments.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.0.13"
},
"package": {
"ecosystem": "npm",
"name": "flowise"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41277"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-639",
"CWE-915"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-17T21:34:16Z",
"nvd_published_at": "2026-04-23T20:16:16Z",
"severity": "HIGH"
},
"details": "### Summary\nA Mass Assignment vulnerability in the DocumentStore creation endpoint allows authenticated users to control the primary key (id) and internal state fields of DocumentStore entities.\n\nBecause the service uses repository.save() with a client-supplied primary key, the POST create endpoint behaves as an implicit UPSERT operation. This enables overwriting existing DocumentStore objects.\n\nIn multi-workspace or multi-tenant deployments, this can lead to cross-workspace object takeover and broken object-level authorization (IDOR), allowing an attacker to reassign or modify DocumentStore objects belonging to other workspaces.\n\n### Details\nThe DocumentStore entity defines a globally unique primary key:\n\n```typescript\n@PrimaryGeneratedColumn(\u0027uuid\u0027)\nid: string\n```\n\nThe create logic is implemented as:\n```typescript\nconst documentStore = repo.create(newDocumentStore)\nconst dbResponse = await repo.save(documentStore)\n```\n\nHere is no DTO allowlist or field filtering before persistence. The entire request body is mapped directly to the entity.\nTypeORM save() behavior:\n\n1. If the primary key (id) exists \u2192 UPDATE\n2. If not \u2192 INSERT\n\nBecause id is accepted from the client, the create endpoint effectively functions as an UPSERT endpoint.\n\nThis allows an authenticated user to submit:\n\n```json\n{\n \"id\": \"\u003cexisting_store_id\u003e\",\n \"name\": \"modified\",\n \"description\": \"modified\",\n \"status\": \"SYNC\",\n \"embeddingConfig\": \"...\",\n \"vectorStoreConfig\": \"...\",\n \"recordManagerConfig\": \"...\"\n}\n```\nIf a DocumentStore with the supplied id already exists, save() performs an UPDATE rather than creating a new record.\n\nImportantly:\n\nThe primary key is globally unique (uuid)\nIt is not composite with workspaceId\nThe create path does not enforce ownership validation before calling save()\nThis introduces a broken object-level authorization risk.\n\nIf an attacker can obtain or enumerate a valid DocumentStore UUID belonging to another workspace, they can:\nSubmit a POST create request with that UUID.\nTrigger an UPDATE on the existing record.\nPotentially overwrite fields including workspaceId, effectively reassigning the object to their own workspace.\n\nBecause the service layer does not verify that the existing record belongs to the caller\u2019s workspace before updating, this may result in cross-workspace object takeover.\n\nAdditionally, several service functions retrieve DocumentStore entities by id without consistently scoping by workspaceId, increasing the risk of IDOR if controller-level protections are bypassed or misconfigured.\n\n### PoC\n\n1. Create a normal DocumentStore in Workspace A.\n2. Capture its id from the API response.\n3. From Workspace B (or another authenticated context), submit:\n\n```http\nPOST /api/v1/document-store\nContent-Type: application/json\n\n{\n \"id\": \"\u003cid_from_workspace_A\u003e\",\n \"name\": \"hijacked\",\n \"description\": \"hijacked\"\n}\n```\n\nBecause the service uses repository.save() with a client-supplied primary key:\n\n- The existing record is updated.\n- The object may become reassigned depending on how workspaceId is handled at controller level.\n- If workspaceId is overwritten during the create flow, the store is effectively migrated to the attacker\u2019s workspace.\n- This demonstrates object takeover via UPSERT semantics on a create endpoint.\n\n### Impact\nThis vulnerability enables:\n\n- Mass Assignment on server-managed fields\n- Overwrite of existing objects via implicit UPSERT behavior\n- Broken Object Level Authorization (BOLA)\n- Potential cross-workspace object takeover in multi-tenant deployments\n- In a SaaS or shared-workspace environment, an attacker who can obtain or guess a valid UUID may modify or reassign DocumentStore objects belonging to other tenants.\n\nBecause DocumentStore objects control embedding providers, vector store configuration, and record management logic, successful takeover can affect data indexing, retrieval, and AI workflow execution.\n\nThis represents a high-risk authorization flaw in multi-tenant environments.",
"id": "GHSA-3prp-9gf7-4rxx",
"modified": "2026-04-24T21:01:04Z",
"published": "2026-04-17T21:34:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-3prp-9gf7-4rxx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41277"
},
{
"type": "PACKAGE",
"url": "https://github.com/FlowiseAI/Flowise"
}
],
"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:P/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Flowise: Mass Assignment in DocumentStore Create Endpoint Leads to Cross-Workspace Object Takeover (IDOR)"
}
GHSA-3PV4-5J2G-FVVJ
Vulnerability from github – Published: 2026-08-23 06:30 – Updated: 2026-08-23 18:31Brave Popup Builder (slug: brave-popup-builder) has a broken access control issue in versions through 0.8.5. Any logged-in user - Subscriber or WooCommerce Customer is enough — can read popup content they shouldn't have access to by passing a post ID in the URL.
{
"affected": [],
"aliases": [
"CVE-2026-77116"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-23T06:17:27Z",
"severity": "MODERATE"
},
"details": "Brave Popup Builder (slug: brave-popup-builder) has a broken access control issue in versions through 0.8.5. Any logged-in user - Subscriber or WooCommerce Customer is enough \u2014 can read popup content they shouldn\u0027t have access to by passing a post ID in the URL.",
"id": "GHSA-3pv4-5j2g-fvvj",
"modified": "2026-08-23T18:31:44Z",
"published": "2026-08-23T06:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77116"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/db0a775c-cbac-4918-8b10-75f4fb2d716a"
}
],
"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-3PVC-3977-GXH7
Vulnerability from github – Published: 2026-10-24 12:30 – Updated: 2026-10-24 12:30yudao-cloud through 2026.09 contains an insecure direct object reference vulnerability in the mall trade module that allows authenticated members to read other members' after-sale operation logs by supplying arbitrary afterSaleId values. Attackers can enumerate sequential after-sale IDs against GET /app-api/trade/after-sale-log/list to expose refund amounts, status transitions and timestamps belonging to other members.
{
"affected": [],
"aliases": [
"CVE-2026-116015"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-24T12:16:57Z",
"severity": "MODERATE"
},
"details": "yudao-cloud through 2026.09 contains an insecure direct object reference vulnerability in the mall trade module that allows authenticated members to read other members\u0027 after-sale operation logs by supplying arbitrary afterSaleId values. Attackers can enumerate sequential after-sale IDs against GET /app-api/trade/after-sale-log/list to expose refund amounts, status transitions and timestamps belonging to other members.",
"id": "GHSA-3pvc-3977-gxh7",
"modified": "2026-10-24T12:30:24Z",
"published": "2026-10-24T12:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-116015"
},
{
"type": "WEB",
"url": "https://github.com/YunaiV/yudao-cloud/issues/344"
},
{
"type": "WEB",
"url": "https://github.com/YunaiV/yudao-cloud/commit/df604fbd9824195ec3e48e2dfd3341c1d4e1edea"
},
{
"type": "WEB",
"url": "https://github.com/YunaiV/yudao-cloud/blob/593354d92a63f401ba73b95da868aade8c3d855d/yudao-module-mall/yudao-module-trade-server/src/main/java/cn/iocoder/yudao/module/trade/controller/app/aftersale/AppAfterSaleLogController.java#L33-L40"
},
{
"type": "WEB",
"url": "https://github.com/YunaiV/yudao-cloud/blob/593354d92a63f401ba73b95da868aade8c3d855d/yudao-module-mall/yudao-module-trade-server/src/main/java/cn/iocoder/yudao/module/trade/dal/mysql/aftersale/AfterSaleLogMapper.java#L13-L17"
},
{
"type": "WEB",
"url": "https://hackmd.io/@hieuPenguinnn/yudao-cloud-mall-after-sale-log-cross-member-idor"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/yudao-cloud-through-2026.09-idor-via-after-sale-log-list-endpoint"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/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-3PVF-VXRV-HH9C
Vulnerability from github – Published: 2026-03-24 16:53 – Updated: 2026-03-25 20:59Summary
A low-privileged authenticated user can read private asset content by calling assets/edit-image with an arbitrary assetId that they are not authorized to view.
The endpoint returns image bytes (or a preview redirect) without enforcing a per-asset view authorization check, leading to potential unauthorized disclosure of private files.
Details
Root cause:
- A user-controlled object reference (assetId) is used to load and return sensitive content.
- The action does not verify whether the current user is authorized to view that asset.
- This creates an authenticated IDOR / authorization bypass.
Impact
- Craft installations where private/non-public assets exist and low-privileged users can authenticate.
Resources
https://github.com/craftcms/cms/commit/7290d91639e
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.17.7"
},
"package": {
"ecosystem": "Packagist",
"name": "craftcms/cms"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0-RC1"
},
{
"fixed": "4.17.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.9.13"
},
"package": {
"ecosystem": "Packagist",
"name": "craftcms/cms"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0-RC1"
},
{
"fixed": "5.9.14"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33158"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-24T16:53:24Z",
"nvd_published_at": "2026-03-24T18:16:09Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nA low-privileged authenticated user can read private asset content by calling `assets/edit-image` with an arbitrary `assetId` that they are not authorized to view.\n\nThe endpoint returns image bytes (or a preview redirect) without enforcing a per-asset view authorization check, leading to potential unauthorized disclosure of private files.\n\n### Details\n\nRoot cause:\n - A user-controlled object reference (`assetId`) is used to load and return sensitive content.\n - The action does not verify whether the current user is authorized to view that asset.\n - This creates an authenticated IDOR / authorization bypass.\n\n### Impact\n\n- Craft installations where private/non-public assets exist and low-privileged users can authenticate.\n\n## Resources\n\nhttps://github.com/craftcms/cms/commit/7290d91639e",
"id": "GHSA-3pvf-vxrv-hh9c",
"modified": "2026-03-25T20:59:46Z",
"published": "2026-03-24T16:53:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/craftcms/cms/security/advisories/GHSA-3pvf-vxrv-hh9c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33158"
},
{
"type": "WEB",
"url": "https://github.com/craftcms/cms/commit/7290d91639e5e3a4f7e221dfbef95c9b77331860"
},
{
"type": "PACKAGE",
"url": "https://github.com/craftcms/cms"
},
{
"type": "WEB",
"url": "https://github.com/craftcms/cms/releases/tag/4.17.8"
},
{
"type": "WEB",
"url": "https://github.com/craftcms/cms/releases/tag/5.9.14"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "Craft CMS: Low-privilege users could read private asset contents when editing an asset (IDOR)"
}
GHSA-3Q6Q-26VG-V97X
Vulnerability from github – Published: 2026-07-14 00:03 – Updated: 2026-07-14 00:03Summary
Kimai 2.56.0 contains an authenticated improper authorization vulnerability in the preset-project activity creation flow. A user with the generic create_activity permission, but without access to a target project, can still create a new Activity under that unauthorized project by visiting the preset project creation route directly.
This is a persistent cross-project business-object creation issue. The attacker does not need permission to view or edit the target project and only needs to know a valid project.id.
Details
The issue affects the activity creation entry point that accepts a preset project identifier:
GET/POST /en/admin/activity/create/{project}GET/POST /en/admin/project/create/{customer}
In src/Controller/ActivityController.php, the controller checks only the global capability to create activities and does not verify whether the current user is allowed to create an activity under the supplied Project object.
The form and repository path also preserve the preset project instead of rejecting it when the user lacks access. Because the preset project is merged into the candidate set, the final save operation can persist a new Activity under a project that is outside the attacker's authorized project scope.
The same logic applies to the src/Controller/ProjectController.php.
A PoC was provided, but removed for security reasons.
Impact
This vulnerability allows an authenticated user to inject new child business objects into projects outside their authorized scope. An attacker can pollute another team's project configuration, influence later timesheet selection and rate inheritance, and create conditions for downstream business abuse if other users start using the injected activity.
Solution
- In
ActivityControllerwe now validate if the project can be edited with[IsGranted('edit', 'project')] - In
ProjectControllerwe now validate if if the customer can be edited with[IsGranted('edit', 'customer')]
See https://www.kimai.org/en/security/ghsa-3q6q-26vg-v97x
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.56.0"
},
"package": {
"ecosystem": "Packagist",
"name": "kimai/kimai"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.57.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-52821"
],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-14T00:03:42Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nKimai 2.56.0 contains an authenticated improper authorization vulnerability in the preset-project activity creation flow. A user with the generic `create_activity` permission, but without access to a target project, can still create a new `Activity` under that unauthorized project by visiting the preset project creation route directly.\n\nThis is a persistent cross-project business-object creation issue. The attacker does not need permission to view or edit the target project and only needs to know a valid `project.id`.\n\n### Details\n\nThe issue affects the activity creation entry point that accepts a preset project identifier:\n\n- `GET/POST /en/admin/activity/create/{project}`\n- `GET/POST /en/admin/project/create/{customer}`\n\nIn `src/Controller/ActivityController.php`, the controller checks only the global capability to create activities and does not verify whether the current user is allowed to create an activity under the supplied `Project` object.\n\nThe form and repository path also preserve the preset project instead of rejecting it when the user lacks access. Because the preset project is merged into the candidate set, the final save operation can persist a new `Activity` under a project that is outside the attacker\u0027s authorized project scope.\n\nThe same logic applies to the `src/Controller/ProjectController.php`.\n\n*A PoC was provided, but removed for security reasons.*\n\n### Impact\n\nThis vulnerability allows an authenticated user to inject new child business objects into projects outside their authorized scope. An attacker can pollute another team\u0027s project configuration, influence later timesheet selection and rate inheritance, and create conditions for downstream business abuse if other users start using the injected activity.\n\n# Solution\n\n- In `ActivityController` we now validate if the project can be edited with `[IsGranted(\u0027edit\u0027, \u0027project\u0027)]`\n- In `ProjectController` we now validate if if the customer can be edited with `[IsGranted(\u0027edit\u0027, \u0027customer\u0027)]`\n\nSee https://www.kimai.org/en/security/ghsa-3q6q-26vg-v97x",
"id": "GHSA-3q6q-26vg-v97x",
"modified": "2026-07-14T00:03:42Z",
"published": "2026-07-14T00:03:42Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kimai/kimai/security/advisories/GHSA-3q6q-26vg-v97x"
},
{
"type": "PACKAGE",
"url": "https://github.com/kimai/kimai"
},
{
"type": "WEB",
"url": "https://www.kimai.org/en/security/ghsa-3q6q-26vg-v97x"
}
],
"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": "Kimai: Improper Authorization Through Activity Creation with Preset Project Allows Creation Under Unauthorized Projects"
}
GHSA-3QR8-PM5H-36F2
Vulnerability from github – Published: 2025-06-10 18:32 – Updated: 2025-06-10 18:32A authorization bypass through user-controlled key in Fortinet FortiPortal versions 7.4.0, versions 7.2.0 through 7.2.5, and versions 7.0.0 through 7.0.8 may allow an authenticated attacker to view unauthorized device information via key modification in API requests.
{
"affected": [],
"aliases": [
"CVE-2024-45329"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-10T17:19:25Z",
"severity": "MODERATE"
},
"details": "A authorization bypass through user-controlled key in Fortinet FortiPortal versions 7.4.0, versions 7.2.0 through 7.2.5, and versions 7.0.0 through 7.0.8 may allow an authenticated attacker to view unauthorized device information via key modification in API requests.",
"id": "GHSA-3qr8-pm5h-36f2",
"modified": "2025-06-10T18:32:27Z",
"published": "2025-06-10T18:32:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45329"
},
{
"type": "WEB",
"url": "https://fortiguard.fortinet.com/psirt/FG-IR-24-274"
}
],
"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-3R8C-RQQR-C7H4
Vulnerability from github – Published: 2022-05-24 19:04 – Updated: 2022-05-24 19:04An Insecure Direct Object Reference (IDOR) vulnerability in Annex Cloud Loyalty Experience Platform <2021.1.0.1 allows any authenticated attacker to modify any existing user, including users assigned to different environments and clients. It was fixed in v2021.1.0.2.
{
"affected": [],
"aliases": [
"CVE-2021-31927"
],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-829"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-10T15:15:00Z",
"severity": "MODERATE"
},
"details": "An Insecure Direct Object Reference (IDOR) vulnerability in Annex Cloud Loyalty Experience Platform \u003c2021.1.0.1 allows any authenticated attacker to modify any existing user, including users assigned to different environments and clients. It was fixed in v2021.1.0.2.",
"id": "GHSA-3r8c-rqqr-c7h4",
"modified": "2022-05-24T19:04:52Z",
"published": "2022-05-24T19:04:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31927"
},
{
"type": "WEB",
"url": "https://github.com/Accenture/AARO-Bugs/blob/master/AARO-CVE-List.md"
},
{
"type": "WEB",
"url": "https://www.annexcloud.com"
}
],
"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-3R9G-8JW6-FCWX
Vulnerability from github – Published: 2026-09-10 09:31 – Updated: 2026-09-10 18:31Authorization bypass through User-Controlled key vulnerability in Apache Camel K.
An authorization vulnerability in custom resource resolution allows a tenant to reference secrets by name in the operator namespace, potentially exposing secrets belonging to other tenants or operator components.
This issue affects Apache Camel K: from 2.0.0 before 2.9.3, from 2.10.1 before 2.10.2.
Users are recommended to upgrade to version 2.9.3, 2.10.2 or 2.11.0, which fixes the issue.
{
"affected": [],
"aliases": [
"CVE-2026-80354"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-10T08:16:59Z",
"severity": "HIGH"
},
"details": "Authorization bypass through User-Controlled key vulnerability in Apache Camel K.\n\n\n\nAn authorization vulnerability in custom resource resolution allows a tenant to reference secrets by name in the operator namespace, potentially exposing secrets belonging to other tenants or operator components.\n\n\n\nThis issue affects Apache Camel K: from 2.0.0 before 2.9.3, from 2.10.1 before 2.10.2.\n\n\n\nUsers are recommended to upgrade to version 2.9.3, 2.10.2 or 2.11.0, which fixes the issue.",
"id": "GHSA-3r9g-8jw6-fcwx",
"modified": "2026-09-10T18:31:39Z",
"published": "2026-09-10T09:31:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80354"
},
{
"type": "WEB",
"url": "https://camel.apache.org/security/CVE-2026-80354.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/09/10/16"
}
],
"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
For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
Mitigation
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
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.