CVE-2026-51874 in Devika
Summary
by MITRE • 10/02/2026
In Devika v1.0, the Patcher Agent save_code_to_project function contains a path traversal vulnerability that allows attackers to write files outside the intended project workspace.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/02/2026
The security flaw identified in Devika version 1.0 resides within the Patcher Agent module, specifically affecting the save_code_to_project function. This component is responsible for handling code modifications and persisting them to the file system as part of an automated development or patching workflow. The underlying technical deficiency is a classic path traversal vulnerability, which stems from insufficient validation of user-supplied input before it is processed by the operating system's file I/O routines. When the function receives a filename or directory structure intended for saving code, it fails to adequately sanitize special characters such as dot-dot-slash sequences (../) or absolute paths that reference locations outside the designated project workspace boundary. This lack of strict path canonicalization allows an attacker to manipulate the input string so that the resulting file write operation targets arbitrary directories on the host system rather than the intended sandboxed environment.
From a technical perspective, this vulnerability exploits the way many programming languages and operating systems resolve relative paths. If the application constructs a full file path by concatenating a base directory with user-controlled input without normalizing or validating that result against allowed prefixes, it creates an opening for directory escape. An attacker can craft a malicious payload where the filename includes sequences like ../../etc/passwd on Linux systems or C:\Windows\System32\drivers\etc\hosts on Windows environments. Because the save_code_to_project function does not enforce strict containment rules, these crafted paths bypass the intended isolation mechanisms. The vulnerability is particularly dangerous in automated agents because it may be triggered by inputs derived from external sources such as user prompts, uploaded files, or data fetched from remote repositories if those inputs are passed directly to this function without rigorous sanitization checks.
The operational impact of this path traversal flaw extends beyond simple unauthorized file writes. By writing arbitrary content to sensitive system locations, an attacker can achieve several malicious outcomes depending on the privileges under which Devika is running. If the process executes with elevated permissions, the attacker could overwrite critical configuration files, inject malicious scripts into startup directories for persistence, or replace legitimate binaries to establish a foothold in the network. Even if run as a standard user, the ability to write outside the project workspace can lead to data corruption of other projects stored on the same machine or leakage of sensitive information by overwriting log files with misleading content. In cloud-native environments where Devika might be deployed within containers or serverless functions, this vulnerability could potentially aid in container escape if combined with other misconfigurations, although the primary risk remains local file system compromise and integrity violation of the host environment.
This type of flaw is formally categorized under CWE-22: Improper Limitation of a Pathname to a Restricted Directory within the Common Weakness Enumeration framework. It represents a failure in input validation where the application does not restrict access to resources outside an intended directory tree. In terms of offensive security tactics, this vulnerability aligns with MITRE ATT&CK technique T1048: Exfiltration Over Alternative Protocol if used for data theft, or more commonly T1562: Impair Defenses when used to disable security tools by overwriting their configuration files. It also relates to TA0003 Persistence and TA0005 Defense Evasion as the attacker can use this write capability to plant backdoors or modify system settings to avoid detection.
To mitigate this vulnerability, developers must implement strict input validation on all file paths passed to the save_code_to_project function. This includes canonicalizing the path using standard library functions that resolve symbolic links and relative references before performing any file operations. The application should then verify that the resolved absolute path starts with the expected project root directory prefix; if it does not, the operation must be rejected immediately. Additionally, employing a whitelist approach for allowed characters in filenames can further reduce the attack surface by preventing special sequence injection. It is also advisable to run the Devika agent with least-privilege principles, ensuring that even if an attacker succeeds in writing files outside the workspace, they lack the permissions necessary to modify critical system areas or execute arbitrary code effectively. Regular security audits and static analysis tools configured to detect path traversal patterns can help identify similar issues across other components of the application before deployment.