The _clean_tmode function in CHIRP's Kenwood ITM driver contains an eval() call operating on data parsed from CSV input. This is a direct code execution vulnerability: when CHIRP imports a CSV file containing mode strings, those strings are passed wholesale to Python's eval() function without any sandboxing or whitelisting. A mode string such as "import('os').system('command')" will execute arbitrary code on the host system with the privileges of the CHIRP process.
The attack surface is any path where CHIRP processes external radio data. This includes direct CSV imports, proprietary image files that export to CSV, and potentially driver loading sequences that handle mode fields. The vulnerable function name itself — containing 'clean' — indicates the developer recognized that untrusted input required transformation, yet implemented that transformation using the most dangerous possible mechanism.
The fix is straightforward: replace eval() with an explicit mode mapping. A simple dictionary lookup against allowed mode strings eliminates the attack vector entirely while preserving functionality. If your CHIRP installation processes radio data from untrusted sources — including files downloaded from forums or shared by other users — you are exposed until patched.
Beyond this specific fix, treat this discovery as a signal that similar patterns may exist elsewhere in CHIRP's driver stack. Volunteer-built radio software typically lacks the static analysis tooling that would flag eval() on untrusted paths, and the patterns that produce one such vulnerability often recur in related drivers. A codebase-wide audit for eval() calls handling file-parsed data would be prudent.