Co znajdziesz w tym artykule?
- 1 Wprowadzenie do problemu / definicja luki
- 2 W skrócie
- 3 Kontekst / historia / powiązania
- 4 Analiza techniczna / szczegóły luk
- 5 Praktyczne konsekwencje / ryzyko
- 6 Rekomendacje operacyjne / co zrobić teraz
- 7 Różnice / porównania z innymi przypadkami
- 8 Podsumowanie / kluczowe wnioski
- 9 Źródła / bibliografia
Wprowadzenie do problemu / definicja luki
Visual Studio Code i jego ekosystem rozszerzeń to „narzędzia produkcyjne” dla developerów, ale z perspektywy bezpieczeństwa są też uprzywilejowanym agentem na stacji roboczej: mają dostęp do plików w projekcie, często uruchamiają lokalne serwery, renderują podglądy HTML/Markdown, a czasem integrują się z terminalem.
W lutym 2026 r. opisano podatności w czterech popularnych rozszerzeniach VS Code (łącznie 125M+ instalacji), które mogą prowadzić do kradzieży plików lokalnych oraz – w części scenariuszy – do zdalnego wykonania kodu (RCE).
W skrócie
Dotknięte rozszerzenia i problemy:
- Live Server – CVE-2025-65717, CVSS 9.1: kradzież plików przez nadużycie lokalnego serwera (typowo
localhost:5500) po nakłonieniu ofiary do wejścia na złośliwą stronę, gdy rozszerzenie działa. (wg badaczy: wciąż niezałatane) - Markdown Preview Enhanced – CVE-2025-65716, CVSS 8.8: wykonanie JavaScript po otwarciu spreparowanego pliku
.md, co umożliwia m.in. enumerację portów lokalnych i potencjalną eksfiltrację. (wg badaczy: wciąż niezałatane) - Code Runner – CVE-2025-65715, CVSS 7.8: RCE przez wstrzyknięcie/zmianę ustawień (np.
settings.json) z użyciem socjotechniki lub nieautoryzowanej modyfikacji konfiguracji. (wg badaczy: wciąż niezałatane) - Microsoft Live Preview – luka bez CVE: scenariusz „one-click” (web → localhost) pozwalający na enumerację i eksfiltrację wrażliwych plików; poprawione w wersji 0.4.16 (wydanie z 11 września 2025), m.in. przez zmiany związane z poprawnym escapowaniem HTML.
Ważny kontekst: badacze wskazują, że wpływ dotyczy też środowisk opartych o infrastrukturę rozszerzeń VS Code, takich jak Cursor i Windsurf.
Kontekst / historia / powiązania
To nie jest historia o „podejrzanych dodatkach z marketplace’u”, tylko o legalnych, masowo używanych rozszerzeniach, które przez swój model działania tworzą ryzykowne mosty: strona WWW → przeglądarka → localhost → pliki na dysku.
OX Security podkreśla też problem procesowy: zgłoszenia miały startować już w 2025 r., a część maintainerów nie zareagowała przez długi czas, co pokazuje brak egzekwowalnej odpowiedzialności w ekosystemie rozszerzeń.
Analiza techniczna / szczegóły luk
1 Live Server (CVE-2025-65717): „każda strona może zagadać do twojego localhost”
Klucz ataku: Live Server uruchamia lokalny serwer HTTP dla podglądu. Jeśli developer ma go aktywnego w tle, a potem wejdzie na złośliwą stronę, osadzony JavaScript może wykonywać żądania do localhost i „przeczołgać” udostępniane zasoby, a następnie wysłać je na serwer atakującego. Badacze opisują to jako atak wymagający jedynie kliknięcia linku w nieodpowiednim momencie.
Co jest podstępne: to wygląda jak „zwykłe przeglądanie internetu”, a nie klasyczne otwieranie podejrzanego pliku wykonywalnego.
2 Markdown Preview Enhanced (CVE-2025-65716): aktywny JS w podglądzie Markdown
W tym przypadku wektorem jest spreparowany plik .md, którego otwarcie w podglądzie może prowadzić do wykonania JavaScript. To może posłużyć do lokalnej enumeracji portów (co działa jako rekonesans), a następnie do eksfiltracji danych (np. z usług developerskich wystawionych lokalnie).
3 Code Runner (CVE-2025-65715): RCE przez konfigurację i socjotechnikę
Code Runner korzysta z ustawień mapujących komendy uruchomieniowe. Jeśli atakujący nakłoni ofiarę do wklejenia „niewinnego” fragmentu konfiguracji do settings.json (globalnie lub w workspace), może dojść do uruchomienia dowolnej komendy. To klasyczny przykład: „konfiguracja też jest kodem” – i może być równie groźna.
4 Microsoft Live Preview: poprawka „po cichu”
W opisie badaczy podatność w Live Preview miała umożliwiać ataki web-owe na komponenty podglądu i w efekcie dostęp do wrażliwych plików. OX Security wskazuje, że Microsoft poprawił problem w v0.4.16, a w changelogu widać m.in. pozycję sugerującą poprawę związaną z escapowaniem HTML (częsty punkt zapalny dla XSS).
Praktyczne konsekwencje / ryzyko
Na stacji developerskiej „wrażliwe” zwykle nie oznacza tylko kodu:
- klucze API, tokeny, pliki
.env, konfiguracje chmurowe/CI, poświadczenia do baz, - pliki SSH, cache credentiali, pliki konfiguracyjne narzędzi,
- dostęp do zasobów firmowych (repozytoria, artefakty, środowiska testowe).
W najgorszym wariancie: eksfiltracja sekretów → przejęcie kont/chmury → ruch lateralny. OX Security wprost podkreśla, że jedna podatność w jednym dodatku może być wystarczająca do kompromitacji organizacji.
Rekomendacje operacyjne / co zrobić teraz
Natychmiast (dla zespołów i pojedynczych devów)
- Zrób inwentaryzację rozszerzeń (również w Cursor/Windsurf, jeśli używane) i usuń/wyłącz wszystko, co nie jest niezbędne.
- Live Preview: zaktualizuj do >= 0.4.16.
- Live Server / Markdown Preview Enhanced / Code Runner: jeśli są niezbędne – rozważ tymczasowe wyłączenie lub używanie tylko w izolacji (np. osobny profil systemu/VM/kontener), bo wg badaczy część problemów pozostawała niezałatana.
- Higiena przeglądarki: nie otwieraj nieznanych linków/stron, gdy działają lokalne serwery podglądu (Live Server/preview).
- Polityka dla
settings.json: zakaz wklejania snippetów konfiguracyjnych z maili/DM/issue bez review; monitoruj zmiany w ustawieniach (np. Git/backup plików konfiguracyjnych).
Krótkoterminowo (dla security/IT)
- Kontrola egress (wyjścia na internet) dla procesów narzędzi developerskich, gdzie to możliwe.
- Segmentacja: stacje developerskie jako strefa o podwyższonym ryzyku (inne zasady dostępu do produkcji).
- Zasada minimalnych uprawnień dla tokenów używanych lokalnie (krótkie TTL, scoped tokens, rotacja).
Różnice / porównania z innymi przypadkami
W odróżnieniu od kampanii z jawnie złośliwymi rozszerzeniami (które czasem da się wyłapać reputacją wydawcy czy anomaliami w kodzie), tutaj mówimy o normalnych, popularnych narzędziach, którym developerzy ufają „z definicji”. To przesuwa ciężar obrony na:
- model uprawnień i sandbox (IDE + webview),
- proces utrzymania i reakcji maintainerów,
- praktyki operacyjne w zespołach (co uruchamiamy lokalnie i kiedy).
Podsumowanie / kluczowe wnioski
- Ekosystem rozszerzeń IDE to krytyczny element łańcucha dostaw: działa blisko sekretów i zasobów firmowych.
- Opisane podatności pokazują trzy bardzo „praktyczne” wektory: web → localhost, podgląd treści (Markdown/HTML) oraz konfiguracja jako wektor RCE.
- Najrozsądniejsza strategia tu i teraz: ograniczyć liczbę rozszerzeń, aktualizować, izolować ryzykowne komponenty i traktować konfiguracje jak kod.
Źródła / bibliografia
- The Hacker News – opis 4 rozszerzeń, CVE i scenariuszy ataku (18.02.2026). (The Hacker News)
- OX Security – raport i rekomendacje dot. „blind spot” w rozszerzeniach IDE (17.02.2026). (OX Security)
- CSO Online – kontekst (responsible disclosure, wpływ na Cursor/Windsurf, status poprawek) (18.02.2026). (CSO Online)
- GitHub:
microsoft/vscode-livepreview– release v0.4.16 (11.09.2025). (GitHub) - ITPro – streszczenie ryzyk i zaleceń ochrony dla developerów (18.02.2026). (IT Pro)