Flowise is a drag & drop user interface to build a customized large language model flow.

CVE-2026-69258 targets the POST /api/v1/prediction/:id endpoint in Flowise < 3.1.3, which is whitelisted from authentication checks. The endpoint accepts an overrideConfig JSON object and unconditionally spreads it into internal flowConfig and flowData structures via two separate spread operations — neither of which checks the chatflow's apiOverrideStatus gate. This means an unauthenticated attacker can overwrite chatId, sessionId, chatHistory, and any $flow.* template variable consumed by downstream nodes. The result is session hijacking, cross-session data pollution, chat history manipulation, and injection of attacker-controlled values into LLM prompt templates. All versions before 3.1.3 are affected; this is distinct from the earlier GHSA-5cph-wvm9-45gj fix, which only gated replaceInputsWithConfig().

There is no official vendor CVSS score from FlowiseAI. Third-party databases (GitLab Advisory Database, SentinelOne) have scored this between 8.2 and 8.8, which is aggressive. Those scores reflect the unauthenticated, zero-interaction attack surface — and they're directionally correct. However, the direct impact is data manipulation and session hijacking, not remote code execution. The real danger is what sits *behind* Flowise: API keys for OpenAI/Azure/AWS, database credentials, and internal tool integrations stored in flow configs. An attacker who can inject into $flow variables can redirect LLM tool calls, exfiltrate secrets embedded in prompt templates, or poison AI agent outputs. The severity is genuinely HIGH, but calling it CRITICAL would require a proven RCE chain, which this CVE alone does not provide.

Why this verdict

• Unauthenticated, zero-click attack surface: The /api/v1/prediction/:id endpoint is explicitly whitelisted from auth in the Flowise codebase. No credentials, no user interaction, no special headers. This removes the most common friction point.
• Significant internet exposure: 12,000–15,000 Flowise instances are publicly reachable. While many are hobby/dev instances, enterprise AI deployments with sensitive tool integrations are in the mix. The reachable population is non-trivial.
• Impact is data-plane manipulation, not control-plane RCE: The attacker gains the ability to hijack sessions, inject into LLM prompts, and manipulate flow variables — but not execute arbitrary code on the host. The severity ceiling is set by what the Flowise agent can *reach*, not by OS-level compromise.
• Role multiplier: Flowise is an AI agent orchestration platform. In its *typical* role (b), it's a dev tool building chatbot prototypes — blast radius is low. In its *high-value* role (c), it orchestrates AI agents with database access, cloud API keys, and internal tool integrations — blast radius extends to credential theft and data exfiltration from connected systems. However, Flowise is not a canonical high-value infrastructure component (not a DC, hypervisor, IdP, or backup server). The high-value role represents a minority of deployments. The floor is HIGH, not CRITICAL.
• Chaining potential: This CVE can chain with other Flowise vulnerabilities (e.g., CVE-2026-41268 RCE via parameter override bypass) to escalate from property injection to code execution — but that requires a separate unpatched vulnerability, not this CVE alone.

Why not higher?

CRITICAL would require either direct RCE, a proven chain to fleet/domain compromise, or a canonical high-value infrastructure role. This CVE yields session hijacking and data manipulation — serious, but bounded by what the Flowise process can access. Flowise is not an identity provider, domain controller, or hypervisor. The blast radius of a compromised Flowise instance is limited to its connected integrations, not the broader network.

Why not lower?

MEDIUM would underestimate the risk of an unauthenticated, zero-interaction vulnerability on 12,000+ internet-facing instances. The attack is trivial (single curl command), requires no privileges, and the target often holds cloud API keys and database credentials in flow configurations. The CWE-639 authorization bypass means every public chatflow is a viable entry point. Downgrading past HIGH would ignore the real-world exposure population and the sensitivity of data Flowise instances routinely handle.

1. Place Flowise behind authentication proxy immediately — Deploy a reverse proxy (nginx, Caddy, Traefik) or zero-trust gateway (Cloudflare Access, Tailscale Funnel) that requires authentication before any request reaches Flowise. This neutralizes the unauthenticated attack vector entirely. Per noisgate mitigation SLA for HIGH, deploy within 30 days.
2. Restrict /api/v1/prediction/ to known client IPs — If the chatbot must remain public, apply WAF or network ACL rules to allow only your frontend application's IP range to reach the prediction endpoint. Block direct access from arbitrary internet sources.
3. Audit and rotate all credentials stored in Flowise flows — Check all chatflows for inline API keys, database passwords, and service tokens. Rotate any credentials that were accessible through $flow.* variables or flow configs. Assume they may have been exposed if your instance was internet-facing before patching.
4. Upgrade to Flowise 3.1.3+ — The definitive fix. Per noisgate remediation SLA for HIGH, complete within 180 days. Given the trivial exploitability, prioritize this ahead of the SLA deadline.
5. Disable unnecessary public chatflow sharing — Review all chatflows with public sharing enabled. Disable sharing for any flow that doesn't require anonymous access. This reduces the attack surface to only intentionally public flows.

Run this on the Flowise host or from any machine with network access to the Flowise instance. No special privileges needed. Usage: bash check_cve_2026_69258.sh https://your-flowise-host:3000

#!/usr/bin/env bash
# CVE-2026-69258 Checker — Flowise overrideConfig property injection
# Usage: bash check_cve_2026_69258.sh <FLOWISE_BASE_URL>
# Exit codes: 0=VULNERABLE, 1=PATCHED, 2=UNKNOWN

set -euo pipefail

BASE_URL="${1:?Usage: $0 <FLOWISE_BASE_URL>}"
BASE_URL="${BASE_URL%/}"

echo "[*] Checking Flowise version at ${BASE_URL}..."

# Try to get version from the API
VERSION=$(curl -sf --max-time 10 "${BASE_URL}/api/v1/version" 2>/dev/null | grep -oP '"version"\s*:\s*"\K[^"]+' || true)

if [ -z "$VERSION" ]; then
  # Fallback: check package.json endpoint or HTML
  VERSION=$(curl -sf --max-time 10 "${BASE_URL}" 2>/dev/null | grep -oP 'flowise[/@]\K[0-9]+\.[0-9]+\.[0-9]+' | head -1 || true)
fi

if [ -z "$VERSION" ]; then
  echo "[!] UNKNOWN — Could not determine Flowise version."
  echo "    Verify manually: curl ${BASE_URL}/api/v1/version"
  exit 2
fi

echo "[*] Detected Flowise version: ${VERSION}"

# Parse version components
IFS='.' read -r MAJOR MINOR PATCH <<< "$VERSION"

# Vulnerable: < 3.1.3
if [ "$MAJOR" -lt 3 ]; then
  echo "[!] VULNERABLE — Flowise ${VERSION} is affected by CVE-2026-69258 (fixed in 3.1.3)."
  exit 0
elif [ "$MAJOR" -eq 3 ] && [ "$MINOR" -lt 1 ]; then
  echo "[!] VULNERABLE — Flowise ${VERSION} is affected by CVE-2026-69258 (fixed in 3.1.3)."
  exit 0
elif [ "$MAJOR" -eq 3 ] && [ "$MINOR" -eq 1 ] && [ "$PATCH" -lt 3 ]; then
  echo "[!] VULNERABLE — Flowise ${VERSION} is affected by CVE-2026-69258 (fixed in 3.1.3)."
  exit 0
else
  echo "[+] PATCHED — Flowise ${VERSION} is not affected by CVE-2026-69258."
  exit 1
fi

Sources

1. GitLab Advisory Database — CVE-2026-69258
2. SentinelOne Vulnerability Database — CVE-2026-69258
3. The Hacker News — Flowise Under Active RCE Exploitation (April 2026)
4. Cybersecurity News — 15,000+ Flowise Instances Exposed
5. FlowiseAI GitHub Security Advisory — GHSA-5cph-wvm9-45gj (prior overrideConfig fix)
6. Flowise Vulnerability Rollup (April 2026)
7. CWE-639: Authorization Bypass Through User-Controlled Key