AI_ONLY_REPORT
package: vim-9.1.083-9.el10_2
------
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.el10_2`; 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:netrw_curdir,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 netrw_injection_poc") . "'
Path(name).write_text("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 netrw_injection_poc
```


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