CVE-2025-26319

What it actually does

FlowiseAI Flowise v2.2.6 contains an arbitrary file upload flaw in the /api/v1/attachments endpoint caused by insufficient validation of uploaded attachment content, type, filename, and/or storage behavior. An attacker who can reach the endpoint may be able to upload unexpected file types or crafted filenames, potentially enabling payload staging, stored malicious content, file overwrite or path traversal depending on deployment configuration, disk exhaustion, and in higher-impact cases server-side code execution if uploaded content can be executed or later processed unsafely by the application or runtime.

Why it matters to the business

A successful exploit can turn an exposed Flowise instance into a foothold for attackers, allowing them to store malicious files, disrupt service availability, tamper with application data, or potentially take control of the server hosting AI workflows. The issue has a critical CVSS score, weaponized exploit maturity, and a high EPSS likelihood, so internet-exposed instances should be treated as high-priority remediation targets even though it is not currently listed in CISA KEV.

How an attack unfolds

An attacker first identifies a reachable Flowise instance and confirms that the /api/v1/attachments API is accessible. They then send a crafted multipart file upload request containing a disallowed file type, malicious payload, oversized file, double-extension filename, or path-manipulating filename. If validation is weak, Flowise accepts and stores the file. The attacker may then attempt to retrieve the uploaded file, trigger application processing of the attachment, overwrite sensitive files, fill storage, or chain the upload with another weakness that causes the uploaded content to execute. In deployments where the uploaded file lands in a web-accessible or executable path, exploitation can escalate from arbitrary file upload to remote code execution or persistent compromise.

How to fix it

Upgrade FlowiseAI Flowise from v2.2.6 to a vendor-provided fixed release or the latest available version that addresses this issue. If an exact fixed version is not available in internal package metadata, verify against the official Flowise release notes and security advisories before deployment. Until upgraded, restrict access to /api/v1/attachments, require strong authentication and authorization for uploads, block the endpoint from the public internet where possible, and apply reverse-proxy or WAF rules to deny risky uploads. Enforce strict allowlists for file extensions and MIME types, generate server-side filenames, reject path traversal sequences, store uploads outside executable or web-served directories, set size quotas, scan uploads for malware, and run the Flowise process with least-privilege filesystem permissions.

How to confirm the fix worked

Confirm that no Flowise instance remains on v2.2.6 or another vulnerable build. Validate that the upgraded application rejects unauthenticated uploads to /api/v1/attachments and blocks disallowed file types, path traversal filenames, double extensions, oversized files, and mismatched Content-Type values. Review configuration to ensure uploaded files are stored outside executable paths and cannot overwrite application files. Use a controlled test file, not a live payload, to confirm that attempted unsafe uploads return an error and do not create files on disk. Re-check reverse-proxy, WAF, and application logs to verify that suspicious upload attempts are denied after mitigation.

Typical attack path

1. Scan for internet-facing FlowiseAI Flowise instances or exposed Flowise API endpoints.
2. Probe /api/v1/attachments with benign multipart upload requests to determine whether authentication and file validation are enforced.
3. Submit crafted uploads such as executable scripts, HTML/JavaScript payloads, archive files, double-extension files, oversized files, or filenames containing traversal sequences.
4. Confirm whether the uploaded file is stored, retrievable, processed by workflows, or placed in a web-accessible location.
5. Abuse the uploaded file to stage tools, poison application content, exhaust disk space, overwrite files, or attempt code execution through downstream processing or misconfigured static serving.
6. Establish persistence or move laterally if the upload results in server compromise.

How to detect it

To determine whether exploitation already occurred, review reverse-proxy, load balancer, API gateway, WAF, and Flowise application logs for POST requests to /api/v1/attachments, especially multipart/form-data requests from unknown IP addresses, unauthenticated clients, unusual user agents, or repeated upload failures followed by success. Look for filenames with executable or script extensions, double extensions, URL-encoded traversal strings, absolute paths, hidden dotfiles, archives, unusually large files, or mismatched MIME types. On hosts and containers, inspect Flowise upload/storage directories and application directories for newly created or modified files around the time of suspicious requests. Correlate suspicious uploads with process telemetry showing the Flowise Node.js process spawning shells or utilities such as sh, bash, cmd, powershell, curl, wget, python, node, npm, chmod, or crypto-mining binaries. Also review outbound network connections shortly after uploads, unexpected scheduled tasks or startup entries, changed application files, abnormal disk growth, and authentication activity using credentials accessible to the Flowise process.

• /api/v1/attachments
• POST /api/v1/attachments
• multipart/form-data
• filename="..
• filename="../
• filename="..\\
• %2e%2e%2f
• %2e%2e%5c
• filename="/
• filename="\\
• filename=".env
• filename=".ssh
• filename="authorized_keys
• filename="id_rsa
• filename="*.php
• filename="*.jsp
• filename="*.jspx
• filename="*.asp
• filename="*.aspx
• filename="*.js
• filename="*.mjs
• filename="*.sh
• filename="*.bash
• filename="*.cmd
• filename="*.bat
• filename="*.ps1
• filename="*.exe
• filename="*.dll
• filename="*.so
• filename="*.jar
• filename="*.war
• filename="*.html
• filename="*.svg
• filename="*.zip
• filename="*.tar
• filename="*.gz
• .php.jpg
• .jsp.jpg
• .js.png
• .sh.txt
• node /api/v1/attachments
• Flowise
• flowise
• curl
• wget
• /bin/sh
• /bin/bash
• cmd.exe
• powershell.exe

What your security team should do

• Immediately inventory all FlowiseAI Flowise deployments and prioritize any internet-facing v2.2.6 instances for upgrade or isolation.
• Upgrade to the latest vendor-fixed Flowise release and confirm the fix through controlled upload validation tests.
• Temporarily restrict or block external access to /api/v1/attachments until patching is complete.
• Add WAF or reverse-proxy controls to block multipart uploads with executable extensions, traversal sequences, double extensions, excessive size, or unauthenticated access.
• Review application, proxy, container, and host logs for historical POST requests to /api/v1/attachments, especially because exploit maturity is weaponized and EPSS likelihood is high.
• Inspect upload directories and application paths for recently created unexpected files, scripts, archives, web shells, or files owned by the Flowise process.
• Hunt for post-exploitation activity from the Flowise runtime, including shell execution, outbound downloads, crypto-mining tools, credential access, and unusual network connections.
• Enforce least privilege for the Flowise service account and ensure upload storage is non-executable and outside the application code path.