What Happened
Flowise, an open-source low-code platform for building AI chatbots and workflows, was found to have CVE-2025-59528—a critical arbitrary JavaScript code injection vulnerability. This flaw allows attackers to inject and execute code through unsafe evaluation of user inputs. VulnCheck detected active exploitation in the wild. Between 12,000 and 15,000 Flowise instances remain exposed online. The vendor released version 3.1.1 two weeks ago to patch the issue, but many teams have not yet updated.
This is a real risk. Your AI workflow builder could become an unauthenticated remote code execution endpoint.
Timeline
Pre-disclosure: CVE-2025-59528 exists in production Flowise deployments. The vulnerability stems from unsafe eval() or similar dynamic code execution against user-controlled input.
Two weeks ago: Flowise maintainers released version 3.1.1 containing the fix.
Recent: VulnCheck security researcher Caitlin Condon observed active exploitation attempts targeting unpatched instances.
Current state: Thousands of internet-facing Flowise deployments remain vulnerable. Attackers have working exploit code. The window between patch availability and widespread exploitation is closed.
Which Controls Failed or Were Missing
Input validation failure: The application evaluated user-supplied data as executable code without sanitization. This violates the principle of secure input handling—never trust data you don't control.
Deployment visibility gap: Running 12,000-15,000 exposed instances suggests teams deployed Flowise without asset inventory or exposure management. You cannot patch what you don't know you're running.
Patch deployment lag: Two weeks passed between patch release and confirmed exploitation. For a CVSS-10 vulnerability in an internet-facing application, your patch window is measured in hours, not weeks.
Dependency tracking absence: Low-code platforms like Flowise are dependencies. Teams building workflows on top of Flowise likely lack processes to monitor the platform's security posture or receive vulnerability notifications.
Change management breakdown: Flowise deployments often happen outside traditional IT approval workflows. A developer spins up an instance to prototype an AI chatbot. That prototype goes to production. Nobody updates the asset register or applies the security baseline.
What the Relevant Standards Require
PCI DSS v4.0.1 Requirement 6.3.2 mandates that custom and bespoke software is developed securely. This includes "input validation to prevent common attacks such as injection flaws." Evaluating user input as code is a canonical injection flaw. If your Flowise instance touches cardholder data—even indirectly through customer service chatbots—this is a compensating control failure.
OWASP Top 10 2021: A03:2021 – Injection explicitly covers code injection. The guidance is clear: validate all input, use parameterized interfaces, and never pass user-controlled data to interpreters. The eval() pattern that enabled CVE-2025-59528 appears in OWASP's example code as what not to do.
OWASP ASVS v4.0.3 Section 5.2.3 requires that applications verify user input using positive validation (allowlists) and reject dangerous characters before processing. Level 2 verification—appropriate for any internet-facing application—demands that "the application does not use eval() or other dynamic code execution features unless absolutely necessary."
NIST 800-53 Rev 5 SI-2 (Flaw Remediation) requires organizations to install security-relevant software updates within the time period directed by the organization. For critical vulnerabilities in internet-facing systems, NIST guidance typically means 15 days maximum. Two weeks with active exploitation exceeds this threshold.
ISO/IEC 27001:2022 Annex A.8.8 (Management of Technical Vulnerabilities) requires timely information about technical vulnerabilities, evaluation of exposure, and appropriate measures in response. Running thousands of instances without awareness of a CVSS-10 patch indicates a gap in vulnerability information processes.
Lessons and Action Items for Your Team
Build an asset inventory that includes shadow IT. Low-code platforms spread through organizations because they're easy to deploy. Your CMDB won't capture them unless you actively scan for them. Use network discovery tools to identify web applications running on non-standard ports. Query your cloud provider APIs for all compute instances, not just those tagged "production."
Create a vulnerability notification pipeline for your entire stack. You need alerts when Flowise releases a security update the same way you get alerts for Apache or Nginx. Subscribe to security advisories for every open-source component you run. For platforms like Flowise, monitor the GitHub repository's security tab and release notes. Configure automated checks that compare your deployed version against the latest release.
Establish severity-based SLAs for patching. CVSS-10 vulnerabilities in internet-facing applications require emergency response. Your SLA might be: Critical (CVSS 9.0-10.0) + internet-facing = 24-hour patch window. High (CVSS 7.0-8.9) + internet-facing = 7 days. Document this policy. Measure compliance. Report exceptions to leadership.
Implement application-level input validation even when using low-code tools. The Flowise vulnerability exploited unsafe code evaluation. Even if you're not writing the platform code, you control what inputs reach it. Add a validation layer between users and your Flowise workflows. Reject special characters, limit input length, and use allowlists for expected patterns.
Require security review before low-code platforms reach production. Your change management process should flag new application frameworks. When someone wants to deploy Flowise, Retool, or similar platforms, security engineering reviews the deployment architecture, authentication model, network exposure, and update process before approval.
Test your incident response for third-party component vulnerabilities. Run a tabletop exercise: "A CVSS-10 vulnerability drops in a platform we use for customer-facing AI chatbots. We have 24 hours. Who makes the decision to take the service offline? Who tests the patch? Who approves production deployment?" Document the answers. Assign the roles.
Monitor for exploitation indicators. VulnCheck detected active exploitation. Your SIEM should alert on unusual JavaScript execution patterns, unexpected outbound connections from application servers, or web requests containing code injection payloads. For Flowise specifically, watch for POST requests to workflow endpoints containing eval, Function(), or other code execution primitives.
The Flowise incident demonstrates that severity scores matter. When you see CVSS-10, you're looking at a vulnerability that gives attackers complete control with minimal effort. Your response timeline must match the threat timeline. Two weeks is too slow when the exploit code is already running.
CVE Details
