CVE-2026-41267: Flowise Auth Bypass Vulnerability

CVE-2026-41267 Overview

CVE-2026-41267 is an improper mass assignment (JSON injection) vulnerability in the account registration endpoint of Flowise Cloud. Flowise is a drag & drop user interface to build customized large language model flows. Prior to version 3.1.0, unauthenticated attackers can inject server-managed fields and nested objects during account creation. This enables client-controlled manipulation of ownership metadata, timestamps, organization association, and role mappings, breaking trust boundaries in a multi-tenant environment.

Critical Impact

Unauthenticated attackers can manipulate server-managed fields during registration, potentially gaining unauthorized access to organization resources and elevated privileges in a multi-tenant LLM platform environment.

Affected Products

• Flowise Cloud versions prior to 3.1.0
• Flowise self-hosted deployments using vulnerable registration endpoints
• Multi-tenant Flowise environments with user registration enabled

Discovery Timeline

• April 23, 2026 - CVE CVE-2026-41267 published to NVD
• April 23, 2026 - Last updated in NVD database

Technical Details for CVE-2026-41267

Vulnerability Analysis

This vulnerability falls under the category of Authorization Bypass through improper mass assignment, classified as CWE-639 (Authorization Bypass Through User-Controlled Key). The flaw exists in the account registration endpoint which fails to properly filter user-supplied JSON data before processing it for account creation.

In a properly secured application, only specific user-controlled fields like username, email, and password should be accepted during registration. However, the vulnerable endpoint in Flowise Cloud accepts and processes additional server-managed fields that should never be modifiable by end users.

Root Cause

The root cause of this vulnerability is the lack of input validation and allowlist filtering on the account registration API endpoint. When processing registration requests, the application directly binds user-supplied JSON data to the account model without restricting which fields can be set. This allows attackers to inject values for sensitive server-managed properties such as organization IDs, role assignments, timestamps, and ownership metadata.

Attack Vector

The attack can be executed over the network without authentication. An attacker crafts a malicious registration request that includes additional JSON fields beyond the expected user registration data. By injecting fields that control organization membership, role assignments, or administrative flags, the attacker can create an account with elevated privileges or associate themselves with target organizations within the multi-tenant platform.

The exploitation involves sending a crafted HTTP POST request to the registration endpoint with injected JSON properties. For example, an attacker might inject organization identifiers to gain access to other tenants' LLM flows, or manipulate role fields to obtain administrative capabilities. For detailed technical information, refer to the GitHub Security Advisory.

Detection Methods for CVE-2026-41267

Indicators of Compromise

• Unusual account creation patterns with non-standard JSON fields in registration requests
• Accounts appearing in organizations without proper invitation workflows
• Users with elevated privileges that were not assigned through administrative processes
• Anomalous timestamps on user accounts that don't match actual creation dates
• Database records showing unexpected ownership or metadata values

Detection Strategies

• Monitor registration endpoint logs for requests containing unexpected JSON fields beyond standard registration parameters
• Implement API request logging to capture full request bodies for forensic analysis
• Deploy web application firewall (WAF) rules to detect JSON injection patterns in registration endpoints
• Audit user accounts for privilege levels that don't match expected onboarding workflows
• Review organization membership changes for accounts added without invitation records

Monitoring Recommendations

• Enable detailed logging on all authentication and registration API endpoints
• Implement real-time alerting for account creation events with anomalous field values
• Conduct regular audits of user-organization associations and role assignments
• Monitor for accounts accessing resources across multiple tenant organizations
• Track API request patterns to the /api/v1/account or similar registration endpoints

How to Mitigate CVE-2026-41267

Immediate Actions Required

• Upgrade Flowise to version 3.1.0 or later immediately
• Audit existing user accounts for unauthorized privilege escalation or organization associations
• Review all accounts created during the vulnerable period for suspicious field values
• Implement network-level access controls to limit registration endpoint exposure
• Consider temporarily disabling public registration until the patch is applied

Patch Information

This vulnerability is fixed in Flowise version 3.1.0. The patch implements proper input validation and allowlist filtering on the account registration endpoint, ensuring that only permitted user-supplied fields are processed during account creation. Server-managed fields such as organization associations, role mappings, and timestamps are now protected from client-side manipulation.

For additional details and patch information, see the GitHub Security Advisory.

Workarounds

• Disable public user registration and use invitation-only account provisioning
• Implement an API gateway or reverse proxy to filter and validate registration requests before they reach Flowise
• Deploy a Web Application Firewall (WAF) with rules to detect and block requests with unexpected JSON fields
• Restrict network access to registration endpoints to trusted IP ranges only
• Implement additional server-side validation in a middleware layer if modifying Flowise source is feasible

# Example: Restrict registration endpoint access via nginx
location /api/v1/account/register {
    # Only allow registration from trusted networks
    allow 10.0.0.0/8;
    allow 192.168.0.0/16;
    deny all;
    
    proxy_pass http://flowise_backend;
}