GHSA-jc5m-wrp2-qq38: PII Disclosure via Flowise Forgot Password Endpoint

Flowise, an open-source UI for building LLM flows, contains an information disclosure vulnerability in its user account management API. The flaw resides in the /api/v1/account/forgot-password endpoint, which is designed to initiate the password recovery process. This endpoint operates without authentication to allow users who have lost their credentials to regain access.

In affected versions, the application fails to sanitize the response sent to the client after a successful email lookup. Instead of returning a generic success message or an empty response, the server serializes and returns the complete database record of the identified user. This behavior constitutes a violation of CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) and CWE-204 (Observable Response Discrepancy), turning a standard account recovery feature into a high-fidelity user enumeration vector.

The root cause of this vulnerability is the insecure implementation of the controller logic handling password reset requests. In a secure design, a forgot-password endpoint should perform two distinct actions: verify the email exists and trigger an out-of-band notification (email) containing the reset instructions. Critically, the HTTP response to the requester should remain constant regardless of whether the email exists, typically returning a 200 OK with a generic message.

However, the Flowise controller in versions <= 3.0.5 directly returns the result of the database query to the HTTP response stream. When the backend service UserService locates a user by the provided email, it returns the user entity (an object containing schema fields) to the controller. The controller then pipes this object directly into res.json(). This bypasses the necessary view-layer abstraction or data transfer object (DTO) mapping that would normally filter out sensitive internal fields like id, createdAt, updatedAt, and status.

The vulnerability exists in the server-side logic handling the POST request to the forgot-password route. The following comparison illustrates the unsafe direct return of the user object versus the sanitized approach.

Vulnerable Implementation (Conceptual): The controller receives the email, queries the database, and immediately returns the result. If user is found, the entire object is serialized to JSON and sent to the client.

// Vulnerable Controller Logic
export const forgotPassword = async (req, res) => {
    const { email } = req.body;
    try {
        // The service finds the user and potentially generates a reset token
        const user = await usersService.forgotPassword(email);
        
        // CRITICAL FLAW: The raw user object is returned to the public client
        return res.json(user);
    } catch (error) {
        return res.status(500).send(error);
    }
}

Secure Implementation (Patch Logic): The fix involves decoupling the database result from the API response. The controller should trigger the email logic but return a static message to the client, preventing data leakage.

// Secure Controller Logic
export const forgotPassword = async (req, res) => {
    const { email } = req.body;
    try {
        // The service handles the lookup and email sending internally
        await usersService.forgotPassword(email);
        
        // FIX: Return a generic message regardless of the outcome
        return res.json({
            code: 200,
            message: 'If an account with that email exists, we sent you an email.'
        });
    } catch (error) {
        // Log the error internally, but do not expose details to the user
        return res.status(500).send('Internal Server Error');
    }
}

Exploitation of this vulnerability is trivial and requires no authentication or special tooling. An attacker simply sends a standard HTTP POST request to the target Flowise instance. The only prerequisite is network access to the application's API port (typically exposed for UI functionality).

Attack Scenario:

1. The attacker creates a list of target email addresses (e.g., corporate emails or common usernames).
2. The attacker scripts a loop to send POST requests to /api/v1/account/forgot-password.
3. The attacker parses the JSON response. If the response contains a user ID and name, the user is confirmed valid.

Proof of Concept:

curl -X POST "https://flowise.target.local/api/v1/account/forgot-password" \
     -H "Content-Type: application/json" \
     -d '{"email": "admin@example.com"}'

Leaked Response Data: Instead of a generic "Email sent" message, the server responds with:

{
  "id": "550e8400-e29b-41d4-a716-446655440000",
  "name": "System Administrator",
  "email": "admin@example.com",
  "status": "ACTIVE",
  "createdAt": "2024-01-15T10:30:00.000Z",
  "updatedAt": "2025-02-10T14:20:00.000Z"
}

This confirms the account exists, provides the full name for social engineering, and reveals account age (via createdAt), which helps identify high-value early adopters or administrative accounts.

The direct impact is the unauthenticated disclosure of PII (Personally Identifiable Information). While this does not immediately grant access to the account, it significantly aids attackers in the reconnaissance phase of an attack chain.

Risk Breakdown:

• User Enumeration: Attackers can validate email lists against the Flowise instance, building a verified directory of users.
• Social Engineering: Knowledge of the name, email, and account status allows for targeted phishing campaigns. An attacker can impersonate support staff, referencing the victim's exact account creation date to establish credibility.
• Precursor to Account Takeover: This vulnerability is closely linked to CVE-2025-58434. In some configurations, the returned user object may include the tempToken used for password resets. If that token is present in the leak, the impact escalates immediately from Information Disclosure to Critical Account Takeover, as the attacker can use the token to set a new password.