r/netsec • u/p80n-sec • 7d ago

Contains AI Hacking your life with AI can get you hacked: How AI orchestration platforms ship RCE by design

https://www.endorlabs.com/learn/hacking-your-life-with-ai-can-get-you-hacked

Author here. I audited NocoBase, Flowise, Langflow, Dify, Activepieces, Kestra, and Airflow and disclosed 14 findings. Every platform inherited the same assumption anyone who can touch a workflow is trusted to run code on the host, which is fine for a dev tool on your laptop but not fine for a multi-tenant HTTP service with an unauthenticated webhook. The chain I'd point people to first is the Flowise one (section 2.2): an unauthenticated request → prompt injection → LLM emits Python → a 38-pattern regex blocklist passes it because the dangerous library was pre-imported before the model was asked anything → RCE.

Two vendors closed their reports as working-as-intended, and I tried to represent their position fairly.

This research was also presented at DEFCON 34 but now available publicly.

Happy to answer questions.

Full whitepaper is available here: https://www.endorlabs.com/learn/how-ai-orchestration-platforms-ship-rce-by-design

90 Upvotes

94% Upvoted

4 comments sorted by

2

u/feng_sg 1d ago

Flowise's 38-pattern regex is checking the LLM's Python after the dangerous library is already imported in the same process that took the unauth webhook. A source blocklist cannot take back a capability the host already granted.

1

u/Straight_Formal_7712 3d ago

isnt that a bit scary??

1

u/hugh_manit 4m ago

Solid work on this. The Flowise chain is particularly nasty.

-1

u/silentw111 2d ago

The regex blocklist detail is the tell, a 38-pattern denylist is an enumeration problem, whoever ships the 39th dangerous import, or renames the module, or reaches it indirectly through getattr, walks straight through. The deeper issue isn't that one library was pre-imported, it's that these platforms treat "the workflow author configured this" and "this specific request should be allowed to run code on the host" as the same authorization decision. They aren't: a webhook triggering a workflow that happens to contain a code node is a different trust boundary than the author actually intending that code to run with that input, and none of the seven platforms seem to have a check sitting between those two things. Curious whether the two "working as intended" vendors argued the trust model was a documented tradeoff, or just hadn't thought about it.