CVE-2026-110237 in Vifminfo

Summary

by MITRE • 10/13/2026

Vifm 0.8.1-beta through 0.14.4 reuses a pre-existing IPC FIFO in the shared temporary directory without checking ownership, allowing local users to execute commands as another user. Attackers can pre-create a world-writable vifm-ipc-vifm FIFO and write IPC packets with -c and ! shell commands that execute with the victim's privileges.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Analysis

by VulDB Data Team • 10/13/2026

The vulnerability in Vifm versions 0.8.1-beta through 0.14.4 represents a critical failure in access control mechanisms within inter-process communication channels, specifically classified under CWE-256: Unprotected Storage of Credentials and CWE-732: Operator Permission Errors. The core technical flaw stems from the application's reliance on named pipes, or FIFOs, located in shared temporary directories such as /tmp for handling internal commands. When Vifm initiates its IPC mechanism to process user inputs like shell expansions or command executions via the -c flag and ! operator, it creates a FIFO endpoint without verifying whether an existing file with that name is already present in the directory. This oversight allows any local user on the system to pre-create a world-writable FIFO using the same naming convention expected by Vifm before the victim application starts or attempts to connect.

By exploiting this race condition and lack of ownership verification, an attacker can manipulate the communication channel between different components of the Vifm process or across distinct user sessions. The attacker writes malicious IPC packets into their pre-created FIFO, which are then read and executed by the vulnerable instance of Vifm running under a higher-privileged context or that of another victim user. This effectively bypasses standard Unix permission models because the execution occurs within the security context of the process reading the pipe rather than the one writing to it. The operational impact is severe, as it enables local privilege escalation and arbitrary command execution with the privileges of the target user. An attacker does not need elevated permissions themselves; they only require write access to the shared temporary directory, which is typically world-writable on most Linux distributions, making this a low-barrier-to-entry attack vector for any authenticated local user.

This behavior aligns closely with ATT&CK technique T1059: Command and Scripting Interpreter, as it involves the abuse of system utilities to execute arbitrary code within an application's context. Furthermore, it reflects principles found in CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization of Access Controls, where shared resources are accessed without adequate safeguards against unauthorized modification or injection. The vulnerability highlights a common pitfall in software development where convenience and simplicity in IPC implementation override security best practices regarding file ownership checks and atomic operations during resource creation.

Mitigation strategies must focus on enforcing strict access controls over inter-process communication endpoints. Developers should implement the use of mkfifo with restrictive permissions, ensuring that only the intended user can write to or read from the FIFO. Alternatively, using Unix domain sockets instead of named pipes in shared directories is a more robust approach as they do not suffer from the same namespace collision issues and allow for finer-grained permission controls via socket file modes. For system administrators unable to immediately patch the software, restricting write access to /tmp through sticky bits or mounting it with noexec options can reduce the attack surface, although this may impact other applications relying on temporary files. The most effective remediation is upgrading Vifm to a version where these IPC mechanisms have been hardened against such injection attacks by verifying file ownership and ensuring exclusive creation of communication channels.

Responsible

VulnCheck

Reservation

10/13/2026

Disclosure

10/13/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!