CVE-2025-58434

What it actually does

An unauthenticated forgot-password API in Flowise issues a valid password-reset tempToken in the HTTP response without proving control of the target mailbox or requiring any prior login. An attacker who knows or guesses a user identifier can obtain that token and complete a password reset, fully impersonating the victim. The same unauthenticated token-disclosure behavior exists on the hosted cloud service and on self-hosted deployments that expose the API. Impact is confidentiality, integrity, and availability of the victim account (CVSS 9.8, AuthenticationBypass family).

Why it matters to the business

Successful abuse is complete account takeover of Flowise users, including administrators, which can expose stored credentials, connected model keys, workflow definitions, and downstream systems those workflows touch. The issue has been public for well over a year, has weaponized exploit maturity, and an EPSS around 0.50 that ticked upward over 30 days, so opportunistic scanning and automated ATO are realistic. Both cloud.flowiseai.com tenants and internet-exposed self-hosted instances are in scope; lingering unpatched deployments remain a high operational and compliance risk even though this CVE is not on CISA KEV.

How an attack unfolds

An attacker locates a Flowise UI or API (cloud or self-hosted) and invokes the public forgot-password function for a chosen user. Instead of only emailing a reset link, the endpoint returns a usable tempToken in the response body. The attacker then submits that token to the password-reset function, sets a password they control, and signs in as the victim. No user interaction, credentials, or mailbox access are required. With weaponized tooling in circulation, this is typically automated against exposed instances rather than a bespoke intrusion. Post-takeover activity commonly includes changing remaining credentials, harvesting API keys and flow configurations, and using the platform as a pivot into connected services.

How to fix it

Upgrade every Flowise deployment (self-hosted Git builds and any packaged release derived from them) to a revision that includes commit 9e178d68873eb876073846433a596590d3d9c863 or later, where the forgot-password handler no longer returns a live tempToken to unauthenticated callers. Prefer the latest maintained Flowise release that contains that commit. Until upgraded: restrict the API to trusted networks, put the application behind authentication-aware reverse proxies, disable or tightly rate-limit public password-reset routes, and force password resets plus session invalidation for all users after patching. Cloud customers should confirm the hosted service has applied the same fix and rotate any credentials that may have been exposed.

How to confirm the fix worked

Confirm running code includes commit 9e178d68873eb876073846433a596590d3d9c863 (or a later release that lists this CVE as fixed). From a non-authenticated vantage, exercise the forgot-password function against a test account and verify the response does not contain a tempToken or other reset secret and that a reset cannot complete without the out-of-band email (or equivalent) step. Inventory all self-hosted listeners and cloud tenants, and treat any pre-fix build as exposed. After upgrade, verify existing sessions were invalidated and that password-reset audit events no longer show token material in responses.

Typical attack path

1. Discover an internet-reachable Flowise cloud tenant or self-hosted instance that still exposes the unauthenticated forgot-password API.
2. Identify a target account (email, username, or other identifier used by the reset flow).
3. Call the forgot-password function without authentication so the service mints and returns a tempToken for that account.
4. Submit the disclosed tempToken to the password-reset function and set a new password.
5. Authenticate as the victim and abuse the account (exfiltrate secrets, modify flows, or persist access).

How to detect it

This CVE is not in KEV, but exploit maturity is weaponized and EPSS is high, so treat pre-fix internet-exposed instances as likely probed. Review reverse-proxy, WAF, and Flowise application logs around the forgot-password and password-reset APIs for unauthenticated callers, bursts of reset requests across many user identifiers, responses or logs that record tempToken values, and password-change events that are not preceded by a legitimate email-click or MFA step. Correlate with new sessions, API-key creation, flow exports, and outbound calls to unfamiliar model or webhook endpoints shortly after a reset. On hosts, look for unexpected Flowise process restarts tied to config or user-database changes. Cloud tenants should review account-activity and audit exports for the same sequence. Absence of logs does not prove non-exploitation if the app was not logging request bodies or authn failures.

• forgot-password
• tempToken
• /api/v1/forgot-password
• /api/v1/account/forgot-password
• /forgot-password
• password reset
• reset password
• cloud.flowiseai.com

What your security team should do

• Patch all Flowise Git/self-hosted deployments to a build containing 9e178d68873eb876073846433a596590d3d9c863 or newer immediately; do not wait for a KEV listing.
• Assume ATO is possible on any instance that was internet-exposed before the fix: force password resets, revoke sessions and API keys, and rotate secrets stored in flows.
• Remove public access to password-reset and related account APIs; require network controls and WAF/rate limits even after patching.
• Hunt historical logs for unauthenticated forgot-password activity followed by successful password changes (weaponized exploit maturity and ~50% EPSS).
• Add regression tests so forgot-password responses never include tempToken or equivalent secrets, and subscribe to Flowise security releases.