{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.1.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "flowise"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-20T15:44:40Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nA 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.\n\nBecause 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.\n\nThis bypasses several security protections including:\n\n- old password verification\n- password hashing enforcement\n- password policy validation\n- session invalidation on password change\n\nWhile 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.\n\n### Details\nThe endpoint **PUT /api/v1/user** allows authenticated users to update their user profile.\n\nThe controller checks that the authenticated user matches the provided id, preventing direct IDOR:\n\n```typescript\nconst currentUser = req.user\nconst { id } = req.body\n\nif (currentUser.id !== id) {\n    throw new InternalFlowiseError(StatusCodes.FORBIDDEN)\n}\n```\n\nHowever, the controller forwards the entire request body directly to the service layer without filtering:\n\n```typescript\nconst user = await userService.updateUser(req.body)\n```\n\nInside UserService.updateUser, the incoming data is merged into the existing user entity:\n\n```typescript\nupdatedUser = queryRunner.manager.merge(User, oldUserData, newUserData)\n```\n\nBecause newUserData is derived from req.body and there is no field allowlist, any field present in the User entity may be modified.\n\nThis includes sensitive fields such as:\n\n- credential\n- tempToken\n- tokenExpiry\n- status\n- email\n\nThe service implements a secure password change workflow that requires the following fields:\n\n```typescript\noldPassword\nnewPassword\nconfirmPassword\n\n```\n\nExample code:\n\n```typescript\nif (newUserData.oldPassword \u0026\u0026 newUserData.newPassword \u0026\u0026 newUserData.confirmPassword) {\n    if (!compareHash(newUserData.oldPassword, oldUserData.credential)) {\n        throw new InternalFlowiseError(StatusCodes.BAD_REQUEST)\n    }\n\n    newUserData.credential = this.encryptUserCredential(newUserData.newPassword)\n}\n```\nHowever, this logic can be bypassed by directly supplying a credential value in the request body.\n\nBecause the merge operation applies all fields from newUserData, the supplied credential hash will overwrite the stored password hash.\n\n### PoC\n**Step 1 -  Authenticate**\n\nLogin as any normal user and obtain a valid JWT token.\n\n**POST /api/v1/auth/login**\n\n**Step 2 - Generate a password hash**\n\nGenerate a bcrypt hash for a password you control.\n\nExample:\n\nbcrypt(\"attacker_password\")\n\nExample hash:\n\n$2b$10$abc123examplehashvalue...\n\nStep 3 - Send crafted update request\n\n```http\nPUT /api/v1/user\nAuthorization: Bearer \u003cJWT_TOKEN\u003e\nContent-Type: application/json\n\n{\n  \"id\": \"\u003cyour-user-id\u003e\",\n  \"credential\": \"$2b$10$abc123examplehashvalue...\"\n}\n```\n\nStep 4 - Login with attacker password\n\nThe password hash in the database is replaced by the supplied value.\n\nThe attacker can now authenticate using:\n\n**attacker_password**\n\nwithout ever providing the previous password.\n\n### Impact\nThis vulnerability allows authenticated users to bypass the password change security controls.\n\nSecurity protections that are bypassed include:\n\ncurrent password verification\n\npassword hashing enforcement\n\npassword policy validation\n\nsession invalidation on password change\n\nAlthough the controller prevents modification of other users\u0027 accounts, the vulnerability enables persistence after account compromise.\n\nExample attack scenario:\n\n- An attacker temporarily obtains a user\u0027s session (XSS, token leak, shared device, etc.)\n- The attacker sends the crafted update request with a new password hash\n- The attacker now permanently controls the account\n- Authentication logic bypass\n- Privilege persistence after compromise\n- Weak account recovery guarantees",
  "id": "GHSA-59fh-9f3p-7m39",
  "modified": "2026-05-20T15:44:40Z",
  "published": "2026-05-20T15:44:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-59fh-9f3p-7m39"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/FlowiseAI/Flowise"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Flowise: Mass Assignment in PUT /api/v1/user Allows Authenticated Users to Override Password Hash and Bypass Password Change Verification"
}