Wprowadzenie do problemu / definicja
Open VSX to otwarty rejestr rozszerzeń dla edytorów i środowisk opartych na Visual Studio Code. Ujawniona w marcu 2026 roku podatność osłabiała obowiązkowy mechanizm kontroli bezpieczeństwa uruchamiany przed publikacją rozszerzeń, co w praktyce mogło dopuścić złośliwy pakiet do publicznego rejestru mimo istnienia procesu skanowania.
Problem dotyczył logiki odpowiedzialnej za interpretację wyniku skanera. System nie rozróżniał sytuacji, w której nie było skanerów do uruchomienia, od przypadku, gdy skanery powinny zadziałać, ale ich zadania nie zostały wykonane z powodu błędu operacyjnego.
W skrócie
Podatność w Open VSX umożliwiała obejście przedpublikacyjnych kontroli bezpieczeństwa przez złośliwe rozszerzenia. Źródłem problemu był błąd typu fail-open, przez który awaria mechanizmu skanującego mogła zostać potraktowana jak poprawny stan procesu publikacji.
- luka dotyczyła pipeline’u skanującego rozszerzenia przed publikacją,
- atak mógł wykorzystywać przeciążenie procesu publikacji plikami .vsix,
- w efekcie niektóre pakiety mogły zostać oznaczone jako zweryfikowane mimo braku skutecznego skanu,
- problem został zaadresowany w wersji Open VSX 0.32.0.
Kontekst / historia
Eclipse Foundation, odpowiedzialna za utrzymanie Open VSX, wdrożyła w lutym 2026 roku obowiązkowe kontrole bezpieczeństwa przed publikacją nowych rozszerzeń. Była to odpowiedź na rosnące znaczenie zagrożeń supply chain oraz ryzyko związane z dystrybucją szkodliwych dodatków w ekosystemie narzędzi deweloperskich.
Znaczenie Open VSX wykracza poza pojedynczy projekt. Rejestr pełni rolę marketplace’u dla wielu środowisk i forków VS Code używanych przez programistów, co oznacza, iż każda luka w jego mechanizmach walidacji może przełożyć się na realne ryzyko dla stacji roboczych, repozytoriów kodu i procesów CI/CD.
Analiza techniczna
Rdzeń problemu stanowił błąd projektowy polegający na użyciu jednej wartości logicznej do reprezentowania dwóch różnych stanów. Ten sam wynik oznaczał zarówno brak skanerów do uruchomienia, jak i niepowodzenie uruchomienia skanowania. W rezultacie warstwa wyższego poziomu traciła informację o awarii i mogła błędnie uznać publikację za bezpieczną.
Taki model prowadził do klasycznego scenariusza fail-open. o ile zadania skanera nie mogły zostać skutecznie zakolejkowane lub uruchomione, system nie blokował publikacji, ale traktował ten stan jak brak potrzeby skanowania. To szczególnie niebezpieczny wzorzec w mechanizmach bezpieczeństwa, które powinny działać zgodnie z zasadą fail-closed.
Według ujawnionych informacji możliwy scenariusz nadużycia obejmował równoległe przesyłanie wielu pakietów .vsix do endpointu publikacji. Taki ruch mógł przeciążyć zasoby backendowe, w tym połączenia do bazy danych, przez co zadania skanujące nie były poprawnie umieszczane w kolejce. Dodatkowo podobna słabość dotyczyła mechanizmu odzyskiwania i ponawiania nieudanych skanów, co zwiększało ryzyko trwałego pominięcia kontroli.
Z perspektywy architektury bezpieczeństwa był to przykład niebezpiecznego zlania stanu biznesowego ze stanem błędu technicznego. W systemach odpowiedzialnych za dopuszczanie artefaktów do dystrybucji każdy stan niejednoznaczny powinien kończyć się blokadą procesu i wyraźnym alarmem operacyjnym.
Konsekwencje / ryzyko
Najważniejszą konsekwencją było obejście zabezpieczenia zaprojektowanego po to, aby zatrzymywać złośliwe rozszerzenia przed ich publiczną publikacją. Co istotne, atakujący nie potrzebował do tego uprzywilejowanego dostępu administracyjnego — wystarczało standardowe konto wydawcy.
Ryzyko wynikające z takiej luki obejmuje zarówno kompromitację pojedynczych stacji roboczych, jak i skutki dla całego łańcucha dostaw oprogramowania.
- publikacja rozszerzenia zawierającego malware lub funkcje kradzieży danych,
- przejęcie tokenów, sekretów i danych projektowych z maszyn deweloperskich,
- nadużycie dostępu do kodu źródłowego i plików konfiguracyjnych,
- rozprzestrzenienie zagrożenia na środowiska build, release i CI/CD,
- spadek zaufania do rejestru rozszerzeń jako elementu ekosystemu programistycznego.
Złośliwe rozszerzenie IDE może działać jak implant w kontekście użytkownika, z szerokim dostępem do plików, procesów oraz połączeń sieciowych. W praktyce podnosi to wagę incydentu do poziomu zagrożenia supply chain o wysokim znaczeniu operacyjnym.
Rekomendacje
Organizacje korzystające z Open VSX oraz podobnych marketplace’ów rozszerzeń powinny potraktować ten incydent jako impuls do przeglądu własnych zabezpieczeń. Szczególnie ważne jest sprawdzenie, czy wykorzystywane komponenty i zależne narzędzia działają już na poprawionych wersjach.
- stosować zasadę fail-closed w pipeline’ach bezpieczeństwa,
- blokować publikację lub instalację rozszerzenia przy każdym błędzie skanera,
- monitorować nowe publikacje i korelować je z telemetrią instalacji,
- ograniczać możliwość instalowania nieautoryzowanych rozszerzeń politykami organizacyjnymi,
- utrzymywać listę dozwolonych dodatków i regularnie przeglądać ich uprawnienia,
- skanować pliki .vsix lokalnie lub we własnym pipeline’ie przed dopuszczeniem do użycia,
- minimalizować ekspozycję sekretów i tokenów w środowisku IDE,
- wdrożyć detekcję nietypowej aktywności rozszerzeń, takiej jak uruchamianie procesów potomnych czy połączenia sieciowe.
Dla zespołów rozwijających podobne platformy najważniejsze są również dobre praktyki projektowe: jawne modelowanie stanów błędów, testy odpornościowe na przeciążenie, bezpieczne mechanizmy kolejkowania oraz niezależne monitorowanie skuteczności skanów. Równie istotne jest alertowanie przy każdej rozbieżności między liczbą opublikowanych pakietów a liczbą pakietów faktycznie przeskanowanych.
Podsumowanie
Luka w Open VSX pokazuje, iż choćby poprawnie zaplanowana kontrola bezpieczeństwa może zostać osłabiona przez pozornie niewielki błąd logiki aplikacyjnej. W tym przypadku awaria skanera mogła zostać potraktowana jak brak konieczności skanowania, co stworzyło realną ścieżkę obejścia zabezpieczeń przed publikacją.
Dla obrońców najważniejszy wniosek jest jednoznaczny: mechanizmy bezpieczeństwa w łańcuchu dostaw systemu muszą być projektowane tak, aby każdy błąd kończył się zatrzymaniem procesu, a nie jego automatycznym przepuszczeniem. W środowiskach deweloperskich skutki takiego przeoczenia mogą być kosztowne zarówno operacyjnie, jak i reputacyjnie.
Źródła
- The Hacker News — https://thehackernews.com/2026/03/open-vsx-bug-let-malicious-vs-code.html
- GitHub – eclipse/openvsx — https://github.com/eclipse/openvsx
- Eclipse mailing list: Short-Term Security Improvements for Open VSX — https://www.eclipse.org/lists/openvsx-dev/msg00025.html
- Statement of Work: Short-Term Security — https://www.eclipse.org/lists/openvsx/pdfn2OhDfOTiF.pdf