REDHAT-BUG-2460434: Race Condition

AIONLYREPORT package: vim-9.1.083-9.el102 ------ Summary: Vimscript injection via unescaped filename in filter() expression in s:NetrwMarkFile(): a crafted filename can break out of the quoted filter() expression during netrw mark/unmark operations and execute arbitrary Vimscript, which can in turn invoke shell commands with the privileges of the Vim user. Requirements to exploit: The attacker must place or induce access to a crafted filename in a directory the victim browses with netrw. The victim must open that directory in Vim and trigger mark/unmark on the malicious entry. Successful exploitation executes attacker-controlled Vimscript and any shell commands it invokes with the privileges of the Vim process. Component affected: Vim netrw implementation - vim91/runtime/autoload/netrw.vim (s:NetrwMarkFile()) Version affected: confirmed in vim-9.1.083-9.el102; available local history shows the vulnerable code from boundary commit e00d3d2 (base vim-9.1.083-9.el10) through current HEAD Patch available: no Version fixed (if any already): unknown Upstream coordination: Not yet notified. This report is the initial triage, and a draft disclosure email is prepared for maintainers. CVSS: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H - 7.8 (HIGH) AV:L - The attacker must control or induce access to a crafted filename in a directory the victim opens locally through Vim/netrw. AC:L - Exploitation requires only crafted filename content; no race condition or special environment is needed beyond using netrw mark/unmark. PR:N - The attacker needs no privileges on the vulnerable Vim instance. UI:R - The victim must browse the directory in netrw and trigger mark/unmark on the crafted entry. S:U - The vulnerable component and the impact remain within the Vim user context. C:H - Arbitrary Vimscript can read files and data accessible to the user running Vim. I:H - Arbitrary Vimscript can modify files or invoke shell commands as that user. A:H - Arbitrary Vimscript or shell commands can disrupt the editor session or destroy user-accessible data. Impact: Important. Successful exploitation leads to arbitrary Vimscript and shell command execution with the privileges of the user running Vim. Although exploitation requires local file placement and explicit user interaction inside netrw, it directly compromises the confidentiality, integrity, and availability of the user's data and environment. Embargo: yes Reason: This issue permits code execution from a crafted filename and no official fix is known yet. Public disclosure before coordination or a fix is available would make social-engineering attacks against users browsing untrusted directories with netrw substantially easier. Suggested public date: 19-Jul-2026 Acknowledgement: Aisle Research

Vulnerability details

In vim91/runtime/autoload/netrw.vim, a:fname from the directory listing is composed into dname and then interpolated directly into a string expression passed to filter(): vim let dname= s:ComposePath(b:netrwcurdir,a:fname) ... call filter(s:netrwmarkfilelist,'v:val != "'.dname.'"') filter({list}, {expr}) evaluates {expr} when it is supplied as a string. A crafted filename containing " and expression fragments can therefore break out of the quoted string during mark/unmark and execute arbitrary Vimscript. Relevant flow: vim nnoremap ... mf :...call <SID>NetrwMarkFile(...,<SID>NetrwGetWord())<cr> fun! s:NetrwGetWord() let dirname= getline('.') return dirname endfun Most relevant CWE identifiers: CWE-94 (Improper Control of Generation of Code)

CWE-74 (Injection into downstream interpreter)

Affected versions

Using available repository history in this checkout: git blame -L 7000,7040 vim91/runtime/autoload/netrw.vim attributes the vulnerable lines to boundary commit e00d3d2 (base vim-9.1.083-9.el10).

Current HEAD in this checkout still contains the vulnerable code.

Based on the available history, the affected range appears to extend from e00d3d2 through current HEAD; earlier upstream introduction could not be confirmed from the truncated history.

Steps to reproduce

1. Create a test directory and a file whose name injects Vimscript into the quoted filter() expression: bash mkdir netrw-poc && cd netrw-poc python3 - <<'PY' from pathlib import Path name = 'x" . execute("silent! !touch netrwinjectionpoc") . "' Path(name).writetext("poc\n") print(name) PY 2. Open Vim in that directory and browse it with netrw (for example, :Ex). 3. Move the cursor to the crafted filename. 4. Press mf once to mark the file, then mf again to unmark it. 5. Observe the command-execution side effect: bash ls -l netrwinjectionpoc

Proposed fix

Use a lambda/Funcref so filter() does not parse attacker-controlled filename data as a Vimscript expression: diff — a/vim91/runtime/autoload/netrw.vim +++ b/vim91/runtime/autoload/netrw.vim @@ call filter(s:netrwmarkfilelist,'v:val != "'.dname.'"') + call filter(s:netrwmarkfilelist, {, v -> v !=# dname})

Alternative safe string form: vim call filter(s:netrwmarkfilelist, 'v:val !=# ' . string(dname)) ------ This report was generated using AI technology. Always review AI-generated content prior to use