CVE-2026-42863: FlowiseAI Mass Assignment Vulnerability in Chatflow Update Endpoint

Technical summary

The chatflow update endpoint in FlowiseAI lacks proper server-side input validation and authorization enforcement. The API accepts and processes client-supplied values for restricted fields including 'deployed', 'isPublic', 'workspaceId', 'createdDate', and 'updatedDate'. An authenticated attacker can craft requests that reassign chatflow objects across workspace boundaries and toggle sensitive operational flags. The absence of attribute-level access controls means the application implicitly trusts user input for properties that define resource ownership and operational state.

Business impact

This vulnerability creates significant organizational risk in multi-tenant or multi-workspace deployments. Attackers can hijack LLM workflows, make private/sensitive chatflows public without authorization, or move them to workspaces outside their control. In environments where different teams or business units operate separate workspaces, a compromised or malicious insider can sabotage others' deployments, disrupt service availability, and potentially expose sensitive model configurations or interaction logs.

Affected systems

FlowiseAI versions prior to 3.1.2 are affected. Organizations running Flowise for LLM flow orchestration, including self-hosted deployments and multi-tenant instances, should verify their version immediately. The vulnerability applies universally across deployment models (cloud, on-premises, containerized) that have not applied the 3.1.2 patch.

Exploitability

Exploitability is moderate to high. An attacker must possess valid authentication credentials (low barrier in many organizations with shared demo accounts, contractor access, or credential compromise). No additional interaction, complex setup, or network positioning is required—the attack is network-accessible and straightforward to execute via standard HTTP requests to the update endpoint. The CVSS 8.1 score reflects the high impact on confidentiality and integrity despite the authentication prerequisite.

Remediation

Upgrade to FlowiseAI version 3.1.2 or later immediately. This version patches the vulnerability by implementing proper input validation and authorization checks on the chatflow update endpoint. Before patching, restrict API access to the update endpoint via network or firewall rules if possible, and audit recent chatflow modifications for unauthorized changes.

Patch guidance

Apply the 3.1.2 update as soon as possible. Verify against the official FlowiseAI release notes and security advisories that your deployment method (npm, Docker, source build) has the fix available. Test the patch in a non-production environment first to confirm compatibility with any custom extensions or integrations. After patching, review audit logs for evidence of unauthorized chatflow modifications during the vulnerability window.

Detection guidance

Monitor API logs for unusual activity on the chatflow update endpoint, particularly requests that modify the 'workspaceId', 'deployed', or 'isPublic' fields. Look for updates from users who typically do not modify those specific fields, or updates that change workspace ownership. If audit logging is enabled, examine the audit trail for chatflows that unexpectedly changed visibility or deployment status. Network-based detection is difficult without inspecting request payloads, so application-level logging and endpoint monitoring are essential.

Why prioritize this

This vulnerability merits prompt patching because it enables lateral privilege escalation and resource hijacking in multi-workspace environments. The authentication requirement limits blast radius compared to unauthenticated RCE, but the ease of exploitation and high impact on integrity justify urgent remediation. Organizations using Flowise in collaborative or sensitive contexts should treat this as high priority.

Risk score, explained

The CVSS 8.1 (HIGH) score reflects a network-accessible vulnerability requiring only low-privilege authentication, with high impact on both confidentiality and integrity. No denial of service or direct system compromise occurs, hence the availability score is unaffected. The severity is driven by the ability to escalate privileges, reassign resources, and modify operational settings that affect who can see and use sensitive LLM workflows.

Frequently asked questions