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).