GHSA-mq4r-h2gh-qv7x: Flowise Allows Mass Assignment in `/api/v1/leads` Endpoint
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](https://cwe.mitre.org/data/definitions/915.html) |
| **Authentication Required** | None |
| **Affected Endpoint** | `POST /api/v1/leads` |DetailsRoot CauseThe 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 identifierLead Entity DefinitionThe 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 AccessibleThe `/api/v1/leads` endpoint is whitelisted in `/packages/server/src/utils/constants.ts`:Proof of ConceptPrerequisitesDocker and Docker Compose installedcurl installedStep 1: Start FlowiseCreate a `docker-compose.yml`:Start the container:Step 2: Baseline Test - Normal Lead CreationFirst, 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 IDNow inject a custom `id`:**Actual Response (vulnerability confirmed):****⚠️ The attacker-controlled `id` was accepted!**Step 4: Exploit - Inject Custom TimestampInject a fake `createdDate`:**Actual Response (vulnerability confirmed):****⚠️ The attacker-controlled timestamp from 1970 was accepted!**Step 5: Exploit - Combined Mass AssignmentInject multiple fields at once:**Actual Response (vulnerability confirmed):****⚠️ ALL three internal fields (`id`, `createdDate`, `chatId`) were controlled by the attacker!**VerificationThe exploit succeeds because:✅ HTTP 200 response (request accepted)✅ `id` field contains attacker-controlled UUID✅ `createdDate` field contains attacker-controlled timestamp✅ `chatId` field contains attacker-controlled string✅ No authentication headers were sentImpactWho is Affected?**All Flowise deployments** that use the leads featureBoth **open-source** and **enterprise** versionsAny system that relies on lead data integrityAttack 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 AssessmentWhile 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 issuesPotential business logic bypassesAudit/compliance concernsFoundation for chained attacksRecommended FixOption 1: Whitelist Allowed Fields (Recommended)Only copy explicitly allowed fields from the request body:Option 2: Use Destructuring with Explicit FieldsOption 3: Use class-transformer with @Exclude()Add decorators to the Lead entity to exclude sensitive fields from assignment:Additional RecommendationConsider 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](https://cwe.mitre.org/data/definitions/915.html)[OWASP: Mass Assignment Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html)[OWASP API Security Top 10 - API6:2023 Unrestricted Access to Sensitive Business Flows](https://owasp.org/API-Security/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows/)[Node.js Security Best Practices](https://nodejs.org/en/docs/guides/security/)
CVSS v3.0: 7.7