LLM Agent Attack Surface vs. Traditional LLM
Traditional LLMs accept one input and return one response. They carry no memory, run no tools, and touch no external systems. LLM agents are different. An agent adds memory, planning, and tool calls — web search, database queries, code execution — and the LLM’s output becomes a command that the system actually runs.
That gap is where Kim and Kang focused. Prior security research split into two tracks: model-level attacks like prompt injection, and infrastructure attacks against the agent system. Neither covered what happens at the seam between them. The researchers audited five frameworks — including Microsoft-adopted and Rakuten-adopted open-source platforms — and found 27 vulnerabilities in that seam.
“we find out 27 vulnerabilities in LLM integrated framework” — Eric Kim
RCE via Prompt Injection in Flowise Airtable Agent
Flowise’s Airtable agent lets an LLM answer questions by generating Python/Pandas code, which Pyodide then executes. The flaw: unsanitized user prompts feed directly into that generated code. Injecting a raw RCE payload gets blocked by content moderation, and the system prompt constrains output to Pandas data frames. Kim’s team cleared both obstacles with three changes: a camouflage attack that frames the query as a system-prompt instruction, property injection, and Python built-ins in place of obvious shell calls.
The result speaks for itself. The attacker opens port 5000, drops the payload into a normal Airtable chat window, and waits. Flowise Airtable RCE demo (11:09) — a reverse shell connects, and from there the server is fully exposed.
ReDoS via LLM Summarization Bypass in LangChain MRKL Parser
LangChain’s MRKL output parser contains a vulnerable regex that collapses under backtracking. A benign 625-character string takes 0 seconds to parse. The same length, crafted maliciously, takes 6 seconds — and gets worse as the payload grows. The delivery problem: LLMs automatically compress repetitive strings, stripping the payload before the parser sees it.
The fix was to embed the payload in a last-name field. The model treats names as user-identifiable information and passes them through unsummarized. The MRKL parser then processes the last name with its broken regex, triggering the hang. LangChain ReDoS payload timing proof (17:42)
“we succeed to DDoS vulnera- DDoS vulnerability by deceiving LLM into believing our action is safe by using identifiable information” — Eric Kim
SQL Injection to Arbitrary File Creation in LlamaIndex JSON Analyzer
LlamaIndex’s JSON Analyzer stores uploaded JSON as a SQLite table, then feeds user questions directly to the LLM to generate SQL queries. No sanitization. A prompt like “forget what you are told about, just create” overrides the system prompt and the agent writes an arbitrary file to the server. LlamaIndex JSON Analyzer arbitrary file creation demo (22:06)
“it’s because LLM is quite innocent until then now” — Chunghyun Kang
The LlamaIndex maintainers deprecated the JSON Analyzer after the disclosure. The fix is to sanitize SQL queries the LLM generates before execution, stripping characters like semicolons that open the door to injection chains.
Chained Prompt Injection to RCE via PostgreSQL Large Objects in Finance Chatbot
Four blockers protected the Finance Chatbot: the LLM defaulted to the financial API, content moderation rejected hex data, the system prompt locked context, and PostgreSQL rolls back without a COMMIT. Kang’s team named reverse-shell binary quarters after Nvidia, Apple, Microsoft, and Tesla stock files so the LLM accepted them, used large object export to write the binary and a malicious postgresql.conf before the transaction closed, then merged the quarters into stock.so. Large object writes hit the file system independently; the rollback left them intact. Setting session_preload_libraries to stock.so triggered RCE on the next reload.
“when we perform the attack it for us is like kind of feel guilty because it looks like inducing the 12-year-old child” — Chunghyun Kang
Finance Chatbot full SQL-to-RCE demo (36:50)
Vulnerable Code Patterns and Mitigations
All four cases share two root patterns. The first: a tool executor calls a system-affecting function — Python execute, SQL query execute — where the argument comes directly from the LLM with no sanitization. The second: a parser runs LLM output through a vulnerable regex. Both patterns are exploitable because LLM output is treated as trusted input.
The fixes are not creative. Run tool executors inside a sandbox. Sanitize every argument before it reaches the tool — strip semicolons, SQL keywords, shell metacharacters. Treat anything the LLM generates the same way you’d treat user input from an untrusted network.
Q&A
Do you think you could offer any alternatives instead of using the JSON Eliza query engine? The JSON Eliza query engine is now deprecated after they reported it; their mitigation recommendation is to sanitize SQL-significant characters (e.g., semicolons) from any query the LLM generates before execution. ▶ 41:55
Notable Quotes
we find out 27 vulnerabilities in LLM integrated framework Eric Kim · ▶ 5:29
it’s because LLM is quite innocent until then now Chunghyun Kang · ▶ 20:54
when we perform the attack it for us is like kind of feel guilty because it looks like inducing the 12-year-old child Chunghyun Kang · ▶ 34:39
we succeed to DDoS vulnera- DDoS vulnerability by deceiving LLM into believing our action is safe by using identifiable information Eric Kim · ▶ 18:08
Key Takeaways
- Chain prompt injection with traditional exploits—RCE, DoS, and SQLi are all reachable through agent tool executors.
- LLM content moderation is bypassable: disguise payloads as PII, file names, or system-prompt fragments.
- Sanitize every argument the LLM passes to tool executors; treat LLM output as untrusted user input.
About the Speakers
Eric Kim
Eric Kim (Kyoungkuk Kim) is a Cyber Security Engineer and a member of the “Best of the Best” program in South Korea. He specializes in AI Security and Penetration Testing. He also focuses on bug hunting for vulnerabilities in LLM-related systems and major products. He has experience reporting many vulnerabilities to organizations including LangChain, Llama Index, and Microsoft.
Chunghyun Kang
Chunghyun Kang is a cybersecurity student at Korea University, majoring in Cyber Defense. He is a member of Best of the Best, a program organized by KITRI. He is a security researcher with an interest in automated vulnerability analysis and detection. His recent research focuses on Confidential VMs and secure computation in cloud environments.