CVE-2026-70471

This is an authorization bypass, not a missing authentication check. The endpoint requires a valid session or API key — it simply fails to verify whether the caller should access the data they're requesting. Flowise's Variables API at `api/v1/variables` correctly enforces the `variables:view` permission before returning variable data. However, the sandbox code execution path in `packages/components/src/utils.ts` performs an equivalent data fetch without any permission check. Any user or API key explicitly denied `variables:view` can call `/api/v1/node-custom-function` with `$vars` injection and receive the identical variable data they were supposed to be blocked from accessing. The bypass uses a legitimate product feature — custom function execution — requiring no additional tooling or exploits. The scope extends beyond user-defined workspace variables. The sandbox resolves variables against `process.env`, meaning server-level environment secrets (database credentials, cloud service keys, API tokens) are in scope. Treat this as a potential infrastructure credential exposure, not just an application secrets issue. Prioritise these actions: apply the Flowise 3.1.3 patch which adds the `variables:view` check to the sandbox path, then audit whether similar authorization gaps exist in other execution paths (background jobs, internal service calls, template rendering) that fetch variable data without checking permissions. Assume any variables accessible to the sandbox during the unpatched period are compromised — rotate credentials stored in environment variables that were potentially exposed. One critical ambiguity remains: whether this bypass was active in default installations or only in deployments where `variables:view` had been explicitly configured and denied. If your Flowise instance uses the permission system, treat this as actively exploitable. If you're on a default single-tenant installation without explicit permission configuration, the practical impact is lower, but the architectural pattern — sandbox code written before the permission system existed — suggests other similar bypasses may exist elsewhere in the codebase.

Reviewed through automated stages and approved by a human before publication.