GHSA-mq4r-h2gh-qv7x

Описание

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.

Details

Root Cause

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

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:

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:

Proof of Concept

Prerequisites

• Docker and Docker Compose installed
• curl installed

Step 1: Start Flowise

Create a docker-compose.yml:

Start the container:

Step 2: Baseline Test - Normal Lead Creation

First, create a normal lead to see expected behavior:

Expected Response (normal behavior):

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

Step 3: Exploit - Inject Custom ID

Now inject a custom id:

Actual Response (vulnerability confirmed):

⚠️ The attacker-controlled id was accepted!

Step 4: Exploit - Inject Custom Timestamp

Inject a fake createdDate:

Actual Response (vulnerability confirmed):

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

Step 5: Exploit - Combined Mass Assignment

Inject multiple fields at once:

Actual Response (vulnerability confirmed):

⚠️ 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

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:

Option 2: Use Destructuring with Explicit Fields

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

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

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