CVE-2026-30822: 
Flowise vulnerability analysis and mitigation

CVE-2026-30822 is a Mass Assignment vulnerability in FlowiseAI's Flowise platform affecting the POST /api/v1/leads endpoint. It allows any unauthenticated remote attacker to inject arbitrary values into internal database entity fields (id, createdDate, chatId) that should be auto-generated by the server. All Flowise versions up to and including 3.0.12 (npm package) are affected; the issue was fixed in version 3.0.13. The vulnerability was published on March 5, 2026, and carries a CVSS v3.0 base score of 7.7 (High) (GitHub Advisory, Flowise Advisory).

The root cause is classified as CWE-915 (Improperly Controlled Modification of Dynamically-Determined Object Attributes). In /packages/server/src/services/leads/index.ts, the createLead function calls Object.assign(newLead, body), which blindly copies all properties from the HTTP request body onto the TypeORM Lead entity — including fields decorated with @PrimaryGeneratedColumn('uuid') and @CreateDateColumn() that TypeORM is supposed to auto-generate. The /api/v1/leads endpoint is explicitly whitelisted in constants.ts (WHITELIST_URLS), meaning no authentication is required to reach it. An attacker simply sends a crafted JSON POST body containing the target internal fields to override them before the entity is persisted to the database (GitHub Advisory, Flowise Advisory).

Successful exploitation allows an unauthenticated attacker to corrupt lead records by injecting arbitrary values for the primary key (id), creation timestamp (createdDate), and chat identifier (chatId). This enables ID collision attacks that may overwrite existing records or cause database conflicts, audit trail manipulation by backdating records to arbitrary timestamps (e.g., epoch 1970), and unauthorized association of leads with arbitrary chatflows. While direct sensitive data exfiltration is not the primary risk, the integrity violation undermines data reliability, compliance posture, and can serve as a foundation for chained attacks against business logic (GitHub Advisory, Flowise Advisory).

A detailed proof-of-concept using curl commands is publicly available in the GitHub Security Advisory, demonstrating step-by-step exploitation with no authentication required (Flowise Advisory). There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.044% (0.455% per the advisory page), placing it in the 64th percentile for exploitation probability within 30 days. The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (GitHub Advisory).

1. Reconnaissance: Identify internet-facing Flowise instances (versions ≤ 3.0.12) using tools like Shodan or Censys, or by probing GET /api/v1/ping to confirm the service is running.
2. Confirm endpoint accessibility: Verify the /api/v1/leads endpoint is reachable without authentication by sending a baseline POST request with only legitimate fields (chatflowid, name, email, phone) and observing a 200 response with auto-generated id and createdDate.
3. Inject custom primary key (ID collision): Send a crafted POST request including an attacker-controlled id field:

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

4. Inject fake timestamp (audit manipulation): Send a request with a manipulated createdDate to backdate or falsify records:

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

5. Combined mass assignment: Inject all three internal fields simultaneously (id, createdDate, chatId) in a single request to fully control the persisted lead record, confirming all fields are accepted as-is in the HTTP 200 response (Flowise Advisory).

• Network: Unexpected POST requests to /api/v1/leads containing JSON body fields id, createdDate, or chatId alongside standard lead fields; requests originating from unusual or external IP addresses with no prior session context.
• Logs: Application/web server access logs showing POST /api/v1/leads with HTTP 200 responses and request bodies containing UUID-formatted id values or ISO 8601 createdDate values not matching the current time; repeated requests from the same IP with varying injected UUIDs.
• Database: Lead records with createdDate values far in the past (e.g., 1970-01-01) or future; id fields containing non-standard or sequential UUIDs inconsistent with server-generated UUIDs; chatId values that do not correspond to any legitimate chat session; duplicate or conflicting primary key entries (Flowise Advisory).

Upgrade Flowise to version 3.0.13 or later, which includes the fix "Fix Mass Assignments in Leads Endpoint" (PR #5668) (Flowise Release). If immediate upgrade is not possible, implement a WAF rule or reverse proxy filter to block POST requests to /api/v1/leads that contain id, createdDate, or chatId fields in the request body. The recommended long-term code fix is to replace Object.assign(newLead, body) with an allowlist-based approach that only copies permitted fields (chatflowid, name, email, phone) from the request body, allowing TypeORM decorators to auto-generate protected fields (GitHub Advisory).

The vulnerability was responsibly disclosed by researcher yueyueL and published to the GitHub Advisory Database on March 5, 2026. The Flowise maintainer team addressed the issue promptly in the 3.0.13 release. Coverage appeared on security aggregators including CVEFeed, CIRCL, and The Hacker Wire shortly after disclosure, and Check Point published a defense advisory (CPAI-2026-3253) referencing the vulnerability (Flowise Advisory, Flowise Release).