CVE-2026-69258: Unauthenticated Property Injection and Authorization Bypass in Flowise

Flowise is an open-source low-code platform designed to orchestrate Large Language Model (LLM) workflows. The system maps distinct nodes representing agents, vector stores, prompt templates, and chat memory states into unified directed graphs. To facilitate real-time interactions, the server exposes public endpoints, including the prediction API route located at POST /api/v1/prediction/:id.

This endpoint accepts a runtime payload, which can include an optional overrideConfig object. The purpose of overrideConfig is to adjust runtime execution arguments for specific workflow elements. However, in vulnerable configurations, the application accepts and processes these parameters without validating authorization states.

The unauthenticated prediction endpoint merges incoming configuration overrides directly into the execution context. An attacker can manipulate this behavior to inject arbitrary properties, leading to CWE-915 (Improperly Controlled Modification of Dynamically-Determined Object Attributes) and CWE-639 (Authorization Bypass Through User-Controlled Key).

The root cause of this vulnerability lies in the unsafe application of the ES6 spread operator (...) to unsanitized, user-supplied JSON objects. In JavaScript, when properties are merged using the spread operator, any key-value pairs matching existing properties will silently overwrite the previous declarations.

The Flowise backend executed this spread operation when constructing execution contexts within three major modules: buildAgentflow.ts, buildChatflow.ts, and utils/index.ts. Because the application failed to implement validation checks or schema enforcement before merging, incoming variables received priority.

Specifically, the application skipped validating the apiOverrideStatus parameter, which is intended to check if overrides are permitted on the active flow. This omission allowed any unauthenticated attacker to inject conflicting variables—such as sessionId or chatHistory—into the active memory configuration, causing the server to process arbitrary falsified data.

The vulnerability is localized to several core orchestration helper files where internal execution state objects are instantiated. In packages/server/src/utils/buildChatflow.ts, the context mapping occurred as follows:

// Vulnerable context construction in buildChatflow.ts
const flowData: ICommonObject = {
    chatId,
    sessionId,
    chatHistory,
    apiMessageId,
    ...incomingInput.overrideConfig // Vulnerable spread
}

A similar implementation error existed in packages/server/src/utils/buildAgentflow.ts and packages/server/src/utils/index.ts where arbitrary fields from the client-side overrideConfig were directly spread into state configurations:

// Vulnerable state merge in buildAgentflow.ts
const flowConfig = {
    apiMessageId,
    chatHistory,
    runtimeChatHistoryLength: Math.max(0, runtimeChatHistory.length - 1),
    state: updatedState,
    ...overrideConfig // Vulnerable spread
}

The fix, introduced in commit 23b997ee5ef9e269b628bad0f56f1ecb86bd2fca, removes the spread operators completely. The variables are now defined strictly and statically:

// Patched context construction in buildChatflow.ts
const flowData: ICommonObject = {
    chatId,
    sessionId,
    chatHistory,
    apiMessageId
}

By enforcing static key assignment, the application completely blocks unvalidated client-provided inputs from modifying administrative context values. Variable overrides are now restricted to authorized workflow nodes and verified via the internal replaceInputsWithConfig() utility.

Exploiting this flaw requires no authentication. The attacker only needs network access to the Flowise server and the target flow identifier. The flow identifier is frequently exposed in client-side integrations, such as public chat widgets.

An attacker constructs a HTTP POST request to /api/v1/prediction/:id. Inside the payload, the attacker defines the overrideConfig block, populating it with values that conflict with the server's internal state. For example, injecting a falsified array of messages into the chatHistory parameter tricks the target LLM model into executing commands based on synthetic conversational turns.

This mechanism allows attackers to mock previous user confirmations, bypass security check-loops, or supply synthetic authorization contexts. This technique alters the conversational history and misleads the LLM into generating unauthorized responses.

The impact of CVE-2026-69258 is substantial due to its threat to system data integrity. By hijacking active sessionId parameters, attackers can cross the boundary of session isolation. This enables them to access, pollute, or hijack conversations belonging to other active users on the platform.

Furthermore, the injection of custom properties inside the $flow.* namespace allows manipulation of execution variables. If the underlying flow contains nodes designed to run SQL queries, make external webhook requests, or call API integrations, attackers can alter the query structures or destination URLs by modifying template variables.

While this vulnerability does not directly yield OS-level remote code execution, the ability to bypass application logical security barriers, manipulate prompt histories, and corrupt administrative routing data merits its High CVSS rating of 8.8.

To resolve this vulnerability, deploy the security update to Flowise version 3.1.3 or higher. Administrators can upgrade standard installations using the NPM package manager or by pulling the corrected Docker container image from the official repository.

# Upgrade standard Flowise deployment
npm install -g flowise@latest
 
# Or pull latest Docker image
docker pull flowiseai/flowise:3.1.3

If patching cannot be performed immediately, employ a Web Application Firewall (WAF) to inspect traffic directed to /api/v1/prediction/. Configure a rule to inspect incoming JSON bodies and block requests containing the overrideConfig key when paired with unauthorized internal parameter keys.

Network administrators can also deploy a Suricata or Snort signature to detect active exploitation attempts at the boundaries of the network by inspecting prediction payload strings.