Summary
A critical code injection vulnerability in Devika's Runner.execute function directly executes content generated by a large language model (LLM).
An attacker who can influence the content reaching this execution path may cause arbitrary code to run with the privileges of the Devika process.
Affected context
The vulnerability occurs in Devika v1.0 when the runner processes LLM-generated content through the Runner.execute function. It becomes risky when model output can be influenced by untrusted prompts, retrieved content, external inputs, or other data that reaches the execution path without being treated as untrusted.
Exploit preconditions
- Attack surface: Devika's LLM-driven runner and execution workflow
- Required access: An ability to influence prompts, task inputs, retrieved content, or other data incorporated into LLM output
- Trigger point: Processing of LLM-generated content by
Runner.execute - Why exploitation is possible: Generated content is executed directly rather than being treated as inert data and constrained by an allowlisted execution model
Why this happens
The underlying issue is the direct execution of LLM-generated content as program logic. This insecure pattern fails to maintain a trust boundary between generated text and executable code, allowing attacker-influenced output to reach an execution mechanism without sufficient validation, interpretation, or restriction.
This maps to CWE-94: Improper Control of Generation of Code ('Code Injection'), because externally influenced content can alter the code executed by the application.
Potential impact
- An attacker may execute arbitrary code in the Devika process context
- Sensitive files, credentials, or environment variables could be accessed
- The application or host environment could be compromised
- Data could be modified, deleted, or exfiltrated
- Compromised workloads could be used for lateral movement or further abuse
General mitigation guidance
Mitigation generally focuses on preventing generated content from becoming unrestricted executable code.
Common defensive patterns include:
- Treating all LLM output as untrusted data by default
- Replacing general-purpose execution with narrowly scoped, allowlisted operations
- Using structured outputs and strict schemas instead of free-form code
- Applying validation, canonicalization, and policy checks before any execution decision
- Running unavoidable dynamic tasks in isolated, least-privileged sandboxes
- Restricting filesystem, network, credential, and process access for the runner
- Separating model interaction from privileged application operations
How teams detect issues like this
Organizations can look for:
- Static-analysis findings involving
exec,eval, shell invocation, dynamic imports, or equivalent execution APIs - Code paths that pass LLM output directly into interpreters, subprocesses, templates, or scripting engines
- Code review signals showing missing allowlists, schemas, approval gates, or sandbox boundaries
- Runtime monitoring for unexpected child processes, command execution, network connections, or access to sensitive paths
- Policy enforcement requiring generated actions to use approved tools and structured interfaces
Automated code-review and application-security tools may help identify direct flows from model output to execution sinks.
