A vulnerability in the widely used open-source forensic tool The Sleuth Kit can be exploited to run arbitrary commands on a system—but the validity of the flaw is hotly contested. Tracked as CVE-2022-45639, the issue affects the fls utility’s -m option, which accepts a user-supplied mount point string. While multiple vulnerability databases assign it a high severity score, third parties have argued that the demonstrated attack never escapes the local user’s security context, effectively limiting harm to what the attacker could already do.

What the Flaw Actually Entails

The Sleuth Kit is a collection of command-line utilities for analyzing disk images and file systems. Its fls tool lists files and directories, and the -m option lets examiners prepend a mount point to each output line—useful for building timelines with the mactime utility. The vulnerability, first published on January 23, 2023, and assigned CVE-2022-45639, is an OS command injection (CWE-78) in version 4.11.1. The proof-of-concept is disarmingly simple: passing a value containing backticks, such as fls -m \id``, causes the shell to execute the command inside the backticks.

According to the National Vulnerability Database (NVD), the CVSS 3.1 base score is 7.8 (High), with an attack vector of Local, low privileges required, no user interaction, and high impact on confidentiality, integrity, and availability. Snyk’s advisory also flags the issue with a working PoC. But here’s the twist: the CVE entry is marked “DISPUTED.” The reason, as noted in the NVD record, is that “there is no analysis showing that the backtick command executes outside the context of the user account that entered the command line.” In other words, the flaw only lets an attacker do what they could already do as the logged-in user—it doesn’t grant elevated privileges.

Who Should Be Concerned—and Who Can Relax

The real-world risk depends entirely on how you use fls.

  • Interactive forensic examiners who run fls manually on their own workstations are at low risk. An attacker would need to trick you into running a command with a malicious -m string, which is nearly a social engineering attack. If you only run trusted commands, you’re fine.
  • Automated forensic pipelines are a different story. If your organization processes disk images from untrusted sources and passes user-controlled strings (like mount points from a web form) directly to fls, then an attacker could inject commands that execute as the pipeline’s service account. This account often has elevated privileges to access raw disk images, making the impact severe.
  • Windows environments deserve extra caution. The Sleuth Kit runs on Windows, and if fls is called from a service running as SYSTEM or a high-integrity process, an injected command could compromise the entire machine. That turns a local, context-limited flaw into a potential disaster. If you’re running Sleuth Kit from an elevated Command Prompt or PowerShell session, the fls process inherits those elevated rights—an attacker who can inject a command into that session effectively gains administrator-level control.

How This Vulnerability Came to Light

The timeline shows a bumpy ride from disclosure to dispute. The NVD initially published CVE-2022-45639 on January 23, 2023, with an incorrect attack vector of Network (AV:N) and a CVSS score of 7.8—implying remote exploitation. By February 2, 2023, after analysis by NIST, the vector was corrected to Local (AV:L). The next day, February 1, the description was updated with the “DISPUTED” tag, and the note about user context was added. The PoC appeared on the Italian security site binaryworld.it and was later mirrored on Packet Storm Security. Multiple vulnerability aggregators, including Snyk and OSV, picked up the alert and propagated the high severity score, leading to widespread concern among forensic practitioners.

After the initial flurry, the CVE record saw further updates. On April 3, 2023, a reference to a Packet Storm Security PoC was added. In subsequent months, MITRE and CISA-ADP adjusted the record. By April 2025, CISA-ADP added an SSVC evaluation with a timestamp of April 2, 2025, noting that a proof-of-concept exists and that, if exploited, the technical impact could be total. Yet the “Disputed” tag remains, underscoring the ongoing disagreement within the security community. The Sleuth Kit maintainers haven’t issued a public statement, but independent security researchers have argued that the issue is being blown out of proportion.

What to Do Now: Immediate Steps

Until an official fix or clearer guidance emerges, here’s how to protect your environment:

  • Sanitize the -m input. If you call fls from any script or application, strip or escape shell metacharacters: backticks (), dollar-parenthesis ($()), semicolons (;), pipes (|), ampersands (&), and newlines. Better yet, accept only a strict whitelist of characters suitable for mount points (e.g.,/`, alphanumerics, colons for Windows paths, hyphens, underscores).
  • Avoid shell interpretation altogether. When launching fls from code, use direct process creation (like execv on Unix, CreateProcess on Windows) with an argument array, rather than building a single command string that gets passed to a shell. This eliminates the risk of metacharacter evaluation.
  • Run with least privilege. Never run fls as root or SYSTEM unless absolutely necessary. Create a dedicated low-privilege user for forensic automation, and restrict who can execute that user’s tasks.
  • Monitor and audit. Enable command-line logging (on Windows, Event ID 4688 with full command line; on Linux, auditd rules or shell history recording). Look for fls invocations with suspicious -m values. If you’re investigating a potential compromise, check for shell artifacts like /dev/pts/ logs showing commands executed after a fls call.
  • Update your wrappers and scripts. If you use any third-party scripts or appliances that integrate fls, contact your vendor to ensure they validate inputs. Many open-source forensic workflows bundle fls with default scripts that might be vulnerable.

What the Industry Should Do Next

This disputed CVE highlights a deeper problem in vulnerability management. Automated scanners and feeds often blast out alerts based on raw CVSS scores without context, causing security teams to waste time on low-risk issues while potentially missing the dangerous ones. For CVE-2022-45639, the key lesson is: always evaluate a vulnerability in the context of your specific deployment, not just its headline number.

The Sleuth Kit’s maintainers could ease the confusion by publishing a short advisory. If the fls binary itself doesn’t invoke a shell when handling -m, they should say so, and point to any wrapper scripts that might. If the issue is in those wrappers, a fix in documentation or example scripts would help.

Forensic tool developers should also take note. Many utilities accept arbitrary strings that later get passed to other command-line tools—a pattern ripe for injection. A proactive audit of tools like fls, mmls, and fsstat could uncover similar latent risks.

Outlook: Watching for Updates

The CVE record has been modified several times, most recently by CISA-ADP in April 2025 with the addition of a Stakeholder-Specific Vulnerability Categorization (SSVC) assessment that notes “poc” exploitation and “total” technical impact. This suggests that some government bodies still view the bug as potentially critical, even if disputed. It’s unlikely the NVD will retract the CVE, but the score could be lowered if consensus builds that the impact is limited.

For day-to-day forensic work, The Sleuth Kit remains a trusted staple. By applying the basic input validation and privilege controls outlined above, you can keep using fls without losing sleep over CVE-2022-45639. Stay aware, but don’t panic.