A Mass Assignment vulnerability in the PUT /api/v1/user endpoint allows authenticated users to directly modify restricted user fields, including the credential (password hash), bypassing the intended password change workflow.
Because the endpoint forwards the entire request body to the service layer without filtering, an attacker can override the credential field without providing the current password.
This bypasses several security protections including:
While the vulnerability cannot be used to modify other users due to an ID check in the controller, it allows attackers who obtain a temporary session (e.g., via token theft or XSS) to establish persistent account access.
The endpoint PUT /api/v1/user allows authenticated users to update their user profile.
The controller checks that the authenticated user matches the provided id, preventing direct IDOR:
const currentUser = req.user
const { id } = req.body
if (currentUser.id !== id) {
throw new InternalFlowiseError(StatusCodes.FORBIDDEN)
}
However, the controller forwards the entire request body directly to the service layer without filtering:
const user = await userService.updateUser(req.body)
Inside UserService.updateUser, the incoming data is merged into the existing user entity:
updatedUser = queryRunner.manager.merge(User, oldUserData, newUserData)
Because newUserData is derived from req.body and there is no field allowlist, any field present in the User entity may be modified.
This includes sensitive fields such as:
The service implements a secure password change workflow that requires the following fields:
oldPassword
newPassword
confirmPassword
Example code:
if (newUserData.oldPassword && newUserData.newPassword && newUserData.confirmPassword) {
if (!compareHash(newUserData.oldPassword, oldUserData.credential)) {
throw new InternalFlowiseError(StatusCodes.BAD_REQUEST)
}
newUserData.credential = this.encryptUserCredential(newUserData.newPassword)
}
However, this logic can be bypassed by directly supplying a credential value in the request body.
Because the merge operation applies all fields from newUserData, the supplied credential hash will overwrite the stored password hash.
Step 1 - Authenticate
Login as any normal user and obtain a valid JWT token.
POST /api/v1/auth/login
Step 2 - Generate a password hash
Generate a bcrypt hash for a password you control.
Example:
bcrypt("attacker_password")
Example hash:
$2b$10$abc123examplehashvalue...
Step 3 - Send crafted update request
PUT /api/v1/user
Authorization: Bearer <JWT_TOKEN>
Content-Type: application/json
{
"id": "<your-user-id>",
"credential": "$2b$10$abc123examplehashvalue..."
}
Step 4 - Login with attacker password
The password hash in the database is replaced by the supplied value.
The attacker can now authenticate using:
attacker_password
without ever providing the previous password.
This vulnerability allows authenticated users to bypass the password change security controls.
Security protections that are bypassed include:
current password verification
password hashing enforcement
password policy validation
session invalidation on password change
Although the controller prevents modification of other users' accounts, the vulnerability enables persistence after account compromise.
Example attack scenario:
| Software | From | Fixed in |
|---|---|---|
flowise
|
- | 3.1.2 |
A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.
CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.
A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.
Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.
Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.
SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.