Hi, The following vulnerabilities were published for vim. CVE-2026-55693[0]: | Vim is an open source, command line text editor. Prior to 9.2.0653, | the tree_count_words() function in src/spellfile.c fills in the | word-count fields of a spell-file word trie by walking it | iteratively with a depth counter. The counter is bounded only by the | trie structure itself; it is never checked against the size of the | fixed MAXWLEN-element stack arrays it indexes (arridx[], curi[], | wordcount[]). A crafted .spl/.sug file pair, loaded when the user | invokes spell suggestion, can drive the descent arbitrarily deep, so | the function writes past the end of those arrays. This is a stack | out-of-bounds write that corrupts the call frame and crashes the | editor. This vulnerability is fixed in 9.2.0653. CVE-2026-55892[1]: | Vim is an open source, command line text editor. Prior to 9.2.0662, | the dump_prefixes() function in src/spell.c walks a spell-file | prefix trie iteratively with a depth counter while dumping the | prefixes that apply to a word. The counter is bounded only by the | trie structure itself; it is never checked against the size of the | fixed MAXWLEN-element stack arrays it indexes (prefix[], arridx[], | curi[]). A crafted .spl file, loaded when the user dumps the word | list, can drive the descent arbitrarily deep, so the function writes | past the end of those arrays. This is a stack out-of-bounds write | that corrupts the call frame and crashes the editor. This | vulnerability is fixed in 9.2.0662. CVE-2026-55895[2]: | Vim is an open source, command line text editor. Prior to 9.2.0663, | a Vimscript code injection vulnerability exists in | s:NetrwLocalRmFile() in the netrw plugin | (runtime/pack/dist/opt/netrw/autoload/netrw.vim) when deleting a | local file from the browser. A filename derived from the buffer's | directory listing is interpolated into an Ex command line passed to | :execute with only the backslash character escaped, allowing a | crafted filename containing a bar (|) to terminate the intended | command and execute arbitrary Vimscript, including shell commands | via :call system() and :!. This vulnerability is fixed in 9.2.0663. CVE-2026-57451[3]: | Vim is an open source, command line text editor. Prior to 9.2.0670, | get_text_props() in src/textprop.c reads a uint16 property count | stored inline after a line's text and returns it as the number of | 32-byte textprop_T entries that follow. The only check is a floor | that guarantees room for a single entry; the count is never checked | against the amount of data actually present. A line that declares a | large count while carrying little data causes consumers to read far | past the end of the line buffer. Such a line can be delivered | through a crafted undo file, leading to a crash. This vulnerability | is fixed in 9.2.0670. CVE-2026-57452[4]: | Vim is an open source, command line text editor. Prior to 9.2.0671, | when Vim opens a file encrypted with the VimCrypt~04! or | VimCrypt~05! method (xchacha20poly1305, requires the +sodium | feature) whose body is shorter than a single libsodium secretstream | header, an unsigned length calculation underflows and a subsequent | decryption call reads far past the end of the input buffer, crashing | Vim. This vulnerability is fixed in 9.2.0671. CVE-2026-57453[5]: | Vim is an open source, command line text editor. From 9.1.1784 until | 9.2.0678, when the bundled zip plugin autoload/zip.vim falls back to | PowerShell to browse, read, extract, update or delete entries in a | zip archive, it builds the PowerShell command by inserting archive | entry names that are quoted only for the shell, not for PowerShell. | A crafted entry name can break out of the intended string context | and cause PowerShell to execute arbitrary commands with the | privileges of the user running Vim, triggered by opening, viewing or | extracting the archive. This vulnerability is fixed in 9.2.0678. CVE-2026-57454[6]: | Vim is an open source, command line text editor. From 9.2.0320 until | 9.2.0679, a crafted undo or swap file can store a virtual-text | property whose offset and length point outside the line's property | data. When Vim restores or displays such a line it converts the | offset into a pointer and reads the virtual text without bounds | checking, causing an out-of-bounds read that can crash Vim or | disclose adjacent heap memory. This vulnerability is fixed in | 9.2.0679. CVE-2026-57455[7]: | Vim is an open source, command line text editor. Prior to 9.2.0698, | the single-byte branch of spell_soundfold_sofo() in src/spell.c | translates a word through a spell file's SOFO (sound-folding) byte | map into a caller-owned result buffer. Its copy loop advances the | output index ri with no upper bound and terminates only on the input | NUL, writing one byte per input byte into the MAXWLEN-element stack | buffer the caller provides. A word longer than MAXWLEN, passed to | soundfold() (or reached via sound-based spell suggestion) while a | SOFO-based spell language is active, therefore writes past the end | of that buffer. This is a stack out-of-bounds write that corrupts | the call frame and crashes the editor. This vulnerability is fixed | in 9.2.0698. CVE-2026-57456[8]: | Vim is an open source, command line text editor. Prior to 9.2.0699, | Vim's Python omni-completion (runtime/autoload/python3complete.vim | and the legacy pythoncomplete.vim) executes reconstructed function | and class definitions from the current buffer with exec() as part of | populating the completion dictionary. When reconstructing that | source, each scope's docstring is inserted verbatim between triple | quotes with no escaping, so a hostile buffer can break out of the | triple-quoted literal and execute attacker-controlled Python during | omni-completion. This vulnerability is fixed in 9.2.0699. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2026-55693 https://www.cve.org/CVERecord?id=CVE-2026-55693 [1] https://security-tracker.debian.org/tracker/CVE-2026-55892 https://www.cve.org/CVERecord?id=CVE-2026-55892 [2] https://security-tracker.debian.org/tracker/CVE-2026-55895 https://www.cve.org/CVERecord?id=CVE-2026-55895 [3] https://security-tracker.debian.org/tracker/CVE-2026-57451 https://www.cve.org/CVERecord?id=CVE-2026-57451 [4] https://security-tracker.debian.org/tracker/CVE-2026-57452 https://www.cve.org/CVERecord?id=CVE-2026-57452 [5] https://security-tracker.debian.org/tracker/CVE-2026-57453 https://www.cve.org/CVERecord?id=CVE-2026-57453 [6] https://security-tracker.debian.org/tracker/CVE-2026-57454 https://www.cve.org/CVERecord?id=CVE-2026-57454 [7] https://security-tracker.debian.org/tracker/CVE-2026-57455 https://www.cve.org/CVERecord?id=CVE-2026-57455 [8] https://security-tracker.debian.org/tracker/CVE-2026-57456 https://www.cve.org/CVERecord?id=CVE-2026-57456 Regards, Salvatore