Archiwa: DevSecOps - Strona 6 z 18

RubyGems wstrzymuje nowe rejestracje po fali złośliwych pakietów

Wprowadzenie do problemu / definicja

RubyGems, kluczowy rejestr pakietów dla ekosystemu Ruby, tymczasowo wyłączył możliwość zakładania nowych kont po wykryciu szeroko zakrojonej kampanii złośliwych publikacji. Zdarzenie wpisuje się w rosnący trend ataków na łańcuch dostaw oprogramowania, w których publiczne repozytoria stają się kanałem dystrybucji malware, narzędzi do kradzieży sekretów oraz kodu wspierającego dalszą kompromitację środowisk deweloperskich i CI/CD.

W skrócie

Operatorzy RubyGems zdecydowali się na czasowe zablokowanie nowych rejestracji po wykryciu setek złośliwych pakietów opublikowanych w serwisie. Skala incydentu wskazuje na zautomatyzowaną kampanię, która mogła być ukierunkowana zarówno na ofensywne działania wobec dostawców bezpieczeństwa, jak i na przejęcie poświadczeń oraz infekowanie środowisk budowania oprogramowania.

zidentyfikowano masową publikację złośliwych pakietów,
wstrzymano nowe rejestracje kont jako działanie ograniczające nadużycia,
incydent należy traktować jako poważne zagrożenie typu supply chain,
ryzyko obejmuje deweloperów, runnerów CI/CD i infrastrukturę wdrożeniową.

Kontekst / historia

Ataki na publiczne menedżery pakietów od lat stanowią jedno z najistotniejszych zagrożeń dla nowoczesnego procesu wytwarzania oprogramowania. W ostatnich kwartałach widoczny jest jednak wyraźny wzrost ich skali, tempa i poziomu automatyzacji. Cyberprzestępcy coraz częściej wybierają metody o niskim koszcie wejścia i wysokiej skuteczności: publikowanie pakietów o mylących nazwach, przejmowanie kont maintainerów, aktualizacje legalnych bibliotek z ukrytym ładunkiem czy kampanie nastawione na eksfiltrację sekretów z maszyn deweloperskich.

RubyGems nie jest odosobnionym przypadkiem. Rejestry takie jak npm, PyPI czy RubyGems pozostają atrakcyjnym celem, ponieważ pozwalają atakującym osiągnąć dużą skalę działania przy relatywnie niewielkich nakładach. Dodatkowym problemem jest wysoki poziom automatyzacji współczesnych pipeline’ów, gdzie zależności są pobierane i uruchamiane w ramach buildów, testów i wdrożeń bez bezpośredniej interwencji człowieka.

Analiza techniczna

Wstępne informacje wskazują, że kampania polegała na hurtowym przesyłaniu setek złośliwych pakietów do rejestru RubyGems. Tego typu operacje mogą przyjmować kilka wariantów technicznych, ale ich cel pozostaje podobny: doprowadzić do wykonania nieautoryzowanego kodu w środowisku ofiary.

Pierwszy scenariusz obejmuje publikację nowych bibliotek zawierających kod uruchamiany podczas instalacji lub pierwszego użycia. W praktyce może to oznaczać wykonywanie poleceń systemowych, pobieranie kolejnych etapów malware, enumerację zmiennych środowiskowych oraz próbę wykradzenia tokenów, kluczy API i danych chmurowych.

Drugi wariant dotyczy pakietów podszywających się pod legalne komponenty. Mechanizmy takie jak typosquatting i brand impersonation wykorzystują literówki, nieuważne kopiowanie nazw oraz niewystarczającą kontrolę zależności. W środowiskach, gdzie walidacja nowych bibliotek jest ograniczona, pojedyncza pomyłka może uruchomić złośliwy kod z uprawnieniami procesu budowania.

Trzeci model operacyjny zakłada selekcję ofiar. Zamiast natychmiastowej detonacji payloadu, pakiet może najpierw sprawdzać nazwę hosta, obecność określonych narzędzi, środowisko chmurowe, tokeny repozytoryjne lub konfigurację CI. Dzięki temu napastnicy ograniczają wykrywalność i kierują właściwe działania tylko do wartościowych celów.

Samo czasowe wyłączenie nowych rejestracji sugeruje również, że mechanizm nadużycia mógł opierać się na automatycznym tworzeniu kont i masowym publikowaniu artefaktów. To typowy wzorzec dla zautomatyzowanych kampanii spamowych i supply chain, których celem jest osiągnięcie jak największej skali przed reakcją moderatorów lub systemów detekcyjnych.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem takiego incydentu jest możliwość kompromitacji łańcucha dostaw oprogramowania. Jeśli złośliwy pakiet trafi do pipeline’u, zagrożone stają się nie tylko stacje robocze programistów, ale również serwery budujące artefakty, środowiska testowe oraz infrastruktura produkcyjna.

Szczególnie niebezpieczne są runner-y CI/CD, które często mają dostęp do najbardziej wrażliwych sekretów organizacji. Mogą to być tokeny publikacyjne, dane dostępu do chmury, poświadczenia do rejestrów kontenerów, klucze wdrożeniowe czy sekrety potrzebne do podpisywania wydań. Utrata takich danych otwiera drogę do dalszej eskalacji działań napastnika.

Drugim istotnym ryzykiem jest utrata integralności procesu wytwórczego. Po uzyskaniu dostępu do kont maintainerów lub sekretów publikacyjnych atakujący może dodać backdoor do legalnego oprogramowania i rozprzestrzenić go jako zaufaną aktualizację. To scenariusz szczególnie groźny, ponieważ złośliwy kod trafia do odbiorców w ramach standardowych procesów aktualizacyjnych.

Nie można też pomijać aspektu monetyzacji. Współczesne kampanie supply chain często łączą kradzież poświadczeń z późniejszym wymuszeniem, sprzedażą dostępu lub współpracą z grupami ransomware. Nawet pojedynczy zainfekowany pakiet może więc stać się początkiem rozległego incydentu obejmującego wiele systemów i zespołów.

Rekomendacje

Organizacje korzystające z RubyGems powinny potraktować zdarzenie jako sygnał do natychmiastowego przeglądu zależności oraz procesów bezpieczeństwa wokół buildów. W pierwszej kolejności warto przeanalizować pakiety dodane lub zaktualizowane bezpośrednio przed ujawnieniem incydentu oraz wszystkie artefakty wykorzystane w automatycznych pipeline’ach.

wstrzymać lub ograniczyć automatyczne aktualizacje zależności do czasu zakończenia analizy,
przeprowadzić audyt manifestów i plików lock,
zweryfikować pochodzenie i integralność pobranych pakietów,
przeprowadzić rotację tokenów, kluczy API i sekretów dostępnych dla CI/CD,
przejrzeć logi buildów pod kątem nietypowych połączeń sieciowych i uruchamiania poleceń systemowych,
ograniczyć uprawnienia runnerów oraz kont technicznych zgodnie z zasadą najmniejszych uprawnień,
izolować środowiska budowania od zasobów o wysokiej wartości,
testować nowe pakiety w środowiskach sandbox przed dopuszczeniem ich do produkcji.

Długoterminowo niezbędne jest przyjęcie bardziej defensywnego modelu zarządzania open source. Obejmuje on skanowanie zależności pod kątem malware, stosowanie list dozwolonych bibliotek, podpisywanie artefaktów, hermetyzację środowisk build oraz wdrożenie narzędzi wykrywających anomalie w łańcuchu dostaw. W organizacjach o podwyższonym profilu ryzyka warto także rozważyć korzystanie z lokalnych mirrorów i wewnętrznych repozytoriów pośredniczących.

Podsumowanie

Czasowe wstrzymanie nowych rejestracji w RubyGems to wyraźny sygnał, że operator platformy zmaga się z incydentem o dużej skali i wysokim potencjale wpływu na użytkowników. Nawet jeśli pełne szczegóły kampanii nie zostały jeszcze ujawnione, sam fakt pojawienia się setek złośliwych pakietów pokazuje, jak podatny na nadużycia pozostaje współczesny łańcuch dostaw oprogramowania.

Dla zespołów bezpieczeństwa, DevOps i DevSecOps jest to kolejne przypomnienie, że menedżery pakietów należy traktować jako krytyczny element powierzchni ataku. Stały monitoring, kontrola zaufania, ograniczanie uprawnień i szybka rotacja sekretów po każdym podejrzeniu kompromitacji powinny dziś stanowić standard operacyjny.

Źródła

TeamPCP kompromituje wtyczkę Checkmarx AST dla Jenkins. Nowy incydent uderza w łańcuch dostaw oprogramowania

Wprowadzenie do problemu / definicja

Ataki na łańcuch dostaw oprogramowania pozostają jednym z najpoważniejszych zagrożeń dla środowisk DevSecOps. Ich istota polega na przejęciu zaufanego komponentu, takiego jak wtyczka CI/CD, pakiet, obraz kontenera lub workflow automatyzacji, a następnie wykorzystaniu go do dystrybucji złośliwych zmian przez legalny kanał aktualizacji. Najnowszy incydent dotyczący Checkmarx i wtyczki AST dla Jenkins wpisuje się dokładnie w ten scenariusz.

W tym przypadku problem dotyczy komponentu używanego w procesach skanowania bezpieczeństwa aplikacji. To szczególnie wrażliwy obszar, ponieważ wtyczki działające w pipeline’ach mają często dostęp do kodu źródłowego, sekretów, tokenów API oraz mechanizmów publikacji artefaktów.

W skrócie

Zmodyfikowana wersja wtyczki Checkmarx Jenkins AST została opublikowana w Jenkins Marketplace. Producent potwierdził incydent i wskazał, że organizacje powinny korzystać z wersji 2.0.13-829.vc72453fa_1c16 z 17 grudnia 2025 roku lub wcześniejszej, a następnie udostępniono nowsze wydanie 2.0.13-848.v76e89de8a_053.

Incydent został powiązany z aktywnością grupy TeamPCP.
Doszło do publikacji nieautoryzowanego wydania w zaufanym kanale dystrybucji.
Zagrożone mogły być sekrety, kod źródłowy oraz integralność procesów CI/CD.
Zdarzenie wpisuje się w szerszą serię naruszeń dotyczących ekosystemu Checkmarx.

Kontekst / historia

To nie jest odosobnione zdarzenie. TeamPCP była wcześniej łączona z naruszeniami obejmującymi obraz Docker KICS, rozszerzenia do Visual Studio Code oraz workflow GitHub Actions. Wspólnym mianownikiem tych incydentów było uderzenie w zaufane komponenty wykorzystywane przez deweloperów i zespoły bezpieczeństwa.

Wtyczka Checkmarx AST Scanner dla Jenkins służy do integracji skanowania bezpieczeństwa aplikacji z pipeline’ami budowania. Jej kompromitacja może oznaczać nie tylko wyciek danych, ale również wpływ na sam proces oceny bezpieczeństwa kodu. To sprawia, że skutki incydentu mogą wykraczać daleko poza pojedynczy serwer Jenkins.

Niepokojący jest również fakt, że kolejne zdarzenie pojawiło się po wcześniejszych problemach bezpieczeństwa związanych z zasobami Checkmarx. Z perspektywy operacyjnej może to sugerować niepełną remediację, utrzymanie dostępu przez napastników albo niewystarczającą rotację poświadczeń po poprzednich incydentach.

Analiza techniczna

Z dostępnych informacji wynika, że atakujący uzyskali nieautoryzowany dostęp do repozytorium lub procesu wydawniczego powiązanego z wtyczką. W rezultacie w oficjalnym kanale dystrybucji pojawiło się zmodyfikowane wydanie pluginu. To kluczowy element tego incydentu, ponieważ użytkownicy nie musieli pobierać pliku z podejrzanego źródła — złośliwa wersja była rozpowszechniana przez legalny kanał.

Wtyczka AST Scanner działa jako pomost między Jenkins a platformą bezpieczeństwa aplikacji Checkmarx. Taki komponent może przetwarzać archiwa kodu źródłowego, obsługiwać wyniki skanowania, korzystać z danych uwierzytelniających i wykonywać operacje w kontekście procesu CI/CD. W praktyce oznacza to szerokie możliwości nadużyć po stronie napastnika.

wyciek tokenów, sekretów i poświadczeń przechowywanych w Jenkins,
kopiowanie lub eksfiltrację kodu źródłowego z pipeline’ów,
manipulację wynikami skanowania bezpieczeństwa,
uruchamianie dodatkowego kodu na agentach build,
utrzymywanie trwałości poprzez dalsze modyfikacje procesu automatyzacji.

Szczególnie istotny jest komunikat wskazujący na publikację „rogue release published outside the official release pipeline”. Taki zapis sugeruje, że problem nie ograniczał się do samej bazy kodu, lecz mógł dotyczyć poświadczeń wydawniczych, tokenów maintainerów, sekretów używanych przez workflow automatyzujące release albo braku odpowiedniej separacji między środowiskiem developerskim a publikacyjnym.

Z technicznego punktu widzenia najgroźniejsze jest to, że złośliwa wersja mogła wyglądać jak standardowa aktualizacja. W organizacjach, które ufają automatycznym aktualizacjom i nie prowadzą dodatkowej walidacji krytycznych zależności, takie wydanie może zostać wdrożone szybko i bez wzbudzania podejrzeń.

Konsekwencje / ryzyko

Ryzyko związane z kompromitacją wtyczki Jenkins należy oceniać jako wysokie. Jenkins w wielu organizacjach posiada szerokie uprawnienia do repozytoriów kodu, rejestrów artefaktów, środowisk chmurowych, narzędzi bezpieczeństwa oraz systemów wdrożeniowych. Naruszenie jednego elementu tego ekosystemu może więc doprowadzić do efektu domina.

kradzież sekretów deweloperskich i poświadczeń usługowych,
wyciek własności intelektualnej poprzez dostęp do kodu źródłowego,
wstrzyknięcie złośliwych zmian do budowanych artefaktów,
obniżenie wiarygodności wyników skanowania bezpieczeństwa,
ryzyko wtórnych naruszeń u klientów i partnerów korzystających z tych artefaktów.

Najbardziej narażone pozostają organizacje, które automatycznie aktualizują wtyczki lub nie stosują ścisłej kontroli integralności komponentów używanych przez Jenkins. W takich środowiskach złośliwe wydanie może zostać rozprowadzone na dużą skalę, zanim zespół bezpieczeństwa zauważy anomalię.

Długofalowo tego typu incydenty osłabiają także zaufanie do narzędzi AppSec i DevSecOps. Jeżeli komponent bezpieczeństwa sam staje się wektorem ataku, organizacje muszą ponownie ocenić ryzyko wynikające z używania zewnętrznych integracji w krytycznych procesach wytwarzania oprogramowania.

Rekomendacje

Organizacje korzystające z Checkmarx AST Scanner w Jenkins powinny w pierwszej kolejności ustalić, jaka wersja wtyczki była zainstalowana oraz kiedy doszło do jej aktualizacji. Następnie należy porównać historię zmian z oficjalnymi komunikatami producenta i przeanalizować logi pod kątem nietypowych zdarzeń związanych z instalacją, wykonaniem i konfiguracją pluginu.

zweryfikować wersję wtyczki i odizolować systemy z podejrzanym wydaniem,
przeprowadzić pełną rotację sekretów dostępnych z poziomu Jenkins,
sprawdzić logi pipeline’ów, agentów build i hostów Jenkins,
zweryfikować integralność wygenerowanych artefaktów, obrazów i paczek,
przeanalizować workflow automatyzacji oraz konfiguracje pluginów zależnych.

W warstwie prewencyjnej warto ograniczyć automatyczne aktualizacje krytycznych wtyczek bez etapu akceptacji, wymusić wieloskładnikowe uwierzytelnianie dla maintainerów i kont publikacyjnych, stosować krótkotrwałe tokeny oraz regularną rotację sekretów. Równie istotna jest separacja ról między tworzeniem kodu, utrzymaniem repozytorium i publikacją release’ów.

Dodatkową warstwę ochrony powinny zapewnić mechanizmy walidacji pochodzenia komponentów, podpisywania artefaktów, lista dozwolonych wersji oraz monitoring anomalii w procesach CI/CD. Każda kompromitacja komponentu używanego w pipeline’ach powinna być traktowana jak potencjalne pełne naruszenie środowiska deweloperskiego.

Podsumowanie

Kompromitacja wtyczki Checkmarx AST dla Jenkins to kolejny wyraźny sygnał, że ataki na łańcuch dostaw oprogramowania stają się coraz bardziej dojrzałe i precyzyjne. Napastnicy nie koncentrują się już wyłącznie na aplikacjach końcowych, lecz coraz częściej celują w narzędzia odpowiedzialne za budowanie, skanowanie i publikację kodu.

Dla zespołów bezpieczeństwa oznacza to konieczność traktowania środowisk CI/CD jako infrastruktury krytycznej. Ochrona sekretów, ścisła kontrola dostępu, walidacja integralności zależności oraz dojrzałe procedury reagowania na incydenty stają się dziś równie ważne jak bezpieczeństwo samego produktu końcowego.

Źródła

AI pomaga cyberprzestępcom: pierwszy znany exploit zero-day omijający 2FA

Wprowadzenie do problemu / definicja

Google Threat Intelligence Group poinformował o wykryciu kampanii, w której atakujący mieli wykorzystać model sztucznej inteligencji do odkrycia oraz przygotowania exploita dla podatności zero-day umożliwiającej obejście mechanizmu uwierzytelniania dwuskładnikowego. To ważny sygnał dla rynku cyberbezpieczeństwa, ponieważ pokazuje, że AI przestaje być wyłącznie narzędziem wspierającym rekonesans czy phishing, a zaczyna odgrywać rolę w bardziej zaawansowanych etapach operacji ofensywnych.

W tym przypadku mowa nie o klasycznej luce technicznej związanej z pamięcią czy walidacją danych, lecz o błędzie logicznym w procesie autoryzacji. Tego typu podatności są trudniejsze do wykrycia przez tradycyjne skanery, ponieważ wynikają z niespójności między założeniami bezpieczeństwa a rzeczywistym działaniem aplikacji.

W skrócie

Google ujawnił, że zidentyfikował nieznanego wcześniej aktora zagrożeń, który prawdopodobnie użył AI do wsparcia procesu odkrywania i uzbrojenia luki zero-day. Podatność dotyczyła popularnego otwartoźródłowego narzędzia administracyjnego dostępnego przez przeglądarkę i pozwalała na obejście 2FA, choć atak nadal wymagał posiadania prawidłowych danych logowania.

Exploit miał zostać napisany w Pythonie i zawierał cechy typowe dla kodu generowanego przez duże modele językowe, takie jak nadmiarowe komentarze, formalna struktura oraz elementy przypominające automatycznie wygenerowaną dokumentację. Problem został zgłoszony producentowi i usunięty przed planowaną próbą szerszego wykorzystania.

Kontekst / historia

W ostatnich miesiącach obserwowany jest szybki wzrost wykorzystania AI w cyberprzestępczości. Początkowo modele językowe służyły głównie do tworzenia wiadomości phishingowych, automatyzacji rekonesansu, tłumaczenia treści, analizy publicznie znanych podatności oraz modyfikowania kodu malware. Nowe ustalenia wskazują jednak na przesunięcie w stronę aktywnego wspierania odkrywania nieznanych wcześniej luk.

To oznacza skrócenie czasu między identyfikacją słabości a przygotowaniem działającego exploita. Z punktu widzenia obrońców rośnie więc presja na szybsze wykrywanie błędów, lepsze modelowanie zagrożeń i skuteczniejsze monitorowanie anomalii związanych z uwierzytelnianiem.

Analiza techniczna

Kluczowym elementem incydentu był charakter luki. Podatność umożliwiała obejście 2FA, ale nie dawała anonimowemu atakującemu natychmiastowego dostępu do systemu. Warunkiem powodzenia ataku było wcześniejsze posiadanie poprawnego loginu i hasła. Dopiero wtedy możliwe było pominięcie drugiego składnika uwierzytelniania.

Według dostępnych informacji źródłem problemu była twardo zakodowana relacja zaufania w logice aplikacji. To szczególnie niebezpieczna klasa błędów, ponieważ nie powoduje awarii ani oczywistych śladów technicznych. Tradycyjne metody, takie jak fuzzing czy klasyczna analiza statyczna, często nie wykrywają takich niespójności, ponieważ problem tkwi w semantyce działania systemu.

Google ocenił z wysoką pewnością, że do wsparcia procesu odkrycia i przygotowania exploita wykorzystano AI. Wskazywać miały na to artefakty obecne w kodzie, między innymi formalny styl implementacji, rozbudowane opisy funkcji, edukacyjny sposób komentowania oraz elementy wyglądające jak wynik działania modelu generatywnego. To istotny precedens, ponieważ sugeruje, że modele językowe stają się przydatne również przy analizie błędów wysokiego poziomu, szczególnie w logice autoryzacji i zarządzania sesją.

Konsekwencje / ryzyko

Najważniejszym ryzykiem jest osłabienie skuteczności 2FA jako zabezpieczenia chroniącego przed przejęciem kont. Jeśli atakujący dysponuje już prawidłowymi poświadczeniami, luka logiczna może pozwolić mu ominąć dodatkową warstwę ochrony i uzyskać pełny dostęp do aplikacji.

Drugą konsekwencją jest przyspieszenie całego łańcucha ataku. AI może znacząco skrócić czas potrzebny na analizę aplikacji, znalezienie nietypowych błędów oraz wygenerowanie gotowego kodu exploitacyjnego. W praktyce zmniejsza to okno czasowe na reakcję zespołów bezpieczeństwa.

Trzecie ryzyko ma wymiar strategiczny. Szczególnie narażone są aplikacje administracyjne, rozwiązania IAM, panele zarządzające oraz systemy webowe obsługujące uwierzytelnianie i autoryzację. W takich środowiskach pojedynczy błąd logiczny może prowadzić do przejęcia kontroli nad kluczowymi zasobami organizacji.

Rekomendacje

Organizacje powinny traktować 2FA jako jeden z elementów szerszej architektury bezpieczeństwa, a nie jako samodzielną gwarancję ochrony. Konieczne jest regularne testowanie logiki uwierzytelniania i autoryzacji pod kątem wyjątków, niejawnych założeń zaufania oraz scenariuszy obejścia kontroli bezpieczeństwa.

prowadzić przeglądy kodu ukierunkowane na błędy logiczne, a nie tylko klasyczne podatności implementacyjne,
testować scenariusze obejścia MFA i 2FA podczas audytów aplikacyjnych oraz ćwiczeń red teamingowych,
ograniczać ekspozycję internetową paneli administracyjnych,
wymuszać segmentację dostępu i zasadę najmniejszych uprawnień,
monitorować przypadki logowania zakończone sukcesem bez standardowego przebiegu drugiego składnika,
korelować zdarzenia IAM z anomaliami sesji, lokalizacji i urządzeń,
przyspieszać wdrażanie poprawek dla systemów dostępnych publicznie.

Zespoły AppSec i DevSecOps powinny dodatkowo uwzględniać w modelowaniu zagrożeń możliwość wykorzystania AI przez przeciwnika do analizy logiki biznesowej. Warto też rozwijać defensywne zastosowania AI do wykrywania niespójności w kodzie, analizy zmian oraz priorytetyzacji ryzyka.

Podsumowanie

Opisany przypadek może być punktem zwrotnym w rozwoju współczesnych zagrożeń. Po raz pierwszy publicznie wskazano, że AI mogła zostać użyta do stworzenia exploita zero-day umożliwiającego obejście 2FA w scenariuszu planowanej masowej eksploatacji. Nawet jeśli atak wymagał wcześniej przejętych poświadczeń, jego znaczenie pozostaje duże, ponieważ pokazuje rosnącą skuteczność modeli AI w identyfikowaniu błędów logicznych wysokiego poziomu.

Dla obrońców to sygnał, że tradycyjne metody wykrywania podatności nie są już wystarczające jako jedyna linia ochrony. Coraz większego znaczenia nabierają testy ukierunkowane na autoryzację, analiza semantyki kodu oraz szybkie reagowanie na anomalie w procesach MFA.

Źródła

Hackers Used AI to Develop First Known Zero-Day 2FA Bypass for Mass Exploitation — https://thehackernews.com/2026/05/hackers-used-ai-to-develop-first-known.html
GTIG AI Threat Tracker: Adversaries Leverage AI for Vulnerability Exploitation, Augmented Operations, and Initial Access — https://cloud.google.com/blog/topics/threat-intelligence/ai-vulnerability-exploitation-initial-access

Build Application Firewall: nowa linia obrony przed atakami na łańcuch dostaw oprogramowania

Wprowadzenie do problemu / definicja

Ataki na łańcuch dostaw oprogramowania należą dziś do najpoważniejszych zagrożeń dla organizacji tworzących i wdrażających aplikacje. Coraz częściej źródłem problemu nie jest bezpośrednio błąd w gotowym produkcie, lecz kompromitacja procesu budowania, narzędzi CI/CD, zależności open source albo mechanizmów automatyzacji.

Na tym tle pojawia się koncepcja Build Application Firewall, czyli warstwy bezpieczeństwa działającej bezpośrednio wewnątrz procesu budowy aplikacji. Jej zadaniem jest monitorowanie zachowania procesów i komponentów uruchamianych podczas builda oraz egzekwowanie polityk bezpieczeństwa w czasie rzeczywistym.

W skrócie

Build Application Firewall różni się od tradycyjnych narzędzi bezpieczeństwa tym, że nie ogranicza się wyłącznie do skanowania kodu, analizy zależności czy kontroli końcowego artefaktu. Zamiast tego obserwuje faktyczne działania wykonywane podczas budowy aplikacji.

wykrywa nieautoryzowane połączenia sieciowe z procesu builda,
identyfikuje próby eksfiltracji sekretów i wrażliwych danych,
kontroluje pobieranie nieoczekiwanych komponentów,
wyłapuje anomalie w przebiegu pipeline’u,
może blokować działania naruszające polityki bezpieczeństwa jeszcze przed ukończeniem kompilacji.

To podejście ma ograniczyć ryzyko incydentów supply chain, szczególnie tych, które wykorzystują zaufane biblioteki, przejęte konta maintainerów lub automatyczne mechanizmy pobierania zależności.

Kontekst / historia

W ostatnich latach liczne incydenty pokazały, że przejęcie jednego elementu ekosystemu developerskiego może wywołać efekt domina i doprowadzić do naruszeń u wielu podmiotów jednocześnie. Jednym z najbardziej znanych przykładów pozostaje atak na SolarWinds, który unaocznił skalę ryzyka związanego z kompromitacją procesu wytwarzania i dystrybucji oprogramowania.

Nowsze przypadki potwierdzają, że zagrożenie nie zniknęło, lecz stale ewoluuje. Problemem stają się zarówno złośliwe aktualizacje bibliotek, jak i przejęcia kont opiekunów pakietów, kompromitacje narzędzi wykorzystywanych w pipeline’ach oraz nadużycia zaufania do popularnych rejestrów i integracji.

W praktyce organizacje często zakładają, że komponent pochodzący z renomowanego źródła jest bezpieczny. Tymczasem złośliwy kod może zostać uruchomiony automatycznie w procesie builda i uzyskać dostęp do sekretów, tokenów oraz systemów wewnętrznych bez wyraźnej interwencji człowieka.

Analiza techniczna

Tradycyjna ochrona pipeline’u opiera się zwykle na skanowaniu zależności, statycznej analizie kodu, kontroli artefaktów końcowych, politykach dostępu i utwardzaniu runnerów. Problem polega na tym, że te mechanizmy koncentrują się głównie na tym, co zostało dostarczone do środowiska budowy, a nie zawsze na tym, co dany komponent rzeczywiście robi podczas wykonania.

Build Application Firewall ma uzupełnić tę lukę poprzez inspekcję aktywności procesów uruchamianych w trakcie builda. Obejmuje to obserwację ruchu wychodzącego, analizę transferu danych, kontrolę operacji względem oczekiwanych źródeł i celów oraz wykrywanie zachowań odbiegających od profilu normalnego działania.

monitorowanie połączeń wychodzących z procesu budowy,
analiza zachowań wskazujących na wyciek sekretów,
kontrola rzeczywistych operacji pull i push,
wykrywanie anomalii behawioralnych,
egzekwowanie polityk bezpieczeństwa na etapie wykonania.

Istotne jest to, że podstawowa telemetria sieciowa lub proste reguły egress nie zawsze wystarczają. Komunikacja do pozornie zaufanego serwisu może wyglądać poprawnie na poziomie DNS lub listy dozwolonych hostów, a mimo to służyć do przesłania tokenów, kluczy API czy innych danych wrażliwych.

Drugą zaletą takiego modelu jest większa odporność na zagrożenia nieznane wcześniej skanerom sygnaturowym. Nawet jeśli pakiet nie budzi podejrzeń podczas analizy statycznej, jego nietypowe działania w czasie builda mogą zostać wykryte jako odchylenie od oczekiwanego wzorca zachowania.

W praktyce koncepcja ta może również poprawić jakość SBOM-ów. System obserwujący rzeczywisty przebieg budowy potrafi lepiej ustalić, jakie komponenty i zależności pośrednie faktycznie zostały użyte oraz jakie artefakty powstały w procesie.

Konsekwencje / ryzyko

Ryzyko związane z atakami na CI/CD jest szczególnie wysokie, ponieważ pojedyncza kompromitacja może zostać powielona w wielu środowiskach i projektach jednocześnie. Jeśli złośliwy komponent przeniknie do zautomatyzowanego pipeline’u, skutki mogą objąć nie tylko producenta, ale też klientów, partnerów i dalszych dostawców.

wdrożenie backdoora do wielu aplikacji,
kradzież sekretów budowania i wdrażania,
przejęcie kont chmurowych lub repozytoriów kodu,
naruszenie integralności artefaktów produkcyjnych,
dalszą propagację zagrożenia w ekosystemie dostaw.

Szczególnym problemem jest szeroka automatyzacja nowoczesnych pipeline’ów. Biblioteki, skrypty instalacyjne, pluginy i narzędzia pomocnicze często dysponują wysokimi uprawnieniami oraz dostępem do cennych danych. To sprawia, że nawet krótka i trudna do zauważenia aktywność może wystarczyć do poważnego incydentu.

Dodatkowym wyzwaniem jest rosnąca złożoność ekosystemu open source oraz możliwość szybszego uzbrajania nowych podatności. W takim środowisku samo poleganie na reputacji pakietu, znanych sygnaturach lub listach IOC przestaje być wystarczające.

Rekomendacje

Organizacje powinny traktować pipeline CI/CD jako środowisko wysokiego ryzyka i wdrażać zabezpieczenia wykraczające poza klasyczne skanowanie zależności. Skuteczna ochrona wymaga połączenia kontroli dostępu, monitoringu runtime i analizy behawioralnej.

wprowadzenie monitoringu runtime dla procesów buildowych,
egzekwowanie restrykcyjnych polityk egress i dostępu do sekretów,
segmentacja oraz utwardzanie runnerów CI/CD,
kontrola pochodzenia zależności, wersji i podpisów,
stosowanie analizy behawioralnej zamiast wyłącznie sygnaturowej,
budowa wiarygodnych SBOM-ów odzwierciedlających rzeczywisty skład artefaktów,
regularne przeglądy zaufanych integracji, pluginów i narzędzi automatyzacyjnych.

W praktyce oznacza to także ograniczanie uprawnień do absolutnego minimum oraz dokładne mapowanie tego, jakie procesy, połączenia i transfery danych są rzeczywiście potrzebne w każdym etapie pipeline’u.

Podsumowanie

Build Application Firewall to odpowiedź na ograniczenia tradycyjnych mechanizmów ochrony środowisk CI/CD. Najważniejsza zmiana polega na przeniesieniu punktu ciężkości z analizy deklaracji, manifestów i artefaktów na ocenę realnego zachowania procesu budowy.

W warunkach rosnącej liczby ataków na łańcuch dostaw oprogramowania taki model może stać się istotnym uzupełnieniem skanerów, SBOM-ów i standardowych polityk bezpieczeństwa. Dla zespołów DevSecOps oznacza to potrzebę głębszej obserwacji runtime buildów, lepszej kontroli przepływu danych i bardziej rygorystycznego zarządzania zaufaniem w całym ekosystemie zależności.

Źródła

https://www.securityweek.com/build-application-firewalls-aim-to-stop-the-next-supply-chain-attack/
https://www.securityweek.com/cisa-nsa-share-guidance-on-securing-ci-cd-environments/
https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/
https://csrc.nist.gov/Projects/ssdf
https://www.cisa.gov/sbom

Kompromitacja wtyczki Checkmarx AST dla Jenkins: TeamPCP ponownie uderza w łańcuch dostaw

Wprowadzenie do problemu / definicja

Ataki na łańcuch dostaw oprogramowania należą dziś do najgroźniejszych zagrożeń dla środowisk DevSecOps oraz CI/CD. Ich istota polega na przejęciu zaufanego elementu procesu wytwarzania oprogramowania, takiego jak wtyczka, biblioteka, obraz kontenera czy workflow automatyzujący build i testy. W najnowszym incydencie ofiarą padła wtyczka Checkmarx AST Scanner dla Jenkins, do której trafiła zmodyfikowana, nieautoryzowana wersja.

To szczególnie niebezpieczny scenariusz, ponieważ komponent zintegrowany z pipeline’ami budowania ma zwykle dostęp do sekretów, tokenów API, poświadczeń chmurowych i danych uwierzytelniających wykorzystywanych przez zespoły deweloperskie oraz bezpieczeństwa. Kompromitacja takiego narzędzia może więc szybko przełożyć się na szerokie skutki operacyjne i bezpieczeństwa.

W skrócie

Checkmarx potwierdził, że w ekosystemie Jenkins pojawiła się zmodyfikowana wersja wtyczki AST Scanner. Producent zalecił użytkownikom sprawdzenie, czy korzystają z wersji 2.0.13-829.vc72453fa_1c16 opublikowanej 17 grudnia 2025 roku lub starszej, a następnie przejście na nowsze wydanie naprawcze 2.0.13-848.v76e89de8a_053.

Incydent jest łączony z aktywnością grupy TeamPCP, która była wcześniej wskazywana w kontekście naruszeń obejmujących inne artefakty Checkmarx, w tym obrazy Docker, rozszerzenia VS Code i workflow GitHub Actions. Zdarzenie wpisuje się w klasyczny model supply chain attack wymierzonego w narzędzia wykorzystywane bezpośrednio w procesie tworzenia i testowania oprogramowania.

Kontekst / historia

To nie jest pierwszy incydent związany z ekosystemem Checkmarx. W marcu 2026 roku firma informowała już o cyberincydencie dotyczącym wybranych komponentów dystrybuowanych przez kanały używane przez zespoły developerskie. Wówczas problem obejmował między innymi workflow GitHub Actions oraz dodatki związane z bezpieczeństwem aplikacji.

Nowy przypadek sugeruje, że przeciwnik mógł utrzymać dostęp do części zasobów albo ponownie wykorzystać słabości w obszarze zarządzania sekretami, repozytoriami i procesem publikacji artefaktów. Powtarzalność podobnych incydentów wskazuje na szerszą kampanię ukierunkowaną na przejmowanie zaufanych elementów łańcucha dostaw oprogramowania.

Analiza techniczna

W analizowanym scenariuszu doszło do opublikowania zmodyfikowanej wersji wtyczki Checkmarx AST Scanner w ekosystemie Jenkins. Z punktu widzenia atakującego jest to wyjątkowo efektywny wektor, ponieważ wiele organizacji ufa oficjalnym kanałom dystrybucji i instaluje aktualizacje bez dodatkowej walidacji pochodzenia artefaktów.

Wtyczka Checkmarx dla Jenkins integruje skanowanie bezpieczeństwa z pipeline’ami buildowymi, co oznacza, że może działać w kontekście bardzo wrażliwych procesów. W praktyce uzyskuje ona często dostęp do konfiguracji buildów, sekretów środowiskowych, tokenów do repozytoriów kodu, kluczy do usług chmurowych oraz wyników skanów bezpieczeństwa.

przechwytywanie sekretów przekazywanych do procesu skanowania,
uruchamianie dodatkowego kodu w kontekście joba Jenkins,
modyfikację wyników skanowania lub telemetrii,
komunikację z zewnętrzną infrastrukturą sterującą,
rozszerzenie wpływu na kolejne elementy pipeline’u i środowiska.

W opisie incydentu pojawiały się również informacje o nieautoryzowanym dostępie do repozytorium powiązanego z projektem oraz o defacemencie. Taki sygnał oznacza, że problem nie ograniczał się wyłącznie do pojedynczego artefaktu, lecz mógł dotyczyć integralności całego procesu utrzymania i publikowania komponentu. Dodatkowo wcześniejsze ostrzeżenia dotyczące publikacji wydania poza oficjalnym pipeline’em wzmacniają podejrzenie naruszenia samego procesu release management.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem kompromitacji wtyczki Jenkins jest utrata zaufania do narzędzia znajdującego się w centrum procesu SDLC. Jeśli złośliwy komponent został uruchomiony w środowisku CI/CD, skutki mogą wykraczać daleko poza pojedynczy serwer Jenkins i obejmować wiele systemów zależnych.

wyciek sekretów developerskich i chmurowych,
przejęcie kont usługowych,
kompromitację repozytoriów kodu źródłowego,
modyfikację pipeline’ów oraz artefaktów budowania,
ruch boczny do innych segmentów infrastruktury.

Ryzyko rośnie szczególnie tam, gdzie Jenkins ma szerokie uprawnienia sieciowe i integruje się jednocześnie z repozytoriami, systemami chmurowymi, skanerami bezpieczeństwa i mechanizmami wdrożeń. Nawet krótka ekspozycja na złośliwą wersję może prowadzić do długotrwałych konsekwencji, jeśli przechwycone tokeny lub klucze nadal pozostają aktywne.

Rekomendacje

Organizacje korzystające z Checkmarx AST Scanner w Jenkins powinny potraktować incydent jako potencjalne naruszenie bezpieczeństwa, a nie jedynie problem z aktualizacją wtyczki. Odpowiedź powinna obejmować zarówno działania natychmiastowe, jak i przegląd długoterminowych mechanizmów ochrony łańcucha dostaw.

zweryfikować wersję zainstalowanej wtyczki na wszystkich kontrolerach Jenkins i agentach buildowych,
przywrócić wersję uznaną za bezpieczną lub przejść na wydanie naprawcze,
przeanalizować logi pod kątem nietypowych aktualizacji, zmian konfiguracji i podejrzanych połączeń wychodzących,
przeprowadzić rotację wszystkich sekretów dostępnych dla pipeline’ów i integracji Checkmarx,
sprawdzić integralność skryptów buildowych, bibliotek współdzielonych i ostatnio tworzonych artefaktów,
wprowadzić pinowanie wersji wtyczek oraz dodatkową walidację pochodzenia komponentów,
ograniczyć uprawnienia Jenkins zgodnie z zasadą najmniejszych przywilejów,
wzmocnić monitoring procesów publikacji i aktualizacji oprogramowania.

Z perspektywy strategicznej incydent potwierdza potrzebę izolacji środowisk CI, segmentacji agentów, ograniczania dostępu do sekretów per job oraz wdrażania mechanizmów potwierdzania integralności artefaktów. Bez takich zabezpieczeń pojedyncza kompromitacja zaufanego komponentu może stać się punktem wyjścia do szerszego naruszenia organizacji.

Podsumowanie

Kompromitacja wtyczki Checkmarx AST dla Jenkins to kolejny przykład skutecznego ataku na zaufany element ekosystemu developerskiego. Uderzenie w narzędzie używane bezpośrednio w pipeline’ach CI/CD daje napastnikom dostęp do wyjątkowo cennych zasobów, w tym sekretów, poświadczeń i procesów budowania oprogramowania.

Dla organizacji oznacza to konieczność traktowania bezpieczeństwa wtyczek, workflow i artefaktów jako kluczowego elementu ochrony łańcucha dostaw. Samo usunięcie podejrzanej wersji nie wystarczy — niezbędne są analiza wpływu, rotacja sekretów oraz przegląd zaufania do procesu publikacji i aktualizacji komponentów.

Źródła

CrowdStrike 2026: AI, Tożsamość I Nowe Ataki

Rok niewidzialnego przeciwnika: czego raport CrowdStrike 2026 uczy o AI, tożsamości i nowych ścieżkach ataku

Zobaczmy, co się dzieje, gdy napastnik nie wrzuca EXE na stację, nie zostawia klasycznego droppera i nie wygląda jak ktoś, kto właśnie „wszedł do środka”. Dzwoni na help desk. Resetuje hasło. Rejestruje urządzenie w chmurze. Przegląda SharePointa. Odpala tymczasową VM-kę w vCenter. A potem szyfruje dane z boku przez SMB albo wyciąga je przez legalny kanał SaaS. Właśnie dlatego raport CrowdStrike 2026 Global Threat Report warto czytać nie jako kolejną publikację „o AI”, tylko jako opis zmiany modelu ataku.

Czytaj dalej

Claude Code pod presją: ukryte przejęcie MCP umożliwia kradzież tokenów OAuth

Wprowadzenie do problemu / definicja

Bezpieczeństwo agentów AI wykorzystywanych w procesie tworzenia oprogramowania staje się jednym z kluczowych tematów dla zespołów DevSecOps. Najnowszy opisywany scenariusz pokazuje, że środowisko Claude Code może zostać wykorzystane do cichego przechwytywania tokenów OAuth poprzez manipulację konfiguracją MCP, czyli warstwy odpowiedzialnej za komunikację z narzędziami i usługami zewnętrznymi.

Problem nie ogranicza się wyłącznie do samej aplikacji. Dotyczy całego łańcucha zaufania obejmującego lokalne pliki konfiguracyjne, integracje SaaS, mechanizmy autoryzacji oraz zależności instalowane na stacji roboczej programisty.

W skrócie

Atakujący może przejąć ruch MCP i działać jako pośrednik między Claude Code a legalnym serwerem integracyjnym.
Celem operacji jest pozyskanie tokenów OAuth dających dostęp do podłączonych usług.
Wektor ataku wykorzystuje modyfikację lokalnej konfiguracji oraz złośliwy pakiet npm z mechanizmem postinstall.
Przejęcie może utrzymywać się po rotacji tokenu i nie musi generować widocznych alertów.
Skutki mogą objąć repozytoria kodu, systemy CI/CD, platformy komunikacyjne i inne usługi biznesowe.

Kontekst / historia

Claude Code to narzędzie agentowe wspierające programistów w pracy z kodem oraz integracjami zewnętrznymi. W tego typu architekturach istotną rolę odgrywają serwery MCP, które pośredniczą w dostępie do funkcji, narzędzi i usług. Oznacza to, że kompromitacja konfiguracji lub przepływu autoryzacji może przełożyć się na dostęp do wielu systemów jednocześnie.

Scenariusz został nagłośniony przez badaczy Mitiga Labs, którzy wskazali, że tokeny OAuth oraz konfiguracja MCP mogą być przechowywane lokalnie w plikach użytkownika. Jeżeli przeciwnik zyska możliwość zmiany tych ustawień, może przekierować komunikację przez kontrolowaną przez siebie infrastrukturę i przechwycić dane uwierzytelniające bez zakłócania pozornego działania aplikacji.

To ważny sygnał dla rynku: nowoczesne narzędzia AI coraz częściej łączą w jednym przepływie roboczym kod źródłowy, tożsamość użytkownika, automatyzację i dostęp do usług trzecich. W efekcie pojedynczy punkt kompromitacji może mieć znaczenie porównywalne z przejęciem konta uprzywilejowanego.

Analiza techniczna

Technicznie atak opiera się na dwóch podstawowych warunkach. Po pierwsze, napastnik musi doprowadzić do instalacji odpowiednio przygotowanego pakietu npm w środowisku, w którym Claude Code korzysta z dynamicznie autoryzowanych serwerów MCP. Po drugie, pakiet wykorzystuje hook postinstall, aby uruchomić dodatkową logikę bez potrzeby dalszej interakcji użytkownika.

Po instalacji złośliwy komponent może przeszukiwać typowe lokalizacje repozytoriów i modyfikować ustawienia zaufania, aby ograniczyć ryzyko pojawienia się ostrzeżeń. Następnie atakujący zmienia lokalny plik konfiguracyjny i dodaje lub podmienia adres serwera MCP na infrastrukturę pośredniczącą kontrolowaną przez siebie.

Od tego momentu inicjalizacja oraz odświeżanie sesji MCP może przebiegać przez serwer proxy napastnika. W praktyce jest to wariant ataku man-in-the-middle osadzony w legalnym przepływie aplikacyjnym. Użytkownik nadal widzi pozornie poprawny proces logowania i komunikacji, podczas gdy token OAuth trafia równolegle do infrastruktury przeciwnika.

Szczególnie groźna jest trwałość tego mechanizmu. Nawet jeśli ofiara ręcznie poprawi konfigurację lub przeprowadzi rotację tokenu, złośliwa logika może ponownie zapisać niepożądane ustawienia przy kolejnym uruchomieniu albo odświeżeniu środowiska. Taka persystencja sprawia, że przejęcie nie musi być jednorazowe i może być automatycznie odnawiane.

Dodatkowym zagrożeniem jest zakres uprawnień przechwyconego tokenu. Jeżeli zapewnia on dostęp do wielu usług SaaS zintegrowanych przez MCP, napastnik może uzyskać funkcjonalny odpowiednik uprzywilejowanego klucza sesyjnego. W praktyce może to oznaczać obejście ochron opartych na MFA, ponieważ celem staje się już wydany token, a nie sam proces logowania.

Konsekwencje / ryzyko

Ryzyko operacyjne jest wysokie, ponieważ skutki takiego incydentu wykraczają poza pojedynczą stację roboczą. Przejęty token może otworzyć drogę do repozytoriów kodu, systemów zgłoszeń, narzędzi CI/CD, platform komunikacyjnych oraz innych usług wykorzystywanych w codziennej pracy zespołów developerskich.

W zależności od zakresu przyznanych uprawnień możliwe stają się kradzież kodu źródłowego, manipulacja pipeline’ami, eksfiltracja danych, nadużycia w środowisku SaaS oraz dalszy ruch boczny w organizacji. To szczególnie niebezpieczne w firmach, gdzie narzędzia agentowe mają szeroki dostęp do zasobów produkcyjnych lub półprodukcyjnych.

Istotnym problemem pozostaje także niska wykrywalność. Ruch może wyglądać jak prawidłowa komunikacja aplikacji z serwerami integracyjnymi, a użytkownik nie musi zobaczyć żadnych alarmujących komunikatów. Dla zespołów SOC oznacza to konieczność monitorowania nie tylko aktywności w usługach końcowych, ale również zmian w lokalnej konfiguracji narzędzi AI i ich zależności.

Rekomendacje

Organizacje korzystające z agentów AI w procesie developerskim powinny wdrożyć kontrolę integralności lokalnych plików konfiguracyjnych, zwłaszcza tych przechowujących definicje serwerów MCP, ustawienia zaufania oraz dane autoryzacyjne. Każda nieautoryzowana zmiana takich plików powinna generować alert i zostać objęta analizą bezpieczeństwa.

Należy także ograniczyć możliwość instalowania niezweryfikowanych pakietów npm i tam, gdzie to możliwe, blokować wykonywanie ryzykownych hooków lifecycle. W środowiskach o podwyższonych wymaganiach bezpieczeństwa warto stosować prywatne rejestry pakietów, allowlisting zależności oraz izolowane stacje robocze dla programistów.

Ważną praktyką jest minimalizacja uprawnień tokenów OAuth oraz skracanie ich czasu życia. Im mniejszy zakres dostępu i krótsza ważność tokenu, tym niższy wpływ potencjalnego przejęcia. Dobrą praktyką pozostaje również przechowywanie sekretów w bezpiecznych magazynach poświadczeń zamiast w prostych lokalnych plikach tekstowych.

Po stronie monitoringu należy obserwować zmiany adresów serwerów MCP, nietypowe odświeżenia tokenów, anomalie w ruchu wychodzącym oraz niespodziewane wywołania API w zintegrowanych usługach SaaS. Skuteczne może być korelowanie telemetrii endpointowej z logami dostawców chmurowych i aplikacyjnych.

W reakcji na incydent zalecane są:

przegląd lokalnych plików konfiguracyjnych i wpisów MCP,
unieważnienie aktywnych tokenów OAuth oraz ponowne wystawienie poświadczeń,
weryfikacja ostatnio instalowanych pakietów i skryptów postinstall,
analiza historii zmian w repozytoriach i integracjach SaaS,
traktowanie narzędzi agentowych jako zasobów uprzywilejowanych wymagających osobnego hardeningu.

Podsumowanie

Przypadek ukrytego przejęcia MCP w Claude Code pokazuje, że bezpieczeństwo narzędzi AI nie kończy się na modelu ani interfejsie użytkownika. Kluczowe znaczenie mają lokalne pliki konfiguracyjne, integracje SaaS, tokeny OAuth oraz łańcuch dostaw pakietów.

Opisany scenariusz łączy cechy ataku supply chain, lokalnej persystencji i man-in-the-middle. Jego skuteczność wynika z cichego charakteru operacji oraz zaufania do legalnego przepływu pracy. Dla zespołów bezpieczeństwa to wyraźny sygnał, że narzędzia agentowe używane przez programistów powinny być objęte równie rygorystyczną ochroną jak inne systemy uprzywilejowane.

Źródła

SecurityWeek — Claude Code OAuth Tokens Can Be Stolen Through Stealthy MCP Hijacking — https://www.securityweek.com/claude-code-oauth-tokens-can-be-stolen-through-stealthy-mcp-hijacking/
Mitiga — Technical write-up on Claude Code MCP hijacking research — https://www.mitiga.io/
OAuth 2.0 Authorization Framework — https://datatracker.ietf.org/doc/html/rfc6749