GHSA-P5W8-M249-4R4V

Vulnerability from github – Published: 2026-08-04 16:50 – Updated: 2026-08-04 16:50
VLAI
Summary
Flowise: `DELETE /api/v1/chatflows/:id` does not validate resource type, allowing `agentflows:delete` and `chatflows:delete` to delete each other’s flow type
Details

summary:

In Flowise, DELETE /api/v1/chatflows/:id authorizes requests with checkAnyPermission('chatflows:delete,agentflows:delete'). Possession of either permission is sufficient to reach the delete path. The delete logic does not validate the target resource type, allowing a caller with only agentflows:delete to delete a CHATFLOW, and a caller with only chatflows:delete to delete an AGENTFLOW.

details:

The delete route accepts either chatflows:delete or agentflows:delete. The subsequent logic only resolves the target record by id and workspaceId, then deletes by id without checking whether the target resource type matches the granted permission domain.

As a result, there is no binding between permission scope and flow type:

  • agentflows:delete can be used to delete CHATFLOW
  • chatflows:delete can be used to delete AGENTFLOW

This breaks the intended RBAC separation between Chatflows and Agentflows.

impact:

Users authorized to manage only one flow type can delete the other flow type within the same workspace, resulting in unauthorized deletion and configuration loss.

reproduction steps:

  1. Log in as a user who can create API keys.
  2. Create a normal CHATFLOW and record its id.
  3. Create an API key with only agentflows:delete.
  4. Use that API key to send:
curl -i -X DELETE \
  -H 'Authorization: Bearer <agentflows_delete_only_key>' \
  http://localhost:8080/api/v1/chatflows/<chatflow_id>
  1. Observe a 200 OK response, for example:
{"raw":[],"affected":1}
  1. Read the same id again and observe 404 Not Found.
Severity
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.1.2"
      },
      "package": {
        "ecosystem": "npm",
        "name": "flowise"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-69262"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-04T16:50:32Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "# summary:\nIn Flowise, `DELETE /api/v1/chatflows/:id` authorizes requests with `checkAnyPermission(\u0027chatflows:delete,agentflows:delete\u0027)`. Possession of either permission is sufficient to reach the delete path. The delete logic does not validate the target resource `type`, allowing a caller with only `agentflows:delete` to delete a `CHATFLOW`, and a caller with only `chatflows:delete` to delete an `AGENTFLOW`.\n\n# details:\nThe delete route accepts either `chatflows:delete` or `agentflows:delete`. The subsequent logic only resolves the target record by `id` and `workspaceId`, then deletes by `id` without checking whether the target resource type matches the granted permission domain.\n\nAs a result, there is no binding between permission scope and flow type:\n\n- `agentflows:delete` can be used to delete `CHATFLOW`\n- `chatflows:delete` can be used to delete `AGENTFLOW`\n\nThis breaks the intended RBAC separation between Chatflows and Agentflows.\n\n# impact:\nUsers authorized to manage only one flow type can delete the other flow type within the same workspace, resulting in unauthorized deletion and configuration loss.\n\n# reproduction steps:\n\n1. Log in as a user who can create API keys.\n2. Create a normal `CHATFLOW` and record its `id`.\n3. Create an API key with only `agentflows:delete`.\n4. Use that API key to send:\n\n```bash\ncurl -i -X DELETE \\\n  -H \u0027Authorization: Bearer \u003cagentflows_delete_only_key\u003e\u0027 \\\n  http://localhost:8080/api/v1/chatflows/\u003cchatflow_id\u003e\n```\n\n5. Observe a `200 OK` response, for example:\n\n```json\n{\"raw\":[],\"affected\":1}\n```\n\n6. Read the same `id` again and observe `404 Not Found`.",
  "id": "GHSA-p5w8-m249-4r4v",
  "modified": "2026-08-04T16:50:32Z",
  "published": "2026-08-04T16:50:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-p5w8-m249-4r4v"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/pull/6445"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/commit/2f528ceced74afaa95fc7a282965e7788796448b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/FlowiseAI/Flowise"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/releases/tag/flowise@3.1.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Flowise: `DELETE /api/v1/chatflows/:id` does not validate resource type, allowing `agentflows:delete` and `chatflows:delete` to delete each other\u2019s flow type"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.