[vim/vim] Modelines cause too many issues (PR #19875)
Christian Brabandt
Problem: Modelines cause too many issues
Solution: Disable modeline by default
Note: this is a slightly backwards incompatible change.
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/19875
Commit Summary
- 1a50fa1 Modelines cause too many issues
File Changes
(4 files)
- M runtime/doc/options.txt (6)
- M runtime/doc/version9.txt (3)
- M src/optiondefs.h (2)
- M src/testdir/test_modeline.vim (4)
Patch Links:
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
MURAOKA Taro
koron left a comment (vim/vim#19875)After this change, many Vim users, including myself, will probably add set modeline to their .vimrc file. If that happens, it becomes unclear whether this can still be considered a security measure.
As an alternative, I propose changing the system so that all options are initially marked as incompatible with modeline, and then clearly safe options are re-marked as compatible with modeline one by one. Currently, we use a blacklist approach to specify options that cannot be used with modeline, but going forward, we will use a whitelist approach to specify options that can be used with modeline.
I think it's acceptable for all options to be temporarily unavailable in modeline during that process. Alternatively, the initial change could involve registering only the options used in modeline in the vim source code to the whitelist.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
BenYip
bennyyip left a comment (vim/vim#19875)What exactly is "too many issues"? I know there is a recent modeline security bug(GHSA-2gmj-rpqf-pxvh). Is there anything else?
I agree with the whitelist approach. Here is a list of common options that should be safe:
autoindent
colorcolumn
commentstring
conceallevel
expandtab
fileencoding
filetype
foldenable
foldlevel
foldmarker
foldmethod
modifiable
readonly
rightleft
shiftwidth
softtabstop
tabstop
varsofttabstop
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Brian Inglis
BrianInglis left a comment (vim/vim#19875)A lot of programmers use various editor (eclipse, emacs, gedit, Kate, VScode, Zed) modelines where supported, as many text files have syntax not recognized as unique MIME types, suffixes, by vim, or maybe also language scripts which need alternate writing directions, especially for comments?
Security should be enhanced for those, but any and all changes should be documented thoroughly and preannounced as deprecated, before dis-/enabling the new features in succeeding release(s).
Perhaps some new approach(es) should also be supported, like other editors' modelines for compatibility, or EditorConfig features, but including support in command line versions, where to my mind modelines supported features previously commonly available only with GUIs.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
James McCoy
jamessan left a comment (vim/vim#19875)FWIW, Debian Vim packages have defaulted to 'nomodeline' for 20 years, and also recommended vim-securemodelines as an way to allow list modelines (with an opinionated builtin list).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#19875)It started with this blog report from calif.io, which resulted in CVE-2026-34714. The written report was extremely hard to read due to the verbose amount of text and was clearly just a dump from claude code. I do expect much better reports from professional security researchers.
This apparently triggered repeated attempts from others to find similar issues, which resulted in CVE-2026-34982. And even more LLMs joined the game and flooded me with additional security reports of dubious quality. Most of them where actual bugs but did not classify as security issue (at least according to my opinion) and that was the reason for the many additional commits which did not go through PR/CI here and that is also the reason why I seemed not that active the last few days.
You can guess how much fun I had, since this happened during my week off so I can take care of my son for easter vacation. This is the reason for commit 2c976d0 to clarify on how to report security issues here.
In any case, those 2 CVEs above triggered the people from oss-sec to question the use of enabled modelines by default and I must say I agree. However, I guess a separate whitelist also makes sense. I guess we should have an option like 'modelinewhitelist', which when set/enabled (which it should by default), should only allow such a list and does therefore restrict the number of options that can be set (when 'modeline' is enabled).
So I guess this makes sense?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
依云
lilydjwg left a comment (vim/vim#19875)I like the whitelist approach, but I have doubt about making it configurable: say there is an option X that does a simple thing and the user decides it's safe to whitelist; what if later version of Vim makes X much more powerful that it is no longer safe to allow unstrusted file to set it?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
mattn
mattn left a comment (vim/vim#19875)I prototyped a VSCode-like trust mechanism (trustdir) to address this issue, implemented in C: #19876. The whitelist approach mentioned here also seems reasonable to me.
That said, I believe something like trustdir (a per-directory trust decision) is still necessary regardless of the approach. I implemented it in C, but thinking about making this achievable via a Vim plugin, it might be worth considering a built-in modeline() function that returns the parsed modeline values. This would allow plugin authors to implement their own trust/whitelist logic on top of it without needing changes to Vim's core modeline processing.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Tony Mechelynck
vim-dev ML
vim-ml left a comment (vim/vim#19875)—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
@chrisbra pushed 1 commit.
- 26277fd Revert "Modelines cause too many issues"
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
@chrisbra pushed 1 commit.
- 691da56 Cannot whitelist modeline options
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#19875)okay, latest commit adds the 'modelinestrict' option (default: on) for whitelisting only some options
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.
Demi Marie Obenour
DemiMarie left a comment (vim/vim#19875)Please do merge this patch. Modelines are just too risky.
At some point, it might make sense to re-enable a strict subset of them. For instance, only allowing shift width, tab stop, soft tab stop, and expand tab should be safe. But even then it should use a parser completely separate from the normal vimscript command parser. One designed with malicious input in mind from the beginning.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.
h_east
h-east left a comment (vim/vim#19875)You can guess how much fun I had, since this happened during my week off so I can take care of my son for easter vacation.
In such situations, I think it's perfectly fine to ask other Vim members for help. At the very least, I'm usually available to step in. Please prioritize spending time with your family 👍
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.