GHSA-59FH-9F3P-7M39: Mass Assignment in Flowise Profile Update Endpoint

Flowise relies on an API endpoint located at PUT /api/v1/user to handle updates to user profile information. This endpoint correctly implements authorization checks to ensure that a user can only modify their own profile data. This specific check prevents direct insecure direct object reference (IDOR) attacks against other accounts.

However, the endpoint lacks input validation and filtering on the attributes provided in the request body. This absence of filtering leads to a mass assignment vulnerability, classified under CWE-915.

An authenticated attacker can supply arbitrary database fields within the JSON payload. The application blindly maps these fields to the underlying user entity. This allows unauthorized modification of sensitive account parameters, including the user's password hash.

The vulnerability originates in the request handling logic of the user controller. The application extracts the id from the request body and compares it against the authenticated session token. If the IDs match, the controller forwards the entire req.body object to the service layer without restricting the allowed keys.

Within UserService.updateUser, the application leverages the TypeORM object-relational mapper to update the database record. The application calls the merge function, passing the existing user data and the unvalidated newUserData derived directly from the HTTP request.

The Flowise user database schema utilizes a column named credential to store the bcrypt-hashed password. Because the TypeORM merge function overwrites existing entity properties with any matching keys from the input object, supplying a credential key in the JSON body modifies this secure field. The system processes the database update without executing the standard password change workflow.

The vulnerable controller implementation demonstrates the missing input sanitization. The code verifies the user identity but immediately passes the raw payload to the database abstraction layer.

// Vulnerable Controller Logic
const currentUser = req.user;
const { id } = req.body;
 
if (currentUser.id !== id) {
    throw new InternalFlowiseError(StatusCodes.FORBIDDEN);
}
// req.body is passed entirely to the service
const user = await userService.updateUser(req.body);

The service layer subsequently executes the merge operation. TypeORM applies all key-value pairs from newUserData onto the oldUserData object, replacing internal attributes.

// Vulnerable Service Logic
updatedUser = queryRunner.manager.merge(User, oldUserData, newUserData);

The remediation implemented in Flowise version 3.1.2 via Pull Request #5986 introduces strict allowlisting. The controller now extracts only explicitly permitted fields, such as name and email, from the request body. Any extraneous fields like credential are discarded before the service layer invokes the database update operation.

Exploitation requires an active authenticated session and knowledge of the underlying database schema. The attacker first generates a valid bcrypt hash for a password they control using standard cryptographic tools.

The attacker intercepts or crafts a PUT request targeting the /api/v1/user endpoint. They inject the credential field containing the newly generated hash into the JSON payload alongside their valid user ID.

PUT /api/v1/user
Authorization: Bearer <JWT_TOKEN>
Content-Type: application/json
 
{
  "id": "<your-user-id>",
  "credential": "$2b$10$abc123examplehashvalue..."
}

Upon processing the request, the application replaces the legitimate password hash in the database. The attacker can subsequently authenticate using the new password. This technique successfully bypasses the requirement to provide the current password, finalizing account takeover without utilizing the standard credential rotation UI.

This mass assignment vulnerability facilitates persistent account compromise. If an attacker gains transient access to a user session through cross-site scripting (XSS) or API token theft, they can permanently backdoor the account by overwriting the credentials.

By overwriting the password hash directly, the attacker evades multiple security controls. The application fails to enforce password complexity policies, does not validate the old password, and fails to invalidate existing active sessions during the unauthorized credential rotation.

The CVSS v4.0 score of 5.3 reflects the specific constraints of the attack. The vulnerability requires a low-privileged authenticated session (PR:L) and specific knowledge of internal field names (AC:H). The impact is strictly isolated to the integrity of the individual user account (VI:H).

Administrators must upgrade Flowise to version 3.1.2 or later to address this vulnerability. The updated release implements field-level allowlisting in the user update controller, preventing the mass assignment condition.

Organizations unable to apply the patch immediately can deploy Web Application Firewall (WAF) rules to inspect traffic destined for PUT /api/v1/user. WAF policies should explicitly block requests containing restricted JSON keys, specifically credential, tempToken, and status.

Development teams utilizing object mappers like TypeORM or Sequelize must avoid passing raw HTTP input directly to merge or update functions. Implementing Data Transfer Objects (DTOs) with strict validation schemas prevents mass assignment flaws by isolating the API presentation layer from internal database models.