Vulnerabilities
368 CVEs · NVD, GitHub Advisories, CISA KEV, FIRST EPSS, GitHub PoC repos
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
| CVE-2026-90580 | Server-Side Request Forgery in FlowiseAI Flowise Evaluations Endpoint FlowiseAI Flowise up to version 3.0.2 contains a server-side request forgery (SSRF) flaw in the Evaluations Endpoint, specifically in the axios.post call within packages/server/src/controllers/evaluations/index.ts. A remote attacker who manipulates the Host or X-Forwarded-Proto headers can trick the server into issuing requests toward attacker-influenced destinations, potentially reaching internal services, cloud metadata endpoints, or other network resources reachable from the Flowise host. The CVSS 4.0 vector indicates low privileges are required (PR:L), so an attacker needs at least limited authenticated access to the Flowise instance, and overall impact is rated low (2.1). Only Flowise versions that are no longer supported by the maintainer are affected, and a public exploit reference exists as a GitHub issue on the Flowise repository. EPSS is very low (0.2%, 12th percentile), the issue is not in the CISA KEV catalog, and no active exploitation in the wild has been reported. Do: Upgrade Flowise to version 3.1.3 or later, which contains the patch (commit 700137738bcaebefd4709021f6d6b0abcd7df0ac); since affected versions are unsupported, running them long-term is not viable. If upgrading is delayed, restrict access to the evaluations endpoint to trusted authenticated users, avoid blindly trusting Host/X-Forwarded-Proto headers from untrusted proxies, and egress-filter the Flowise server so it cannot reach internal services or metadata endpoints. Review server logs for unexpected outbound requests originating from the evaluations controller as evidence of exploitation attempts. | 2.1 | <1% | PoC |
| moderate≈ low thousands of internet-exposed self-hosted Flowise deployments | |
| CVE-2026-90535 | Unauthenticated Denial of Service in Flowise Text-to-Speech Abort Endpoint Flowise versions before 3.1.4 contain a missing-authorization flaw (CWE-862) in the /api/v1/text-to-speech/abort endpoint, which accepts user-supplied chatflowId and chatId values without verifying that the requester owns the session. An unauthenticated remote attacker who knows or guesses valid identifiers can submit abort requests that terminate other users' active chatflow predictions, causing targeted service disruption. The impact is limited to availability of individual chat sessions (CVSS 4.0: 6.3, medium) with no confidentiality or integrity impact. Anyone running a self-hosted Flowise instance on a version prior to 3.1.4, especially one exposed to untrusted networks, is affected. Exploitation status: a public advisory/PoC reference exists, EPSS is very low (0.2%, 16th percentile), and the flaw is not in the CISA KEV catalog, so no in-the-wild exploitation is known. Do: Upgrade Flowise to version 3.1.4 or later, where ownership verification for the abort endpoint is enforced. If immediate patching is not possible, place Flowise behind an authenticating reverse proxy or restrict network access so unauthenticated callers cannot reach /api/v1/text-to-speech/abort. Review application logs for abort requests referencing chatflowId/chatId values not associated with legitimate sessions as an indicator of abuse. | 6.3 group max | <1% | PoC |
| moderatelikely 1,000–10,000 internet-exposed self-hosted Flowise instances | |
| CVE-2026-52098 | Unauthenticated RCE in Flowise via /api/v1/prediction/ API Flowise 3.1.2 contains an improper code generation control flaw (CWE-94, code injection) in its /api/v1/prediction/ API endpoint. A remote, unauthenticated attacker can send a crafted request to this endpoint to execute arbitrary code on the server hosting Flowise, achieving full confidentiality, integrity, and availability impact (CVSS 9.8) under the application's privileges. Only version 3.1.2 is named in the available data; the full range of affected versions and any patched release are not specified. As of the provided data, the issue is not listed in CISA's KEV and no public proof-of-concept or confirmed in-the-wild exploitation is known. The critical rating reflects that the flaw is network-reachable with no privileges or user interaction required. Do: Inventory Flowise deployments and identify any running version 3.1.2; upgrade to a patched release as soon as the vendor publishes one (no fixed version is named in the current data), and monitor the Flowise GitHub repository for an official advisory. Until patched, restrict access to /api/v1/prediction/ by enforcing authentication, binding the service to internal interfaces, or adding reverse-proxy/firewall rules. Review logs for unexpected or unauthenticated requests to that endpoint as a sign of probing or exploitation. | 9.8 | — |
| moderate≈1,000–10,000 internet-exposed instances; total installs likely higher (self-hosted Docker/npm deployments) | ||
| CVE-2026-84869 | Missing authorization in ScreenConnect client allows unauthorized file execution CVE-2026-84869 is a critical authorization flaw (CWE-862 missing authorization, CWE-269 improper privilege management) in the ScreenConnect client, the endpoint-side agent of ConnectWise's widely used remote access and remote support platform, in which files can be transferred to a machine and executed during an active remote session without the expected authorization or without confirmation by the Host (technician). It is triggered in certain circumstances during an active session, with a network attack vector, low attack complexity, low privileges required, and no user interaction per the CVSS 3.1 vector. An actor who obtains or already holds access to a session context could thereby push and run files on the managed endpoint, potentially achieving code execution with high confidentiality, integrity, and availability impact (CVSS 3.1 score 9.9, scope changed). Only endpoints running the ScreenConnect client are affected; ScreenConnect servers are not impacted, and the affected client version ranges are governed by ConnectWise security advisory AV26-903 (not enumerated in the available data). The flaw is not currently known to be exploited: it is not in CISA KEV, no public proof of concept is known, and EPSS assigns a modest 0.4% probability of exploitation within the next 30 days (32nd percentile). Do: Follow ConnectWise security advisory AV26-903 and update ScreenConnect clients to the patched version it specifies, noting that ScreenConnect servers do not require remediation. Until patching is complete, monitor active remote sessions, require Host confirmation for file transfers, and review recent sessions on high-value endpoints for unexpected transferred or executed files; given no known exploitation and the active-session prerequisite, prioritize endpoints routinely accessed remotely. | 9.9 | <1% | KEV |
| massplausibly millions of managed endpoints running the ScreenConnect client agent | |
| CVE-2026-73483 | Authenticated Sandbox Escape Leading to RCE in Flowise Flowise versions 3.1.2 and earlier contain a sandbox escape in the vm2/@flowiseai/nodevm JavaScript sandbox (CWE-78) that allows code to break out of the intended isolation and execute on the host. An authenticated user with access to the /api/v1/node-custom-function endpoint triggers the flaw by supplying attacker-controlled executablePath and args parameters to puppeteer.launch(), which internally calls child_process.spawn() outside the sandbox boundary. Successful exploitation yields arbitrary OS command execution as the Flowise process user (root in the official Docker image) as well as arbitrary host file disclosure through Chromium's file:// URL handling. All deployments at or below 3.1.2 are affected; versions 3.0.8 through 3.1.2 are only exploitable when ALLOW_BUILTIN_DEP=true, while earlier versions are exploitable by default. No in-the-wild exploitation is currently known (not in CISA KEV, EPSS about 0.6%), but a public advisory with a proof-of-concept reference exists and the flaw is fixed in 3.1.3. Do: Upgrade Flowise (both flowise and flowise-components packages) to 3.1.3 or later. If upgrading is not immediately possible on 3.0.8-3.1.2, ensure ALLOW_BUILTIN_DEP is not enabled, and in all cases restrict /api/v1/node-custom-function to fully trusted users and avoid exposing Flowise to unauthenticated or low-trust accounts. Review process and API logs for unexpected child process spawns or Chromium launches with unusual executablePath/args, since these would indicate exploitation. | 9.4 group max | <1% | PoC |
| largeon the order of tens of thousands of self-hosted instances (roughly 10k-100k deployments) | |
| CVE-2026-71962 | Unauthenticated private file disclosure in Flowise via missing authorization Flowise versions 2.2.4 through 3.1.4 contain a missing-authorization flaw (CWE-862) in the POST /api/v1/openai-assistants-file/download endpoint, which is listed in the product's global authentication whitelist and therefore skips all session and API key verification. An unauthenticated attacker can call the endpoint with valid chatflowId, chatId, and fileName identifiers to download files from any chatflow on the instance, including private chatflows belonging to other workspaces or organizations. The attacker gains unauthorized read access to potentially sensitive chatbot files, crossing user, workspace, and organization boundaries with no privileges or user interaction required. Any deployment running an affected Flowise version is exposed, particularly self-hosted instances reachable over a network by untrusted users. Exploitation has not been confirmed in the wild: the flaw is not in CISA KEV, EPSS assigns a 0.7% 30-day exploitation probability, and one public proof-of-concept is available. Do: Upgrade Flowise to a patched release newer than 3.1.4; as an interim mitigation, remove POST /api/v1/openai-assistants-file/download from the global authentication whitelist or restrict network access to the instance. Review access logs for unauthenticated calls to this endpoint and treat files served by any chatflow, including other workspaces' private ones, as potentially disclosed. | 8.7 | <1% | PoC |
| large≈ tens of thousands of self-hosted instances (public internet scans show thousands exposed) | |
| CVE-2026-67620 | SSRF in Flowise Bypasses Deny List to Expose OCI/Alibaba Cloud Metadata Credentials Flowise through 3.1.4 contains a server-side request forgery flaw (CWE-918) in the SSRF guard implemented in httpSecurity.ts, where the DEFAULT_DENY_LIST omits the Oracle Cloud Infrastructure metadata endpoint 192.0.0.192 and the Alibaba Cloud metadata endpoint 100.100.100.200. An authenticated attacker triggers the flaw by calling the fetch-links API endpoint with a crafted URL parameter, bypassing deny-list validation including redirect-based bypasses; unauthenticated exploitation is also possible when URL-fetching nodes exist in public chatflows. The attacker forces the server to issue arbitrary GET requests to cloud instance metadata services, exposing instance identity data and role credentials on OCI or Alibaba Cloud deployments. Any Flowise deployment up to and including 3.1.4 is affected, with practical impact concentrated on instances running on Oracle Cloud Infrastructure or Alibaba Cloud. No in-the-wild exploitation is currently known (EPSS 0.3%, not in CISA KEV), but a public proof-of-concept is available. Do: Upgrade Flowise to a release newer than 3.1.4; as interim mitigation, restrict access to the fetch-links endpoint, require authentication on chatflows containing URL-fetching nodes, and block egress to 192.0.0.192 and 100.100.100.200 at the network level. Operators of OCI or Alibaba Cloud instances should review attached instance roles and rotate any role credentials that may have been exposed. | 6.3 | <1% | PoC |
| moderate~ a few thousand self-hosted instances, of which only the OCI/Alibaba Cloud subset can have credentials stolen | |
| CVE-2026-70636 | Unauthenticated OAuth2 Credential Refresh Bypass in Flowise Flowise through version 3.1.4 contains an authentication bypass (CWE-862) caused by prefix-based whitelist matching in the authentication middleware defined in packages/server/src/utils/constants.ts. An unauthenticated attacker can send a POST request to the OAuth2 credential refresh route with a trailing credential identifier, which slips past the whitelist check and bypasses all authentication and authorization controls. This triggers unauthorized OAuth token rotation against credentials belonging to any workspace, and the repeated forced refreshes can disrupt or invalidate dependent OAuth integrations relying on those credentials. The flaw affects any self-hosted Flowise deployment up to and including 3.1.4 where the server API is reachable by untrusted parties, and it is a bypass of the incomplete fix for CVE-2026-41273. A public proof-of-concept write-up exists, EPSS is currently low (0.4%), and there is no evidence of exploitation in the wild or a CISA KEV listing. Do: Upgrade Flowise to a version newer than 3.1.4 that corrects the middleware whitelist matching (verify the fix notes reference CVE-2026-70636, since 3.1.4's fix for CVE-2026-41273 is insufficient). Until patched, restrict network access to the Flowise server API (bind to internal interfaces, enforce VPN/IP allowlisting, and require an auth proxy) and treat previously configured OAuth2 credentials as potentially rotated by an attacker — review refresh/audit logs for unexpected token rotations and re-authorize any dependent OAuth integrations that break. | 8.7 group max | <1% | PoC |
| moderatelikely tens of thousands of self-hosted instances (order of magnitude ~10,000), only a subset internet-exposed | |
| CVE-2026-70470 | Homoglyph blacklist bypass in Flowise Python validator yields unauthenticated host RCE Flowise versions before 3.1.3 validate attacker-supplied Python code with an ASCII word-boundary blacklist regex in validatePythonCodeForDataFrame, which gates pyodide.runPythonAsync in the CSV Agent and Airtable Agent nodes. Because JavaScript regex word boundaries are ASCII-only while Python 3 NFKC-normalizes identifiers at parse time, homoglyph forms such as __cl𝐚ss__, __subcl𝐚sses__, and __b𝐮iltins__ slip past the blacklist and are parsed as their dangerous ASCII equivalents. An unauthenticated attacker who can submit code to these agent nodes gains arbitrary Python execution inside Pyodide and, via Pyodide's JS module interop, full OS command execution on the Flowise host (CVSS 4.0: 9.5, no privileges or user interaction required). Self-hosted Flowise deployments running any version prior to 3.1.3 with the vulnerable agent nodes reachable are affected; the issue is fixed in 3.1.3. A public GitHub security advisory documents the technical details, but EPSS is low (0.8% over 30 days), the flaw is not in CISA's KEV, and no exploitation in the wild is known. Do: Upgrade Flowise to version 3.1.3 or later immediately. Until patched, place Flowise behind authentication and network access controls so untrusted users cannot reach the CSV Agent or Airtable Agent nodes, and consider disabling those nodes. Review host logs for unexpected Python or OS command execution originating from the Flowise process, and rotate any secrets or API keys accessible from the host. | 9.5 group max | <1% | PoC |
| moderate≈1,000–10,000 internet-exposed self-hosted instances (estimate) | |
| CVE-2026-50736 | The pglogical queue mechanism, used to convey out-of-band commands such as replicated DDL from a publisher to a subscriber, executes message payloads on the sub The pglogical queue mechanism, used to convey out-of-band commands such as replicated DDL from a publisher to a subscriber, executes message payloads on the subscriber at the privilege level of the apply worker, which is equivalent to a PostgreSQL superuser in default installations. A party acting as the publisher can send crafted queue messages that cause arbitrary SQL to be executed on the subscriber as superuser, escalating from a role permitted to use pglogical to full superuser and breaking the isolation between tenants in shared deployments. To exploit the issue an attacker must be able to direct a subscription at an endpoint they control. In default installations this requires privileges normally reserved for a superuser, so the issue is most relevant to managed deployments where the ability to create subscriptions has been delegated to non-superuser roles. NVD description · AI analysis pending | 9.0 group max | <1% |
| — | ||
| CVE-2026-56271 | Flowise before 3.1.0 (affected versions 3.0.13 and earlier) uses weak hardcoded default JWT secrets ('auth_token', 'refresh_token') and default audience and iss Flowise before 3.1.0 (affected versions 3.0.13 and earlier) uses weak hardcoded default JWT secrets ('auth_token', 'refresh_token') and default audience and issuer values ('AUDIENCE', 'ISSUER') in the enterprise passport authentication middleware (packages/server/src/enterprise/middleware/passport/index.ts). When the corresponding environment variables (JWT_AUTH_TOKEN_SECRET, JWT_REFRESH_TOKEN_SECRET, JWT_AUDIENCE, JWT_ISSUER) are not set, the application silently falls back to these publicly known defaults, allowing an attacker to forge valid JWTs and impersonate any user, including administrators, resulting in authentication bypass. NVD description · AI analysis pending | 9.3 | <1% |
| — | ||
| CVE-2026-56278 +1 in the same advisory: …56277 | Flowise before 3.1.0 (affected versions 3.0.13 and earlier) uses a weak hardcoded default secret ('flowise') for the express-session middleware when the EXPRESS Flowise before 3.1.0 (affected versions 3.0.13 and earlier) uses a weak hardcoded default secret ('flowise') for the express-session middleware when the EXPRESS_SESSION_SECRET environment variable is not set (packages/server/src/enterprise/middleware/passport/index.ts). Because this default secret is publicly visible in the source code, an attacker can forge valid signed session cookies to impersonate any user and bypass authentication. NVD description · AI analysis pending | 9.3 group max | <1% |
| — |