Greeter Framework Hijacks 4,972 Flowise Instances, Exposes Cloud Secrets
Researchers at Era Security discovered a malicious framework called Greeter that sent 4,972 “hello” messages to Flowise AI development platforms, injecting JavaScript via the overrideConfig parameter, enabling host reconnaissance, credential harvesting, and cloud‑metadata probing across thousands of exposed instances, raising alarm for any organization that runs AI‑enabled tooling in production.
How does Greeter inject malicious commands into Flowise?
Greeter exploits Flowise’s public API endpoint that accepts an overrideConfig JSON field. By embedding obfuscated JavaScript inside this field, the attacker can execute code on the server without the payload ever being stored in the workflow definition, effectively achieving a fileless execution path.
The injected script runs in the context of the Flowise process, allowing it to call system utilities, read environment variables, and make outbound network requests. Because the malicious code is not persisted, traditional file‑based detection tools often miss it.
What types of data and cloud resources are targeted?
Analysis of more than 4,000 reconstructed commands revealed a focus on three attack phases: reconnaissance, credential discovery, and persistence preparation.
- Host reconnaissance – Commands enumerate running processes, open ports, and user privileges to map the underlying system.
- Credential discovery – Scripts search for SSH keys, AWS/Azure/GCP metadata tokens, and other secrets cached on the host.
- Persistence preparation – The framework attempts to drop lightweight launchers or schedule cron jobs, positioning the attacker for long‑term access without writing obvious binaries.
By probing cloud‑provider metadata endpoints, Greeter can retrieve IAM role credentials, effectively turning a compromised Flowise node into a foothold for lateral movement in the broader cloud environment.
Which Flowise deployments are most at risk?
Era’s honeypot deployment identified 4,372 internet‑exposed Flowise instances, of which 46 were unauthenticated and matched the vulnerable configuration used in the research. Any publicly reachable Flowise instance that does not enforce authentication or restrict the overrideConfig endpoint is a prime target.
Enterprises that host internal Flowise services behind permissive firewalls, or that expose demo instances for trial users, inadvertently increase their attack surface. The popularity of Flowise—over 55,000 GitHub stars—means many organizations may be running it without a hardened deployment checklist.
How can organizations detect and block this attack?
Because the malicious payload never lands on disk, detection must focus on behavior and network indicators. Recommended steps include:
- Enable API authentication and enforce least‑privilege tokens for all Flowise endpoints.
- Audit and restrict the
overrideConfigparameter, allowing only whitelisted keys. - Deploy runtime monitoring (e.g., Falco, Sysdig) to alert on suspicious process launches, outbound requests to cloud metadata services, or unexpected JavaScript execution within the Flowise container.
- Regularly scan public IP ranges for exposed Flowise instances using tools like Shodan or Nmap, and remediate any that lack proper access controls.
Integrating these controls into a broader attack‑surface management program helps surface hidden entry points before threat actors can weaponize them.
What does this mean for you?
If your organization relies on Flowise—or any AI‑assisted development platform—review your deployment topology today. Close any unauthenticated public endpoints, enforce strict API validation, and add behavioral monitoring to catch fileless attacks. Proactive hygiene reduces the risk that a compromised AI tool becomes a gateway to your cloud assets.
Frequently asked questions
Can the Greeter framework affect on‑premise Flowise installations?
Yes. Greeter targets the Flowise API itself, so any installation—cloud‑hosted or on‑premise—that exposes the vulnerable endpoint without authentication can be compromised.
What is the safest way to expose Flowise for external users?
Place Flowise behind a reverse proxy that requires strong authentication, limit the allowed IP ranges, and disable or tightly validate the overrideConfig parameter to prevent arbitrary code execution.
How can I quickly check if my Flowise instance is exposed publicly?
Use internet‑wide scanners like Shodan or run a targeted Nmap scan on your public IP ranges for the Flowise port (default 3000) and verify whether the API endpoint returns unauthenticated responses.
Does this attack rely on a specific version of Flowise?
The research did not pinpoint a version‑specific bug; the exploit leverages a design choice in the API that is present in multiple releases, so all actively maintained versions should be reviewed.
Are there any indicators of compromise (IOCs) for Greeter activity?
Common IOCs include outbound HTTP requests to cloud metadata URLs (e.g., http://169.254.169.254), execution of commands that list SSH keys, and unexpected JavaScript strings in process memory captured by runtime monitoring tools.
