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
5658 vulnerabilities reference this CWE, most recent first.
GHSA-465F-7H5Q-H9G2
Vulnerability from github – Published: 2022-11-29 00:30 – Updated: 2022-12-02 00:30The user_id and device_id on the Ourphoto App version 1.4.1 /device/* end-points both suffer from insecure direct object reference vulnerabilities. Other end-users user_id and device_id values can be enumerated by incrementing or decrementing id numbers. The impact of this vulnerability allows an attacker to discover sensitive information such as end-user email addresses, and their unique frame_token value of all other Ourphoto App end-users.
{
"affected": [],
"aliases": [
"CVE-2022-24187"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-11-28T22:15:00Z",
"severity": "HIGH"
},
"details": "The user_id and device_id on the Ourphoto App version 1.4.1 /device/* end-points both suffer from insecure direct object reference vulnerabilities. Other end-users user_id and device_id values can be enumerated by incrementing or decrementing id numbers. The impact of this vulnerability allows an attacker to discover sensitive information such as end-user email addresses, and their unique frame_token value of all other Ourphoto App end-users.",
"id": "GHSA-465f-7h5q-h9g2",
"modified": "2022-12-02T00:30:25Z",
"published": "2022-11-29T00:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24187"
},
{
"type": "WEB",
"url": "https://apps.apple.com/us/app/ourphoto-keep-our-memories/id1476241568"
},
{
"type": "WEB",
"url": "https://www.scrawledsecurityblog.com/2022/11/automating-unsolicited-richard-pics.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4672-HWV6-GQ62
Vulnerability from github – Published: 2026-10-02 22:42 – Updated: 2026-10-02 22:42Summary
Trigger.dev isolates each project into multiple environments (dev, staging, prod, and per-PR preview branches), each with its own secret API key — the environment is a trust boundary (a dev/preview/CI key is lower-trust than a prod key). Most API routes enforce this by scoping resource lookups to the authenticated key's environment (where: { friendlyId, runtimeEnvironmentId: auth.environment.id }).
The deployment cancel path does not. DeploymentService.getDeployment() scopes the lookup by projectId only — never environmentId — so a secret key for any environment in a project can cancel a deployment belonging to any other environment of the same project, including production. The deployment GET route, by contrast, is env-scoped — so the same key that is 404'd when trying to read a prod deployment can nonetheless cancel it. That asymmetry is the bug.
Affected
apps/webapp, HEAD 5d99457 (current main). Affects self-hosted and cloud.
Root cause
apps/webapp/app/routes/api.v1.deployments.$deploymentId.cancel.ts authenticates to an environment and calls deploymentService.cancelDeployment(authenticatedEnv, deploymentId, ...).
apps/webapp/app/v3/services/deployment.server.ts:
public cancelDeployment(authenticatedEnv: Pick<AuthenticatedEnvironment,"projectId">, friendlyId, ...) {
return this.getDeployment(authenticatedEnv.projectId, friendlyId) // projectId only
.andThen(validateDeployment) // rejects only FINAL statuses
.andThen(cancelDeployment); // updateMany -> status CANCELED
}
private getDeployment(projectId: string, friendlyId: string) {
return this._prisma.workerDeployment.findFirst({
where: { friendlyId, projectId }, // <-- NO environmentId filter
});
}
cancelDeployment accepts authenticatedEnv but its type is literally Pick<AuthenticatedEnvironment,"projectId"> — it discards the environment identity. validateDeployment blocks only FINAL_DEPLOYMENT_STATUSES, so any in-progress deployment (PENDING/INSTALLING/BUILDING/DEPLOYING) is cancellable.
Contrast — the correctly env-scoped sibling api.v1.deployments.$deploymentId.ts (GET):
const deployment = await prisma.workerDeployment.findFirst({
where: { friendlyId: deploymentId, environmentId: authenticatedEnv.id }, // env-scoped
});
Reads are env-scoped; the cancel mutation is not. The same getDeployment(authenticatedEnv.projectId, …) helper also backs the deployment progress methods (deployment.server.ts:172,329), so the projectId-only scope is a small class.
Runtime PoC (proven on the self-host stack)
Seeded one project with a prod env (key tr_prod_…) and a dev env (key tr_dev_…) and one WorkerDeployment (deployment_pocvictim, status DEPLOYING) in the prod env. As the dev key:
status BEFORE : DEPLOYING
GET /api/v1/deployments/deployment_pocvictim (dev key) -> 404 (env-scoped read DENIES it)
POST /api/v1/deployments/deployment_pocvictim/cancel (dev key) -> 204
status AFTER : CANCELED (prod deploy canceled by the dev key)
CONTROL: same cancel with a DIFFERENT project's key -> 404 (projectId scope blocks cross-project)
The dev key cannot read the prod deployment (404) yet cancels it (204 → CANCELED); a different project's key is correctly 404'd — so the gap is precisely cross-environment within a project.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.5.5"
},
"package": {
"ecosystem": "npm",
"name": "trigger.dev"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.5.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-02T22:42:40Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nTrigger.dev isolates each project into multiple **environments** (`dev`, `staging`, `prod`, and per-PR `preview` branches), each with its **own secret API key** \u2014 the environment is a trust boundary (a `dev`/preview/CI key is lower-trust than a `prod` key). Most API routes enforce this by scoping resource lookups to the authenticated key\u0027s environment (`where: { friendlyId, runtimeEnvironmentId: auth.environment.id }`).\n\nThe deployment **cancel** path does not. `DeploymentService.getDeployment()` scopes the lookup by **`projectId` only** \u2014 never `environmentId` \u2014 so a secret key for *any* environment in a project can cancel a deployment belonging to *any other* environment of the same project, including **production**. The deployment **GET** route, by contrast, *is* env-scoped \u2014 so the same key that is **404\u0027d when trying to read** a prod deployment can nonetheless **cancel** it. That asymmetry is the bug.\n\n### Affected\n\n`apps/webapp`, HEAD `5d99457` (current `main`). Affects self-hosted and cloud.\n\n### Root cause\n\n`apps/webapp/app/routes/api.v1.deployments.$deploymentId.cancel.ts` authenticates to an environment and calls `deploymentService.cancelDeployment(authenticatedEnv, deploymentId, ...)`.\n\n`apps/webapp/app/v3/services/deployment.server.ts`:\n```ts\npublic cancelDeployment(authenticatedEnv: Pick\u003cAuthenticatedEnvironment,\"projectId\"\u003e, friendlyId, ...) {\n return this.getDeployment(authenticatedEnv.projectId, friendlyId) // projectId only\n .andThen(validateDeployment) // rejects only FINAL statuses\n .andThen(cancelDeployment); // updateMany -\u003e status CANCELED\n}\nprivate getDeployment(projectId: string, friendlyId: string) {\n return this._prisma.workerDeployment.findFirst({\n where: { friendlyId, projectId }, // \u003c-- NO environmentId filter\n });\n}\n```\n\n`cancelDeployment` accepts `authenticatedEnv` but its type is literally `Pick\u003cAuthenticatedEnvironment,\"projectId\"\u003e` \u2014 it discards the environment identity. `validateDeployment` blocks only `FINAL_DEPLOYMENT_STATUSES`, so any in-progress deployment (`PENDING`/`INSTALLING`/`BUILDING`/`DEPLOYING`) is cancellable.\n\n**Contrast \u2014 the correctly env-scoped sibling** `api.v1.deployments.$deploymentId.ts` (GET):\n```ts\nconst deployment = await prisma.workerDeployment.findFirst({\n where: { friendlyId: deploymentId, environmentId: authenticatedEnv.id }, // env-scoped\n});\n```\nReads are env-scoped; the cancel mutation is not. The same `getDeployment(authenticatedEnv.projectId, \u2026)` helper also backs the deployment *progress* methods (`deployment.server.ts:172,329`), so the projectId-only scope is a small class.\n\n### Runtime PoC (proven on the self-host stack)\n\nSeeded one project with a `prod` env (key `tr_prod_\u2026`) and a `dev` env (key `tr_dev_\u2026`) and one `WorkerDeployment` (`deployment_pocvictim`, status `DEPLOYING`) in the **prod** env. As the **dev** key:\n\n```\nstatus BEFORE : DEPLOYING\nGET /api/v1/deployments/deployment_pocvictim (dev key) -\u003e 404 (env-scoped read DENIES it)\nPOST /api/v1/deployments/deployment_pocvictim/cancel (dev key) -\u003e 204\nstatus AFTER : CANCELED (prod deploy canceled by the dev key)\nCONTROL: same cancel with a DIFFERENT project\u0027s key -\u003e 404 (projectId scope blocks cross-project)\n```\n\nThe dev key cannot *read* the prod deployment (404) yet *cancels* it (204 \u2192 CANCELED); a different project\u0027s key is correctly 404\u0027d \u2014 so the gap is precisely cross-environment within a project.",
"id": "GHSA-4672-hwv6-gq62",
"modified": "2026-10-02T22:42:40Z",
"published": "2026-10-02T22:42:40Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/triggerdotdev/trigger.dev/security/advisories/GHSA-4672-hwv6-gq62"
},
{
"type": "WEB",
"url": "https://github.com/triggerdotdev/trigger.dev/pull/4316"
},
{
"type": "WEB",
"url": "https://github.com/triggerdotdev/trigger.dev/commit/6997aeb05e27d2db47f9eda01fdc8a17c81a1ae0"
},
{
"type": "PACKAGE",
"url": "https://github.com/triggerdotdev/trigger.dev"
},
{
"type": "WEB",
"url": "https://github.com/triggerdotdev/trigger.dev/releases/tag/v4.5.6"
}
],
"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:L",
"type": "CVSS_V3"
}
],
"summary": "Trigger.dev: Cross-environment deployment cancel"
}
GHSA-468H-QQC5-V34C
Vulnerability from github – Published: 2022-04-08 00:00 – Updated: 2022-04-16 00:01Insecure direct object reference in SUNNY TRIPOWER 5.0 Firmware version 3.10.16.R leads to unauthorized user groups accessing due to insecure cookie handling.
{
"affected": [],
"aliases": [
"CVE-2021-46416"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-07T11:15:00Z",
"severity": "HIGH"
},
"details": "Insecure direct object reference in SUNNY TRIPOWER 5.0 Firmware version 3.10.16.R leads to unauthorized user groups accessing due to insecure cookie handling.",
"id": "GHSA-468h-qqc5-v34c",
"modified": "2022-04-16T00:01:30Z",
"published": "2022-04-08T00:00:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46416"
},
{
"type": "WEB",
"url": "https://drive.google.com/drive/folders/1BPULhDC_g__seH_VnQlVtkrKdOLkXdzV?usp=sharing"
},
{
"type": "WEB",
"url": "https://www.sma.de/en/products/solarinverters/sunny-tripower-30-40-50-60.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/166670/SAM-SUNNY-TRIPOWER-5.0-Insecure-Direct-Object-Reference.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-46CX-8JFV-GCG7
Vulnerability from github – Published: 2026-10-30 18:32 – Updated: 2026-10-30 18:32abp-next-admin 10.4.0 through 10.7.0 contains a cross-tenant authorization bypass in the BlobManagement download-by-name endpoint, letting authenticated users read other tenants' files. Attackers supply a victim tenantId in the request path, causing DownloadByNameAsync to switch tenant context and return blobs stored by that tenant.
{
"affected": [],
"aliases": [
"CVE-2026-119708"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-30T16:17:53Z",
"severity": "HIGH"
},
"details": "abp-next-admin 10.4.0 through 10.7.0 contains a cross-tenant authorization bypass in the BlobManagement download-by-name endpoint, letting authenticated users read other tenants\u0027 files. Attackers supply a victim tenantId in the request path, causing DownloadByNameAsync to switch tenant context and return blobs stored by that tenant.",
"id": "GHSA-46cx-8jfv-gcg7",
"modified": "2026-10-30T18:32:39Z",
"published": "2026-10-30T18:32:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-119708"
},
{
"type": "WEB",
"url": "https://github.com/colinin/abp-next-admin/issues/1628"
},
{
"type": "WEB",
"url": "https://github.com/colinin/abp-next-admin/pull/1633"
},
{
"type": "WEB",
"url": "https://github.com/colinin/abp-next-admin/commit/3ea383093d51b18984652fc9b2d3dcc779a372ee"
},
{
"type": "WEB",
"url": "https://github.com/colinin/abp-next-admin/commit/fc5e6d5a8a11a65e06fe001fe4a55e414956fc0c"
},
{
"type": "WEB",
"url": "https://github.com/colinin/abp-next-admin"
},
{
"type": "WEB",
"url": "https://github.com/colinin/abp-next-admin/blob/10.7.0/aspnet-core/modules/blob-management/LINGYUN.Abp.BlobManagement.Application/LINGYUN/Abp/BlobManagement/BlobAppService.cs#L60-L68"
},
{
"type": "WEB",
"url": "https://hackmd.io/@hieuPenguinnn/abp-next-admin-blob-download-by-name-cross-tenant-idor"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/abp-next-admin-10.4.0-through-10.7.0-cross-tenant-file-disclosure-via-blob-download-by-name"
}
],
"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:N",
"type": "CVSS_V3"
},
{
"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: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-46GH-PG58-2QQH
Vulnerability from github – Published: 2026-10-16 00:31 – Updated: 2026-10-16 00:31Dokploy through 0.30.8 contains a cross-organization authorization bypass in the port tRPC router that allows authenticated owners or admins of any organization to manage other tenants' ports because the target application's organization is never verified. Attackers supplying a known portId or applicationId to port.create, port.one, port.update, or port.delete can read, modify, delete, or add port mappings, disrupting how victim services are published.
{
"affected": [],
"aliases": [
"CVE-2026-111331"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-15T22:19:31Z",
"severity": "MODERATE"
},
"details": "Dokploy through 0.30.8 contains a cross-organization authorization bypass in the port tRPC router that allows authenticated owners or admins of any organization to manage other tenants\u0027 ports because the target application\u0027s organization is never verified. Attackers supplying a known portId or applicationId to port.create, port.one, port.update, or port.delete can read, modify, delete, or add port mappings, disrupting how victim services are published.",
"id": "GHSA-46gh-pg58-2qqh",
"modified": "2026-10-16T00:31:56Z",
"published": "2026-10-16T00:31:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-111331"
},
{
"type": "WEB",
"url": "https://github.com/Dokploy/dokploy"
},
{
"type": "WEB",
"url": "https://github.com/Dokploy/dokploy/blob/v0.30.8/apps/dokploy/server/api/routers/port.ts#L17-L113"
},
{
"type": "WEB",
"url": "https://github.com/Dokploy/dokploy/blob/v0.30.8/packages/server/src/services/permission.ts#L244-L261"
},
{
"type": "WEB",
"url": "https://hackmd.io/@hieuPenguinnn/dokploy-port-router-cross-org-idor"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/dokploy-through-0.30.8-cross-organization-authorization-bypass-via-port-trpc-router"
}
],
"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:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/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-46MW-PP5W-GFF7
Vulnerability from github – Published: 2025-04-15 21:31 – Updated: 2025-04-15 21:31An unauthenticated attacker can get users' emails by knowing usernames. A password reset email will be sent in response to this unsolicited request.
{
"affected": [],
"aliases": [
"CVE-2025-27568"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-15T21:15:55Z",
"severity": "MODERATE"
},
"details": "An unauthenticated attacker can get users\u0027 emails by knowing usernames. A password reset email will be sent in response to this unsolicited request.",
"id": "GHSA-46mw-pp5w-gff7",
"modified": "2025-04-15T21:31:45Z",
"published": "2025-04-15T21:31:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27568"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-105-04"
}
],
"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"
},
{
"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: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-46R4-Q7WV-32FC
Vulnerability from github – Published: 2026-10-21 16:29 – Updated: 2026-10-21 16:29Summary
The OpenChoreo API server authorized PUT .../workflowruns/{runName} against ownership metadata taken from the request body, while the object it actually mutated was selected by the URL path. Nothing forced the two to agree.
A WorkflowRun's membership in a project and component is carried entirely by its openchoreo.dev/project and openchoreo.dev/component labels. Because the workflowrun:update check read those labels from the submitted object rather than the stored one, a caller holding workflowrun:update on one component could name a run belonging to a different project or component in the URL, supply labels for the component they legitimately control, pass the check, and have the unrelated run rewritten with their own ownership labels.
The namespace is taken from the URL and feeds both the authorization check and the Kubernetes read, so it cannot diverge. This is cross-project and cross-component escalation inside a single namespace, not a cross-tenant issue.
Impact
Rewriting the ownership labels transfers authority over the run. Every other WorkflowRun check (view, logs, events, status, delete, list) derives its scope from the stored labels, so once the write lands the policy engine legitimately grants the attacker access to an object they never had rights to. They can then:
- Read the victim's build logs. These stream raw pod logs from the workflow plane and routinely carry source paths, registry destinations, and credentials a build step echoed by accident.
- Read the run's Kubernetes events.
- Delete the run.
So the primary impact is confidentiality and availability, not only integrity. On the integrity side, spec.workflow.parameters can be overwritten on a pending run, and manipulating the two ownership labels can either wedge the run in a permanent ComponentValidationFailed condition or downgrade it to a standalone run that skips component validation.
Exploitation requires an authenticated caller with an AuthzRoleBinding or ClusterAuthzRoleBinding granting workflowrun:update at project or component scope in the victim's namespace, plus knowledge of the target run's name. An anonymous caller cannot reach this.
Patches
The authorization check now loads the stored WorkflowRun and derives every ownership attribute from it instead of from the request body. Separately, the openchoreo.dev/project and openchoreo.dev/component labels are now immutable on update, so an authorized caller cannot hand their own run to another project either.
| Line | Affected | Fixed in |
|---|---|---|
| 1.0.x | 1.0.0 through 1.0.5 | 1.0.6 |
| 1.1.x | 1.1.0 through 1.1.6 | 1.1.7 |
| 1.2.x | 1.2.0 through 1.2.4 | 1.2.5 |
Upgrade to the patched release on your line. No configuration change is needed after upgrading.
Workarounds
If you cannot upgrade immediately, restrict who holds workflowrun:update.
Audit your AuthzRole and ClusterAuthzRole definitions for that action and remove it from any role granted to principals you would not trust with write access to every workflow run in the namespace. Among the roles shipped with OpenChoreo, only the system role workload-publisher lists workflowrun:update explicitly, and admin holds it through its * wildcard. Custom roles in your own values file may also include it, so check those.
Treat any credential bound to workload-publisher as privileged. CI systems are the usual holder, and a leaked CI token is enough to run this.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/openchoreo/openchoreo"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "1.0.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/openchoreo/openchoreo"
},
"ranges": [
{
"events": [
{
"introduced": "1.1.0"
},
{
"fixed": "1.1.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/openchoreo/openchoreo"
},
"ranges": [
{
"events": [
{
"introduced": "1.2.0"
},
{
"fixed": "1.2.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-113727"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-21T16:29:53Z",
"nvd_published_at": "2026-10-20T22:19:29Z",
"severity": "HIGH"
},
"details": "## Summary\n\nThe OpenChoreo API server authorized `PUT .../workflowruns/{runName}` against ownership metadata taken from the request body, while the object it actually mutated was selected by the URL path. Nothing forced the two to agree.\n\nA `WorkflowRun`\u0027s membership in a project and component is carried entirely by its `openchoreo.dev/project` and `openchoreo.dev/component` labels. Because the `workflowrun:update` check read those labels from the submitted object rather than the stored one, a caller holding `workflowrun:update` on one component could name a run belonging to a different project or component in the URL, supply labels for the component they legitimately control, pass the check, and have the unrelated run rewritten with their own ownership labels.\n\nThe namespace is taken from the URL and feeds both the authorization check and the Kubernetes read, so it cannot diverge. This is cross-project and cross-component escalation inside a single namespace, not a cross-tenant issue.\n\n## Impact\n\nRewriting the ownership labels transfers authority over the run. Every other WorkflowRun check (view, logs, events, status, delete, list) derives its scope from the stored labels, so once the write lands the policy engine legitimately grants the attacker access to an object they never had rights to. They can then:\n\n- Read the victim\u0027s build logs. These stream raw pod logs from the workflow plane and routinely carry source paths, registry destinations, and credentials a build step echoed by accident.\n- Read the run\u0027s Kubernetes events.\n- Delete the run.\n\nSo the primary impact is confidentiality and availability, not only integrity. On the integrity side, `spec.workflow.parameters` can be overwritten on a pending run, and manipulating the two ownership labels can either wedge the run in a permanent `ComponentValidationFailed` condition or downgrade it to a standalone run that skips component validation.\n\nExploitation requires an authenticated caller with an `AuthzRoleBinding` or `ClusterAuthzRoleBinding` granting `workflowrun:update` at project or component scope in the victim\u0027s namespace, plus knowledge of the target run\u0027s name. An anonymous caller cannot reach this.\n\n## Patches\n\nThe authorization check now loads the stored WorkflowRun and derives every ownership attribute from it instead of from the request body. Separately, the `openchoreo.dev/project` and `openchoreo.dev/component` labels are now immutable on update, so an authorized caller cannot hand their own run to another project either.\n\n| Line | Affected | Fixed in |\n|---|---|---|\n| 1.0.x | 1.0.0 through 1.0.5 | 1.0.6 |\n| 1.1.x | 1.1.0 through 1.1.6 | 1.1.7 |\n| 1.2.x | 1.2.0 through 1.2.4 | 1.2.5 |\n\nUpgrade to the patched release on your line. No configuration change is needed after upgrading.\n\n## Workarounds\n\nIf you cannot upgrade immediately, restrict who holds `workflowrun:update`.\n\nAudit your `AuthzRole` and `ClusterAuthzRole` definitions for that action and remove it from any role granted to principals you would not trust with write access to every workflow run in the namespace. Among the roles shipped with OpenChoreo, only the system role `workload-publisher` lists `workflowrun:update` explicitly, and `admin` holds it through its `*` wildcard. Custom roles in your own values file may also include it, so check those.\n\nTreat any credential bound to `workload-publisher` as privileged. CI systems are the usual holder, and a leaked CI token is enough to run this.",
"id": "GHSA-46r4-q7wv-32fc",
"modified": "2026-10-21T16:29:53Z",
"published": "2026-10-21T16:29:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openchoreo/openchoreo/security/advisories/GHSA-46r4-q7wv-32fc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-113727"
},
{
"type": "WEB",
"url": "https://github.com/openchoreo/openchoreo/pull/4596"
},
{
"type": "WEB",
"url": "https://github.com/openchoreo/openchoreo/pull/4618"
},
{
"type": "WEB",
"url": "https://github.com/openchoreo/openchoreo/pull/4626"
},
{
"type": "WEB",
"url": "https://github.com/openchoreo/openchoreo/pull/4627"
},
{
"type": "WEB",
"url": "https://github.com/openchoreo/openchoreo/commit/0e311468bb704b0dce7753b89c9d0204009285ca"
},
{
"type": "WEB",
"url": "https://github.com/openchoreo/openchoreo/commit/477031c6fece0666f144942fb02c0b579dacc0bb"
},
{
"type": "WEB",
"url": "https://github.com/openchoreo/openchoreo/commit/91e1e868eb8e0e67274109018d00a767b22eda14"
},
{
"type": "WEB",
"url": "https://github.com/openchoreo/openchoreo/commit/d5ed0ef62d9c9af7b05a72aed2bcbc0ac9d45426"
},
{
"type": "PACKAGE",
"url": "https://github.com/openchoreo/openchoreo"
},
{
"type": "WEB",
"url": "https://github.com/openchoreo/openchoreo/releases/tag/v1.0.6"
},
{
"type": "WEB",
"url": "https://github.com/openchoreo/openchoreo/releases/tag/v1.1.7"
},
{
"type": "WEB",
"url": "https://github.com/openchoreo/openchoreo/releases/tag/v1.2.5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "OpenChoreo: Authorization bypass on WorkflowRun update allows cross-project takeover of workflow runs"
}
GHSA-46WG-6RQP-7R32
Vulnerability from github – Published: 2026-04-28 00:31 – Updated: 2026-04-28 00:31A weak key generation vulnerability exists in specific firmware versions of Milesight AIOT cameras allows authorization to be bypassed.
{
"affected": [],
"aliases": [
"CVE-2026-28747"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-27T23:16:02Z",
"severity": "HIGH"
},
"details": "A weak key generation vulnerability exists in specific firmware versions of Milesight AIOT cameras allows authorization to be bypassed.",
"id": "GHSA-46wg-6rqp-7r32",
"modified": "2026-04-28T00:31:40Z",
"published": "2026-04-28T00:31:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28747"
},
{
"type": "WEB",
"url": "https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2026/icsa-26-113-03.json"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-113-03"
},
{
"type": "WEB",
"url": "https://www.milesight.com/support/download/firmware"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/AC:H/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/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-4759-M874-GWP3
Vulnerability from github – Published: 2026-04-09 00:32 – Updated: 2026-04-09 00:32GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.2 before 18.8.9, 18.9 before 18.9.5, and 18.10 before 18.10.3 that could have allowed an authenticated user to access confidential issues assigned to other users via CSV export due to insufficient authorization checks.
{
"affected": [],
"aliases": [
"CVE-2026-2104"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-08T23:16:58Z",
"severity": "MODERATE"
},
"details": "GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.2 before 18.8.9, 18.9 before 18.9.5, and 18.10 before 18.10.3 that could have allowed an authenticated user to access confidential issues assigned to other users via CSV export due to insufficient authorization checks.",
"id": "GHSA-4759-m874-gwp3",
"modified": "2026-04-09T00:32:01Z",
"published": "2026-04-09T00:32:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2104"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/3541476"
},
{
"type": "WEB",
"url": "https://about.gitlab.com/releases/2026/04/08/patch-release-gitlab-18-10-3-released"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/work_items/589021"
}
],
"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-477F-M8HC-8Q86
Vulnerability from github – Published: 2024-10-28 03:30 – Updated: 2024-10-28 03:30The eHRD CTMS from Sunnet has an Insecure Direct Object Reference (IDOR) vulnerability, allowing unauthenticated remote attackers to modify a specific parameter to access arbitrary files uploaded by any user.
{
"affected": [],
"aliases": [
"CVE-2024-10439"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-28T03:15:02Z",
"severity": "MODERATE"
},
"details": "The eHRD CTMS from Sunnet has an Insecure Direct Object Reference (IDOR) vulnerability, allowing unauthenticated remote attackers to modify a specific parameter to access arbitrary files uploaded by any user.",
"id": "GHSA-477f-m8hc-8q86",
"modified": "2024-10-28T03:30:39Z",
"published": "2024-10-28T03:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10439"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/en/cp-139-8167-a2c0d-2.html"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/tw/cp-132-8166-085c4-1.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
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.