GHSA-X2G5-FVC2-GQVP: Insufficient Bcrypt Salt Rounds in Flowise

A security audit of the flowise npm package revealed a critical configuration weakness in its authentication mechanism. The application relies on bcrypt for password hashing, a standard algorithm designed to be computationally expensive to resist brute-force attacks. However, the implementation utilized a cost factor (salt rounds) of 5, which is drastically lower than the current OWASP recommendation of 10 or higher.

The vulnerability is classified under CWE-916: Use of Password Hash with Insufficient Computational Effort. While bcrypt is theoretically secure, its security relies entirely on the work factor. A factor of 5 corresponds to $2^5$ (32) iterations, whereas the standard factor of 10 corresponds to $2^{10}$ (1024) iterations. This exponential difference means hashes generated by vulnerable versions of Flowise are approximately 32 times easier to crack than those adhering to minimum security standards.

The root cause resides in the encryption.util.ts and account.service.ts modules within the Flowise server. The application hardcoded or defaulted the salt rounds parameter for bcrypt to 5 without providing a mechanism to enforce a higher minimum for existing users.

Bcrypt's design allows the cost factor to be embedded in the hash string (e.g., $2b$05$...). When validating a password, the library reads this cost from the stored hash. Because the application strictly generated new hashes with cost 5, the entire user database accumulated weak credentials over time. There was no logic to detect "legacy" weak hashes during authentication and transparently upgrade them to a secure work factor.

The remediation in version 2.2.6 introduces two key changes: increasing the default cost factor and implementing a "hash upgrade" strategy. The following analysis highlights the changes in the encryption utility and the login flow.

1. Increasing the Work Factor

The default rounds were increased to 10. The code also now respects an environment variable, allowing administrators to increase this further.

// packages/server/src/enterprise/utils/encryption.util.ts
 
export function getPasswordSaltRounds(): number {
    // FIX: Default increased to 10, configurable via ENV
    return parseInt(process.env.PASSWORD_SALT_HASH_ROUNDS || '10', 10)
}

2. The Upgrade Logic (Re-hashing)

Crucially, simply changing the default only protects new users. To fix existing users, the system checks the rounds of the stored hash during successful login. If the rounds are insufficient, it re-hashes the plaintext password with the new cost and updates the database.

// packages/server/src/enterprise/services/account.service.ts
 
// ... inside the login function ...
 
// Check if the stored hash uses fewer rounds than the current policy
if (hashNeedsUpgrade(user.credential!, getPasswordSaltRounds())) {
    // Re-hash the plaintext password with 10 rounds
    const newHash = getHash(password);
    
    // Persist the stronger hash to the database immediately
    await this.userService.saveUser({ ...user, credential: newHash });
}

This vulnerability is not exploitable directly over the network; it is a post-compromise weakness. The primary attack vector involves an attacker first gaining read access to the Flowise database—typically via SQL Injection, a Local File Inclusion (LFI) vulnerability reading the SQLite file, or a leaked backup.

Once the attacker extracts the credential column, they can mount an offline attack using tools like Hashcat or John the Ripper. Because the work factor is 5 ($2^5 = 32$ iterations), a modern consumer GPU (e.g., RTX 4090) can calculate billions of candidate hashes per second against this target.

For context:

• Cost 5: An attacker can likely crack complex 8-character passwords in minutes.
• Cost 10: The same attack would take roughly 32 times longer, pushing complex passwords out of the "trivial" cracking range into "resource-intensive."

The impact is primarily a loss of confidentiality regarding user credentials. If an attacker cracks the administrative password for a Flowise instance, they gain full control over the application.

Since Flowise is an LLM orchestration tool, an administrator can likely:

1. Access sensitive API keys (OpenAI, Anthropic, etc.) stored in the tool.
2. Modify LLM flows to inject malicious prompts or exfiltrate data.
3. Execute arbitrary code if the Flowise instance allows custom JavaScript execution nodes.

Furthermore, if users reuse passwords across services, this breach could lead to lateral movement within the organization.