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…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…