chore(release): staging to production - 2026.04.17 - #1042
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
…rsation fix(chat): restore chatId/sessionId filtering lost during Flowise 3.0.11 merge
maxtechera
temporarily deployed
to
staging - aai-unified2-flowise-moonstruck
March 27, 2026 15:10 — with 
Render
Inactive
Render
Inactive
The mergeUsers function was overwriting server-enriched permission data
(roles, permissions, features) with client-side Auth0 data that lacks
these fields. This caused Admin users to fail permission checks because
hasFeature('org:manage') would return false despite having the role.
The fix explicitly preserves auth fields from the server (initialUser)
and only allows runtime updates for non-auth fields (name, email, picture).
Fixes visibility settings not working for Admin users.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
maxtechera
temporarily deployed
to
staging - aai-unified2-flowise-moonstruck
March 30, 2026 14:57 — with
Render
Inactive
Render
Inactive
…s token lacks claim The access token sent to Flowise does not carry the https://theanswer.ai/roles custom claim (only the ID token does). verifyAAIToken extracts roles from the access token and gets roles=[], causing enrichUserWithAAIData to return empty roles/permissions/features, which then overwrites the correct roles from the Auth0 session in the merge. Save https://theanswer.ai/roles from the session before the Flowise merge and restore it afterward if Flowise returned an empty roles array. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…ider Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
fix(auth): preserve server-enriched auth fields in PermissionProvider merge
github-actions
Bot
changed the title
useAuth0() from @auth0/auth0-react has no Auth0Provider in the Flowise UI component tree — only UserProvider from @auth0/nextjs-auth0/client is present. This caused useAuth0() to return undefined, making createPermissionManager receive an empty object, which disabled all visibility checkboxes for every user. Fix: read from Redux state.auth.user, which is populated by useAuth0Setup after /auth/me enrichment and contains the correct roles and permissions.
fix(permissions): restore visibility controls in Flowise canvas for admin users
…d Browser Extension visibility Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…er, guard, error re-throw - Add organizationId filter to getBrowserExtensionChatflows query for multi-tenancy compliance - Add activeWorkspaceId guard that throws PRECONDITION_FAILED before the query runs - Re-throw InternalFlowiseError in both catch blocks so NOT_FOUND/FORBIDDEN preserve their status codes Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…kspace and org
Add activeWorkspaceId and organizationId guards before query, then scope
findOneBy to { id, workspaceId, organizationId } — matching the pattern
in getBrowserExtensionChatflows and all other services (tools, assistants,
credentials, variables). Prevents cross-workspace visibility toggling.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Replace triple-key filter (userId + workspaceId + organizationId) with workspace-scoped dual-path query: show user's own chatflows AND chatflows shared with the organization via (userId OR Organization visibility). Remove redundant organizationId guard and filter from update path — checkOwnership and enforceAbility already handle org-level auth. Closes #1054 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
fix(browser-extension): scope chatflow results to active workspace and Browser Extension visibility
github-actions
Bot
changed the title
…1056) ## Summary Patches **CVE-2026-40933** (Flowise MCP Remote Command Execution) against our fork, which currently runs Flowise **3.0.11** (within the vulnerable `<= 3.0.13` range). The existing MCP command-injection validator in [`packages/components/nodes/tools/MCP/core.ts`](packages/components/nodes/tools/MCP/core.ts) checks each argument for shell metacharacters in isolation, but does not reject inline code-execution flags (`-c`, `--call`, `-e`, `--eval`, `-p`, `--print`, `--exec`) that allow an allowlisted command (`npx`, `node`, `python`, `python3`) to execute a subsequent argument as arbitrary code / shell. ### Reported CVE payload ```json { "command": "npx", "args": ["-c", "touch /tmp/pwn"] } ``` Both `"-c"` and `"touch /tmp/pwn"` individually pass the existing metacharacter check, but together they instruct `npx` to run the second argument as a shell command, yielding **authenticated RCE** via the Custom MCP node in the chatflow canvas. ## Why we are not upgrading to Flowise 3.1.0 The upstream 3.1.0 release is a breaking major release (LangChain v1 migration, AgentFlow SDK rename, HTTP security defaults, 200+ PRs). A full upgrade of this heavily customized fork would require weeks of work and extensive regression testing. That effort is being tracked as a separate roadmap item -- this PR provides the targeted hotfix in the meantime. ## Changes - [`packages/components/nodes/tools/MCP/core.ts`](packages/components/nodes/tools/MCP/core.ts): - Adds `validateInlineExecFlags()` that rejects any argument list containing one of the forbidden flags as a standalone argument, with inline JSDoc referencing CVE-2026-40933. - Wires it into `validateMCPServerConfig()` alongside the existing `validateArgsForLocalFileAccess` and `validateCommandInjection` checks. ## Why this is non-breaking - Legitimate MCP server configs such as `npx -y @modelcontextprotocol/server-filesystem /allowed/path` do not use any of the blocked flags. - Only two callers of `validateMCPServerConfig` exist: `CustomMCP` and `Supergateway`. Neither uses inline-exec flags as part of normal operation. - The 15+ pre-built MCP adapters (Github, Slack, Jira, Confluence, Linear, Atlassian, etc.) do not go through the validator at all -- they use hardcoded `command`/`args` and are unaffected. - TypeScript type-check passes with no new errors. ## Explicitly NOT changing - `CUSTOM_MCP_PROTOCOL=sse` is a valid nuclear-option mitigation that disables stdio transport entirely in [`CustomMCP.ts`](packages/components/nodes/tools/MCP/CustomMCP/CustomMCP.ts), but was not flipped here because without tenant-usage visibility it could silently break customer chatflows that rely on legitimate stdio Custom MCP configs. Code-level hardening was chosen to target the specific CVE bypass without collateral breakage. The env var remains available as defense-in-depth if needed. - No version bump (still `3.0.11`). A fork-versioning strategy (e.g., `3.0.11-aai.1`) should be addressed in its own PR since it touches multiple packages, deploy configs, and version-comparison scripts. ## Test plan - [ ] Smoke test on staging: load a chatflow containing a Custom MCP node with a benign config (e.g., `npx -y @modelcontextprotocol/server-filesystem`) and confirm it still lists actions correctly. - [ ] Smoke test on staging: attempt the CVE payload `{"command":"npx","args":["-c","touch /tmp/pwn"]}` in a Custom MCP node and confirm it is rejected with the `inline code-execution flag` error. - [ ] Verify other MCP-backed chatflows (Slack / Jira / Github / etc.) load tools normally -- they should not be affected at all. - [ ] If staging smoke test passes, merge to `staging` and then to `prod`. ## References - Upwind Security advisory: https://x.com/UpwindMDR/status/2044857553415491857 - Internal Slack escalation from Mark Lukowski re: ias-aai-prod-flowise-Service-OWMAlRszsOn0 - Upstream patch in Flowise 3.1.0: https://github.com/FlowiseAI/Flowise/releases/tag/flowise%403.1.0
github-actions
Bot
changed the title
maxtechera
temporarily deployed
to
staging - aai-unified2-flowise-moonstruck
April 17, 2026 22:32 — with
Render
Inactive
Render
Inactive
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🚀 Release: Staging to Production
Release Date: 2026-04-17
Changes in this release
This PR is automatically created/updated when commits are pushed to staging.
Merging this PR will trigger the release workflow to create a new GitHub release.