Hacking your life with AI can get you hacked | Blog | Endor Labs

-->

No items found.

Solutions

Research

Resources

LeanAppSec

Docs

Pricing

Login

Book a Demo

Book Demo

By clicking “Accept”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.

DenyAccept

18px_cookie

e-remove

Customize your preferences

Essential<br>Required

These items are required to enable basic website functionality.

Marketing

Essential<br>These items are used to deliver advertising that is more relevant to you and your interests.

Analytics

Essential<br>These items help the website operator understand how its website performs, how visitors interact with the site, and whether there may be technical issues.

Personalization

Essential<br>These items allow the website to remember choices you make (such as your user name, language, or the region you are in) and provide enhanced, more personal features.

Remove all cookiesSave & submit

Blog<br>Hacking your life with AI can get you hacked<br>I uncovered 14 critical and high severity vulnerabilities, including multiple unauthenticated prompt-injection to RCE chains, across seven AI orchestration platforms. This research was presented at DEFCON 34.

Written by<br>Peyton Kennedy

Published on<br>August 18, 2026

Updated on<br>August 18, 2026

Topics<br>Open Source<br>Security

Summarize with AI

How AI orchestration platforms ship RCE by design<br>NocoBase, Flowise, Langflow, Dify, Activepieces, Kestra, and Apache Airflow have quietly become critical infrastructure as a result of the agentic AI buildout. They’re used by individuals and enterprises alike to hack personal productivity, build agents, and automate workflows. Langflow and Dify each carry more than 150,000 GitHub stars each, among the most-starred projects in the AI ecosystem. Even the smallest platform in this study, Activepieces, has more than 23,000 GitHub stars.<br>All seven have become critical infrastructure for developers building AI agents and workflows, but they also all All share the same dangerous assumption:<br>"Anyone who can touch a workflow is trusted to run code on the host."<br>I went hunting across those seven platforms and walked out with fourteen critical and high vulnerabilities and multiple public CVEs/GHSAs (7 and growing) . I collected an arsenal of vulnerabilities and primitives: shell injection, executing user supplied code on validation, prompt injecting LLMs to remote code execution, sandbox bypasses, and unauthenticated APIs that execute code.<br>The most serious chain needs almost no setup. An unauthenticated user can trigger a prompt injection, executing code and allowing them to exiltrate data, all without ever creating an account or credentials on the platform. With some configurations, Flowise, Kestra, and Langflow could all be exploited without an attacker ever signing in.<br>Some vendors closed the reports as working-as-designed, on the argument that executing code is the product and hardening the deployment is the developer's problem. That argument holds up until you notice the necessary defenses are either not present or any internet user can execute the code.<br>Every vulnerability is a variation on the same error. These are multi-tenant code-execution environments, shipped as single-user developer tools, and the threat model has not expanded alongside the products.<br>As a result, individuals and enterprises building agents with these platforms inherent the permissive threat models they ship by design. These vulnerabilities provide access to sensitive information meant to provide context to AI agents—credentials and access to personal email and calendars for individuals, or customer data for enterprises. Any connector implemented should be treated as a point of compromise.<br>I presented this research at DEF CON 34 and have published the full technical whitepaper here. I’ve summarized some of the technical findings below.<br>The spectrum: from accidental to intentional<br>The findings from my research sit on a spectrum:<br>Accidental: tried to build security but shipped it broken<br>LLM as code: trusted LLM output as executable code<br>Wrong phase: Built or applied a sandbox but to the wrong phases<br>Intentional: Don’t apply a sandbox, leaving it to the builder.

The accidental end<br>NocoBase<br>On the accidental end, NocoBase built three defenses around its expression evaluator: a SES Compartment, a string preprocessor, and a Proxy guard.<br>All three had holes. The lockdown() call that arms SES was commented out with a TODO. The Proxy's has() trap returns true for a TypeScript private field, because private is a compile-time fiction that compiles to an ordinary instance property. Every authenticated user could reach the sandbox through an ACL that read loggedIn. One request escalated a member account to COPY … TO PROGRAM on the database host. CVSS 9.9, no malice anywhere. Velocity outran review.<br>Further right, Flowise and Langflow...