Package Instance

Flowise affected by Server-Side Request Forgery (SSRF) in HTTP Node Leading to Internal Network Access
**Description:**
Flowise exposes an HTTP Node in AgentFlow and Chatflow that performs server-side HTTP requests using user-controlled URLs. By default, there are no restrictions on target hosts, including private/internal IP ranges (RFC 1918), localhost, or cloud metadata endpoints.
This enables Server-Side Request Forgery (SSRF), allowing any user interacting with a publicly exposed chatflow to force the Flowise server to make requests to internal network resources that are inaccessible from the public internet.

**Impact includes:**
- Access to internal admin panels (e.g., internal company dashboards, Jenkins, Kubernetes API, etc.).
- Retrieval of cloud provider metadata (e.g., AWS IMDSv1 at [http://169.254.169.254], GCP, Azure).
- Port scanning and enumeration of internal services.
- Potential lateral movement or privilege escalation in compromised environments.

This vulnerability is particularly severe because:
- Flowise instances are often deployed publicly without authentication (FLOWISE_USERNAME/PASSWORD not set by default).
- The HTTP Node is easily accessible in simple flows with minimal configuration.

**Proof of Concept (PoC):**
A minimal flow consisting of three nodes demonstrates successful internal network access:
Flow Structure:
<img width="1131" height="323" alt="image" src="https://github.com/user-attachments/assets/f6ddc74f-3ae9-4376-995a-693fb272627a" />
HTTP Node Configuration:
The HTTP Node is configured to perform a GET request to an internal address on localhost:
URL: http://127.0.0.1:8000 (or any internal service)
<img width="568" height="759" alt="image" src="https://github.com/user-attachments/assets/a5735e1f-f735-4d01-9d72-a772963254c8" />

Successful Response from Internal Service:
When the flow is triggered via chat input, the Flowise server successfully retrieves and returns content from the internal mock server running on port 8000 within the same container/network:
<img width="377" height="627" alt="image" src="https://github.com/user-attachments/assets/ff3fcfc6-4957-4aae-9c9d-13b4fca1d0ef" />


**Impact**
This is a Server-Side Request Forgery (SSRF) vulnerability with both read and write capabilities.
The HTTP Request node supports all standard HTTP methods (GET, POST, PUT, PATCH, DELETE), allowing attackers to not only retrieve sensitive information but also modify, create, or delete data on internal services if those services expose mutable endpoints:
- Read access: Retrieval of sensitive internal data, cloud provider metadata (e.g., AWS IAM credentials at http://169.254.169.254/latest/meta-data/iam/security-credentials/), secrets, configuration files, or database contents.
- Write access: Modification or deletion of internal resources via POST/PUT/PATCH/DELETE methods (e.g., creating malicious users/configurations, overwriting files, deleting data, triggering destructive actions on internal admin panels, CI/CD systems like Jenkins, Kubernetes APIs, or cloud management interfaces).
Amplification: Retrieved cloud credentials can be used for further privilege escalation or lateral movement outside the n8n instance.


Suggested Long-term Fix (for Flowise):
- Add optional security controls to HTTP Node:
- Toggle: "Block private IP ranges and localhost" (enabled by default).
- Field: "Allowed domains" (`whitelist`).
- Display prominent warning when URL field uses template variables (e.g., {{ }}).
- Update documentation with explicit SSRF risks and best practices.

Flowise has Authorization Bypass via Spoofed x-request-from Header
Flowise trusts any HTTP client that sets the header `x-request-from: internal`, allowing an authenticated tenant session to bypass all `/api/v1/**` authorization checks. With only a browser cookie, a low-privilege tenant can invoke internal administration endpoints (API key management, credential stores, custom function execution, etc.), effectively escalating privileges.

Flowise Vulnerable to PII Disclosure on Unauthenticated Forgot Password Endpoint
The `/api/v1/account/forgot-password` endpoint returns the full user object including PII (id, name, email, status, timestamps) in the response body instead of a generic success message. This exposes sensitive user information to unauthenticated attackers who only need to know a valid email address.

Flowise has IDOR leading to Account Takeover and Enterprise Feature Bypass via SSO Configuration
The Flowise platform has a critical Insecure Direct Object Reference (IDOR) vulnerability combined with a Business Logic Flaw in the PUT /api/v1/loginmethod endpoint.

While the endpoint requires authentication, it fails to validate if the authenticated user has ownership or administrative rights over the target organizationId. This allows any low-privileged user (including "Free" plan users) to:

1. Overwrite the SSO configuration of any other organization.
2. Enable "Enterprise-only" features (SSO/SAML) without a license.
3. Perform Account Takeover  by redirecting the authentication flow.

Flowise has Insufficient Password Salt Rounds
The default bcrypt salt rounds is set to 5, which is below the recommended minimum for security.

Flowise Allows Mass Assignment in `/api/v1/leads` Endpoint
**A Mass Assignment vulnerability in the `/api/v1/leads` endpoint allows any unauthenticated user to control internal entity fields (`id`, `createdDate`, `chatId`) by including them in the request body.**

The endpoint uses `Object.assign()` to copy all properties from the request body to the Lead entity without any input validation or field filtering. This allows attackers to bypass auto-generated fields and inject arbitrary values.

| Field | Value |
|-------|-------|
| **Vulnerability Type** | Mass Assignment |
| **CWE ID** | [CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes](https://cwe.mitre.org/data/definitions/915.html) |
| **Authentication Required** | None |
| **Affected Endpoint** | `POST /api/v1/leads` |


---

Flowise has Arbitrary File Upload via MIME Spoofing
---

**1. Root Cause**
The vulnerability stems from relying solely on the MIME type without cross-validating the file extension or actual content. This allows attackers to upload executable files (e.g., `.js`, `.php`) or malicious scripts (`.html`) by masquerading them as benign images or documents.

**2. Key Attack Scenarios**

- **Server Compromise (RCE):** An attacker uploads a **Web Shell** and triggers its execution on the server. Successful exploitation grants system privileges, allowing unauthorized access to internal data and full control over the server.
- **Client-Side Attack (Stored XSS):** An attacker uploads files containing malicious scripts (e.g., HTML, SVG). When a victim views the file, the script executes within their browser, leading to session cookie theft and account takeover.

**3. Impact**
This vulnerability is rated as **High** severity. The risk is particularly critical if the system utilizes shared storage (e.g., S3, GCS) or static hosting features, as the compromise could spread to the entire infrastructure and affect other tenants.

Flowise Missing Authentication on NVIDIA NIM Endpoints
The NVIDIA NIM router (`/api/v1/nvidia-nim/*`) is `whitelist`ed in the global authentication middleware, allowing unauthenticated access to privileged container management and token generation endpoints.