Większość artykułów o bezpieczeństwie w tym newsletterze dotyczy rzeczy, które przydarzają się bezpośrednio tobie: wiadomości phishingowej, wycieku hasła, fałszywej strony zakupowej. Ten jest inny. Opisane poniżej incydenty przydarzyły się programistom — ludziom, którzy piszą aplikacje i tworzą usługi używane przez ciebie każdego dnia. Powód, dla którego znalazły się tutaj, jest jednak prosty: jeśli ktoś zatruje narzędzia wykorzystywane do tworzenia oprogramowania, trucizna nie pozostanie u twórcy. Trafi do produktu.

Niedawno wydarzyły się dwie rzeczy, które dobrze to ilustrują. Żadna nie trafiła na pierwsze strony gazet tak jak poważny wyciek, ponieważ żadna nie była konkretnie wyciekiem dotyczącym ciebie. Oba ataki wymierzone były w proces, w ramach którego powstaje oprogramowanie, które ostatecznie instalujesz, otwierasz lub do którego się logujesz.

Podrobione rozszerzenia podszywające się pod zaufane marki

Open VSX to publiczny marketplace rozszerzeń do edytorów kodu — niewielkich dodatków instalowanych przez programistów w celu uzyskania autouzupełniania, lintingu i integracji z narzędziami używanymi na co dzień (Visual Studio Code i kilka jego otwartoźródłowych odpowiedników korzysta z tego repozytorium). Między 26 lipca a 1 sierpnia 2026 roku badacze bezpieczeństwa z Manifold Security znaleźli w rejestrze 77 podrobionych rozszerzeń. Każde kopiowało nazwę i przestrzeń nazw prawdziwego, zaufanego rozszerzenia, ale zostało opublikowane z konta, do którego nie należał oryginał — to klasyczna próba podszycia się, nazywana czasem zajmowaniem przestrzeni nazw.

Zajęte nazwy nie były przypadkowe. Wykorzystywały tożsamości AMD, LEGO Education, Hyperledger, Azure, projektów open source Salesforce, amerykańskiej agencji federalnej oraz — w pewnym mrocznym sensie ironii — samego marketplace'u rozszerzeń. Każdy z 77 pakietów łączył się z jednym adresem domenowym, zarejestrowanym zaledwie 11 dni przed pojawieniem się pierwszego fałszywego pakietu. Taki wzorzec sugeruje skoordynowaną, celowo przygotowaną kampanię, a nie przypadkowe kopiowanie.

Większość fałszywych rozszerzeń robiła coś nieskomplikowanego: po cichu wysyłała nazwę hosta na serwer atakującego, co samo w sobie mogło być jedynie sprawdzeniem, kto zainstalował przynętę. Badacze odkryli jednak, że mniej więcej jedna czwarta z 77 — 19 pakietów — szła dalej. Kilka sekund po aktywacji zbierały nazwę hosta, nazwę użytkownika systemu operacyjnego, szczegóły edytora oraz identyfikator maszyny. Następnie odczytywały projekt otwarty przez programistę: zdalne repozytorium git (ujawniające organizację i hosta repozytorium), domenę adresu e-mail użytego przy commicie, bieżącą gałąź oraz najnowszy commit. Pobierały także wartości związane z ciągłą integracją — dane uwierzytelniające i konfigurację, dzięki którym systemy automatyczne mogą budować i wdrażać kod bez każdorazowego wpisywania hasła przez człowieka.

Żadne z tych danych nie przydaje się do opróżnienia czyjegoś konta bankowego. Przydają się do czegoś innego: ustalenia, dla jakich firm pracuje programista, jak wygląda ich wewnętrzna infrastruktura oraz jak uzyskać w niej przyczółek.

Błąd z oceną 9,8 na 10 w maszynie, która buduje oprogramowanie

Drugi incydent dotyczy TeamCity, platformy ciągłej integracji i ciągłego dostarczania (CI/CD) firmy JetBrains. Jeśli edytor kodu jest miejscem, w którym programiści piszą oprogramowanie, platforma CI/CD jest automatyczną halą fabryczną, gdzie ten kod jest kompilowany, testowany i wypuszczany na produkcję — często bez jakiegokolwiek kliknięcia „wdroż” przez człowieka. TeamCity stanowi centralny element tej infrastruktury w wielu firmach.

W wersjach TeamCity instalowanych lokalnie ujawniono lukę śledzoną jako CVE-2026-63077, z oceną dotkliwości 9,8 na 10. Jest to błąd deserializacji — klasa błędów, w której program na tyle ufa danym wejściowym, że bez uprzedniego sprawdzenia, czym właściwie są, zamienia je bezpośrednio w wykonywany kod. W praktyce pozwalało to atakującemu wysłać żądanie do podatnego serwera TeamCity bez konieczności logowania i uruchamiać dowolne polecenia z takimi samymi uprawnieniami jak sama usługa TeamCity. JetBrains udostępnił poprawki (wersje 2025.11.7 i 2026.1.3, a także wtyczkę z poprawką dla starszych instalacji 2017.1+), ale amerykańska Agencja ds. Cyberbezpieczeństwa i Bezpieczeństwa Infrastruktury (CISA) ostrzegła od tego czasu, że atakujący aktywnie wykorzystują niezałatane systemy.

Kto kontroluje serwer budowania firmy, ten kontroluje to, co firma wypuszcza. To nie jest hipotetyczna sytuacja — na tym właśnie polega działanie tego narzędzia.

Ten sam schemat, dwoje różnych drzwi

To niezwiązane ze sobą incydenty opisane przez różnych badaczy, ale mają wspólną strukturę. Żaden nie atakuje gotowego produktu. Oba uderzają o krok wcześniej — w edytor, w którym programista pisze kod, albo w serwer, który zamienia ten kod w wydane oprogramowanie. To cecha definiująca atak na łańcuch dostaw oprogramowania: zamiast włamywać się do jednego celu, przejmujesz coś znajdującego się wyżej w łańcuchu, od czego zależy wiele celów, i pozwalasz, by ich własny zaufany proces przeniósł twój dostęp dalej.

Warto uczciwie powiedzieć, czego jeszcze nie wiemy. Żaden z raportów, które pojawiły się w tym tygodniu, nie ujawnił potwierdzonego przypadku przejęcia aplikacji lub użytkownika końcowego jako bezpośredniego skutku — kampania z rozszerzeniami wygląda na rozpoznanie i gromadzenie danych dostępowych, a wykorzystanie TeamCity opisano jako aktywne, ale bez wskazania konkretnych ofiar. To normalne; przejęcia w łańcuchu dostaw często są wykrywane w punkcie wejścia na długo przed prześledzeniem (albo zamiast prześledzenia) ostatecznych skutków.

Dlaczego to twój problem, a nie tylko ich

Prawdopodobnie nigdy nie zainstalujesz rozszerzenia do kodowania ani nie uruchomisz serwera CI/CD. Korzystasz jednak z efektów pracy setek takich narzędzi: aplikacji bankowej, menedżera haseł, szkolnego portalu swojego dziecka, przeglądarki, w której to czytasz. Wszystko to przeszło przez edytor jakiegoś programisty i potok budowania jakiejś firmy, zanim trafiło na twój telefon. Jeśli któreś z tych ogniw zostanie po cichu przejęte, złośliwa zmiana może zostać dostarczona wraz ze zwykłą, rutynową aktualizacją oprogramowania — taką, którą instalujesz, bo powiedziano ci, że aktualizowanie jest bezpieczne.

Dlatego porady zawarte w analizie przyczyn wycieku czasem brzmią dziwnie dla osób nietechnicznych: firma mówi, że jej systemy zostały przejęte za pośrednictwem serwera budowania, skradzionych danych uwierzytelniających programisty albo złośliwej zależności, a to może brzmieć abstrakcyjnie w porównaniu z „ktoś odgadł moje hasło”. Nie jest abstrakcyjne. To ten sam skutek — naruszenie twoich danych lub integralności aplikacji — osiągnięty przez drzwi, o których istnieniu nie miałeś pojęcia.

Co naprawdę pomaga

Nie możesz kontrolować potoku CI/CD swojego banku i nie powinieneś musieć tego robić. Kilka nawyków rzeczywiście zmniejsza jednak narażenie na ten rodzaj ryzyka:

Włącz automatyczne aktualizacje, ale nie traktuj aktualizacji jako automatycznie godnych zaufania. To dzięki poprawkom takie naprawy jak ta dotycząca TeamCity trafiają do używanego przez ciebie oprogramowania — bycie na bieżąco zamyka luki, które atakujący aktywnie sprawdzają. Jednocześnie aktualizacja jest tylko tak dobra, jak potok, który ją stworzył, a to właśnie on jest tutaj celem; nie istnieje doskonała indywidualna ochrona przed naprawdę zatrutym wydaniem pochodzącym z wcześniejszego ogniwa, dlatego jest to zasadniczo problem po stronie dostawcy, a nie twój problem.

Jeśli pracujesz z programistami lub nimi zarządzasz, są dwie konkretne i możliwe do sprawdzenia rzeczy: upewnij się, że każde rozszerzenie do edytora kodu zostało zainstalowane z rzeczywistego, zweryfikowanego konta wydawcy, a nie tylko z konta o pasującej nazwie (Open VSX i podobne marketplace'y pokazują tożsamość wydawcy — sprawdź ją, nie ufaj wyłącznie ikonie i tytułowi); a jeśli twoja organizacja korzysta z lokalnie instalowanego TeamCity, potwierdź jeszcze dziś, że działa w wersji 2025.11.7 lub 2026.1.3 albo że zastosowano wtyczkę z poprawką — nie czekaj do kolejnego okna serwisowego. Ostrzeżenie CISA oznacza, że luka jest aktywnie wykorzystywana, a nie że jest to zagrożenie teoretyczne.

Dla wszystkich pozostałych przydatna zmiana polega po prostu na świadomości: kiedy czytasz o wycieku w firmie, którego źródłem był „przejęty programistyczny zestaw narzędzi” albo „system budowania”, nie jest to niszowy techniczny przypis. To ta sama kategoria zdarzeń co wycieki haseł i oszustwa phishingowe, o których ten newsletter pisze częściej — tyle że zaczęła się o jedną warstwę wcześniej, zanim produkt w ogóle do ciebie dotarł.