Wprowadzenie do problemu / definicja
Nowe ustalenia dotyczące bezpieczeństwa popularnych edytorów Vim i GNU Emacs pokazują, iż choćby zwykłe otwarcie pliku tekstowego może prowadzić do zdalnego wykonania kodu. To szczególnie niepokojące, ponieważ oba narzędzia są powszechnie wykorzystywane przez administratorów, programistów oraz zespoły DevOps, często również w środowiskach uprzywilejowanych.
W praktyce oznacza to, iż odpowiednio przygotowany plik lub katalog roboczy może uruchomić polecenia systemowe w kontekście aktualnego użytkownika, bez potrzeby manualnego uruchamiania makr czy skryptów. Taki scenariusz znacząco podnosi ryzyko ataków dostarczanych przez archiwa, załączniki lub współdzielone katalogi projektowe.
W skrócie
Badacz Hung Nguyen opisał dwa odrębne wektory prowadzące do wykonania kodu po otwarciu pliku w Vim i GNU Emacs. W przypadku Vim problem został już naprawiony i dotyczy wybranych wersji edytora, natomiast w Emacsie zagrożenie wynika z automatycznej integracji z Git podczas otwierania plików znajdujących się w repozytorium.
- Vim był podatny na łańcuch błędów związanych z modeline i mechanizmami bezpieczeństwa.
- Problem w Vim został załatany w wersji 9.2.0272.
- GNU Emacs może pośrednio uruchamiać złośliwy kod poprzez wywołania Git i kontrolowany przez atakującego plik .git/config.
- Atak może zostać dostarczony w pozornie nieszkodliwym archiwum lub katalogu projektu.
Kontekst / historia
Sprawa zwróciła uwagę branży nie tylko ze względu na potencjalny wpływ podatności, ale także sposób ich odkrycia. Według opublikowanych informacji badacz wykorzystał prosty prompt skierowany do asystenta AI, aby pomóc w analizie kodu oraz opracowaniu wariantów proof-of-concept.
Publiczne ujawnienie problemu nastąpiło pod koniec marca 2026 roku. W przypadku Vim podatność została zgłoszona opiekunom projektu i gwałtownie poprawiona. Opis wskazuje, iż luka dotyczy wersji od 9.1.1391 do wydań wcześniejszych niż 9.2.0272. Dla tego błędu nie przypisano jeszcze identyfikatora CVE.
W GNU Emacs sytuacja pozostaje bardziej złożona. Maintainerzy mieli uznać, iż bezpośrednim źródłem wykonania polecenia jest Git, a nie sam edytor. Z perspektywy użytkownika nie zmienia to jednak faktu, iż wektor uruchamia się podczas standardowego otwierania pliku w Emacsie.
Analiza techniczna
W Vim podatność wynika z połączenia dwóch problemów. Pierwszy dotyczył opcji tabpanel, która akceptowała wyrażenia %{expr} bez zastosowania odpowiednich ograniczeń bezpieczeństwa powiązanych z mechanizmem modeline. Drugi problem polegał na tym, iż choć wyrażenie wykonywano w sandboxie, funkcja autocmd_add() nie przeprowadzała adekwatnej kontroli bezpieczeństwa, umożliwiając obejście izolacji.
W efekcie atakujący mógł przygotować specjalnie spreparowany plik, którego otwarcie w podatnej wersji Vim prowadziło do zarejestrowania zdarzeń i ostatecznie do wykonania komend systemowych. Ze względu na szeroką obecność Vim w systemach Linux oraz jego częste użycie na serwerach, potencjalny wpływ tego błędu jest istotny.
W GNU Emacs wektor ataku nie bazuje na samej treści pliku tekstowego. Kluczową rolę odgrywa automatyczna integracja z systemami kontroli wersji. Funkcja vc-refresh-state jest wywoływana przy otwieraniu pliku, aby ustalić jego stan względem repozytorium. jeżeli plik znajduje się w katalogu zarządzanym przez Git, Emacs może uruchomić polecenia takie jak git ls-files oraz git status.
Git, wykonując te operacje, odczytuje lokalny plik .git/config. o ile konfiguracja zawiera opcję core.fsmonitor wskazującą zewnętrzny program pomocniczy, może dojść do uruchomienia kontrolowanego przez atakującego pliku wykonywalnego. Oznacza to, iż napastnik może przygotować archiwum zawierające zwykły plik tekstowy oraz ukryty katalog .git z minimalną strukturą repozytorium i złośliwą konfiguracją.
Po rozpakowaniu takiej paczki i otwarciu pliku w Emacsie dochodzi do automatycznego wywołania Git, a następnie do uruchomienia payloadu. Co istotne, sam dokument nie musi zawierać podejrzanych znaczników, takich jak lokalne zmienne, formy eval czy inne elementy zwykle kojarzone z ryzykiem wykonania kodu.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją obu scenariuszy jest możliwość wykonania dowolnego kodu z uprawnieniami bieżącego użytkownika. W praktyce może to prowadzić do kradzieży kluczy SSH, tokenów dostępowych, danych z repozytoriów, a także do instalacji trwałego backdoora lub wykorzystania stacji roboczej jako punktu wyjścia do dalszego ruchu bocznego.
Ryzyko rośnie szczególnie w organizacjach, w których narzędzia deweloperskie mają dostęp do środowisk CI/CD, chmury, produkcji lub poufnych sekretów. W takich warunkach kompromitacja jednej sesji edytora może przełożyć się na znacznie szerszy incydent bezpieczeństwa.
- Wysokie zagrożenie dotyczy użytkowników niezałatanych wersji Vim.
- W Emacsie ryzyko pozostaje aktualne tam, gdzie otwierane są niezweryfikowane katalogi z ukrytymi repozytoriami Git.
- Atak może zostać dostarczony przez ZIP, tarball, załącznik lub współdzielony folder projektowy.
- Problem pokazuje, iż podatne bywają nie tylko parsery plików, ale całe łańcuchy automatycznych zachowań narzędzi deweloperskich.
Rekomendacje
Organizacje korzystające z Vim powinny jak najszybciej zweryfikować wykorzystywane wersje edytora i przeprowadzić aktualizację co najmniej do wydania 9.2.0272 lub nowszego. Warto również sprawdzić serwery administracyjne, obrazy kontenerów oraz środowiska deweloperskie, aby wykluczyć obecność podatnych wersji.
W środowiskach używających GNU Emacs konieczne jest wdrożenie działań ograniczających ryzyko, choćby jeżeli poprawka po stronie projektu nie została jeszcze uzgodniona. Szczególnie ważne jest ograniczenie zaufania do zewnętrznych archiwów i katalogów roboczych.
- Nie otwierać plików z nieznanych archiwów i niezweryfikowanych katalogów.
- Skanować rozpakowane paczki pod kątem ukrytych katalogów .git.
- Uruchamiać edytory w środowiskach izolowanych, takich jak kontenery lub sandboxy desktopowe.
- Ograniczyć dostęp stacji deweloperskich do kluczy, tokenów i innych sekretów.
- Monitorować procesy potomne uruchamiane przez edytory i narzędzia SCM.
- Wdrożyć reguły EDR wykrywające nietypowe uruchomienia powłoki, skryptów i binariów z katalogów projektowych.
Dodatkowo warto rozważyć utwardzenie sposobu wywoływania Git, tak aby neutralizować niebezpieczne opcje konfiguracyjne, w tym core.fsmonitor. Cały incydent stanowi kolejny argument za tym, aby edytory, IDE i narzędzia kontroli wersji traktować jako komponenty wysokiego ryzyka wymagające regularnego hardeningu.
Podsumowanie
Luki opisane w Vim i GNU Emacs pokazują, iż choćby otwarcie zwykłego pliku tekstowego nie zawsze jest dziś czynnością bezpieczną. W przypadku Vim problem został już naprawiony, ale wymaga szybkiego wdrożenia aktualizacji. W GNU Emacs wektor związany z integracją z Git pozostaje istotnym ryzykiem operacyjnym, które należy ograniczać przez ostrożność użytkowników, izolację środowiska oraz kontrolę konfiguracji.
Dla zespołów bezpieczeństwa to wyraźny sygnał, iż narzędzia deweloperskie muszą być obejmowane podobną dyscypliną ochronną jak przeglądarki, klienty poczty czy inne krytyczne aplikacje końcowe.
Źródła
- BleepingComputer – Claude AI finds Vim, Emacs RCE bugs that trigger on file open — https://www.bleepingcomputer.com/news/security/claude-ai-finds-vim-emacs-rce-bugs-that-trigger-on-file-open/
- GitHub Security Advisory – Vim tabpanel modeline escape affects Vim > 9.1.1390 && Vim < 9.2.0272 — https://github.com/vim/vim/security/advisories/GHSA-2gmj-rpqf-pxvh
- Calif – MAD Bugs: vim vs emacs vs Claude — https://blog.calif.io/p/mad-bugs-vim-vs-emacs-vs-claude
- GitHub – GNU Emacs: Multiple Remote Code Execution Vectors on File Open — https://github.com/califio/publications/blob/main/MADBugs/vim-vs-emacs-vs-claude/Emacs.md