EUVD-2026-31439
GHSA-3623-vc46-pwpv
Severity by source
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Local vector (state file on disk), no privileges needed to create long history entries, user interaction required to launch vifm, availability-only impact per provided CVSS 4.0 impact metrics.
Primary rating from Vendor (CERT-PL).
CVSS VectorVendor: CERT-PL
Lifecycle Timeline
3DescriptionCVE.org
vifm is vulnerable to a heap buffer overflow during the history merge process when saving the state file (vifminfo.json). This flaw occurs because the application lacks a runtime check on the length of history entries in release builds, potentially allowing a crafted long path or command in the history to cause memory corruption or application crashes. Releases from 0.12.1 to 0.14.3 (including) are considered vulnerable. This issue was fixed in commit 23063c7
AnalysisAI
Heap buffer overflow in vifm's trie implementation exposes versions 0.12.1 through 0.14.3 to memory corruption or application crash when processing history entries that exceed PATH_MAX*2 bytes during state file (vifminfo.json) load and merge. The root cause is a missing runtime length check in release builds - a guard assert existed only in debug builds, leaving production binaries unprotected against oversized keys in the trie string storage. Exploitation yields at most application availability impact (crash); no public exploit code exists and CISA has not added this to the KEV catalog, with EPSS at 0.02%.
Technical ContextAI
vifm is a terminal-based vi-like file manager written in C. It uses an internal trie data structure (src/utils/trie.c) to store and merge history entries from its state file (vifminfo.json). Each trie node's string storage was allocated in fixed-size buffers defined as STR_BUF_SIZE = PATH_MAX*2 (typically 8192 bytes on Linux). An assert statement validated that inserted keys did not exceed this limit, but assert() is a no-op in release builds compiled with NDEBUG, meaning the length guard was entirely absent in shipped binaries. When a key longer than STR_BUF_SIZE was inserted - either via a crafted state file or via a genuinely long filesystem path or command in history - malloc() allocated only STR_BUF_SIZE bytes while the subsequent memcpy wrote the full key length, causing a heap buffer overflow (CWE-122). The affected CPE is cpe:2.3:a:vifm:vifm:*:*:*:*:*:*:*:* for versions 0.12.1 through 0.14.3. Discovered by Michał Majchrowicz and Marcin Wyczechowski of CERT-PL.
RemediationAI
The upstream fix is available in commit 23063c741f15a85621fd232dfc3ac5b779f6910d at https://github.com/vifm/vifm/commit/23063c741f15a85621fd232dfc3ac5b779f6910d; this changes trie string buffer allocation to use MAX(MIN_STR_BUF_SIZE, len) so buffers always accommodate the actual key length rather than a fixed cap. A formally tagged release containing this fix has not been independently confirmed from the available data - users should build from a commit at or after 23063c7 until an official release is published. As a compensating control where building from source is not feasible, administrators can restrict write access to vifminfo.json or use filesystem controls to prevent untrusted content from entering the file, though this does not address locally-triggered history entries from long paths. Users who do not rely on vifm's history merge functionality can consider disabling history persistence via vifm configuration, accepting the trade-off of lost command history across sessions.
Same weakness CWE-122 – Heap-based Buffer Overflow
View allSame technique Buffer Overflow
View allVendor StatusVendor
SUSE
| Product | Status |
|---|---|
| openSUSE Tumbleweed | Fixed |
Share
External POC / Exploit Code
Leaving vuln.today