CVE-2026-78136 in Chirp
Summary
by MITRE • 08/23/2026
chirpmyradio CHIRP before 39178db allows eval injection via crafted CSV data. This occurs in _clean_tmode in drivers/kenwood_itm.py.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/23/2026
The vulnerability identified in versions of the CHIRP radio programming software prior to commit hash 39178db represents a critical server-side code execution flaw rooted in improper input validation and unsafe data handling practices. Specifically, this issue manifests within the Kenwood ITM driver module, affecting the _clean_tmode function which is responsible for processing tone mode configurations from uploaded CSV files. The core technical deficiency lies in the application's failure to sanitize or strictly validate user-supplied data before passing it to Python’s eval() function. By allowing crafted CSV content to be interpreted as executable code rather than static string literals, the software creates a direct pathway for arbitrary command execution on the host system where CHIRP is running.
From an architectural perspective, this flaw aligns with CWE-95, commonly known as Improper Neutralization of Directives in Dynamically Evaluated Code or eval Injection. The vulnerability arises because the developer assumed that data imported from a CSV file would be benign and strictly formatted according to expected patterns for radio programming parameters. However, by relying on dynamic evaluation without rigorous type checking or allow-listing of permitted values, the application violates fundamental security principles regarding input validation. An attacker who can trick a user into importing a maliciously crafted CSV file containing specific Python syntax within the tone mode field can trigger this code path, leading to remote code execution under the context of the currently logged-in user.
The operational impact of this vulnerability is severe due to its potential for full system compromise. Since CHIRP typically runs with standard user privileges on desktop operating systems such as Windows, macOS, or Linux, successful exploitation allows an attacker to execute arbitrary commands within that security context. This can lead to the theft of sensitive data stored locally by the application, including radio configuration files which may contain proprietary frequencies and access codes for private networks. Furthermore, if the victim has administrative privileges or uses password managers integrated with their browser or operating system, the attacker could potentially escalate privileges or exfiltrate credentials. The attack vector is primarily social engineering based, requiring the user to import a malicious file, but once triggered, no further interaction is needed for code execution.
In terms of threat modeling and industry standards, this vulnerability maps directly to MITRE ATT&CK technique T1059, Command and Scripting Interpreter, specifically under sub-techniques involving Python scripting (T1059.006). The exploitation chain involves the attacker crafting a CSV payload that exploits the eval function, which serves as the mechanism for code execution within the application environment. This is classified as an injection vulnerability because external data is injected into a command or query context where it is interpreted by the interpreter rather than treated as data.
Mitigation strategies must focus on immediate remediation and future prevention measures. The primary mitigation is to upgrade CHIRP to version 39178db or any subsequent release that has patched this specific flaw in drivers/kenwood_itm.py. For organizations deploying this software across multiple endpoints, it is advisable to enforce application whitelisting policies to prevent unauthorized execution of scripts and binaries unless explicitly approved by security teams. Additionally, users should be educated on the risks associated with importing files from untrusted sources, as social engineering remains a primary vector for triggering such vulnerabilities. From a development standpoint, replacing eval() calls with safer parsing methods or strict type validation is essential to eliminate this class of vulnerability in future iterations of the software.