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
5710 vulnerabilities reference this CWE, most recent first.
GHSA-393C-P46R-7C95
Vulnerability from github – Published: 2026-04-04 06:06 – Updated: 2026-04-09 19:05Summary
A broken access control vulnerability was identified in the Directus file management API that allows authenticated users to overwrite files belonging to other users by manipulating the filename_disk parameter.
Details
The PATCH /files/{id} endpoint accepts a user-controlled filename_disk parameter. By setting this value to match the storage path of another user's file, an attacker can overwrite that file's content while manipulating metadata fields such as uploaded_by to obscure the tampering.
Impact
- Unauthorized File Overwrite: Attackers can replace legitimate files with malicious content, creating significant risk of malware propagation and data corruption.
- Remote Code Execution: If the storage backend is shared with the extensions location, attackers can deploy malicious extensions that execute arbitrary code when loaded.
- Data Integrity Compromise: Files can be tampered with or replaced without visible indication in the application interface.
Mitigation
The filename_disk parameter should be treated as a server-controlled value. Uniqueness of storage paths must be enforced server-side, and filename_disk should be excluded from the fields users are permitted to update directly.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "directus"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "11.17.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-39942"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-639",
"CWE-915"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-04T06:06:39Z",
"nvd_published_at": "2026-04-09T17:16:29Z",
"severity": "HIGH"
},
"details": "## Summary\n\nA broken access control vulnerability was identified in the Directus file management API that allows authenticated users to overwrite files belonging to other users by manipulating the `filename_disk` parameter.\n\n## Details\n\nThe `PATCH /files/{id}` endpoint accepts a user-controlled `filename_disk` parameter. By setting this value to match the storage path of another user\u0027s file, an attacker can overwrite that file\u0027s content while manipulating metadata fields such as `uploaded_by` to obscure the tampering.\n\n## Impact\n\n- **Unauthorized File Overwrite**: Attackers can replace legitimate files with malicious content, creating significant risk of malware propagation and data corruption.\n- **Remote Code Execution**: If the storage backend is shared with the extensions location, attackers can deploy malicious extensions that execute arbitrary code when loaded.\n- **Data Integrity Compromise**: Files can be tampered with or replaced without visible indication in the application interface.\n\n## Mitigation\n\nThe `filename_disk` parameter should be treated as a server-controlled value. Uniqueness of storage paths must be enforced server-side, and `filename_disk` should be excluded from the fields users are permitted to update directly.",
"id": "GHSA-393c-p46r-7c95",
"modified": "2026-04-09T19:05:27Z",
"published": "2026-04-04T06:06:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/directus/directus/security/advisories/GHSA-393c-p46r-7c95"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39942"
},
{
"type": "PACKAGE",
"url": "https://github.com/directus/directus"
},
{
"type": "WEB",
"url": "https://github.com/directus/directus/releases/tag/v11.17.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Directus: Path Traversal and Broken Access Control in File Management API"
}
GHSA-3972-HWR2-MQJW
Vulnerability from github – Published: 2026-10-17 06:30 – Updated: 2026-10-17 06:30The Tutor LMS – eLearning and online course solution plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 4.1.0 via the '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 arbitrary courses created by other instructors — overwriting their title, content, and status — and reassign ownership of those courses to themselves. This is possible because Input::sanitize_array() preserves attacker-supplied POST keys (including 'ID') without stripping them, and WordPress interprets a non-empty ID in the wp_insert_post() argument array as an update to the existing post rather than a new insert.
{
"affected": [],
"aliases": [
"CVE-2026-92715"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-17T04:17:10Z",
"severity": "MODERATE"
},
"details": "The Tutor LMS \u2013 eLearning and online course solution plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 4.1.0 via the \u0027ID\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 arbitrary courses created by other instructors \u2014 overwriting their title, content, and status \u2014 and reassign ownership of those courses to themselves. This is possible because Input::sanitize_array() preserves attacker-supplied POST keys (including \u0027ID\u0027) without stripping them, and WordPress interprets a non-empty ID in the wp_insert_post() argument array as an update to the existing post rather than a new insert.",
"id": "GHSA-3972-hwr2-mqjw",
"modified": "2026-10-17T06:30:33Z",
"published": "2026-10-17T06:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-92715"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/tutor/tags/4.0.8/classes/Course.php#L1009"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/tutor/tags/4.0.8/classes/Course.php#L1053"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/tutor/tags/4.0.8/classes/Course.php#L303"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/tutor/tags/4.0.8/classes/Course.php#L850"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3730615/tutor/trunk/classes/Course.php"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/12f093bd-5230-4103-b571-80543c1b43cf?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-397Q-QWG5-F6MC
Vulnerability from github – Published: 2026-08-13 21:36 – Updated: 2026-08-13 21:36Authorization Bypass Through User-Controlled Key (CWE-639) in Kibana can lead to unauthorized cross-space access via Accessing Functionality Not Properly Constrained by ACLs (CAPEC-1). The result is disclosure of inference output from a trained model in a different space that the user is not authorized to list, read, or use, which exposes the behavior of a model. The same pattern also reached the deployment stop and deployment update operations, allowing an active trained model deployment in another space to be stopped or to have its allocated resources altered.
{
"affected": [],
"aliases": [
"CVE-2026-72629"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-13T20:17:23Z",
"severity": "HIGH"
},
"details": "Authorization Bypass Through User-Controlled Key (CWE-639) in Kibana can lead to unauthorized cross-space access via Accessing Functionality Not Properly Constrained by ACLs (CAPEC-1). The result is disclosure of inference output from a trained model in a different space that the user is not authorized to list, read, or use, which exposes the behavior of a model. The same pattern also reached the deployment stop and deployment update operations, allowing an active trained model deployment in another space to be stopped or to have its allocated resources altered.",
"id": "GHSA-397q-qwg5-f6mc",
"modified": "2026-08-13T21:36:07Z",
"published": "2026-08-13T21:36:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72629"
},
{
"type": "WEB",
"url": "https://discuss.elastic.co/t/kibana-8-19-20-9-4-5-9-5-1-security-update-esa-2026-126/389530"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-397R-9XJ2-FJ79
Vulnerability from github – Published: 2022-05-24 17:07 – Updated: 2022-05-24 17:07An IDOR was discovered in < 12.3.2, < 12.2.6, and < 12.1.12 for GitLab Community Edition (CE) and Enterprise Edition (EE) that allowed a maintainer to add any private group to a protected environment.
{
"affected": [],
"aliases": [
"CVE-2019-15582"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-01-28T03:15:00Z",
"severity": "MODERATE"
},
"details": "An IDOR was discovered in \u003c 12.3.2, \u003c 12.2.6, and \u003c 12.1.12 for GitLab Community Edition (CE) and Enterprise Edition (EE) that allowed a maintainer to add any private group to a protected environment.",
"id": "GHSA-397r-9xj2-fj79",
"modified": "2022-05-24T17:07:31Z",
"published": "2022-05-24T17:07:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-15582"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/566216"
},
{
"type": "WEB",
"url": "https://about.gitlab.com/blog/2019/09/30/security-release-gitlab-12-dot-3-dot-2-released"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-39P5-2WRR-XH29
Vulnerability from github – Published: 2026-10-09 20:52 – Updated: 2026-10-09 20:52Summary
When you share a project with a team, the API lets you attach any team on the instance, including teams you have nothing to do with, as long as you're an admin of the project. Listing a project's teams then returns each team's full member roster. So any logged-in user can spin up a throwaway project, attach team IDs one by one, and read back the name, description, and complete member list of every team on the instance. Normally you can only see teams you belong to; this path ignores that.
Details
Sharing a project with a team is a two-step flow: you PUT a team to the project, then you GET the project's teams to see them. The share endpoint only enforces that you're an admin of the target project, it doesn't care whether the team you're referencing is one you're allowed to see. Any existing team ID is accepted.
The listing endpoint is even more permissive: read access to the project is enough, which you obviously have on a project you created. And its response isn't just a list of team names, it includes each team's description, creator, and a full members array with every member's username, display name, and admin flag.
Put together, an attacker who owns a single project can walk the team ID space and pull the roster of every team in the instance, including teams they aren't a member of. This contradicts how team visibility works everywhere else in the product, where you only ever see teams you belong to. Emails are stripped from the roster, so what leaks is identities and org structure rather than contact details.
The fix is to require that the caller actually has access to the team they're attaching, not just to the project.
PoC
The attacker needs nothing but an ordinary account.
- Create a throwaway project you own:
- Attach team IDs one by one (sweep the range you want):
PUT /api/v1/projects/<your_project_id>/teams
{<SNIP>, "team_id": <N>, <SNIP>}
- Read them back with their rosters:
GET /api/v1/projects/<your_project_id>/teams
Each entry contains the team name, description, creator, and a members array with every member's username, display name, and admin flag, for teams you are not a member of.
Impact
Information disclosure of the instance-wide team directory: team names, descriptions, and full membership, for teams the attacker has no relationship with. This maps out the organisation's group structure and who belongs where, useful for targeting and social engineering. Any authenticated account is enough; no share link, no admin rights, no victim interaction.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.5.0"
},
"package": {
"ecosystem": "Go",
"name": "code.vikunja.io/api"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-91980"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-09T20:52:27Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\nWhen you share a project with a team, the API lets you attach any team on the instance, including teams you have nothing to do with, as long as you\u0027re an admin of the project. Listing a project\u0027s teams then returns each team\u0027s full member roster. So any logged-in user can spin up a throwaway project, attach team IDs one by one, and read back the name, description, and complete member list of every team on the instance. Normally you can only see teams you belong to; this path ignores that.\n\n### Details\nSharing a project with a team is a two-step flow: you PUT a team to the project, then you GET the project\u0027s teams to see them. The share endpoint only enforces that you\u0027re an admin of the target project, it doesn\u0027t care whether the team you\u0027re referencing is one you\u0027re allowed to see. Any existing team ID is accepted.\n\nThe listing endpoint is even more permissive: read access to the project is enough, which you obviously have on a project you created. And its response isn\u0027t just a list of team names, it includes each team\u0027s description, creator, and a full members array with every member\u0027s username, display name, and admin flag.\n\nPut together, an attacker who owns a single project can walk the team ID space and pull the roster of every team in the instance, including teams they aren\u0027t a member of. This contradicts how team visibility works everywhere else in the product, where you only ever see teams you belong to. Emails are stripped from the roster, so what leaks is identities and org structure rather than contact details.\n\nThe fix is to require that the caller actually has access to the team they\u0027re attaching, not just to the project.\n\n### PoC\nThe attacker needs nothing but an ordinary account.\n\n1. Create a throwaway project you own:\n2. Attach team IDs one by one (sweep the range you want):\n```\nPUT /api/v1/projects/\u003cyour_project_id\u003e/teams\n{\u003cSNIP\u003e, \"team_id\": \u003cN\u003e, \u003cSNIP\u003e}\n```\n3. Read them back with their rosters:\n```\nGET /api/v1/projects/\u003cyour_project_id\u003e/teams\n```\nEach entry contains the team name, description, creator, and a members array with every member\u0027s username, display name, and admin flag, for teams you are not a member of.\n\n### Impact\nInformation disclosure of the instance-wide team directory: team names, descriptions, and full membership, for teams the attacker has no relationship with. This maps out the organisation\u0027s group structure and who belongs where, useful for targeting and social engineering. Any authenticated account is enough; no share link, no admin rights, no victim interaction.",
"id": "GHSA-39p5-2wrr-xh29",
"modified": "2026-10-09T20:52:27Z",
"published": "2026-10-09T20:52:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-39p5-2wrr-xh29"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-91980"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/pull/3688"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-vikunja/vikunja"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/releases/tag/v2.6.0"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/vikunja-before-2.6.0-team-enumeration-via-project-share"
}
],
"schema_version": "1.4.0",
"severity": [
{
"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",
"type": "CVSS_V4"
}
],
"summary": "Vikunja: Any user can enumerate every team and its members by attaching arbitrary teams to a throwaway project"
}
GHSA-39W6-QC54-G7CG
Vulnerability from github – Published: 2026-10-30 15:34 – Updated: 2026-10-30 15:34Open Web Analytics before 1.14.1 contains an authorization vulnerability that allows authenticated users to read other sites' report data because clickstream and transaction reports are not scoped to the authorized siteId. Users with view_reports on one site can supply that siteId with another site's session_id or order_id to read its visit history, IP addresses, user agents and order data.
{
"affected": [],
"aliases": [
"CVE-2026-119646"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-30T15:16:47Z",
"severity": "MODERATE"
},
"details": "Open Web Analytics before 1.14.1 contains an authorization vulnerability that allows authenticated users to read other sites\u0027 report data because clickstream and transaction reports are not scoped to the authorized siteId. Users with view_reports on one site can supply that siteId with another site\u0027s session_id or order_id to read its visit history, IP addresses, user agents and order data.",
"id": "GHSA-39w6-qc54-g7cg",
"modified": "2026-10-30T15:34:37Z",
"published": "2026-10-30T15:34:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-119646"
},
{
"type": "WEB",
"url": "https://github.com/Open-Web-Analytics/Open-Web-Analytics/issues/1236"
},
{
"type": "WEB",
"url": "https://github.com/Open-Web-Analytics/Open-Web-Analytics/commit/9a1b62893fe8242048a1129d96f89a52f910be72"
},
{
"type": "WEB",
"url": "https://github.com/Open-Web-Analytics/Open-Web-Analytics/commit/e6832fa60ead473c5792a999ae32abb3fecc2790"
},
{
"type": "WEB",
"url": "https://github.com/Open-Web-Analytics/Open-Web-Analytics"
},
{
"type": "WEB",
"url": "https://github.com/Open-Web-Analytics/Open-Web-Analytics/blob/1.14.0/modules/Base/Controller/ReportsRest.php#L466-L618"
},
{
"type": "WEB",
"url": "https://github.com/Open-Web-Analytics/Open-Web-Analytics/releases/tag/1.14.1"
},
{
"type": "WEB",
"url": "https://hackmd.io/@hieuPenguinnn/open-web-analytics-reports-rest-cross-site-idor"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/open-web-analytics-before-1.14.1-cross-site-data-disclosure-via-rest-report-api"
}
],
"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-39W7-GH54-79CF
Vulnerability from github – Published: 2026-08-31 15:34 – Updated: 2026-08-31 15:34Joomla Extension - joomshaper.com - Broken Object-Level Authorization in Blog Image Deletion in Helix Ultimate < 2.2.10 - Blog::remove_image() checked whether the user was authorized to edit the article ID passed in the request, but did not verify whether the specified image path (src) belonged to that article. On Joomla 3 builds where physical file deletion was triggered, an author could supply their own article ID alongside an arbitrary file path under the /images/ directory to delete arbitrary files.
{
"affected": [],
"aliases": [
"CVE-2026-78075"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-31T14:17:23Z",
"severity": "MODERATE"
},
"details": "Joomla Extension - joomshaper.com - Broken Object-Level Authorization in Blog Image Deletion in Helix Ultimate \u003c 2.2.10 - `Blog::remove_image()` checked whether the user was authorized to edit the article ID passed in the request, but did not verify whether the specified image path (src) belonged to that article. On Joomla 3 builds where physical file deletion was triggered, an author could supply their own article ID alongside an arbitrary file path under the `/images/` directory to delete arbitrary files.",
"id": "GHSA-39w7-gh54-79cf",
"modified": "2026-08-31T15:34:45Z",
"published": "2026-08-31T15:34:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-78075"
},
{
"type": "WEB",
"url": "https://www.joomshaper.com/joomla-templates/helixultimate"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:L/VA:L/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-39XV-4J8V-HP84
Vulnerability from github – Published: 2024-06-27 15:30 – Updated: 2026-06-03 18:33Authorization Bypass Through User-Controlled Key vulnerability in Talya Informatics Travel APPS allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Travel APPS: before v17.0.68.
{
"affected": [],
"aliases": [
"CVE-2024-1107"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-27T13:15:54Z",
"severity": "HIGH"
},
"details": "Authorization Bypass Through User-Controlled Key vulnerability in Talya Informatics Travel APPS allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Travel APPS: before v17.0.68.",
"id": "GHSA-39xv-4j8v-hp84",
"modified": "2026-06-03T18:33:05Z",
"published": "2024-06-27T15:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1107"
},
{
"type": "WEB",
"url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-24-0809"
},
{
"type": "WEB",
"url": "https://www.usom.gov.tr/bildirim/tr-24-0809"
}
],
"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-3C27-7487-M6FW
Vulnerability from github – Published: 2026-02-11 12:30 – Updated: 2026-02-11 12:30GitLab has remediated an issue in GitLab CE/EE affecting all versions from 17.11 before 18.6.6, 18.7 before 18.7.4, and 18.8 before 18.8.4 that, under certain conditions could have allowed an authenticated user to view certain pipeline values by querying the API.
{
"affected": [],
"aliases": [
"CVE-2025-14594"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-11T12:16:03Z",
"severity": "LOW"
},
"details": "GitLab has remediated an issue in GitLab CE/EE affecting all versions from 17.11 before 18.6.6, 18.7 before 18.7.4, and 18.8 before 18.8.4 that, under certain conditions could have allowed an authenticated user to view certain pipeline values by querying the API.",
"id": "GHSA-3c27-7487-m6fw",
"modified": "2026-02-11T12:30:22Z",
"published": "2026-02-11T12:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14594"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/3457591"
},
{
"type": "WEB",
"url": "https://about.gitlab.com/releases/2026/02/10/patch-release-gitlab-18-8-4-released"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/583967"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-3C93-G9G6-P5J4
Vulnerability from github – Published: 2026-05-06 03:33 – Updated: 2026-05-11 16:23An authorization bypass (CWE-639) in the GetUserRoles gRPC API endpoint in Velocidex Velociraptor below version 0.76.5 allows any authenticated low-privilege user to retrieve the complete ACL policy (roles and permissions) for any user across all organizations by supplying targeted Name and Org parameters via a network request.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "www.velocidex.com/golang/velociraptor"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.76.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-7573"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-11T16:23:57Z",
"nvd_published_at": "2026-05-06T03:15:59Z",
"severity": "MODERATE"
},
"details": "An authorization bypass (CWE-639) in the GetUserRoles gRPC API endpoint in Velocidex Velociraptor below version 0.76.5 allows any authenticated low-privilege user to retrieve the complete ACL policy (roles and permissions) for any user across all organizations by supplying targeted Name and Org parameters via a network request.",
"id": "GHSA-3c93-g9g6-p5j4",
"modified": "2026-05-11T16:23:57Z",
"published": "2026-05-06T03:33:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-7573"
},
{
"type": "WEB",
"url": "https://docs.velociraptor.app/announcements/advisories/cve-2026-7573"
},
{
"type": "PACKAGE",
"url": "https://github.com/Velocidex/velociraptor"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Velocidex Velociraptor has an authorization bypass vulnerability"
}
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.