CVE-2026-67620: Flowise Cloud Metadata SSRF Bug - What It Means for Your Business and How to Respond

Introduction

CVE-2026-67620 is a security vulnerability affecting Flowise, an open-source platform used to build and run artificial intelligence workflows, chatbots, and agent-based applications. If your organization operates Flowise version 3.1.4 or earlier, particularly in Oracle Cloud Infrastructure or Alibaba Cloud, this issue deserves immediate review.

The vulnerability could allow an attacker to make your Flowise server request sensitive information from internal cloud services. In certain configurations, that information can include credentials associated with the cloud system hosting the application. The business consequence is not limited to the AI workflow itself. It can extend to other systems, data, and cloud resources that the compromised credentials can access.

This post explains the vulnerability in business terms, outlines who may be affected, and provides practical response steps. A technical appendix is included for security, infrastructure, and application teams responsible for validation and remediation.

S1 — Background & History

CVE-2026-67620 was published on August 8, 2026, and concerns Flowise versions through 3.1.4. The record was submitted by VulnCheck and is tracked in the National Vulnerability Database, or NVD, as a server-side request forgery vulnerability. It received a CVSS 4.0 base score of 6.3, classified as Medium severity by the assigning organization.

In plain language, the weakness can cause a Flowise server to retrieve information from destinations it should never contact. The affected security control failed to block two cloud-provider metadata addresses used by Oracle Cloud Infrastructure and Alibaba Cloud. Metadata services can supply details about a cloud virtual machine, including identity information and temporary permissions.

The public record was added to NVD on August 8 and last modified there on August 10, 2026. NVD currently marks the CVE as unsupported when assigned and has not supplied its own enrichment score. The published record identifies Flowise through version 3.1.4 as affected and maps the vulnerability to CWE-918, Server-Side Request Forgery.

S2 — What This Means for Your Business

If you use Flowise to support customer service, internal knowledge search, sales enablement, automation, or AI-assisted operations, CVE-2026-67620 can create risk beyond the application team. A successful attack may expose credentials connected to the cloud system where Flowise runs. Those credentials could permit access to cloud services based on the permissions assigned to that workload.

For your operations, this can mean unauthorized use of cloud resources, disruption while systems are investigated, emergency credential rotation, and delayed AI-service delivery. If Flowise supports public-facing workflows or business-critical internal processes, you may need to temporarily limit features that fetch content from external web addresses.

For data protection, the main concern is that cloud credentials can be used as a stepping stone. The extent of exposure depends on the access rights assigned to the affected cloud workload. Broad permissions increase the potential impact; tightly scoped permissions reduce it but do not eliminate the need to investigate.

For your reputation and compliance posture, the incident may trigger customer notifications, contractual security obligations, evidence-preservation requirements, and reporting duties, depending on the data and systems accessible through the cloud role. Canadian and U.S. organizations should involve privacy, legal, and compliance stakeholders early if indicators suggest credentials or regulated information may have been exposed.

S3 — Real-World Examples

A regional bank: A regional bank uses Flowise to support an internal employee assistant that retrieves policy documents and approved public resources. If the Flowise environment is hosted on Oracle Cloud Infrastructure and a compromised account exploits the issue, the attacker may obtain cloud identity information and use it to explore services available to the application’s cloud role. The bank could face investigation costs, service interruption, and heightened scrutiny over safeguards protecting financial and customer information.

A mid-sized Canadian retailer: A retailer runs an AI support assistant that helps staff summarize product, inventory, and supplier information. A publicly accessible workflow with a URL-fetching feature may increase exposure because the vulnerability can be reachable without a user login in certain public-chatflow configurations. The business may need to disable features, assess cloud activity, and rotate credentials while preserving continuity for customer support.

A healthcare software provider: A healthcare technology company uses Flowise to prototype documentation and support workflows. Even if the Flowise server does not directly contain patient records, cloud credentials retrieved through the flaw could enable access to connected storage, logs, or services if permissions are overly broad. The organization could incur incident-response expenses and contractual risk with healthcare customers.

A growing technology firm: A software-as-a-service company deploys Flowise rapidly to test customer-facing AI features. An attacker might use the vulnerability to access temporary cloud credentials, then use those permissions to consume resources or inspect environment data. The immediate cost may be cloud spend and engineering disruption, followed by longer-term pressure from enterprise customers to demonstrate stronger security controls.

S4 — Am I Affected?

• You are likely affected if you run Flowise version 3.1.4 or any earlier version, including self-hosted instances deployed through source, containers, or package-based installations.
• You face elevated risk if your Flowise deployment runs on Oracle Cloud Infrastructure or Alibaba Cloud, where the omitted metadata service addresses are relevant.
• You should treat the issue as urgent if your Flowise application can fetch user-supplied web addresses or includes URL-fetching workflow nodes.
• You may have unauthenticated exposure if you operate public Flowise chatflows that include URL-fetching nodes.
• You should investigate even if Flowise is internal-only, because an authenticated user or compromised account could still provide a malicious web address.
• You are less directly exposed if you do not use Flowise, operate only a supported replacement, or can verify that Flowise cannot reach cloud metadata services or internal network destinations.
• You still need review if Flowise sits behind a firewall, because the vulnerable request originates from the Flowise server itself.

Key Takeaways

• CVE-2026-67620 affects Flowise through version 3.1.4 and can allow the server to retrieve information from cloud metadata services it should not access.
• Organizations operating Flowise on Oracle Cloud Infrastructure or Alibaba Cloud should prioritize assessment because the flaw concerns metadata endpoints used by those platforms.
• Public chatflows with URL-fetching functionality may create a path for exploitation without a user login, making exposure management especially important.
• Because Flowise has been sunset and no vendor patch is expected, you should plan compensating controls and migration to a supported alternative rather than relying on a future update.
• A focused security assessment can validate real exposure, review cloud permissions, and identify whether related architecture weaknesses increase the potential impact.

Call to Action

CVE-2026-67620 is a reminder that AI workflow platforms must be assessed as part of your wider cloud security posture. IntegSec can help you validate whether Flowise is exposed, test the effectiveness of compensating controls, assess cloud-role permissions, and identify attack paths that automated scanning may miss. Contact IntegSec to schedule a penetration test and build a practical plan for reducing cybersecurity risk across your AI, cloud, and public-facing application environment.

TECHNICAL APPENDIX

A — Technical Analysis

CVE-2026-67620 is an SSRF vulnerability in Flowise’s httpSecurity.ts SSRF guard. The affected logic uses DEFAULT_DENY_LIST filtering for outbound requests but omits Oracle Cloud Infrastructure metadata address 192.0.0.192 and Alibaba Cloud metadata address 100.100.100.200. An attacker can send a crafted URL to Flowise’s fetch-links application programming interface endpoint and cause the Flowise process to issue an arbitrary HTTP GET request to those metadata services.

The flaw is remotely reachable over the network and has low attack complexity. The CVSS 4.0 vector is CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N, which reflects network reachability, low complexity, low privileges in the standard case, no required user interaction, and potential impact outside the vulnerable component. NVD records a CVSS-B score of 6.3, Medium, supplied by VulnCheck. The weakness classification is CWE-918, Server-Side Request Forgery. Public chatflows containing URL-fetching nodes may enable exploitation without authentication.

B — Detection & Verification

Confirm the installed Flowise version before conducting controlled validation. Any version through 3.1.4 should be considered affected unless the deployment has been replaced or protected with effective compensating controls.

• Enumerate a container-based deployment with docker exec <container> flowise --version, docker inspect <container>, or the image tag referenced by your deployment manifest.
• Enumerate Node.js-based deployments with npm list flowise flowise-components flowise-ui, pnpm list flowise, or review package-lock.json, pnpm-lock.yaml, and yarn.lock.
• Search application and reverse-proxy logs for requests to the fetch-links endpoint containing url= parameters, encoded internal addresses, link-local addresses, or attacker-controlled redirect domains.
• Alert on egress from Flowise application hosts to 192.0.0.192, 100.100.100.200, 169.254.169.254, private address space, or internal administrative networks.
• Review public chatflows for URL-fetching nodes and identify any route that permits untrusted users to supply URLs.
• Correlate suspicious requests with Oracle Cloud Infrastructure Audit or Alibaba Cloud ActionTrail events involving unexpected use of the Flowise instance’s assigned identity or role.

C — Mitigation & Remediation

1. Immediate (0–24h): Identify every Flowise instance and determine whether it runs on Oracle Cloud Infrastructure or Alibaba Cloud. Restrict or disable the fetch-links capability, remove URL-fetching nodes from public chatflows, and require authentication for all remaining workflows that accept user-controlled URLs. Block outbound traffic from Flowise hosts to 192.0.0.192, 100.100.100.200, 169.254.169.254, private address ranges, and internal management networks unless an explicitly approved business need exists.
2. Short-term (1–7d): Review Flowise application logs, web-server logs, network telemetry, and cloud audit trails for suspicious requests and use of workload credentials. Rotate cloud credentials, secrets, application tokens, and service-account access that could have been exposed. Reduce the permissions granted to the Flowise workload identity using least privilege. Route outbound HTTP traffic through an authenticated egress proxy with a destination allow-list, and configure alerting for redirect chains that resolve to internal or metadata destinations.
3. Long-term (ongoing): Official vendor patching should normally be the first remediation path. However, the Flowise project is sunset and no vendor patch is expected for this issue. Organizations should therefore migrate affected workflows to a supported platform or maintain a securely governed internal fork only where the engineering and support burden is formally accepted. During transition, enforce network segmentation, cloud metadata hardening where supported, centralized logging, regular configuration reviews, and recurring penetration testing of AI workflow and cloud integrations.

D — Best Practices

• Use destination allow-lists for server-side web requests rather than relying solely on deny-lists of prohibited addresses.
• Revalidate the resolved destination after every redirect and reject requests resolving to private, loopback, link-local, cloud metadata, or internal management addresses.
• Ensure public AI chatflows cannot invoke URL-fetching capabilities with untrusted input unless a tightly controlled proxy enforces approved destinations.
• Assign the Flowise workload only the minimum cloud permissions necessary for its documented function, and regularly review those permissions.
• Segment AI workflow servers from sensitive internal services and monitor their outbound network traffic for unexpected metadata-service or private-network connections.