Flowise EUVD-2026-38202

Exploitation requires a valid low-privilege authenticated session on the Flowise instance (PR:L per CVSS 4.0 vector) - unauthenticated exploitation is not supported by available data. The attacker must have permission to create or modify workflow nodes, specifically the S3 Document Loader component, and the Flowise deployment must have the S3 Document Loader node available and usable by that user role. Exploitation is further constrained by the AWS IAM permissions of the S3 credentials configured in Flowise: if the configured IAM role is scoped to specific key prefixes, traversal to out-of-scope paths will be blocked at the AWS authorization layer regardless of the Flowise-level flaw. Limiting factors include: required low-privilege authentication, access to the S3 Document Loader node specifically, and AWS IAM policy scope on configured credentials.

The CVSS 4.0 base score of 2.1 reflects constrained real-world impact: the attack vector is network (AV:N) with low complexity (AC:L) and no attack prerequisites (AT:N), but requires low-privilege authentication (PR:L) and produces only limited confidentiality, integrity, and availability impact on the vulnerable system (VC:L/VI:L/VA:L) with no scope change to subsequent systems (SC:N/SI:N/SA:N). The E:P exploit maturity modifier confirms publicly available exploit code exists, lowering the exploitation barrier. However, the absence of a CISA KEV listing and the low base score suggest this has not seen widespread exploitation. EPSS data was not included in available intelligence - its absence means probabilistic exploitation likelihood cannot be quantified here. The primary real-world risk is elevated in multi-tenant Flowise deployments where low-privilege users should not have cross-tenant file access. For single-user or internally-restricted deployments, practical impact is limited.

An authenticated Flowise user with access to the workflow editor configures an S3 Document Loader node with a crafted object key containing path traversal sequences (e.g., ../../sensitive-prefix/credentials). When the workflow executes, the unsanitized key is processed by S3.ts, causing the loader to resolve and return content from unintended S3 paths. Publicly available exploit code exists per the GitHub PoC reference, meaning the technique is already documented and reproducible with low skill.