Like letting anyone in the lobby rewrite the receptionist's script mid-conversation with your customers
Flowise versions before 3.1.3 expose the POST /api/v1/prediction/:id endpoint without authentication — it's intentionally whitelisted so public chatbots work. The problem: the endpoint accepts an overrideConfig JSON object that the server blindly spreads (via ECMAScript CopyDataProperties) into the internal flowConfig and flowData objects at two code locations in buildChatflow.ts and index.ts. Because apiOverrideStatus is never checked on these paths — a bypass of the earlier GHSA-5cph-wvm9-45gj fix from v2.1.4 — an unauthenticated attacker can overwrite chatId to hijack another user's conversation history, replace chatHistory to perform transcript-level prompt injection, and inject arbitrary $flow.* template variables that downstream nodes resolve when making API calls, database queries, or tool invocations. All three npm packages (flowise, flowise-components, flowise-ui) versions 1.x through 3.1.2 are affected.
The vendor scored this CVSS 9.1 CRITICAL (v3.1: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N), but the GitLab advisory and CVSS v4.0 assessments both land at HIGH (8.2–8.8). The CRITICAL label hinges on C:H and I:H, which overstates reality: confidentiality loss is bounded to chat transcripts and template variable values within the Flowise application context — not system-level secrets or database dumps — and integrity impact is to flow execution logic, not the underlying OS or adjacent systems. There is no direct code execution from this CVE alone (that's CVE-2026-41268, a related but distinct overrideConfig-to-RCE chain fixed in 3.1.0). With an EPSS of 0.00667, no KEV listing, no public PoC on pocindex.io or GitHub, and a now-archived repository, the real-world urgency is HIGH, not CRITICAL.
4 steps from start to impact.
Identify an exposed Flowise instance with a public chatflow
/api/v1/public-chatflows. No authentication is needed; the prediction endpoint is in WHITELIST_URLS by design.- Flowise instance is internet-reachable
- At least one chatflow is set to public/shared
- Not all Flowise instances have public chatflows — many are dev/test environments
- Enterprises using Flowise Enterprise tier may have SSO/RBAC gating access
http.title:"Flowise" or Censys query for Flowise favicon hash. GreyNoise does not track Flowise-specific scanning tags as of October 2026.Send overrideConfig payload to prediction endpoint
POST /api/v1/prediction/<chatflowId> request with a malicious overrideConfig object in the JSON body. Because the two spread-operator sites at buildChatflow.ts:557 and index.ts:574 do not check apiOverrideStatus, any properties in overrideConfig are merged directly into flowConfig and flowData. This is a trivial HTTP request — no exploit toolkit or weaponized tool required, just curl or any HTTP client.- Target runs Flowise < 3.1.3
- None — this is a single unauthenticated HTTP POST
overrideConfig keys matching chatId, sessionId, chatHistory. No Nuclei template or Metasploit module exists for this specific CVE as of October 2026.Hijack victim session via chatId override
"overrideConfig": {"chatId": "<victim-chatId>"}, the attacker's request executes in the context of the victim's conversation. The LLM responds with the victim's prior chat history, exposing any sensitive data the victim shared — PII, financial details, proprietary questions. The attacker can also inject chatHistory to replace the model's belief about what was said, bypassing system-prompt defenses via transcript-level prompt injection rather than instruction-level injection.- Attacker knows or can enumerate a valid chatId (often a UUID, but may be sequential or guessable in older deployments)
- Chat IDs are UUIDs in current versions — brute-force is impractical without enumeration
- Chat transcripts may contain limited sensitive data depending on use case
Inject $flow template variables to redirect node behavior
$flow.* template syntax in downstream nodes. If a flow node references $flow.apiUrl, $flow.apiKey, $flow.queryParam, or similar, the attacker can redirect API calls to an attacker-controlled endpoint (SSRF-like exfiltration), change query parameters, or alter tool invocations. This turns a property injection into a server-side request manipulation depending entirely on how the chatflow is authored.- Flow nodes must reference $flow.* variables that overlap with injected property names
- The chatflow must contain nodes that make outbound API calls or tool invocations
- Requires knowledge of the chatflow's internal variable names — not exposed by default
- Not all chatflows use $flow.* variables; simple Q&A chatbots typically don't
/api/v1/prediction/:id is in WHITELIST_URLS. Removing public sharing or gating all Flowise access behind an authenticating proxy (nginx + OAuth2-proxy, Cloudflare Access, or Tailscale) eliminates the unauthenticated attack surface entirely. Deploy within the noisgate mitigation SLA of 30 days for HIGH severity.POST /api/v1/prediction/* that rejects JSON bodies containing overrideConfig with keys matching chatId, sessionId, chatHistory, or apiMessageId. This is a surgical block that preserves legitimate chatbot functionality while stripping the weaponizable properties. Deploy within 30 days per noisgate mitigation SLA.23b997e, 09f099d). Given the repository was archived in August 2026 with no further patches expected, organizations should evaluate migrating to supported alternatives. Apply the patch within the noisgate remediation SLA of 180 days. If running Flowise only for internal experimentation, decommission rather than patch — the project is EOL.api.openai.com, generativelanguage.googleapis.com) neutralizes the $flow template injection → SSRF exfiltration vector. Attackers can still hijack sessions but cannot redirect tool calls to attacker-controlled servers. Deploy within 30 days.- Rate limiting on the prediction endpoint — the attack requires only a single request per session hijack; rate limiting doesn't help against low-and-slow exploitation.
- Flowise's built-in
apiOverrideStatustoggle — CVE-2026-69258 exists precisely because two code paths bypass this check. Toggling it off provides a false sense of security on versions < 3.1.3. - Input validation on the
questionfield — the malicious payload is inoverrideConfig, not the question text. Prompt-injection defenses at the LLM layer don't address this server-side property injection.
The supporting signals.
| In-the-Wild Exploitation | Not observed. CVE-2026-69258 is not in CISA KEV. No campaigns targeting this specific CVE have been reported. However, Flowise's overrideConfig attack surface has prior exploitation history — CVE-2025-59528 (CVSS 10.0 RCE via CustomMCP node) was actively exploited starting April 2026 from a Starlink IP, per VulnCheck. |
|---|---|
| Proof-of-Concept | No dedicated PoC repository found. Checked pocindex.io, SecureWithUmer/CVE-2026-PoCs, GitHub topic searches — no hits. However, exploitation is trivial (single curl command) and the HackerNoon writeup by the researcher contains working payload examples for chatId hijacking. |
| EPSS | 0.00667 — low exploitation probability. This places it well below the 90th percentile threshold where EPSS typically flags actionable risk. |
| CVSS Vector | Vendor v3.1: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N (9.1 CRITICAL). GitLab advisory v3.1: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N (8.2 HIGH). CVSS v4.0: 8.8 HIGH. The C:H in the vendor score is disputed — data exposure is bounded to chat transcripts and flow variable values, not system-wide secrets. |
| Affected Versions | flowise, flowise-components, flowise-ui npm packages versions 1.x through 3.1.2. All three packages must be upgraded together. |
| Fixed Version | 3.1.3 — fix landed May 7, 2026 in PR #6279, commits 23b997e and 09f099d. Fix strategy: removed spread operator entirely, replaced with explicit pick() allowlist excluding chatId, sessionId, chatHistory, apiMessageId. |
| Internet Exposure | 12,000–15,000 Flowise instances are internet-facing per Shodan/Censys scans cited in April 2026 Hacker News and GBHackers reporting. Of ~1,000 tested instances, 156 allowed fully unauthenticated access. No GreyNoise tag exists for Flowise-specific scanning. |
| Disclosure Timeline | Reported March 2026 → Acknowledged within 3 days → Fixed May 7, 2026 (v3.1.3) → CVE assigned August 4, 2026. Repository archived August 2026 after Workday acquisition (August 2025). No further patches expected. |
| Researcher | Aviral Srivastava (@aviralxroot), Application Security Engineer at Amazon, Penn State MS Cybersecurity. Also credited for CVE-2026-33017 (Langflow RCE, Pwnie nominee, CISA KEV). Published detailed Medium writeup: *"Flowise patched overrideConfig. I found the two places the patch never reached."* |
| Prior overrideConfig History | This is the third overrideConfig advisory for Flowise: GHSA-5cph-wvm9-45gj (v2.1.4, Nov 2024) added apiOverrideStatus gate; GHSA-cvrr-qhgw-2mm6 / CVE-2026-41268 (v3.1.0) addressed RCE via MCP node + NODE_OPTIONS injection. CVE-2026-69258 bypasses the 2024 fix at two ungated code paths. |
Sources.
- HackerNoon — Researcher writeup by Aviral Srivastava
- GitHub Security Advisory GHSA-6vh2-wg4h-4vwj
- OSV — CVE-2026-69258 affected packages and versions
- GitLab Advisory Database — npm/flowise/CVE-2026-69258
- The Hacker News — Flowise 12,000+ instances actively exploited (CVE-2025-59528 context)
- GBHackers — 15,000+ exposed Flowise instances
- SentinelOne Vulnerability Database — CVE-2026-69258
- Prior overrideConfig advisory GHSA-5cph-wvm9-45gj (Flowise v2.1.4)
Why this verdict
- Confidentiality overstated in vendor vector: The vendor rates C:H, but the data reachable through chatId hijacking is bounded to chat transcripts within the Flowise application — not system credentials, database contents, or secrets at rest. The GitLab advisory correctly scores C:L. Adjusting C:H → C:L drops the v3.1 base from 9.1 to 8.2.
- No direct code execution: This CVE enables property injection and session hijacking, not RCE. The overrideConfig-to-RCE chain (CVE-2026-41268) was separately patched in 3.1.0 with additional controls beyond
apiOverrideStatus. Chaining CVE-2026-69258 with the RCE path requires the MCP node to be present AND the 3.1.0 fix to be absent — a narrow intersection since most instances vulnerable to CVE-2026-69258 (< 3.1.3) would have 3.1.0–3.1.2 with the RCE fix applied. - Low exploitation signals: EPSS 0.00667, not in KEV, no public PoC repos, no Nuclei template, no Metasploit module, no GreyNoise tag. Active exploitation of Flowise exists but targets CVE-2025-59528 (CustomMCP RCE), not this property injection flaw.
- Niche and declining install base: Flowise is an open-source AI workflow builder, not enterprise infrastructure. The GitHub repository was archived in August 2026 following Workday's acquisition. While 12K-15K instances are exposed, the population is actively shrinking with no new patches forthcoming.
- Role multiplier: Flowise occupies the *application tier / AI orchestration* role — it is NOT a canonical high-value component (not an IdP, domain controller, hypervisor, CI/CD pipeline, backup system, or network edge appliance). In its worst-case deployment as a customer-facing AI chatbot handling PII, the blast radius of session hijacking is *tenant-level data exposure within Flowise* — not domain takeover, fleet compromise, or supply-chain pivot. This means no floor override applies. Even at Fortune 500 deployers (Thermo Fisher, Deloitte, Accenture per vendor claims), Flowise is one application among thousands, not identity-tier or infrastructure-tier.
- Friction on $flow variable injection: Exploiting template variable injection requires knowledge of the chatflow's internal variable naming, which is not exposed via the API. Blind injection is possible but yields unpredictable results. Most simple Q&A chatflows don't use custom
$flow.*variables at all.
Why not higher?
CRITICAL would require either direct RCE, fleet-scale blast radius, or the affected component being a canonical high-value target. CVE-2026-69258 delivers none of these: it's property injection (not code execution) in an application-tier AI tool (not infrastructure), bounded to tenant-level data exposure. The vendor's 9.1 CRITICAL rating relies on a C:H assessment that doesn't survive contact with the actual data accessible through the attack.
Why not lower?
MEDIUM would undercount the risk from unauthenticated, zero-interaction exploitation against a population of 12K+ internet-facing instances with working payload examples published by the researcher. Session hijacking of AI chatbots handling customer data is a real breach scenario, and the $flow template injection pathway — while conditional — could enable SSRF-equivalent behavior in well-authored chatflows. The complete absence of authentication or complexity barriers keeps this firmly in HIGH territory.
Crowdsourced verification payload.
Run this script from any workstation or CI runner with curl and jq installed. Pass the target Flowise base URL as the first argument: bash check_cve_2026_69258.sh https://flowise.example.com. No authentication required — the script probes the unauthenticated version endpoint and tests the prediction API behavior. Needs network access to the target Flowise instance on its HTTP port.
#!/usr/bin/env bash
# check_cve_2026_69258.sh — Detect CVE-2026-69258 (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
TARGET="${1:?Usage: $0 <FLOWISE_BASE_URL>}"
TARGET="${TARGET%/}" # strip trailing slash
echo "[*] Checking CVE-2026-69258 against: $TARGET"
# Step 1: Get Flowise version via API
VERSION=$(curl -sf --max-time 10 "${TARGET}/api/v1/version" 2>/dev/null | jq -r '.version // empty' 2>/dev/null || true)
if [ -z "$VERSION" ]; then
# Fallback: try the root page or other endpoints
VERSION=$(curl -sf --max-time 10 "${TARGET}/api/v1/node-icon/chatOpenAI" -o /dev/null -w '%{http_code}' 2>/dev/null || true)
if [ "$VERSION" = "000" ] || [ -z "$VERSION" ]; then
echo "[!] Could not connect to Flowise instance at $TARGET"
echo "UNKNOWN"
exit 2
fi
echo "[!] Connected but could not determine version. Checking endpoint behavior."
VERSION="unknown"
fi
if [ "$VERSION" != "unknown" ]; then
echo "[*] Detected Flowise version: $VERSION"
# Compare version — vulnerable if < 3.1.3
MAJOR=$(echo "$VERSION" | cut -d. -f1)
MINOR=$(echo "$VERSION" | cut -d. -f2)
PATCH=$(echo "$VERSION" | cut -d. -f3)
if [ "$MAJOR" -lt 3 ] 2>/dev/null; then
echo "[!] Version $VERSION is below 3.1.3"
echo "VULNERABLE"
exit 0
elif [ "$MAJOR" -eq 3 ] && [ "$MINOR" -lt 1 ] 2>/dev/null; then
echo "[!] Version $VERSION is below 3.1.3"
echo "VULNERABLE"
exit 0
elif [ "$MAJOR" -eq 3 ] && [ "$MINOR" -eq 1 ] && [ "$PATCH" -lt 3 ] 2>/dev/null; then
echo "[!] Version $VERSION is below 3.1.3"
echo "VULNERABLE"
exit 0
elif [ "$MAJOR" -eq 3 ] && [ "$MINOR" -eq 1 ] && [ "$PATCH" -ge 3 ] 2>/dev/null; then
echo "[+] Version $VERSION is >= 3.1.3 (patched)"
echo "PATCHED"
exit 1
elif [ "$MAJOR" -gt 3 ] 2>/dev/null; then
echo "[+] Version $VERSION is >= 3.1.3 (patched)"
echo "PATCHED"
exit 1
fi
fi
# Step 2: Check if public chatflows exist (non-destructive)
PUBLIC_FLOWS=$(curl -sf --max-time 10 "${TARGET}/api/v1/public-chatflows" 2>/dev/null || true)
if echo "$PUBLIC_FLOWS" | jq -e '. | length > 0' >/dev/null 2>&1; then
FLOW_COUNT=$(echo "$PUBLIC_FLOWS" | jq '. | length')
echo "[!] Found $FLOW_COUNT public chatflow(s) — attack surface is live"
else
echo "[*] No public chatflows found or endpoint not accessible"
fi
echo "[*] Version-based check inconclusive"
echo "UNKNOWN"
exit 2