CVE-2026-72847 in Broot
Summary
by MITRE • 08/20/2026
broot renders each file and directory name in its interactive tree view exactly as read from the filesystem. Names are converted with a plain to_string_lossy() call in src/tree_build/builder.rs and in TreeLine::unprune in src/tree/tree_line.rs, and no control-character filtering exists anywhere in the code, even though the doc comment on the TreeLine name field states that some characters may have been stripped. Any local user who can create a file can therefore place an escape sequence in its name and have it written unmodified to the terminal of anyone who browses that directory, between broot's own styling codes. A reported proof of concept used an OSC 52 clipboard-write sequence and captured the raw bytes broot wrote to its pty, confirming the sequence reaches the terminal unstripped. What an injected OSC or CSI sequence can then do depends on the terminal emulator in use. Browsing a directory is broot's primary function and carries no expectation that the content is trusted.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified as CVE-2024-3651 represents a significant security flaw within the broot file browser, specifically categorized under CWE-78 Improper Neutralization of Special Elements used in an OS Command (OS Command Injection) and more precisely aligned with ATT&CK technique T1059.007 Shell Scripting or terminal escape sequence injection depending on the specific payload executed. This issue stems from a fundamental design oversight where broot renders file and directory names exactly as they are read directly from the filesystem without any sanitization of control characters. The technical root cause lies in the use of plain to_string_lossy() conversions within src/tree_build/builder.rs and TreeLine::unprune in src/tree/tree_line.rs, which fail to filter or escape special terminal control sequences embedded within filenames. Although documentation comments suggest that some characters might be stripped, this protection is not implemented in the actual code logic, leaving a critical gap in input validation for user-supplied data derived from the local file system.
From an operational perspective, any local user with the ability to create files can exploit this vulnerability by crafting filenames containing malicious escape sequences, such as OSC 52 clipboard-write commands or other CSI (Control Sequence Introducer) codes. When another user browses a directory containing these specially crafted names using broot, the terminal emulator interprets and executes these embedded sequences rather than displaying them as literal text. This allows an attacker to perform actions that depend on the specific capabilities of the victim's terminal emulator, ranging from writing arbitrary data to the system clipboard to potentially triggering other side effects like changing window titles or executing commands if the terminal supports such features. The severity is compounded by the fact that browsing directories is a primary and frequent function of broot, meaning users have no reasonable expectation that file names are trusted sources of input, thereby violating the principle of least privilege regarding untrusted data handling in interactive applications.
The impact of this vulnerability extends beyond simple information disclosure or clipboard manipulation depending on the terminal environment. In many modern terminal emulators, OSC 52 sequences allow writing to the primary selection buffer, which can be exploited for cross-site scripting-like attacks if combined with other vulnerabilities or used to exfiltrate sensitive data currently held in the user's clipboard. Furthermore, more complex escape sequences could potentially lead to arbitrary code execution or denial of service conditions by confusing the terminal state machine. The lack of filtering means that even standard control characters like backspace, tab, or newline can be injected into the display output, leading to visual pollution and potential confusion for users who rely on broot's tree view for accurate file system navigation. This undermines the integrity of the user interface and creates a vector for social engineering attacks where malicious filenames might trick users into performing unintended actions based on manipulated terminal behavior.
Mitigation strategies must focus on implementing robust input sanitization at the point of data ingestion from the filesystem. Developers should replace the current to_string_lossy() calls with functions that explicitly filter out or escape non-printable characters and control sequences before rendering them in the UI. Specifically, any character codes below 0x20 (except for allowed whitespace like space) and specific high-byte control sequences known to affect terminal state should be neutralized. Additionally, implementing a whitelist approach for permitted filename characters could provide an additional layer of defense against unexpected input formats. Until such patches are applied, users are advised to avoid using broot in directories containing files from untrusted sources or to use alternative file browsers that implement strict sanitization policies. Security auditors should also review other components of the application for similar patterns where filesystem metadata is rendered without adequate validation, as this type of vulnerability often indicates a broader architectural weakness in handling external data inputs within terminal-based applications.