One Attacker Probes Exposed Flowise AI for Secrets and Workflow Control
Researchers observed an operator using an unauthenticated Flowise server to harvest credentials and attempt workflow hijacking via simulated nodes.
Key points
- Sekoia shared findings from a late August 2026 honeypot test of Flowise 2.2.8 in a September 7 report.
- The attacker queried APIs to list chatflows and stored credentials, seeking API keys and database details.
- Attempts to create a workflow with an HTTP Request node aimed to trigger outbound callbacks to attacker infrastructure.
An operator targeted an exposed Flowise AI orchestration server to extract stored secrets and manipulate workflow configurations, according to findings from Sekoia. The security firm published these observations in a private FLINT report on 7 September 2026, detailing activity captured against a honeypot in late August 2026. The simulated environment mirrored Flowise 2.2.8, allowing researchers to record network requests without executing actual system code or language models.
What specific actions did the attacker take?
The operator began by verifying the service version and querying application programming interfaces that listed available chatflows and stored credentials. Requests targeted individual credential records to harvest API keys and database connection strings. After a two-hour pause, the attacker expanded probing to additional APIs and inference routes. They attempted to rename an existing workflow and created a new chatflow named "System Status." This new flow included an HTTP Request node directed at infrastructure controlled by the attacker.
Did the attacker achieve remote code execution?
No confirmed exploitation occurred, as the target was a honeypot that did not run real system code. Sekoia explicitly stated the activity did not demonstrate exploitation of CVE-2024-31621, an authentication bypass flaw fixed in Flowise 1.6.6. That CVE was cited only as a behavioral comparison. The attacker’s attempt to abuse workflow functionality aimed to generate outbound callbacks, not to achieve code execution or persistence on the host. The investigation confirms the intent to leverage legitimate features for malicious communication.
Which vulnerabilities were referenced in the report?
The report notes that the operator’s behavior resembled attempts to exploit several known issues, including the CustomMCP remote code execution vulnerability (CVE-2025-59528) and the CSV Agent remote code execution vulnerability (CVE-2026-41264). The attacker also sent prompts designed to override system instructions, expose conversation history, and probe available tools. These prompts targeted a simulated finance retrieval-augmented generation workflow. The sequence suggested an initial automated scan followed by manual interaction using tailored inputs.
What does this mean for production deployments?
Sekoia researchers observed that platforms connecting language models to secrets, databases, and external tools present valuable targets for credential theft and workflow hijacking. Because the honeypot used simulated responses and canary credentials, the investigation does not establish that secrets were actually stolen from a production Flowise deployment. The findings highlight the risk of exposed orchestration servers where attackers can enumerate workflows and attempt to repurpose agents for offensive analysis.
Detection notes
Security teams should monitor for unauthenticated access to Flowise API endpoints that list chatflows or retrieve stored credentials. Look for unusual creation or modification of workflows, particularly those adding HTTP Request nodes pointing to external domains. Alert on outbound connections from orchestration servers that do not match expected tool integrations. Check for prompt injection attempts that try to reveal system instructions or conversation history. Immediately isolate any exposed instance and rotate all associated API keys and database passwords. Review firewall logs for unexpected outbound traffic originating from application servers during quiet periods.
Background: Honeypots
Honeypots provide pure threat data by inviting attacks on isolated systems. They reveal attacker tactics without risking production data. However, they require careful isolation to prevent pivot attacks and generate no value if ignored. Use them for detection, not defense.
Read the full guide: Honeypots for Security: Real Benefits, Hidden Costs, and Limits
What to do and how to stay safe: Flowise AI
- Ensure Flowise AI instances are not directly accessible from the internet without authentication or network-level restrictions.
- Audit API endpoints to confirm that listing workflows and credentials requires strong authentication and role-based access controls.
- Monitor outbound network traffic from orchestration servers to detect unexpected callbacks or connections to unknown infrastructure.
- Rotate any API keys or database credentials that were stored in exposed environments once the vendor provides an update.
Step-by-step guide: Patch Management Checklist: Secure Systems Without Breaking Them
General security guidance from the Firewall Scoop newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Was CVE-2024-31621 exploited in this incident?
No, Sekoia explicitly stated that the activity did not demonstrate exploitation of CVE-2024-31621, which was fixed in Flowise 1.6.6.
What version of Flowise was targeted?
The honeypot emulated Flowise 2.2.8 to capture the attacker's requests without running real system code.
Did the attacker successfully steal credentials?
The investigation does not establish that secrets were actually stolen, as the target was a honeypot with simulated responses.
