FlowCage

A CLI and CI gate that scans self-hosted Langflow, Dify, Flowise, and n8n instances for hardcoded secrets in flow exports, out-of-date builds against known CVEs, and flow-sharing configs that leak another tenant's credentials.

Problem

On June 25, 2026, Sysdig caught an attacker exploiting a Langflow endpoint that let any logged-in user run someone else's saved flow just by guessing its ID — and those flows commonly have LLM provider keys and cloud credentials baked into their node configs. Four more bugs surfaced in Dify eleven days earlier with the same root problem: tenant isolation that lived in application logic instead of the platform's architecture. Teams that stood up these tools last year for internal agent-building now have production instances holding real secrets, and nothing in their existing pipeline — not Semgrep, not gitleaks, not Trivy — knows what a Langflow flow export or a Dify DSL file looks like.

Target user

A platform or AppSec engineer at a company that self-hosts Langflow, Dify, Flowise, or n8n so product teams can wire up internal AI agents without waiting on the platform team. They already run secret scanners on application code; they have nothing that reads flow JSON, checks the running container tag against a CVE feed, or verifies that a low-privilege API token actually can't touch someone else's flow. Job to be done: before this flow gets committed or this instance goes live, tell me if it's carrying a secret or shipping a known hole.

MVP scope

• Parser for each platform's export format (Langflow JSON, Dify DSL YAML, Flowise chatflow JSON, n8n workflow JSON) that walks node parameters and flags hardcoded API keys, LLM provider tokens, and cloud credentials using per-field schema awareness rather than blind regex
• Version fingerprinting against a maintained CVE table — starting with Langflow < 1.9.2 (CVE-2026-55255) and Dify < 1.14.2 (the four DifyTap CVEs) — by hitting the instance's own /api/version or /health endpoint
• Opt-in ownership self-test: using a token the org already controls, attempt to invoke a second flow ID that token shouldn't own, and confirm the platform actually rejects it rather than trusting the changelog
• GitHub Action / GitLab CI job that fails a merge when a committed flow export contains a hardcoded secret or the pinned Docker image tag matches a known-vulnerable build
• SARIF output for code scanning plus a plain terminal report with a fix line per finding (rotate this key, upgrade to 1.9.2, your ownership check isn't enforced)
• Webhook/Slack alert when a new CVE lands against a platform version the org has pinned, sourced from the NVD feed and the CISA KEV catalog

Monetization

Freemium. The CLI and CI action are MIT-licensed and free. A hosted tier at $15/seat/month watches an org's pinned platform versions continuously, runs the ownership self-test on a schedule instead of only at CI time, and pushes the CVE alert before the next scheduled scan would catch it. A $399/month flat enterprise tier adds SSO, an audit log, and a private CVE feed mirror for air-gapped deployments.

Why now

CVE-2026-55255 hit Langflow at a 9.9 CVSS score, was exploited in the wild before most self-hosters had patched, and became the first AI-agent-building platform on CISA's Known Exploited Vulnerabilities list on July 7, 2026. DifyTap landed eleven days earlier against a platform running over a million AI apps, with the same failure mode: isolation that depended on the platform remembering to check ownership rather than the architecture enforcing it. Both incidents point at the same blind spot — nobody scans the artifacts these tools produce, and nobody checks the running version against what's actually being exploited this month.

Risks & open questions

• Export formats change fast and each platform maintains its own; the parser layer is a standing maintenance cost that needs community contribution to keep up, not a one-time build
• Secrets referenced indirectly through environment-variable placeholders won't show up in a static scan of the export file, so coverage is real but partial
• Demand depends on how many companies actually self-host these platforms versus using a vendor's hosted cloud tier, where this tool has no instance to point at
• The ownership self-test has to stay scoped to flow IDs the org's own token controls — any drift toward probing IDs the org doesn't own turns a defensive feature into something that looks like an attack
• Once CISA KEV pressure forces patches, some of this value gets commoditized by the platforms shipping their own built-in secret scanning within a year

Next step

Build the Langflow parser and the CVE-2026-55255 version check first, since it has a live CISA deadline and a public exploit trace to test against; if the CI action catches a planted secret and a pinned-vulnerable-version fixture cleanly, promote to weekly prototype.

Sources

• https://www.helpnetsecurity.com/2026/07/08/langflow-vulnerability-cve-2026-55255-exploited/ — CVE-2026-55255 details: CVSS 9.9, exploited in the wild June 25 2026, CISA KEV addition July 7 2026, credentials embedded in hijacked flows
• https://thehackernews.com/2026/06/researchers-detail-difytap-flaws-in.html — DifyTap: four CVEs disclosed June 22-23 2026 against Dify, a platform powering over 1 million AI apps
• https://konghq.com/blog/enterprise/ai-agent-platforms-hacked-whats-missing — framing on why multi-tenant AI agent platforms keep failing at architectural isolation rather than one-off bugs