Vulnerabilities

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.

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.

Tesseract OCR versions 5.5.3 and earlier contain a heap out-of-bounds write (CWE-787) in the LSTM recognition path: while earlier hardening added bounds checks to NetworkIO::CopyTimeStepGeneral and NetworkIO::Randomize, the NetworkIO::WriteTimeStepPart and NetworkIO::AddTimeStepPart functions in src/lstm/networkio.cpp remained unchecked. The flaw is triggered when the default LSTM engine processes a specially crafted .traineddata model file: in LSTM::Forward (src/lstm/lstm.cpp) the source_ buffer is sized from the independently deserialized na_ field, but WriteTimeStepPart writes a count driven by ns_ from the CI gate WeightMatrix dim1() value, so a crafted NT_LSTM layer with ns_ much larger than na_ overruns the heap buffer during the first recognition step. An attacker who can get such a model file processed gains heap corruption, causing a crash or potentially controlled memory corruption; CVSS 4.0 rates this 8.6 High with a local attack vector and no privileges or user interaction required. Anyone running Tesseract 5.5.3 or earlier is affected in principle, with practical risk concentrated in applications and pipelines that load third-party or otherwise untrusted .traineddata language models rather than only official trusted ones. No public proof-of-concept or in-the-wild exploitation is known, the flaw is not in CISA KEV, and no fixed release was available at the time of review.

Do: No fixed Tesseract release is available yet, so monitor the project for a patched version and upgrade as soon as one ships. Until then, avoid loading .traineddata files from untrusted or third-party sources on affected builds, verify the provenance and integrity of any externally sourced language models, and consider running OCR of external models in sandboxed, low-privilege workers to limit impact of a crash or heap corruption.

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.

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.

Improper Neutralization of Input During Web Page Generation ("Cross-site Scripting") vulnerability in Drupal Entity Browser allows Stored XSS. This issue affects Entity Browser versions: from 0.0.0 to 2.16.0.

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.

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.

CVE-2026-72898 is a critical SQL injection flaw (CWE-89, CVSS 4.0 score of 10) in Metabase, a widely used open-source business intelligence platform. A remote, unauthenticated attacker can send crafted input to the '/reset_password' database endpoint to inject arbitrary SQL into the underlying database. Successful exploitation grants the attacker administrator access to the connected Metabase instance, with confidentiality, integrity, and availability impacts rated high in the CVSS 4.0 vector. Any organization running an affected Metabase instance, particularly one exposed to the internet, is at risk. The flaw is a zero-day being exploited in the wild, was added to CISA's Known Exploited Vulnerabilities catalog on 2026-08-11, and carries a 94.2% EPSS probability of exploitation within 30 days (100th percentile).

Do: Upgrade promptly to the fixed Metabase release identified in the vendor's security advisory (no version numbers were provided in the available data), as the flaw is being exploited in the wild and is on CISA's KEV list under BOD 26-04. Until patched, restrict internet access to Metabase and limit reachability of the '/reset_password' endpoint to trusted networks. Hunt for compromise by reviewing access logs for anomalous requests to the reset-password endpoint and checking for unexpected administrator accounts or changed admin 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.

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.

Eclipse GlassFish versions in the 8.0.x line before 8.0.4 combine a cross-site request forgery (CSRF) issue with a server-side request forgery (SSRF, CWE-918) in the DownloadServlet ContentSources feature, which can send the domain's administrative REST token (gfresttoken) to an attacker-controlled host. The attack is triggered when an administrator who is logged into the GlassFish Admin Console is lured to attacker-controlled content, at which point the SSRF leaks the token to the attacker's server. Using the leaked token, the attacker gains full, unauthenticated control of the affected GlassFish domain — with high-impact confidentiality, integrity, and availability consequences per the 9.6 CVSS score — until the token expires. Only deployments running Eclipse GlassFish 8.0.x releases prior to 8.0.4 are affected, and the attack requires an admin actively using the Admin Console from a browser that can reach attacker-controlled pages. No in-the-wild exploitation is currently known; a public proof-of-concept report exists, the flaw is not in CISA KEV, and EPSS rates the 30-day exploitation probability at just 0.3%.

Do: Upgrade Eclipse GlassFish to 8.0.4 or later. As interim mitigation, restrict Admin Console access (e.g., limit the admin listener to trusted networks), avoid browsing untrusted sites while logged into the Admin Console, and review server logs for unexpected outbound requests to unfamiliar hosts that could indicate token leakage. If a leak is suspected, invalidate active admin sessions/tokens and rotate administrator credentials.

Eclipse Theia up to and including 1.73.1 binds an unauthenticated POST /file-upload endpoint in every filesystem-enabled deployment, and the handler writes the uploaded file to an attacker-supplied absolute path with overwrite enabled and no workspace confinement. Because the HTTP middleware in browser (non-Electron) deployments does not reject tokenless requests and multipart/form-data is CORS-safelisted, a malicious web page a user simply visits can trigger the write cross-origin with no preflight and no credentials. An attacker gains arbitrary file write anywhere the backend process can write, which can escalate to remote code execution, for example by overwriting a startup-executed file such as ~/.bashrc. Affected users are operators of Theia instances running in browser mode with the filesystem extension; Electron-mode deployments use a separate security token and are not affected through this path. Public proof-of-concept write-ups exist in the Eclipse vulnerability tracker, but there are no confirmed in-the-wild exploits, the flaw is not in CISA KEV, and EPSS puts 30-day exploitation probability at about 0.4%.

Do: Upgrade Eclipse Theia to the first patched release after 1.73.1 per the Eclipse security advisory (GitLab vulnerability report 595). Until then, restrict network access to the Theia backend, enforce connection-token checks on HTTP routes, or disable/restrict the /file-upload binding, and verify whether your deployment runs in browser mode versus Electron and is reachable from user web browsing.

Eclipse Mojarra versions 2.3 and later mishandle URLs in `DefaultFaceletFactory`, failing to properly sanitize or block remote URLs when loading Facelets. An attacker who can influence the Facelet URL supplied to the factory can cause the target server to fetch and process a remote Facelet as part of a normal request, without authentication. Because the included resource is processed with the privileges of the target server, this can expose restricted files such as `WEB-INF/web.xml` or `/etc/passwd`; per the CVSS score, impact is limited to confidentiality. Any application running on Mojarra 2.3 or later where user-controlled input can reach Facelet URL resolution is potentially affected. Exploitation has not been reported in the wild (not in CISA KEV), one public proof-of-concept reference exists, and EPSS estimates only about a 0.4% chance of exploitation in the next 30 days.

Do: Check whether your applications use Mojarra 2.3 or later and whether user input can influence Facelet URLs, then upgrade to the patched Mojarra release identified in the Eclipse security advisory (see the Eclipse vulnerability report work item for fixed versions). As interim mitigation, restrict or disable remote URL resolution in `DefaultFaceletFactory`, limit the server's outbound fetch capability, and ensure `WEB-INF` contents are not readable through application views.

In Eclipse Accessibility Tools Framework (ACTF) versions up to 1.6.0 (including source code versions up to v20260630 and ACTF based application miChecker versions up to 3.1.0), it has been identified that an XML External Entity (XXE) vulnerability exists. If this vulnerability is exploited, a malicious third party could gain access to local resources or internal network resources via computer running applications that use Eclipse ACTF, including miChecker.

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.