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

bash

# 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;
}