GHSA-8R8H-6VCC-XHRV

Vulnerability from github – Published: 2026-08-04 17:43 – Updated: 2026-08-04 17:43
VLAI
Summary
Flowise: RBAC Bypass Leading to Unauthorized Workspace Variables Disclosure
Details

Finding — Unauthorized Workspace Variables disclosure via $vars injection (bypasses variables:view)

### What’s wrong (code locations)

  • Variables for the active workspace are fetched without checking “variables:view” at this call site: flowise-src/ packages/components/src/utils.ts:932
  • Runtime variables are resolved from server environment variables: flowise-src/packages/components/src/utils.ts:976
  • $vars is always injected into the code execution sandbox: flowise-src/packages/components/src/utils.ts:1782
  • The official Variables API is permission-protected (contrast): flowise-src/packages/server/src/routes/variables/ index.ts:11

### Why it is a privilege boundary bypass

A user/API key might be denied variables:view (and the /api/v1/variables route enforces it), but they can still:

  • call /api/v1/node-custom-function (Finding 1)
  • and have $vars pre-populated with all variables for the workspace, including runtime values from process.env

### What data is exposed

Inside the custom JS context, $vars contains a flat map of:

  • Variable.name -> Variable.value for static variables, and
  • Variable.name -> process.env[Variable.name] for runtime variables (type === 'runtime')

This can expose secrets such as database passwords, JWT secrets, SMTP passwords, cloud keys, etc., depending on what the workspace Variables are configured to map.

### Recommended fix (minimum)

  • Do not inject $vars unless the caller is authorized:
    • enforce variables:view before injecting $vars, or
    • inject only an explicit allowlist of variables needed for the function
  • Consider disabling or heavily restricting type=runtime variables in self-hosted environments (or restrict which env keys may be mapped).
Show details on source website

{
  "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-70471"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-04T17:43:36Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Finding \u2014 Unauthorized Workspace Variables disclosure via $vars injection (bypasses variables:view)\n\n  ### What\u2019s wrong (code locations)\n\n  - Variables for the active workspace are fetched without checking \u201cvariables:view\u201d at this call site: flowise-src/\n    packages/components/src/utils.ts:932\n  - Runtime variables are resolved from server environment variables: flowise-src/packages/components/src/utils.ts:976\n  - $vars is always injected into the code execution sandbox: flowise-src/packages/components/src/utils.ts:1782\n  - The official Variables API is permission-protected (contrast): flowise-src/packages/server/src/routes/variables/\n    index.ts:11\n\n  ### Why it is a privilege boundary bypass\n\n  A user/API key might be denied variables:view (and the /api/v1/variables route enforces it), but they can still:\n\n  - call /api/v1/node-custom-function (Finding 1)\n  - and have $vars pre-populated with all variables for the workspace, including runtime values from process.env\n\n  ### What data is exposed\n\n  Inside the custom JS context, $vars contains a flat map of:\n\n  - Variable.name -\u003e Variable.value for static variables, and\n  - Variable.name -\u003e process.env[Variable.name] for runtime variables (type === \u0027runtime\u0027)\n\n  This can expose secrets such as database passwords, JWT secrets, SMTP passwords, cloud keys, etc., depending on what\n  the workspace Variables are configured to map.\n\n  ### Recommended fix (minimum)\n\n  - Do not inject $vars unless the caller is authorized:\n      - enforce variables:view before injecting $vars, or\n      - inject only an explicit allowlist of variables needed for the function\n  - Consider disabling or heavily restricting type=runtime variables in self-hosted environments (or restrict which env\n    keys may be mapped).",
  "id": "GHSA-8r8h-6vcc-xhrv",
  "modified": "2026-08-04T17:43:36Z",
  "published": "2026-08-04T17:43:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-8r8h-6vcc-xhrv"
    },
    {
      "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:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Flowise: RBAC Bypass Leading to Unauthorized Workspace Variables Disclosure"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

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.

Loading…

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…