Summary
Devika v1.0 contains a critical code injection vulnerability in the Runner.run_code function. If an attacker can influence code or instructions passed to this function, they may cause arbitrary code to execute in the application's runtime context.
Affected context
The vulnerability occurs in Devika's runner component, specifically in src/agents/runner/runner.py, where the Runner.run_code function processes code for execution. Risk depends on whether untrusted users, prompts, repository content, integrations, or other external inputs can reach this function without strong isolation and authorization controls.
Exploit preconditions
- Attack surface: The Devika code-execution runner and any interface that
invokes Runner.run_code
- Required access: The ability to supply or influence input that reaches the
runner; the exact access level depends on the deployment and exposed
interfaces
- Trigger point: Execution of attacker-influenced content by
Runner.run_code
- Why exploitation is possible: Input is treated as executable code rather
than as inert data, allowing attacker-controlled instructions to run in the
process context
Why this happens
The underlying flaw is a code injection pattern in which data from a potentially untrusted source reaches a runtime code-execution function without sufficient separation, validation, or containment. This maps to CWE-94, Improper Control of Generation of Code, because externally influenced content can alter or supply executable program logic.
Potential impact
- An attacker may execute arbitrary code with the privileges of the Devika process.
- Sensitive files, environment variables, or application data could be exposed.
- The application could be modified, disrupted, or used for unauthorized actions.
- A compromised process could enable further movement into connected services or infrastructure.
General mitigation guidance
Mitigation generally focuses on removing dynamic execution of untrusted content and reducing the trust placed in model, user, repository, and integration inputs. Secure-by-default alternatives include structured operations, allowlisted capabilities, and declarative task formats instead of general-purpose code execution. Where execution is an essential feature, strong sandboxing, process isolation, resource limits, filesystem and network restrictions, explicit authorization, and least-privilege service identities can reduce exposure. Validation should constrain intent and allowed operations, but should not be treated as a substitute for isolation.
How teams detect issues like this
Detection approaches include static analysis for calls to dynamic execution APIs and data flows from user-controlled, model-controlled, repository, or network inputs into Runner.run_code. Code reviews should examine whether execution functions receive untrusted strings, whether authorization occurs before execution, and whether sandbox boundaries are enforced independently of input validation. Runtime monitoring can flag unexpected child processes, filesystem access, network connections, and execution of commands outside approved workflows. Security policies and automated review tools can enforce approved execution patterns in CI.
