CWE-639
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.
3214 vulnerabilities reference this CWE, most recent first.
GHSA-5JP2-VWRJ-99RF
Vulnerability from github – Published: 2022-10-19 20:26 – Updated: 2025-04-16 16:08Impact
For some Post/Put Concourse endpoint containing :team_name in the URL, a Concourse user can send a request with body including :team_name=team2 to bypass team scope check to gain access to certain resources belong to any other team. The user only needs a valid user session and belongs to team2.
Exploitable endpoints:
{Path: "/api/v1/teams/:team_name/pipelines/:pipeline_name/jobs/:job_name/builds/:build_name", Method: "POST", Name: RerunJobBuild},
{Path: "/api/v1/teams/:team_name/pipelines/:pipeline_name/jobs/:job_name/pause", Method: "PUT", Name: PauseJob},
{Path: "/api/v1/teams/:team_name/pipelines/:pipeline_name/jobs/:job_name/unpause", Method: "PUT", Name: UnpauseJob},
{Path: "/api/v1/teams/:team_name/pipelines/:pipeline_name/jobs/:job_name/schedule", Method: "PUT", Name: ScheduleJob},
{Path: "/api/v1/teams/:team_name/pipelines/:pipeline_name/pause", Method: "PUT", Name: PausePipeline},
{Path: "/api/v1/teams/:team_name/pipelines/:pipeline_name/unpause", Method: "PUT", Name: UnpausePipeline},
{Path: "/api/v1/teams/:team_name/pipelines/:pipeline_name/expose", Method: "PUT", Name: ExposePipeline},
{Path: "/api/v1/teams/:team_name/pipelines/:pipeline_name/hide", Method: "PUT", Name: HidePipeline},
{Path: "/api/v1/teams/:team_name/pipelines/:pipeline_name/rename", Method: "PUT", Name: RenamePipeline},
{Path: "/api/v1/teams/:team_name/pipelines/:pipeline_name/archive", Method: "PUT", Name: ArchivePipeline},
{Path: "/api/v1/teams/:team_name/pipelines/:pipeline_name/resources/:resource_name/versions/:resource_config_version_id/enable", Method: "PUT", Name: EnableResourceVersion},
{Path: "/api/v1/teams/:team_name/pipelines/:pipeline_name/resources/:resource_name/versions/:resource_config_version_id/disable", Method: "PUT", Name: DisableResourceVersion},
{Path: "/api/v1/teams/:team_name/pipelines/:pipeline_name/resources/:resource_name/versions/:resource_config_version_id/pin", Method: "PUT", Name: PinResourceVersion},
{Path: "/api/v1/teams/:team_name/pipelines/:pipeline_name/resources/:resource_name/unpin", Method: "PUT", Name: UnpinResource},
{Path: "/api/v1/teams/:team_name/artifacts", Method: "POST", Name: CreateArtifact},
Steps to reproduce
- Set up a Concourse deployment with team 1 (with pipeline 1) and team 2. User is in team 2 but not team 1.
- Login as user to team 2.
fly -t ci login -n team2 -u user -p password
- Try pausing pipeline 1 in team 1 using fly. Verify the command output is
pipeline 'pipeline1' not found.
fly -t ci pause-pipeline -p pipeline1
- Send a customized request through
fly curlcommand intend to pause pipeline 1 again.
fly -t ci curl /api/v1/teams/team1/pipelines/pipeline1/pause -- -X PUT -d ":team_name=team2" -H "Content-type: application/x-www-form-urlencoded"
- pipeline 1 in team 1 will be paused.
In step 4, the parameter pollution would allow an user from any team to pause a pipeline that belongs to other team.
Patches
Concourse v6.7.9 and v7.8.3 were both released with a fix on October 12, 2022.
Instead of using FormValue to parse team_name in the request, where allows body parameters to take precedence over URL query string values, both patch versions are now using URL.Query().Get() over multiple scope handlers to prevent the parameter pollution.
Workarounds
No known workarounds for existing versions.
References
- https://github.com/concourse/concourse/pull/8566: PR with the fix
For more information
If you have any questions or comments about this advisory, you may reach us privately at security@concourse-ci.org.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/concourse/concourse"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.7.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/concourse/concourse"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.8.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-31683"
],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2022-10-19T20:26:05Z",
"nvd_published_at": "2022-12-19T16:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\nFor some Post/Put Concourse endpoint containing `:team_name` in the URL, a Concourse user can send a request with body including `:team_name=team2` to bypass team scope check to gain access to certain resources belong to any other team. The user only needs a valid user session and belongs to team2.\n\nExploitable endpoints:\n```\n{Path: \"/api/v1/teams/:team_name/pipelines/:pipeline_name/jobs/:job_name/builds/:build_name\", Method: \"POST\", Name: RerunJobBuild},\n{Path: \"/api/v1/teams/:team_name/pipelines/:pipeline_name/jobs/:job_name/pause\", Method: \"PUT\", Name: PauseJob},\n{Path: \"/api/v1/teams/:team_name/pipelines/:pipeline_name/jobs/:job_name/unpause\", Method: \"PUT\", Name: UnpauseJob},\n{Path: \"/api/v1/teams/:team_name/pipelines/:pipeline_name/jobs/:job_name/schedule\", Method: \"PUT\", Name: ScheduleJob},\n\n{Path: \"/api/v1/teams/:team_name/pipelines/:pipeline_name/pause\", Method: \"PUT\", Name: PausePipeline},\n{Path: \"/api/v1/teams/:team_name/pipelines/:pipeline_name/unpause\", Method: \"PUT\", Name: UnpausePipeline},\n{Path: \"/api/v1/teams/:team_name/pipelines/:pipeline_name/expose\", Method: \"PUT\", Name: ExposePipeline},\n{Path: \"/api/v1/teams/:team_name/pipelines/:pipeline_name/hide\", Method: \"PUT\", Name: HidePipeline},\n{Path: \"/api/v1/teams/:team_name/pipelines/:pipeline_name/rename\", Method: \"PUT\", Name: RenamePipeline},\n{Path: \"/api/v1/teams/:team_name/pipelines/:pipeline_name/archive\", Method: \"PUT\", Name: ArchivePipeline},\n\n{Path: \"/api/v1/teams/:team_name/pipelines/:pipeline_name/resources/:resource_name/versions/:resource_config_version_id/enable\", Method: \"PUT\", Name: EnableResourceVersion},\n{Path: \"/api/v1/teams/:team_name/pipelines/:pipeline_name/resources/:resource_name/versions/:resource_config_version_id/disable\", Method: \"PUT\", Name: DisableResourceVersion},\n{Path: \"/api/v1/teams/:team_name/pipelines/:pipeline_name/resources/:resource_name/versions/:resource_config_version_id/pin\", Method: \"PUT\", Name: PinResourceVersion},\n{Path: \"/api/v1/teams/:team_name/pipelines/:pipeline_name/resources/:resource_name/unpin\", Method: \"PUT\", Name: UnpinResource},\n\t\n{Path: \"/api/v1/teams/:team_name/artifacts\", Method: \"POST\", Name: CreateArtifact},\n```\n\n### Steps to reproduce\n\n1. Set up a Concourse deployment with team 1 (with pipeline 1) and team 2. User is in team 2 but not team 1.\n2. Login as user to team 2.\n```\nfly -t ci login -n team2 -u user -p password\n```\n3. Try pausing pipeline 1 in team 1 using fly. Verify the command output is `pipeline \u0027pipeline1\u0027 not found`.\n```\nfly -t ci pause-pipeline -p pipeline1\n```\n\n\n4. Send a customized request through `fly curl` command intend to pause pipeline 1 again. \n```\nfly -t ci curl /api/v1/teams/team1/pipelines/pipeline1/pause -- -X PUT -d \":team_name=team2\" -H \"Content-type: application/x-www-form-urlencoded\"\n```\n5. pipeline 1 in team 1 will be paused.\n\nIn step 4, the parameter pollution would allow an user from any team to pause a pipeline that belongs to other team.\n\n### Patches\nConcourse [v6.7.9](https://github.com/concourse/concourse/releases/tag/v6.7.9) and [v7.8.3](https://github.com/concourse/concourse/releases/tag/v7.8.3) were both released with a fix on October 12, 2022.\n\nInstead of using [`FormValue`](https://pkg.go.dev/net/http#Request.FormValue) to parse team_name in the request, where allows body parameters to take precedence over URL query string values, both patch versions are now using `URL.Query().Get()` over multiple scope handlers to prevent the parameter pollution.\n\n### Workarounds\nNo known workarounds for existing versions.\n\n### References\n * https://github.com/concourse/concourse/pull/8566: PR with the fix\n\n### For more information\nIf you have any questions or comments about this advisory, you may reach us privately at [security@concourse-ci.org](mailto:security@concourse-ci.org).",
"id": "GHSA-5jp2-vwrj-99rf",
"modified": "2025-04-16T16:08:47Z",
"published": "2022-10-19T20:26:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/concourse/concourse/security/advisories/GHSA-5jp2-vwrj-99rf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31683"
},
{
"type": "WEB",
"url": "https://github.com/concourse/concourse/pull/8566"
},
{
"type": "WEB",
"url": "https://github.com/concourse/concourse/pull/8580"
},
{
"type": "WEB",
"url": "https://github.com/concourse/concourse/commit/57e06711b0d861775a5a6bd078a34abeb0e2638e"
},
{
"type": "WEB",
"url": "https://github.com/concourse/concourse/commit/ba885834d9bcbb9d1ccb9964faa7af0e78a72205"
},
{
"type": "PACKAGE",
"url": "https://github.com/concourse/concourse"
},
{
"type": "WEB",
"url": "https://github.com/concourse/concourse/releases/tag/v6.7.9"
},
{
"type": "WEB",
"url": "https://github.com/concourse/concourse/releases/tag/v7.8.3"
}
],
"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": "Team scope authorization bypass when Post/Put request with :team_name in body, allows HTTP parameter pollution "
}
GHSA-5JRM-J79M-QQVM
Vulnerability from github – Published: 2023-05-04 21:30 – Updated: 2024-04-04 03:49Insecure permissions in the updateUserInfo function of newbee-mall before commit 1f2c2dfy allows attackers to obtain user account information.
{
"affected": [],
"aliases": [
"CVE-2023-30216"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-04T21:15:11Z",
"severity": "MODERATE"
},
"details": "Insecure permissions in the updateUserInfo function of newbee-mall before commit 1f2c2dfy allows attackers to obtain user account information.",
"id": "GHSA-5jrm-j79m-qqvm",
"modified": "2024-04-04T03:49:02Z",
"published": "2023-05-04T21:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30216"
},
{
"type": "WEB",
"url": "https://github.com/newbee-ltd/newbee-mall/issues/76"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-5JVJ-HXMH-6H6J
Vulnerability from github – Published: 2026-03-29 15:46 – Updated: 2026-04-10 17:26Summary
Gateway HTTP Session History Route Bypasses Operator Read Scope
Affected Packages / Versions
- Package:
openclaw - Affected versions:
<= 2026.3.24 - First patched version:
2026.3.25 - Latest published npm version at verification time:
2026.3.24
Details
The HTTP /sessions/:sessionKey/history route previously authenticated bearer tokens but skipped the same operator.read check used by chat.history over WebSocket. Commit 1c45123231516fa50f8cf8522ba5ff2fb2ca7aea makes HTTP callers declare operator scopes and rejects history reads that do not include operator.read.
Verified vulnerable on tag v2026.3.24 and fixed on main by commit 1c45123231516fa50f8cf8522ba5ff2fb2ca7aea.
Fix Commit(s)
1c45123231516fa50f8cf8522ba5ff2fb2ca7aea
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2026.3.24"
},
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.3.25"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35657"
],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-29T15:46:40Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nGateway HTTP Session History Route Bypasses Operator Read Scope\n\n## Affected Packages / Versions\n\n- Package: `openclaw`\n- Affected versions: `\u003c= 2026.3.24`\n- First patched version: `2026.3.25`\n- Latest published npm version at verification time: `2026.3.24`\n\n## Details\n\nThe HTTP `/sessions/:sessionKey/history` route previously authenticated bearer tokens but skipped the same `operator.read` check used by `chat.history` over WebSocket. Commit `1c45123231516fa50f8cf8522ba5ff2fb2ca7aea` makes HTTP callers declare operator scopes and rejects history reads that do not include `operator.read`.\n\nVerified vulnerable on tag `v2026.3.24` and fixed on `main` by commit `1c45123231516fa50f8cf8522ba5ff2fb2ca7aea`.\n\n## Fix Commit(s)\n\n- `1c45123231516fa50f8cf8522ba5ff2fb2ca7aea`",
"id": "GHSA-5jvj-hxmh-6h6j",
"modified": "2026-04-10T17:26:09Z",
"published": "2026-03-29T15:46:40Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-5jvj-hxmh-6h6j"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/1c45123231516fa50f8cf8522ba5ff2fb2ca7aea"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
}
],
"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": "OpenClaw: Gateway HTTP Session History Route Bypasses Operator Read Scope"
}
GHSA-5JX9-W35F-VP65
Vulnerability from github – Published: 2026-05-29 22:51 – Updated: 2026-05-29 22:51Summary
Type: Insecure Direct Object Reference. Five label endpoints — PATCH /workspaces/{workspace_id}/labels/{label_id}, DELETE .../labels/{label_id}, POST .../issues/{issue_id}/labels/{label_id}, DELETE .../issues/{issue_id}/labels/{label_id}, GET .../issues/{issue_id}/labels — gate access on require_workspace_member(workspace_id) only and pass URL-supplied label_id and issue_id straight through to LabelService without verifying either belongs to the workspace.
File: src/praisonai-platform/praisonai_platform/services/label_service.py, lines 35-100; route handlers at src/praisonai-platform/praisonai_platform/api/routes/labels.py, lines 42-106.
Root cause: identical pattern to the agent / issue / project / comment IDORs in this codebase: the route's workspace_id is used as a membership predicate but never threaded through to the service layer. LabelService.get(label_id) runs session.get(IssueLabel, label_id) with no workspace filter; update/delete inherit the gap; add_to_issue(issue_id, label_id) and remove_from_issue(issue_id, label_id) write/delete association rows without verifying either ID belongs to the membership-checked workspace; list_for_issue(issue_id) reads them.
Affected Code
File 1: src/praisonai-platform/praisonai_platform/services/label_service.py, lines 35-100.
class LabelService:
...
async def get(self, label_id: str) -> Optional[IssueLabel]:
return await self._session.get(IssueLabel, label_id) # <-- BUG: no workspace_id predicate
async def update(
self,
label_id: str,
...
) -> Optional[IssueLabel]:
label = await self.get(label_id) # <-- inherits the gap
...
async def delete(self, label_id: str) -> bool:
label = await self.get(label_id) # <-- inherits the gap
...
async def add_to_issue(self, issue_id: str, label_id: str) -> None:
# writes a row in issue_label association table; no workspace check on either id
async def remove_from_issue(self, issue_id: str, label_id: str) -> None:
# deletes from association table; no workspace check on either id
async def list_for_issue(self, issue_id: str) -> list[IssueLabel]:
# reads from association table; no workspace check on issue_id
File 2: src/praisonai-platform/praisonai_platform/api/routes/labels.py, lines 42-106.
@router.patch("/labels/{label_id}", response_model=LabelResponse)
async def update_label(workspace_id: str, label_id: str, body: LabelUpdate, ...):
svc = LabelService(session)
label = await svc.update(label_id, body.name, body.color) # <-- writes any label in the DB
...
@router.delete("/labels/{label_id}", ...)
async def delete_label(workspace_id: str, label_id: str, ...):
deleted = await svc.delete(label_id) # <-- deletes any label in the DB
...
@router.post("/issues/{issue_id}/labels/{label_id}", ...)
async def add_label_to_issue(workspace_id: str, issue_id: str, label_id: str, ...):
await svc.add_to_issue(issue_id, label_id) # <-- attaches any label to any issue cross-workspace
@router.delete("/issues/{issue_id}/labels/{label_id}", ...)
async def remove_label_from_issue(workspace_id: str, issue_id: str, label_id: str, ...):
await svc.remove_from_issue(issue_id, label_id) # <-- detaches any label from any issue cross-workspace
@router.get("/issues/{issue_id}/labels", ...)
async def list_issue_labels(workspace_id: str, issue_id: str, ...):
labels = await svc.list_for_issue(issue_id) # <-- reads label assignments for any issue
Why it's wrong: the workspace_id URL segment is treated as a UI hint; the actual label_id and issue_id lookups query the database without a workspace constraint. The MemberService in this same codebase uses a composite key correctly; the label service does not. The add_to_issue and remove_from_issue paths are particularly nasty because they touch two unverified IDs at once: an attacker can attach a foreign workspace's label to a foreign workspace's issue (or detach the legitimate labels), corrupting both sides of an association the attacker has no business touching.
Exploit Chain
- Attacker registers a workspace
W_attacker(member) and harvests a foreign-workspacelabel_idL_Tand a foreign-workspaceissue_idI_T. Both leak vialist_labelsresponses (which include label IDs — but only forW_attacker; for the target the IDs come from issue records that include label associations, activity feeds, exported dumps, error messages). State: attacker holdsL_TandI_T. - Attacker authenticates and sends
PATCH /workspaces/W_attacker/labels/L_Twith{"name": "<deleted>", "color": "#000000"}.require_workspace_member(W_attacker, attacker)passes.LabelService.update(L_T, ...)loads the foreign label and renames it. State: every issue across the foreign workspace that bears this label now displays the attacker-chosen name and colour. - Attacker sends
DELETE /workspaces/W_attacker/labels/L_T.LabelService.delete(L_T)deletes the foreign label, dropping every issue-label association row that referenced it (cascade or orphan, depending on schema). State: foreign workspace's labels are gone or corrupted. - Attacker sends
POST /workspaces/W_attacker/issues/I_T/labels/L_T2to attach foreign labelL_T2to foreign issueI_T.LabelService.add_to_issue(I_T, L_T2)writes the association row regardless of either ID's workspace. State: the foreign issue now carries an arbitrary attacker-chosen label, which surfaces in every filter/search/board view in the foreign workspace's UI. - Attacker sends
DELETE /workspaces/W_attacker/issues/I_T/labels/L_legitto strip the legitimate label off the foreign issue. State: triagers can no longer find the issue via label filters. - Attacker sends
GET /workspaces/W_attacker/issues/I_T/labelsto read the current label set on any foreign issue. State: the attacker fingerprints the foreign workspace's triage taxonomy. - Final state: with one workspace-member token plus harvested foreign IDs, the attacker rewrites and deletes other workspaces' labels, attaches/detaches arbitrary labels on other workspaces' issues, and reads triage state across the deployment.
Security Impact
Severity: sec-moderate. CVSS 6.3: network attack, low complexity, low privileges, no user interaction, scope unchanged. The integrity damage is high (rename/delete of foreign labels is permanent and silent; cross-workspace label-attachment corrupts UI filters), confidentiality is low (label names are not the most sensitive field but do leak triage taxonomy), availability low (foreign workspaces may lose triage visibility into their own issues until the labels are restored).
Attacker capability: rename and delete any label in the multi-tenant deployment; attach any label to any issue; detach any label from any issue; list label assignments for any issue. Combined with the companion IssueService IDOR (separate advisory), the attacker can also modify the underlying issue, making the cross-workspace tampering very difficult to detect.
Preconditions: praisonai-platform is deployed multi-tenant; the attacker has any membership token; target IDs are known or guessable.
Differential: source-inspection-verified end-to-end. The asymmetry between LabelService.list_for_workspace(workspace_id) (correctly workspace-scoped) and LabelService.get(label_id) / add_to_issue(issue_id, label_id) (no workspace check) confirms the gap. With the suggested fix below, label and issue IDs that do not belong to the membership-checked workspace return 404, and the attacker cannot touch them.
Suggested Fix
Make every single-row label lookup take the workspace predicate; verify both issue_id and label_id belong to workspace_id for the association routes.
--- a/src/praisonai-platform/praisonai_platform/services/label_service.py
+++ b/src/praisonai-platform/praisonai_platform/services/label_service.py
@@ -33,7 +33,12 @@ class LabelService:
return label
- async def get(self, label_id: str) -> Optional[IssueLabel]:
- return await self._session.get(IssueLabel, label_id)
+ async def get(self, workspace_id: str, label_id: str) -> Optional[IssueLabel]:
+ stmt = select(IssueLabel).where(
+ IssueLabel.id == label_id,
+ IssueLabel.workspace_id == workspace_id,
+ )
+ return (await self._session.execute(stmt)).scalar_one_or_none()
- async def add_to_issue(self, issue_id: str, label_id: str) -> None:
+ async def add_to_issue(self, workspace_id: str, issue_id: str, label_id: str) -> None:
+ # Verify both ids belong to workspace_id before writing the association row.
Then update the route handlers in routes/labels.py to thread workspace_id through every call. The same single-key-lookup pattern is filed separately for AgentService, IssueService, ProjectService, and CommentService — each is its own exploitable IDOR.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.1.2"
},
"package": {
"ecosystem": "PyPI",
"name": "praisonai-platform"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.1.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-47414"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-29T22:51:07Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\n**Type:** Insecure Direct Object Reference. Five label endpoints \u2014 `PATCH /workspaces/{workspace_id}/labels/{label_id}`, `DELETE .../labels/{label_id}`, `POST .../issues/{issue_id}/labels/{label_id}`, `DELETE .../issues/{issue_id}/labels/{label_id}`, `GET .../issues/{issue_id}/labels` \u2014 gate access on `require_workspace_member(workspace_id)` only and pass URL-supplied `label_id` and `issue_id` straight through to `LabelService` without verifying either belongs to the workspace.\n**File:** `src/praisonai-platform/praisonai_platform/services/label_service.py`, lines 35-100; route handlers at `src/praisonai-platform/praisonai_platform/api/routes/labels.py`, lines 42-106.\n**Root cause:** identical pattern to the agent / issue / project / comment IDORs in this codebase: the route\u0027s `workspace_id` is used as a membership predicate but never threaded through to the service layer. `LabelService.get(label_id)` runs `session.get(IssueLabel, label_id)` with no workspace filter; `update`/`delete` inherit the gap; `add_to_issue(issue_id, label_id)` and `remove_from_issue(issue_id, label_id)` write/delete association rows without verifying either ID belongs to the membership-checked workspace; `list_for_issue(issue_id)` reads them.\n\n## Affected Code\n\n**File 1:** `src/praisonai-platform/praisonai_platform/services/label_service.py`, lines 35-100.\n\n```python\nclass LabelService:\n ...\n\n async def get(self, label_id: str) -\u003e Optional[IssueLabel]:\n return await self._session.get(IssueLabel, label_id) # \u003c-- BUG: no workspace_id predicate\n\n async def update(\n self,\n label_id: str,\n ...\n ) -\u003e Optional[IssueLabel]:\n label = await self.get(label_id) # \u003c-- inherits the gap\n ...\n\n async def delete(self, label_id: str) -\u003e bool:\n label = await self.get(label_id) # \u003c-- inherits the gap\n ...\n\n async def add_to_issue(self, issue_id: str, label_id: str) -\u003e None:\n # writes a row in issue_label association table; no workspace check on either id\n\n async def remove_from_issue(self, issue_id: str, label_id: str) -\u003e None:\n # deletes from association table; no workspace check on either id\n\n async def list_for_issue(self, issue_id: str) -\u003e list[IssueLabel]:\n # reads from association table; no workspace check on issue_id\n```\n\n**File 2:** `src/praisonai-platform/praisonai_platform/api/routes/labels.py`, lines 42-106.\n\n```python\n@router.patch(\"/labels/{label_id}\", response_model=LabelResponse)\nasync def update_label(workspace_id: str, label_id: str, body: LabelUpdate, ...):\n svc = LabelService(session)\n label = await svc.update(label_id, body.name, body.color) # \u003c-- writes any label in the DB\n ...\n\n@router.delete(\"/labels/{label_id}\", ...)\nasync def delete_label(workspace_id: str, label_id: str, ...):\n deleted = await svc.delete(label_id) # \u003c-- deletes any label in the DB\n ...\n\n@router.post(\"/issues/{issue_id}/labels/{label_id}\", ...)\nasync def add_label_to_issue(workspace_id: str, issue_id: str, label_id: str, ...):\n await svc.add_to_issue(issue_id, label_id) # \u003c-- attaches any label to any issue cross-workspace\n\n@router.delete(\"/issues/{issue_id}/labels/{label_id}\", ...)\nasync def remove_label_from_issue(workspace_id: str, issue_id: str, label_id: str, ...):\n await svc.remove_from_issue(issue_id, label_id) # \u003c-- detaches any label from any issue cross-workspace\n\n@router.get(\"/issues/{issue_id}/labels\", ...)\nasync def list_issue_labels(workspace_id: str, issue_id: str, ...):\n labels = await svc.list_for_issue(issue_id) # \u003c-- reads label assignments for any issue\n```\n\n**Why it\u0027s wrong:** the `workspace_id` URL segment is treated as a UI hint; the actual `label_id` and `issue_id` lookups query the database without a workspace constraint. The `MemberService` in this same codebase uses a composite key correctly; the label service does not. The `add_to_issue` and `remove_from_issue` paths are particularly nasty because they touch *two* unverified IDs at once: an attacker can attach a foreign workspace\u0027s label to a foreign workspace\u0027s issue (or detach the legitimate labels), corrupting both sides of an association the attacker has no business touching.\n\n## Exploit Chain\n\n1. Attacker registers a workspace `W_attacker` (member) and harvests a foreign-workspace `label_id` `L_T` and a foreign-workspace `issue_id` `I_T`. Both leak via `list_labels` responses (which include label IDs \u2014 but only for `W_attacker`; for the target the IDs come from issue records that include label associations, activity feeds, exported dumps, error messages). State: attacker holds `L_T` and `I_T`.\n2. Attacker authenticates and sends `PATCH /workspaces/W_attacker/labels/L_T` with `{\"name\": \"\u003cdeleted\u003e\", \"color\": \"#000000\"}`. `require_workspace_member(W_attacker, attacker)` passes. `LabelService.update(L_T, ...)` loads the foreign label and renames it. State: every issue across the foreign workspace that bears this label now displays the attacker-chosen name and colour.\n3. Attacker sends `DELETE /workspaces/W_attacker/labels/L_T`. `LabelService.delete(L_T)` deletes the foreign label, dropping every issue-label association row that referenced it (cascade or orphan, depending on schema). State: foreign workspace\u0027s labels are gone or corrupted.\n4. Attacker sends `POST /workspaces/W_attacker/issues/I_T/labels/L_T2` to attach foreign label `L_T2` to foreign issue `I_T`. `LabelService.add_to_issue(I_T, L_T2)` writes the association row regardless of either ID\u0027s workspace. State: the foreign issue now carries an arbitrary attacker-chosen label, which surfaces in every filter/search/board view in the foreign workspace\u0027s UI.\n5. Attacker sends `DELETE /workspaces/W_attacker/issues/I_T/labels/L_legit` to strip the legitimate label off the foreign issue. State: triagers can no longer find the issue via label filters.\n6. Attacker sends `GET /workspaces/W_attacker/issues/I_T/labels` to read the current label set on any foreign issue. State: the attacker fingerprints the foreign workspace\u0027s triage taxonomy.\n7. Final state: with one workspace-member token plus harvested foreign IDs, the attacker rewrites and deletes other workspaces\u0027 labels, attaches/detaches arbitrary labels on other workspaces\u0027 issues, and reads triage state across the deployment.\n\n## Security Impact\n\n**Severity:** sec-moderate. CVSS 6.3: network attack, low complexity, low privileges, no user interaction, scope unchanged. The integrity damage is high (rename/delete of foreign labels is permanent and silent; cross-workspace label-attachment corrupts UI filters), confidentiality is low (label names are not the most sensitive field but do leak triage taxonomy), availability low (foreign workspaces may lose triage visibility into their own issues until the labels are restored).\n**Attacker capability:** rename and delete any label in the multi-tenant deployment; attach any label to any issue; detach any label from any issue; list label assignments for any issue. Combined with the companion `IssueService` IDOR (separate advisory), the attacker can also modify the underlying issue, making the cross-workspace tampering very difficult to detect.\n**Preconditions:** `praisonai-platform` is deployed multi-tenant; the attacker has any membership token; target IDs are known or guessable.\n**Differential:** source-inspection-verified end-to-end. The asymmetry between `LabelService.list_for_workspace(workspace_id)` (correctly workspace-scoped) and `LabelService.get(label_id) / add_to_issue(issue_id, label_id)` (no workspace check) confirms the gap. With the suggested fix below, label and issue IDs that do not belong to the membership-checked workspace return 404, and the attacker cannot touch them.\n\n## Suggested Fix\n\nMake every single-row label lookup take the workspace predicate; verify both `issue_id` and `label_id` belong to `workspace_id` for the association routes.\n\n```diff\n--- a/src/praisonai-platform/praisonai_platform/services/label_service.py\n+++ b/src/praisonai-platform/praisonai_platform/services/label_service.py\n@@ -33,7 +33,12 @@ class LabelService:\n return label\n\n- async def get(self, label_id: str) -\u003e Optional[IssueLabel]:\n- return await self._session.get(IssueLabel, label_id)\n+ async def get(self, workspace_id: str, label_id: str) -\u003e Optional[IssueLabel]:\n+ stmt = select(IssueLabel).where(\n+ IssueLabel.id == label_id,\n+ IssueLabel.workspace_id == workspace_id,\n+ )\n+ return (await self._session.execute(stmt)).scalar_one_or_none()\n\n- async def add_to_issue(self, issue_id: str, label_id: str) -\u003e None:\n+ async def add_to_issue(self, workspace_id: str, issue_id: str, label_id: str) -\u003e None:\n+ # Verify both ids belong to workspace_id before writing the association row.\n```\n\nThen update the route handlers in `routes/labels.py` to thread `workspace_id` through every call. The same single-key-lookup pattern is filed separately for `AgentService`, `IssueService`, `ProjectService`, and `CommentService` \u2014 each is its own exploitable IDOR.",
"id": "GHSA-5jx9-w35f-vp65",
"modified": "2026-05-29T22:51:07Z",
"published": "2026-05-29T22:51:07Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-5jx9-w35f-vp65"
},
{
"type": "PACKAGE",
"url": "https://github.com/MervinPraison/PraisonAI"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "praisonai-platform: Label endpoints\u0027 unchecked label_id/issue_id enable cross-workspace label IDOR (edit, delete, link)"
}
GHSA-5M2R-V35X-JHHX
Vulnerability from github – Published: 2025-10-27 03:30 – Updated: 2025-11-13 12:31Authorization Bypass Through User-Controlled Key vulnerability in mediavine Create by Mediavine mediavine-create allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Create by Mediavine: from n/a through <= 1.9.14.
{
"affected": [],
"aliases": [
"CVE-2025-62893"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-27T02:15:48Z",
"severity": "HIGH"
},
"details": "Authorization Bypass Through User-Controlled Key vulnerability in mediavine Create by Mediavine mediavine-create allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Create by Mediavine: from n/a through \u003c= 1.9.14.",
"id": "GHSA-5m2r-v35x-jhhx",
"modified": "2025-11-13T12:31:28Z",
"published": "2025-10-27T03:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62893"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/mediavine-create/vulnerability/wordpress-create-by-mediavine-plugin-1-9-14-insecure-direct-object-references-idor-vulnerability"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/mediavine-create/vulnerability/wordpress-create-by-mediavine-plugin-1-9-14-insecure-direct-object-references-idor-vulnerability?_s_id=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:N",
"type": "CVSS_V3"
}
]
}
GHSA-5M34-QPJQ-HJHF
Vulnerability from github – Published: 2024-01-17 21:30 – Updated: 2024-01-17 21:30Insecure Direct Object Reference vulnerabilities were discovered in the Avaya Aura Experience Portal Manager which may allow partial information disclosure to an authenticated non-privileged user. Affected versions include 8.0.x and 8.1.x, prior to 8.1.2 patch 0402. Versions prior to 8.0 are end of manufacturer support.
{
"affected": [],
"aliases": [
"CVE-2023-7031"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-17T19:15:08Z",
"severity": "MODERATE"
},
"details": "Insecure Direct Object Reference vulnerabilities were discovered in the Avaya Aura Experience Portal Manager which may allow partial information disclosure to an authenticated non-privileged user. Affected versions include 8.0.x and 8.1.x, prior to 8.1.2 patch 0402. Versions prior to 8.0 are end of manufacturer support.",
"id": "GHSA-5m34-qpjq-hjhf",
"modified": "2024-01-17T21:30:20Z",
"published": "2024-01-17T21:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-7031"
},
{
"type": "WEB",
"url": "https://support.avaya.com/css/public/documents/101088063"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-5MV2-W7GR-RP48
Vulnerability from github – Published: 2023-02-17 12:30 – Updated: 2026-06-01 15:30Improper Input Validation, Authorization Bypass Through User-Controlled Key vulnerability in Kron Tech Single Connect on Windows allows Privilege Abuse. This issue affects Single Connect: 2.16.
{
"affected": [],
"aliases": [
"CVE-2023-0882"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-17T10:15:00Z",
"severity": "HIGH"
},
"details": "Improper Input Validation, Authorization Bypass Through User-Controlled Key vulnerability in Kron Tech Single Connect on Windows allows Privilege Abuse. This issue affects Single Connect: 2.16.",
"id": "GHSA-5mv2-w7gr-rp48",
"modified": "2026-06-01T15:30:28Z",
"published": "2023-02-17T12:30:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0882"
},
{
"type": "WEB",
"url": "https://docs.krontech.com/singleconnect-2-16/update-patch-rdp-proxy-idor-vulnerability"
},
{
"type": "WEB",
"url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-23-0092"
},
{
"type": "WEB",
"url": "https://www.usom.gov.tr/bildirim/tr-23-0092"
}
],
"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-5P7F-47WP-86C5
Vulnerability from github – Published: 2022-05-13 01:50 – Updated: 2022-05-13 01:50In Monstra CMS 3.0.4, an attacker with 'Editor' privileges can change the password of the administrator via an admin/index.php?id=users&action=edit&user_id=1, Insecure Direct Object Reference (IDOR).
{
"affected": [],
"aliases": [
"CVE-2018-16608"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-09-10T13:29:00Z",
"severity": "HIGH"
},
"details": "In Monstra CMS 3.0.4, an attacker with \u0027Editor\u0027 privileges can change the password of the administrator via an admin/index.php?id=users\u0026action=edit\u0026user_id=1, Insecure Direct Object Reference (IDOR).",
"id": "GHSA-5p7f-47wp-86c5",
"modified": "2022-05-13T01:50:23Z",
"published": "2022-05-13T01:50:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-16608"
},
{
"type": "WEB",
"url": "https://github.com/monstra-cms/monstra/issues/453"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-5PGF-H923-M958
Vulnerability from github – Published: 2026-03-24 16:59 – Updated: 2026-03-25 21:00Summary
An unauthenticated user can call assets/generate-transform with a private assetId, receive a valid transform URL, and fetch transformed image bytes.
The endpoint is anonymous and does not enforce per-asset authorization before returning the transform URL.
Details
Root cause: - Anonymous endpoint accepts user-controlled asset reference. - It creates and returns a transform URL for that asset without checking access rights. - If the transform output is reachable, guest users can read content derived from private assets.
Who is impacted:
- Installations where private source assets can be transformed and transform URLs are reachable.
Security consequence:
- Anonymous users can obtain content derived from private assets without authentication.
Resources
https://github.com/craftcms/cms/commit/7290d91639e
{
"affected": [
{
"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"
}
]
},
{
"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"
}
]
}
],
"aliases": [
"CVE-2026-33160"
],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-24T16:59:58Z",
"nvd_published_at": "2026-03-24T18:16:10Z",
"severity": "LOW"
},
"details": "### Summary\n\nAn unauthenticated user can call `assets/generate-transform` with a private `assetId`, receive a valid transform URL, and fetch transformed image bytes.\n\nThe endpoint is anonymous and does not enforce per-asset authorization before returning the transform URL.\n\n### Details\n\nRoot cause:\n- Anonymous endpoint accepts user-controlled asset reference.\n- It creates and returns a transform URL for that asset without checking access rights.\n- If the transform output is reachable, guest users can read content derived from private assets.\n\nWho is impacted:\n\n- Installations where private source assets can be transformed and transform URLs are reachable.\n\nSecurity consequence:\n\n - Anonymous users can obtain content derived from private assets without authentication.\n\n### Resources\n\nhttps://github.com/craftcms/cms/commit/7290d91639e",
"id": "GHSA-5pgf-h923-m958",
"modified": "2026-03-25T21:00:12Z",
"published": "2026-03-24T16:59:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/craftcms/cms/security/advisories/GHSA-5pgf-h923-m958"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33160"
},
{
"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:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "Craft CMS may expose private assets through anonymous \"generate transform\" calls via transform URL"
}
GHSA-5PPV-GW49-FRMX
Vulnerability from github – Published: 2026-03-11 06:31 – Updated: 2026-03-11 15:31The Gutena Forms WordPress plugin before 1.6.1 does not validate option to be updated, which could allow contributors and above role to update arbitrary boolean and array options (such as users_can_register).
{
"affected": [],
"aliases": [
"CVE-2026-1753"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-11T06:17:13Z",
"severity": "MODERATE"
},
"details": "The Gutena Forms WordPress plugin before 1.6.1 does not validate option to be updated, which could allow contributors and above role to update arbitrary boolean and array options (such as users_can_register).",
"id": "GHSA-5ppv-gw49-frmx",
"modified": "2026-03-11T15:31:51Z",
"published": "2026-03-11T06:31:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1753"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/c42dbab9-b729-4748-88e5-0bd2f6d66e3d"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:N/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.