Archiwa: Security News - Strona 134 z 511 - Security Bez Tabu

Irańska grupa APT nasila cyberwywiad wobec kluczowych sektorów w USA i krajach sojuszniczych

Cybersecurity news

Wprowadzenie do problemu / definicja

W maju 2026 roku ujawniono nowe ustalenia dotyczące aktywności irańsko-powiązanej grupy APT znanej jako Screening Serpens. Opisywane kampanie koncentrują się na działaniach cyberwywiadowczych wymierzonych w organizacje o wysokiej wartości operacyjnej i strategicznej, przede wszystkim z sektorów lotniczego, obronnego, telekomunikacyjnego oraz technologicznego.

Rdzeniem operacji pozostaje spear phishing, czyli celowane wiadomości przygotowywane pod konkretną osobę lub rolę zawodową. Atakujący wykorzystują wiarygodne przynęty, podszywanie się pod znane marki oraz złośliwe oprogramowanie typu RAT, aby uzyskać trwały dostęp do środowiska ofiary.

W skrócie

Badacze zagrożeń opisali serię kampanii prowadzonych od lutego do kwietnia 2026 roku. W operacjach wykorzystano sześć nowych wariantów malware należących do dwóch rodzin: MiniUpdate oraz MiniJunk V2.

  • Celami były podmioty w Stanach Zjednoczonych, Izraelu, Zjednoczonych Emiratach Arabskich oraz innych organizacjach na Bliskim Wschodzie.
  • Przynęty obejmowały fałszywe oferty pracy, spreparowane portale rekrutacyjne i imitacje zaproszeń do spotkań wideo.
  • Ataki były silnie spersonalizowane i przygotowywane pod konkretne osoby.
  • Operatorzy stosowali wydzieloną infrastrukturę C2 dla poszczególnych celów, co utrudniało wykrycie i korelację incydentów.

Kontekst / historia

Screening Serpens od lat jest wiązana z irańskimi celami wywiadowczymi i była już wcześniej opisywana pod innymi nazwami. Najnowsza fala kampanii pokazuje jednak wyraźny wzrost dojrzałości operacyjnej: lepsze rozpoznanie ofiar, większą personalizację przynęt oraz bardziej uporządkowane wykorzystanie infrastruktury.

Z analiz wynika, że intensyfikacja działań nastąpiła po rozpoczęciu regionalnego konfliktu na Bliskim Wschodzie 28 lutego 2026 roku. Od połowy lutego do połowy kwietnia grupa prowadziła operacje konsekwentnie, z ograniczaniem współdzielenia infrastruktury między kampaniami i częstą rotacją domen sterujących.

Taki model działania jest charakterystyczny dla dojrzałych grup APT. Pozwala ograniczać skutki wykrycia pojedynczej kampanii, utrudnia blokowanie na podstawie prostych IOC i zwiększa szanse na długotrwałe utrzymanie dostępu.

Analiza techniczna

Techniczna strona kampanii opierała się na połączeniu socjotechniki z malware uruchamianym przez samą ofiarę. W części przypadków wykorzystywano archiwa ZIP zawierające dokumenty PDF z opisami stanowisk, a następnie kolejne archiwum lub plik wykonywalny udający dostęp do portalu rekrutacyjnego. W innych scenariuszach atakujący podszywali się pod oprogramowanie do wideokonferencji i nakłaniali do pobrania rzekomego instalatora.

Po uruchomieniu ładunku grupa wykorzystywała techniki związane z ładowaniem złośliwych bibliotek przez legalne komponenty. Podejście to przypomina DLL sideloading lub hijacking przepływu wykonania, w którym zaufany proces ładuje podstawiony moduł zamiast oczekiwanej biblioteki. Dzięki temu złośliwy kod działa pod osłoną legalnego procesu, co utrudnia detekcję.

Jednym z bardziej interesujących elementów ewolucji kampanii było zastosowanie techniki AppDomainManager hijacking w środowisku .NET. Pozwala ona wpłynąć na inicjalizację aplikacji jeszcze przed właściwym wykonaniem głównej logiki programu, co może służyć osłabieniu lokalnych mechanizmów ochronnych i przygotowaniu środowiska pod działanie wielofunkcyjnych RAT-ów.

Rodzina MiniUpdate była używana między innymi w kampaniach z marca 2026 roku wymierzonych w podmioty w USA i Izraelu, a następnie także przeciwko celom na Bliskim Wschodzie w połowie kwietnia. Z kolei MiniJunk V2 pojawiał się już w lutym i marcu, a jeden z opisanych przypadków wskazywał na długotrwałe przygotowanie operacji wobec specjalisty IT aktywnie poszukującego pracy.

W warstwie infrastrukturalnej operatorzy korzystali z niewielkich zestawów domen C2, często przypisywanych do konkretnej ofiary i konkretnego wariantu malware. Taki model skraca czas życia infrastruktury, zmniejsza jej widoczność i utrudnia klasyczne blokowanie wyłącznie na podstawie znanych wskaźników kompromitacji.

Konsekwencje / ryzyko

Najpoważniejszym ryzykiem jest skuteczny cyberwywiad przeciwko organizacjom o znaczeniu strategicznym. Uzyskanie dostępu przez RAT może umożliwić kradzież dokumentów, pozyskanie danych uwierzytelniających, mapowanie środowiska, ruch boczny i przygotowanie kolejnych etapów operacji.

Szczególnie zagrożone są zespoły inżynieryjne, IT, telekomunikacyjne, badawczo-rozwojowe oraz administracyjne. To właśnie wobec tych ról najłatwiej zbudować przekonującą narrację rekrutacyjną lub biznesową, która skłoni użytkownika do samodzielnego uruchomienia złośliwego pliku.

Ryzyko nie ogranicza się wyłącznie do organizacji bezpośrednio związanych z obronnością. Potencjalnymi ofiarami mogą stać się również firmy z łańcucha dostaw, operatorzy telekomunikacyjni oraz dostawcy usług wspierających krytyczne procesy biznesowe i państwowe.

Rekomendacje

Organizacje powinny traktować wysoko spersonalizowane wiadomości rekrutacyjne, oferty współpracy i zaproszenia do spotkań jako potencjalny wektor ataku, szczególnie gdy zawierają archiwa ZIP, instalatory albo nietypowe instrukcje uruchamiania plików. Niezbędne są jasne procedury weryfikacji takich materiałów, zwłaszcza w działach technicznych i wśród pracowników aktywnych zawodowo w sieci.

  • Monitorować uruchamianie legalnych plików EXE z nietypowych lokalizacji użytkownika.
  • Wykrywać anomalie związane z ładowaniem bibliotek DLL oraz konfiguracją aplikacji .NET.
  • Analizować tworzenie procesów potomnych z archiwów i katalogów tymczasowych.
  • Stosować EDR lub XDR z detekcją behawioralną, a nie wyłącznie ochronę sygnaturową.
  • Blokować wykonywanie niepodpisanych lub nieautoryzowanych komponentów z katalogów użytkownika.
  • Ograniczać uruchamianie archiwów i instalatorów pobieranych z poczty oraz komunikatorów.
  • Wzmacniać ochronę tożsamości, segmentację dostępu i stosowanie MFA odpornego na phishing.

Ważną rolę odgrywają również zespoły SOC i threat hunting. Powinny one rozwijać reguły detekcyjne pod kątem przynęt rekrutacyjnych, spoofingu marek, fałszywych portali spotkań i technik sideloadingu. Równolegle należy prowadzić szkolenia użytkowników skoncentrowane na scenariuszach spear phishingu opartych na realnym kontekście zawodowym.

Podsumowanie

Najnowsza aktywność grupy Screening Serpens pokazuje, że współczesne operacje APT coraz częściej opierają się na połączeniu precyzyjnego rozpoznania ofiary z umiarkowanie złożonym, ale skutecznie wdrażanym malware. O sile kampanii decyduje nie tylko sam kod, lecz cały łańcuch ataku: wiarygodna przynęta, legalnie wyglądający nośnik infekcji, techniki ukrywania wykonania oraz dedykowana infrastruktura C2.

Dla organizacji działających w sektorach strategicznych oznacza to konieczność przesunięcia uwagi z obrony przed phishingiem masowym na ochronę przed wysoce ukierunkowanym spear phishingiem. Skuteczna odpowiedź wymaga połączenia detekcji behawioralnej, kontroli uruchamiania kodu, ochrony tożsamości i stałego monitorowania oznak kampanii celowanych.

Źródła

  1. Cybersecurity Dive: Iran-linked hackers target key US, allied sectors with sophisticated spear-phishing messages
  2. Unit 42: Tracking Iranian APT Screening Serpens’ 2026 Espionage Campaigns
  3. MITRE ATT&CK: Hijack Execution Flow: DLL

Wyciek kluczy CISA na publicznym GitHubie wywołał reakcję Kongresu

Cybersecurity news

Wprowadzenie do problemu / definicja

Amerykańska agencja CISA, odpowiadająca za cyberbezpieczeństwo i ochronę infrastruktury krytycznej, znalazła się w centrum poważnego incydentu po ujawnieniu poświadczeń dostępowych w publicznym repozytorium GitHub. Sprawa dotyczy danych opublikowanych przez kontraktora posiadającego administracyjny dostęp do środowiska deweloperskiego agencji, co nadaje zdarzeniu szczególnie wysoki ciężar operacyjny i wizerunkowy.

Wyciek obejmował jawne sekrety, takie jak klucze, tokeny oraz pliki konfiguracyjne, które mogły ułatwić dalszą penetrację środowisk rządowych oraz łańcuchów CI/CD. Tego rodzaju ekspozycja stanowi klasyczny przykład zagrożenia wynikającego z niewłaściwego zarządzania sekretami w procesach wytwórczych i integracyjnych.

W skrócie

  • Do publicznego repozytorium trafiły poświadczenia związane m.in. z zasobami AWS GovCloud i systemami wewnętrznymi.
  • Część mechanizmów ochronnych platformy kodowej miała zostać wyłączona lub ominięta.
  • CISA rozpoczęła działania ograniczające skutki incydentu, ale pełna rotacja sekretów nie nastąpiła natychmiast.
  • Sprawa wywołała reakcję amerykańskich ustawodawców, którzy zażądali formalnych wyjaśnień.
  • Incydent ujawnił ryzyka związane z nadzorem nad kontraktorami i bezpieczeństwem procesów DevSecOps.

Kontekst / historia

Opisywany przypadek wpisuje się w szerszy problem operacyjnego zarządzania sekretami w organizacjach wykorzystujących platformy Git do rozwoju oprogramowania, automatyzacji wdrożeń i integracji środowisk chmurowych. Publiczne repozytorium, które stało się źródłem incydentu, miało według dostępnych informacji bardziej charakter roboczego magazynu danych niż formalnie zarządzanego projektu programistycznego.

Ekspozycja mogła utrzymywać się przez dłuższy czas, a najbardziej wrażliwe dane miały zostać dodane pod koniec kwietnia 2026 roku. Po nagłośnieniu sprawy senator Maggie Hassan oraz członkowie Izby Reprezentantów, w tym Bennie Thompson i Delia Ramirez, wystąpili o wyjaśnienia dotyczące przyczyn, zakresu i skutków zdarzenia. Polityczny wymiar incydentu został dodatkowo wzmocniony przez trwającą debatę na temat kondycji organizacyjnej i kadrowej CISA.

Analiza techniczna

Technicznie był to incydent typu secret leak, jednak jego skala wykracza poza typowe przypadki przypadkowego umieszczenia tokenu w kodzie. Wśród ujawnionych danych miały znajdować się poświadczenia do środowisk chmurowych, pliki konfiguracyjne oraz klucze prywatne służące do autoryzacji aplikacji zintegrowanych z organizacją GitHub.

Najpoważniejsze ryzyko wiązano z kluczem RSA przypisanym do aplikacji GitHub o szerokim zakresie dostępu do organizacji kodowej CISA. Taki klucz mógł potencjalnie umożliwić odczyt prywatnych repozytoriów, rejestrację złośliwych self-hosted runnerów, przejęcie sekretów używanych przez pipeline’y CI/CD, a także modyfikację ustawień administracyjnych, takich jak webhooki, deploy keys czy reguły ochrony gałęzi. W praktyce oznacza to zagrożenie zarówno dla poufności kodu, jak i integralności całego procesu budowania i wdrażania oprogramowania.

Dodatkowym problemem jest fakt, że publiczne platformy kodowe są stale monitorowane przez boty i narzędzia służące do automatycznego wyszukiwania nowo opublikowanych sekretów. Nawet bardzo krótki czas ekspozycji może wystarczyć, aby klucze zostały przechwycone i wykorzystane przez osoby trzecie. Jeżeli ujawnione dane dawały dostęp do GovCloud, konfiguracji Kubernetes lub tokenów administracyjnych, napastnik mógł uzyskać widoczność środowiska, a następnie przeprowadzić lateral movement.

Incydent zwraca również uwagę na ograniczenia kontroli prewencyjnych. Nawet jeśli platforma oferuje skanowanie sekretów i polityki organizacyjne, zabezpieczenia mogą zostać osłabione przez błędy użytkownika, obchodzenie procedur lub korzystanie z niezarządzanych kont i repozytoriów roboczych. To połączenie ryzyka ludzkiego, słabego governance i niedostatecznej kontroli nad procesem developerskim.

Konsekwencje / ryzyko

Skutki takiego wycieku należy rozpatrywać wielowymiarowo. Najbardziej oczywiste jest ryzyko nieautoryzowanego dostępu do systemów, kodu źródłowego, sekretów wtórnych oraz infrastruktury chmurowej. W przypadku kompromitacji elementów CI/CD pojawia się także możliwość przeprowadzenia ataku na łańcuch dostaw, w tym modyfikacji artefaktów, wstrzyknięcia złośliwego kodu lub manipulacji konfiguracjami wdrożeniowymi.

Dla organizacji rządowej równie istotne są skutki operacyjne i reputacyjne. Nawet jeśli nie potwierdzono naruszenia danych o charakterze misyjnym, sama ekspozycja poświadczeń związanych z infrastrukturą o wysokim znaczeniu osłabia zaufanie do praktyk bezpieczeństwa. W dodatku istnieje ryzyko, że część kluczy została przechwycona jeszcze przed ich unieważnieniem, co wymusza retrospektywną analizę logów API, zmian w repozytoriach, aktywności IAM i zdarzeń chmurowych.

Incydent uwidacznia również problem zależności od kontraktorów oraz niedostatecznego nadzoru nad wykorzystywaniem prywatnych kont i narzędzi do pracy służbowej. To obszar często marginalizowany w modelach zagrożeń, mimo że może prowadzić do konsekwencji porównywalnych z klasycznym przejęciem uprzywilejowanego konta.

Rekomendacje

Organizacje powinny traktować ten przypadek jako ostrzeżenie i wdrażać wielowarstwową ochronę sekretów. Obejmuje to zarówno skanowanie commitów po stronie dewelopera, jak i centralne mechanizmy wykrywania poświadczeń na poziomie platformy repozytoryjnej. Kluczowe jest wymuszanie blokady pushów zawierających sekrety oraz ograniczenie możliwości wyłączania takich zabezpieczeń bez formalnej autoryzacji.

Niezbędna pozostaje pełna inwentaryzacja sekretów, ich właścicieli, zakresów uprawnień i okresów ważności. Każdy sekret powinien być łatwy do rotacji, ograniczony zasadą najmniejszych uprawnień i powiązany z centralnym systemem zarządzania tajemnicami. Tam, gdzie to możliwe, warto zastępować klucze długoterminowe mechanizmami krótkotrwałych poświadczeń, federacją tożsamości i podejściem just-in-time.

  • Rozdzielenie środowisk i repozytoriów prywatnych od publicznych.
  • Zakaz wykorzystywania prywatnych kont do obsługi materiałów służbowych.
  • Monitoring zdarzeń GitHub lub GitLab pod kątem nieautoryzowanego tworzenia repozytoriów.
  • Kontrola rejestracji i uprawnień self-hosted runnerów.
  • Regularny audyt aplikacji integracyjnych, webhooków, deploy keys i tokenów automatyzacyjnych.
  • Natychmiastowa rotacja sekretów i analiza blast radius po wykryciu wycieku.

Warto podkreślić, że samo usunięcie danych z repozytorium nie rozwiązuje problemu. Jeżeli sekrety były publicznie dostępne, należy zakładać, że mogły zostać skopiowane, zarchiwizowane lub automatycznie przechwycone. Dlatego reakcja powinna obejmować nie tylko remediację techniczną, ale również dochodzenie i ocenę realnego wpływu incydentu.

Podsumowanie

Wyciek kluczy CISA do publicznego repozytorium GitHub pokazuje, że niekontrolowana ekspozycja sekretów nadal pozostaje jednym z najbardziej praktycznych i kosztownych błędów operacyjnych w cyberbezpieczeństwie. W tym przypadku problem wykraczał poza pojedynczy token i obejmował zestaw poświadczeń mogących prowadzić do szerokiej kompromitacji środowisk chmurowych oraz procesów wytwórczych.

Reakcja Kongresu podkreśla skalę i wagę incydentu, ale najważniejsza lekcja dla rynku jest uniwersalna: skuteczna ochrona sekretów wymaga nie tylko narzędzi, lecz także dyscypliny procesowej, dojrzałego governance oraz ścisłej kontroli nad działaniami wykonawców zewnętrznych.

Źródła

  • Krebs on Security — Lawmakers Demand Answers as CISA Tries to Contain Data Leak — https://krebsonsecurity.com/2026/05/lawmakers-demand-answers-as-cisa-tries-to-contain-data-leak/
  • Federal News Network — Restoring CISA is one issue many lawmakers can agree on — https://federalnewsnetwork.com/congress/2026/05/restoring-cisa-is-one-issue-many-lawmakers-can-agree-on/
  • Truffle Security Blog — Blog archive and disclosures related to leaked secrets research — https://trufflesecurity.com/blog

Cisco łata krytyczną lukę CVE-2026-20223 w Secure Workload z oceną CVSS 10.0

Cybersecurity news

Wprowadzenie do problemu / definicja

Cisco opublikowało poprawki dla krytycznej podatności w platformie Secure Workload, oznaczonej jako CVE-2026-20223. Luka wynika z niewystarczającej walidacji dostępu oraz uwierzytelniania w wybranych wewnętrznych endpointach REST API i może umożliwić zdalnemu, nieuwierzytelnionemu atakującemu uzyskanie dostępu do zasobów z uprawnieniami roli Site Admin. Ze względu na maksymalną ocenę CVSS 10.0 problem należy traktować jako zdarzenie o najwyższym priorytecie bezpieczeństwa.

W skrócie

Podatność wpływa na Cisco Secure Workload zarówno w modelu SaaS, jak i w środowiskach on-premise. Skuteczna eksploatacja może prowadzić do odczytu danych wrażliwych, modyfikacji konfiguracji oraz naruszenia separacji między tenantami. Producent poinformował, że nie są dostępne skuteczne obejścia, dlatego jedyną realną metodą ograniczenia ryzyka pozostaje szybkie wdrożenie poprawek.

  • Identyfikator podatności: CVE-2026-20223
  • Ocena ryzyka: CVSS 10.0
  • Typ problemu: niewłaściwa kontrola dostępu i uwierzytelniania w REST API
  • Możliwy skutek: dostęp administracyjny na poziomie Site Admin
  • Status mitigacji: brak obejść, konieczna aktualizacja

Kontekst / historia

Cisco Secure Workload jest wykorzystywane do ochrony obciążeń, mikrosegmentacji oraz egzekwowania polityk bezpieczeństwa w środowiskach hybrydowych i chmurowych. W takich platformach interfejsy REST API mają znaczenie krytyczne, ponieważ obsługują integracje z narzędziami zarządzania, automatyzacją i orkiestracją procesów bezpieczeństwa.

Według opublikowanych informacji podatność została wykryta podczas wewnętrznych testów bezpieczeństwa producenta. Cisco nie wskazało dowodów na aktywne wykorzystanie luki w środowiskach produkcyjnych, jednak charakter błędu i poziom możliwych uprawnień powodują, że luka może szybko stać się celem badań ofensywnych oraz prób automatycznej eksploatacji.

Problem dotyczy wydań 3.9 i starszych, a także linii 3.10 oraz 4.0. Poprawki zostały udostępnione odpowiednio w wersjach 3.10.8.3 i 4.0.3.17. Organizacje pozostające na starszej gałęzi 3.9 muszą zaplanować pilną migrację do wspieranej wersji zawierającej poprawkę bezpieczeństwa.

Analiza techniczna

Techniczne sedno podatności sprowadza się do niewystarczającej kontroli dostępu w wewnętrznych endpointach REST API. Oznacza to, że aplikacja nie egzekwowała poprawnie wymagań związanych z uwierzytelnieniem i autoryzacją dla części żądań kierowanych do podatnych interfejsów. W praktyce atakujący mógł uzyskać dostęp do funkcji, które powinny być zastrzeżone dla uprzywilejowanych użytkowników.

Tego rodzaju błąd jest szczególnie groźny w systemach wielodzierżawczych. Jeśli granice tenantów nie są wymuszane konsekwentnie na poziomie logiki API, ryzyko obejmuje nie tylko odczyt danych, ale także wykonywanie działań administracyjnych poza zakresem uprawnień. W przypadku CVE-2026-20223 skuteczna eksploatacja może prowadzić do operowania z przywilejami Site Admin, co znacząco zwiększa możliwy wpływ na środowisko.

Z perspektywy architektury bezpieczeństwa oznacza to potencjalne obejście klasycznych warstw ochronnych, takich jak segmentacja sieci czy filtrowanie ruchu. Jeżeli podatny interfejs API pozostaje osiągalny, brak skutecznego wymuszenia uwierzytelnienia i autoryzacji może sam w sobie otworzyć drogę do przejęcia uprzywilejowanej ścieżki operacyjnej. W środowiskach zintegrowanych z automatyzacją skutki mogą objąć zmianę polityk bezpieczeństwa, modyfikację konfiguracji oraz naruszenie integralności zarządzanych zasobów.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem luki jest możliwość nieautoryzowanego dostępu do wrażliwych informacji i wykonywania zmian konfiguracyjnych z bardzo wysokim poziomem uprawnień. W organizacjach korzystających z Secure Workload do segmentacji i egzekwowania polityk bezpieczeństwa może to doprowadzić do osłabienia kontroli między segmentami, utraty poufności danych oraz przygotowania gruntu pod dalszy ruch boczny napastnika.

Ryzyko jest szczególnie wysokie w środowiskach wielodzierżawczych, gdzie naruszenie separacji tenantów może przełożyć się na ekspozycję danych różnych jednostek biznesowych lub klientów. Dodatkowo możliwość wprowadzania zmian konfiguracyjnych przez nieuwierzytelnionego atakującego zwiększa ryzyko sabotażu operacyjnego, modyfikacji polityk egzekwowania ruchu, ukrywania śladów aktywności oraz przygotowania kolejnych etapów ataku.

Brak potwierdzonej aktywnej eksploatacji nie powinien usypiać czujności. Publiczne ujawnienie podatności zwykle skraca czas potrzebny na opracowanie exploitów oraz masowe skanowanie infrastruktury pod kątem podatnych instancji.

Rekomendacje

Organizacje korzystające z Cisco Secure Workload powinny niezwłocznie przeprowadzić inwentaryzację wszystkich instancji SaaS i on-premise oraz zweryfikować ich wersje. Systemy działające w gałęzi 3.10 należy zaktualizować co najmniej do wersji 3.10.8.3, a środowiska 4.0 do wersji 4.0.3.17. Instancje 3.9 i starsze powinny zostać objęte planem pilnej migracji do wspieranej wersji zawierającej poprawkę.

Do czasu pełnego wdrożenia aktualizacji warto ograniczyć ekspozycję operacyjną interfejsów zarządzających. Choć producent nie udostępnił obejść, działania kompensacyjne mogą zmniejszyć powierzchnię ataku i utrudnić wykorzystanie podatności.

  • Ograniczyć dostęp do interfejsów administracyjnych i API wyłącznie do zaufanych segmentów sieci.
  • Wdrożyć listy dozwolonych adresów oraz dodatkowe mechanizmy filtrowania ruchu tam, gdzie architektura na to pozwala.
  • Uruchomić wzmożony monitoring logów aplikacyjnych, żądań API oraz zmian konfiguracyjnych.
  • Zweryfikować operacje administracyjne wykonywane poza standardowymi oknami zmian.
  • Przeprowadzić retrospektywną analizę logów pod kątem oznak wcześniejszej eksploatacji.
  • Po aktualizacji wykonać przegląd integralności konfiguracji i polityk bezpieczeństwa.

Podsumowanie

CVE-2026-20223 to krytyczna luka w Cisco Secure Workload, której źródłem jest niewłaściwa kontrola dostępu do wewnętrznych endpointów REST API. Skuteczny atak może zapewnić nieuwierzytelnionemu napastnikowi szerokie uprawnienia administracyjne, w tym dostęp do danych i możliwość modyfikacji konfiguracji ponad granicami tenantów. Ponieważ nie istnieją obejścia, kluczowe znaczenie ma szybkie wdrożenie poprawek, ograniczenie dostępności interfejsów zarządzających oraz intensywny monitoring pod kątem nietypowych operacji API.

Źródła

  1. Cisco Secure Workload Unauthorized API Access Vulnerability
  2. NVD – CVE-2026-20223
  3. Cisco Patches CVSS 10.0 Secure Workload REST API Flaw Enabling Data Access
  4. Cisco fixed maximum severity flaw CVE-2026-20223 in Secure Workload

Grafana potwierdza kradzież kodu źródłowego po ataku supply chain na TanStack

Cybersecurity news

Wprowadzenie do problemu / definicja

Ataki na łańcuch dostaw oprogramowania należą dziś do najgroźniejszych scenariuszy bezpieczeństwa, ponieważ pozwalają napastnikom ominąć bezpośrednie zabezpieczenia ofiary i uderzyć w zależności, procesy automatyzacji lub narzędzia deweloperskie. Incydent dotyczący Grafana Labs i ekosystemu TanStack pokazuje, że nawet szybka reakcja organizacji może okazać się niewystarczająca, jeśli choć jeden token lub element pipeline’u pozostanie aktywny.

W omawianym przypadku skutkiem ataku było nieautoryzowane pobranie publicznego i prywatnego kodu źródłowego oraz części wewnętrznych repozytoriów zawierających informacje operacyjne i biznesowe. Firma podkreśliła jednak, że nie ma dowodów na naruszenie środowisk produkcyjnych ani platformy Grafana Cloud.

W skrócie

  • Grafana wykryła złośliwą aktywność 11 maja 2026 roku.
  • Incydent był powiązany z atakiem supply chain wymierzonym w pakiety TanStack.
  • Podczas reakcji rotowano tokeny workflow w GitHubie, ale jeden z nich nie został unieważniony.
  • Napastnicy wykorzystali pominięty token do uzyskania dostępu do repozytoriów organizacji.
  • Skradziono kod źródłowy oraz wybrane wewnętrzne repozytoria z danymi operacyjnymi i kontaktowymi.
  • Grafana odmówiła zapłaty okupu po otrzymaniu żądania 16 maja 2026 roku.

Kontekst / historia

Tłem incydentu była szersza kampania wymierzona w ekosystemy NPM i PyPI, przypisywana rodzinie Mini Shai-Hulud. Atakujący wykorzystywali złośliwe pakiety oraz mechanizmy samopropagacji do pozyskiwania tokenów, sekretów i innych danych uwierzytelniających obecnych w środowiskach deweloperskich.

Grafana poinformowała, że 11 maja 2026 roku wykryła aktywność związaną z tym atakiem i rozpoczęła działania ograniczające, w tym rotację tokenów GitHub workflow. Późniejsza analiza wykazała jednak, że jeden z workflowów, początkowo uznany za bezpieczny, również został skompromitowany. To właśnie ten nieuwzględniony token umożliwił wtórny dostęp do repozytoriów.

Sytuacja eskalowała 16 maja 2026 roku, gdy organizacja otrzymała żądanie okupu pod groźbą ujawnienia pobranego kodu źródłowego. Firma odmówiła zapłaty, rozszerzyła działania reagowania oraz powiadomiła organy ścigania.

Analiza techniczna

Z technicznego punktu widzenia incydent pokazuje typowy łańcuch przejścia od kompromitacji zależności do naruszenia procesów CI/CD i zasobów deweloperskich. Kluczową rolę odegrały tokeny automatyzacji wykorzystywane przez workflowy GitHub Actions lub pokrewne mechanizmy integracyjne. Jeśli taki token zostanie przejęty przez złośliwy kod uruchomiony w środowisku programistycznym lub buildowym, może otworzyć drogę do repozytoriów, sekretów, artefaktów i konfiguracji.

Atak można podzielić na trzy etapy. Najpierw doszło do kompromitacji w łańcuchu dostaw związanej z pakietami TanStack. Następnie napastnicy uzyskali dostęp do tokenów workflow. W końcu wykorzystali co najmniej jeden nieodwołany token do wejścia do środowiska GitHub Grafany i pobrania zawartości repozytoriów.

Szczególnie istotny jest wymiar operacyjny tej sytuacji. Częściowa rotacja sekretów nie zapewnia pełnego bezpieczeństwa, jeśli organizacja korzysta z wielu workflowów, integracji botów, kluczy i poświadczeń aplikacyjnych. Wystarczy pominięcie jednego uprzywilejowanego elementu, aby utrzymać aktywny dostęp dla atakującego.

Z dostępnych informacji wynika, że zakres naruszenia ograniczył się do środowiska GitHub. Nie potwierdzono modyfikacji kodu ani przejścia napastników do produkcji, jednak sam wyciek prywatnego kodu źródłowego i repozytoriów wewnętrznych stanowi poważny problem. Tego typu zasoby mogą zawierać informacje o architekturze, integracjach, wzorcach wdrożeniowych, konfiguracji i organizacji środowiska.

Konsekwencje / ryzyko

Najważniejszą konsekwencją incydentu jest utrata poufności kodu źródłowego oraz danych operacyjnych. Nawet jeśli atakujący nie zmodyfikowali kodu i nie uzyskali dostępu do systemów produkcyjnych, pozyskane repozytoria mogą zostać wykorzystane do przyszłych kampanii rozpoznawczych i ukierunkowanych ataków.

Ryzyko obejmuje również działania następcze wobec pracowników i partnerów. Skradzione służbowe dane kontaktowe mogą zostać użyte w kampaniach spear phishingowych, próbach wyłudzeń BEC, podszywaniu się pod personel techniczny lub w kolejnych próbach zdobycia dostępu do infrastruktury.

Z perspektywy klientów i społeczności open source komunikat ma częściowo uspokajający charakter, ponieważ brak jest dowodów na wpływ na produkcję oraz na modyfikację kodu. Nie oznacza to jednak pełnego braku zagrożenia. Każdy incydent obejmujący środowisko deweloperskie powinien skutkować wzmożonym monitoringiem integralności kodu, buildów, release’ów i pochodzenia artefaktów.

Rekomendacje

Incydent w Grafana Labs to ważna lekcja dla organizacji korzystających z GitHub Actions, NPM, PyPI i rozbudowanych pipeline’ów CI/CD. Ochrona łańcucha dostaw musi obejmować nie tylko zależności, ale również sekrety i tożsamości maszynowe.

  • Przeprowadzić pełną inwentaryzację tokenów, kluczy, sekretów repozytoryjnych i organizacyjnych.
  • Ograniczać uprawnienia tokenów zgodnie z zasadą najmniejszych uprawnień.
  • Stosować poświadczenia krótkotrwałe i federację tożsamości zamiast sekretów długowiecznych.
  • Monitorować anomalie w repozytoriach i workflowach, w tym nietypowe klonowania i uruchomienia pipeline’ów.
  • Przygotować procedurę pełnego resetu poświadczeń obejmującą potwierdzenie unieważnienia każdego sekretu.
  • Wzmacniać integralność łańcucha dostaw poprzez pinning zależności, weryfikację podpisów, SBOM i attestation buildów.

Szczególną uwagę należy zwrócić na zależności transitywne oraz środowiska deweloperskie, które mają szeroki dostęp do sekretów chmurowych i repozytoryjnych. To właśnie tam często pojawiają się najcenniejsze dla napastników punkty zaczepienia.

Podsumowanie

Przypadek Grafana Labs pokazuje, że współczesny atak supply chain nie kończy się na złośliwym pakiecie. Jego prawdziwym celem są często tokeny automatyzacji, sekrety i uprzywilejowane procesy CI/CD, które umożliwiają dostęp do kodu źródłowego i danych operacyjnych.

W tym incydencie o skali naruszenia przesądziło pominięcie pojedynczego tokenu podczas reakcji. To wystarczyło, by napastnicy pobrali kod i zażądali okupu. Dla całej branży to kolejne ostrzeżenie, że bezpieczeństwo łańcucha dostaw musi obejmować pełną kontrolę nad sekretami, monitoring tożsamości maszynowych oraz rygorystyczne uszczelnienie środowisk deweloperskich.

Źródła

  1. Grafana Labs security update: Latest on TanStack npm supply chain ransomware incident
  2. Grafana Says Codebase and Other Data Stolen via TanStack Supply Chain Attack
  3. Malware in @tanstack/* packages exfiltrates cloud credentials, GitHub tokens, and SSH keys

BYOVD bez sprzętu: podatne sterowniki Windows nadal mogą być osiągalne i groźne

Cybersecurity news

Wprowadzenie do problemu / definicja

Technika BYOVD, czyli Bring Your Own Vulnerable Driver, polega na wykorzystaniu legalnie podpisanego, ale podatnego sterownika systemu Windows do uzyskania dostępu na poziomie jądra, eskalacji uprawnień lub obejścia mechanizmów ochronnych. Najnowsze analizy pokazują, że część takich sterowników może pozostać dostępna z poziomu user mode nawet wtedy, gdy w systemie nie ma fizycznego urządzenia, dla którego zostały zaprojektowane.

To istotna zmiana w postrzeganiu ryzyka. Dotychczas brak sprzętu często uznawano za naturalną barierę ograniczającą możliwość wykorzystania luki. W praktyce okazuje się jednak, że sposób inicjalizacji sterownika, logika Plug and Play oraz tworzenie obiektów urządzeń mogą pozwolić na osiągnięcie podatnej ścieżki kodu również bez obecności odpowiadającego mu hardware.

W skrócie

Badacze opisali, w jaki sposób oceniać, czy podatny sterownik Windows da się wykorzystać bez podłączonego urządzenia. Kluczowe znaczenie ma to, czy sterownik tworzy obiekt urządzenia bezwarunkowo, warunkowo czy dopiero po enumeracji sprzętu przez mechanizmy PnP.

  • Brak fizycznego urządzenia nie zawsze eliminuje możliwość eksploatacji sterownika.
  • Istotne są szczegóły implementacyjne, a nie tylko sama klasa podatności.
  • Atakujący mogą próbować sztucznie odtworzyć warunki inicjalizacji sterownika.
  • BYOVD pozostaje ważnym narzędziem do obchodzenia EDR, self-protection i eskalacji uprawnień.

Kontekst / historia

BYOVD od lat jest jednym z najważniejszych wektorów post-exploitation w środowisku Windows. Atakujący wykorzystują legalne i podpisane sterowniki z lukami, ponieważ kod wykonywany w kernel mode daje możliwości niedostępne dla zwykłych procesów użytkownika. W praktyce obejmuje to między innymi arbitralny odczyt i zapis pamięci, manipulację uchwytami, kończenie procesów oraz obchodzenie mechanizmów integralności i ochrony narzędzi bezpieczeństwa.

Przez długi czas analiza ryzyka koncentrowała się głównie na rodzaju podatności, na przykład na tym, czy dany sterownik umożliwia arbitrary kernel read/write. Mniej uwagi poświęcano temu, czy podatny kod jest faktycznie osiągalny na konkretnym systemie. Najnowsze badania przesuwają punkt ciężkości właśnie na exploitable path, czyli realną możliwość uruchomienia podatnej funkcjonalności w środowisku, w którym nie występuje dedykowany sprzęt.

Z perspektywy obrony ma to duże znaczenie. Microsoft rozwija mechanizmy ograniczające uruchamianie znanych podatnych sterowników, w tym rekomendowane reguły blokowania oraz ochrony związane z integralnością kodu. Mimo to ekosystem Windows nadal zawiera dużą liczbę starszych, niszowych lub historycznych sterowników, które mogą zostać wykorzystane przez operatorów ransomware i grupy intrusion do realizacji działań na poziomie jądra.

Analiza techniczna

Sedno problemu sprowadza się do pytania, kiedy i w jaki sposób sterownik tworzy device object oraz czy jego logika inicjalizacji wymaga obecności konkretnego urządzenia. W najprostszym wariancie sterownik tworzy obiekt urządzenia już podczas wykonania procedury inicjalizacyjnej. W takiej sytuacji samo załadowanie sterownika może wystarczyć, aby proces użytkownika uzyskał dostęp do interfejsu I/O i wywoływał żądania prowadzące do wykonania podatnego kodu.

Częściej spotykany jest jednak model warunkowy. Sterownik może sprawdzać określone klucze rejestru, artefakty instalacyjne, stan środowiska lub oczekiwać, że odpowiednia ścieżka zostanie aktywowana przez Plug and Play. W sterownikach PnP kluczową rolę odgrywają mechanizmy takie jak AddDevice, obsługa żądań PnP oraz tworzenie obiektów urządzeń funkcyjnych i filtrujących. To właśnie w tych momentach mogą powstawać struktury i interfejsy niezbędne do późniejszego wywołania podatnej funkcji.

Z punktu widzenia exploitability oznacza to, że sam plik sterownika nie zawsze stanowi natychmiastową ścieżkę ataku. Atakujący może jednak próbować doprowadzić do spełnienia warunków inicjalizacji. Jedną z metod jest utworzenie programowo emulowanego urządzenia z odpowiednim identyfikatorem sprzętowym, tak aby system skojarzył sterownik z nowym węzłem urządzenia. Innym podejściem może być manipulacja logiką filtrowania lub stosem urządzeń w celu osiągnięcia pożądanego fragmentu kodu bez fizycznego hardware.

W części przypadków dostępność interfejsu I/O może być krótkotrwała. Sterownik może utworzyć obiekt urządzenia, a następnie usunąć go po wykryciu braku zgodnego sprzętu. Taka sytuacja tworzy bardzo wąskie okno czasowe przypominające race condition, ale z perspektywy ofensywnej nadal może wystarczyć do wysłania odpowiednio przygotowanego żądania DeviceIoControl.

Dodatkowym utrudnieniem dla atakującego jest aktywne odpytywanie sprzętu. Jeżeli sterownik wykonuje rzeczywiste operacje komunikacyjne z magistralą lub urządzeniem końcowym, emulacja staje się bardziej złożona. Nie oznacza to jednak automatycznie, że wykorzystanie luki jest niemożliwe. W niektórych przypadkach wystarcza częściowa inicjalizacja i samo wystawienie osiągalnego obiektu urządzenia.

Konsekwencje / ryzyko

Najważniejszy wniosek jest praktyczny: podatność sterownika nie przestaje być istotna tylko dlatego, że dane urządzenie nie jest podłączone do komputera. Jeśli napastnik może załadować podatny sterownik i doprowadzić do utworzenia dostępnego interfejsu I/O, zyskuje potencjalny kanał do wykonywania operacji jądrowych, wyłączenia mechanizmów ochronnych lub lokalnej eskalacji uprawnień.

To wpływa na sposób priorytetyzacji zagrożeń. W wielu organizacjach przyjmuje się, że specjalistyczne sterowniki sprzętowe stanowią ryzyko wyłącznie na stacjach, na których faktycznie występuje określone urządzenie. Opisana perspektywa pokazuje, że ekspozycja może obejmować znacznie szerszy zakres systemów, jeżeli możliwe jest sztuczne odtworzenie warunków inicjalizacji sterownika.

Ryzyko rośnie szczególnie wtedy, gdy atakujący ma już uprawnienia administratora lokalnego. W takim scenariuszu BYOVD staje się narzędziem do przejścia z kontekstu administracyjnego do operacji w jądrze, neutralizacji EDR, ukrycia aktywności i przygotowania środowiska pod kolejne etapy ataku. Jest to model dobrze znany z nowoczesnych kampanii ransomware oraz działań grup wykorzystujących signed drivers do obejścia zabezpieczeń endpointów.

Rekomendacje

Organizacje powinny traktować sterowniki jako wysokowartościową powierzchnię ataku niezależnie od tego, czy odpowiadające im urządzenia fizycznie występują w środowisku. Inwentaryzacja powinna obejmować nie tylko aktywne urządzenia, ale również zainstalowane pakiety sterowników, usługi kernel mode, elementy driver store oraz historyczne pozostałości po oprogramowaniu producentów.

  • Włączyć i egzekwować listy blokowania znanych podatnych sterowników.
  • Utrzymywać ochrony integralności kodu, w tym mechanizmy takie jak HVCI, tam gdzie pozwala na to zgodność środowiska.
  • Ograniczać możliwość ładowania nowych sterowników przez ścisłą kontrolę uprawnień administracyjnych i polityki application control.
  • Monitorować tworzenie oraz uruchamianie usług typu kernel driver.
  • Wykrywać nietypowe użycie narzędzi i interfejsów związanych z instalacją sterowników, takich jak sc.exe, INF i SetupAPI.
  • Korelować zdarzenia dotyczące tworzenia urządzeń programowych i zmian w stosach urządzeń.
  • Porównywać lokalne sterowniki z publicznymi bazami known vulnerable drivers oraz komponentów nadużywanych w incydentach.

Z perspektywy SOC i DFIR warto rozszerzyć detekcję o sytuacje, w których w systemie pojawia się sterownik producenta urządzeń nieużywanych w organizacji. Podejrzane mogą być także krótkotrwałe obiekty urządzeń, nietypowe wywołania DeviceIoControl kierowane do sterowników firm trzecich oraz zdarzenia blokowania przez polityki integralności kodu.

Dla zespołów hardeningowych ważne jest również testowanie odporności na BYOVD w warunkach laboratoryjnych. Sama obecność podatnego sterownika na dysku lub w magazynie sterowników powinna być traktowana jako potencjalny problem bezpieczeństwa, szczególnie jeśli dany komponent figuruje na listach znanych podatnych sterowników albo ma historię nadużyć w realnych operacjach ofensywnych.

Podsumowanie

Analiza osiągalności podatnych sterowników bez fizycznego sprzętu pokazuje, że realna powierzchnia ataku BYOVD jest szersza, niż zakładano w uproszczonym modelu opartym wyłącznie na obecności urządzenia. O możliwości wykorzystania luki decydują przede wszystkim szczegóły implementacyjne: moment tworzenia device object, zależność od PnP, warunki inicjalizacji i ewentualna potrzeba aktywnej komunikacji ze sprzętem.

Dla obrońców oznacza to konieczność odejścia od założenia, że brak hardware automatycznie neutralizuje zagrożenie. Skuteczna strategia ochrony wymaga blokowania znanych podatnych sterowników, kontroli ładowania kodu jądra, monitorowania nietypowych instalacji driverów oraz regularnego usuwania zbędnych komponentów kernel mode z systemów Windows.

Źródła

  1. https://thehackernews.com/2026/05/making-vulnerable-drivers-exploitable.html
  2. https://atos.net/en/lp/cybershield/making-vulnerable-drivers-exploitable-without-hardware-the-byovd-perspective
  3. https://learn.microsoft.com/en-us/windows/security/application-security/application-control/windows-defender-application-control/design/microsoft-recommended-driver-block-rules
  4. https://support.microsoft.com/en-us/windows/device-security-in-the-windows-security-app-afa11526-de57-b1c5-599f-3a4c6a61c5e2
  5. https://www.loldrivers.io/

Megalodon: masowy atak na GitHub z użyciem złośliwych workflow CI/CD

Cybersecurity news

Wprowadzenie do problemu / definicja

Megalodon to kampania wymierzona w łańcuch dostaw oprogramowania, której celem były repozytoria GitHub oraz mechanizmy automatyzacji GitHub Actions. Atak nie koncentrował się na klasycznym wstrzykiwaniu złośliwego kodu do aplikacji, lecz na przejęciu kontroli nad procesem budowania, testowania i publikacji poprzez dodawanie złośliwych workflow CI/CD.

To szczególnie groźny model działania, ponieważ pipeline’y często mają dostęp do sekretów, tokenów chmurowych, kluczy SSH i uprawnień publikacyjnych. Kompromitacja workflow może więc prowadzić nie tylko do wycieku danych, ale także do publikacji zainfekowanych artefaktów pod marką legalnego dostawcy.

W skrócie

Badacze opisali zautomatyzowaną kampanię, w ramach której w ciągu około sześciu godzin do tysięcy repozytoriów GitHub trafiły tysiące złośliwych commitów. Atakujący podszywali się pod techniczne tożsamości przypominające boty CI i umieszczali w commitach workflow GitHub Actions zawierające zakodowany ładunek bash odpowiedzialny za eksfiltrację wrażliwych danych z runnerów.

  • Kampania objęła 5561 repozytoriów i 5718 złośliwych commitów.
  • Zaobserwowano wariant masowy oraz wariant ukierunkowany.
  • Celem były m.in. sekrety środowiskowe, tokeny OIDC, poświadczenia chmurowe i klucze SSH.
  • Jeden z nagłośnionych przypadków dotyczył procesu publikacji pakietu @tiledesk/tiledesk-server.

Kontekst / historia

Megalodon wpisuje się w rosnący trend ataków supply chain wymierzonych w ekosystemy open source i platformy deweloperskie. W tego typu operacjach napastnicy wykorzystują zależności między repozytoriami, systemami CI/CD i rejestrami pakietów, aby przejść od pojedynczej kompromitacji do szerszego skażenia procesu dostarczania oprogramowania.

W opisywanym przypadku złośliwe commity zostały rozesłane masowo 18 maja 2026 roku. Operacja wyróżniała się wysoką automatyzacją, ujednoliconymi komunikatami commitów oraz próbą nadania zmianom pozorów rutynowej konserwacji pipeline’ów, co mogło utrudniać ich ręczne wykrycie podczas przeglądu zmian.

Analiza techniczna

Rdzeń ataku polegał na modyfikacji plików workflow odpowiedzialnych za GitHub Actions. Zamiast jawnego kodu do kradzieży sekretów, atakujący wykorzystywali payload bash zakodowany w Base64, co utrudniało szybką identyfikację złośliwego działania podczas pobieżnego przeglądu commitów.

Według opisu incydentu malware zbierał m.in. zmienne środowiskowe procesu CI, poświadczenia AWS i Google Cloud, tokeny OIDC, klucze prywatne SSH, konfiguracje Docker i Kubernetes, tokeny Vault, dane Terraform, historię poleceń powłoki oraz inne sekrety wykrywane na podstawie wzorców. Szczególnie niebezpieczne było przejmowanie tokenów używanych w procesach automatycznego publikowania i integracji z usługami chmurowymi.

Badacze rozróżnili dwa warianty ładunku. Wariant masowy, określany jako SysDiag, dodawał workflow uruchamiany przy zdarzeniach push i pull request. Wariant ukierunkowany, nazwany Optimize-Build, korzystał z triggera workflow_dispatch, dzięki czemu mógł być aktywowany ręcznie i pozostawać mniej widoczny w codziennej pracy zespołu.

Najgroźniejszy scenariusz pojawia się wtedy, gdy zainfekowana zmiana zostaje zaakceptowana jako pozornie nieszkodliwa poprawka CI. Po uruchomieniu workflow złośliwy kod działa w zaufanym kontekście pipeline’u, a więc często z dostępem do sekretów organizacyjnych, tożsamości chmurowych oraz procesów publikacji pakietów i artefaktów.

Konsekwencje / ryzyko

Ryzyko związane z Megalodon ma charakter wielowarstwowy. Atak może prowadzić do kradzieży sekretów CI/CD, ruchów bocznych w środowiskach chmurowych, przejęcia kont projektowych, modyfikacji release’ów oraz publikacji złośliwych pakietów. W skrajnym przypadku kompromitacja pojedynczego repozytorium staje się punktem wyjścia do naruszenia całego łańcucha wydawniczego.

Dla organizacji utrzymujących wiele repozytoriów szczególnie niebezpieczne jest współdzielenie sekretów oraz nadmierne uprawnienia workflow. Jeżeli pipeline’y mają szeroki dostęp do zasobów, atak nie musi wykorzystywać klasycznej podatności aplikacyjnej. Wystarczy skutecznie wprowadzić workflow imitujący optymalizację lub konserwację CI, a następnie uruchomić go w zaufanym środowisku.

Rekomendacje

Organizacje powinny traktować pliki workflow CI/CD jako zasoby wysokiego ryzyka i objąć je równie rygorystyczną kontrolą jak kod odpowiedzialny za uwierzytelnianie czy kryptografię. Każda zmiana w katalogach workflow powinna wymagać obowiązkowego review przez zaufanych maintainerów oraz ochrony za pomocą reguł CODEOWNERS i zabezpieczeń gałęzi.

Kluczowe znaczenie ma także ograniczanie uprawnień zgodnie z zasadą najmniejszych przywilejów. Dotyczy to zakresów GITHUB_TOKEN, dostępu do sekretów repozytorium, środowisk wdrożeniowych oraz federacji OIDC. Warto jawnie definiować minimalne permissions w plikach workflow i usuwać nieużywane sekrety z poziomu repozytoriów oraz organizacji.

Niezbędne jest monitorowanie zmian w GitHub Actions pod kątem anomalii, takich jak użycie Base64, poleceń pobierających dane z nieznanych hostów, prób dostępu do usług metadanych chmurowych, odczytu plików z katalogów domowych runnera czy masowej enumeracji zmiennych środowiskowych.

  • blokowanie auto-merge dla zmian modyfikujących workflow,
  • wymuszanie podpisywania commitów i walidacji tożsamości autorów,
  • izolacja runnerów oraz segmentacja środowisk buildowych,
  • rotacja sekretów i audyt poświadczeń po incydencie,
  • skanowanie artefaktów release i pakietów przed publikacją,
  • centralne logowanie oraz alertowanie dla zdarzeń workflow_dispatch i zmian uprawnień.

W środowiskach publikujących pakiety warto ograniczać użycie długowiecznych tokenów na rzecz krótkotrwałych poświadczeń federacyjnych. Modele oparte na OIDC zmniejszają ryzyko wykorzystania statycznych tokenów skradzionych z runnerów lub logów.

Podsumowanie

Megalodon pokazuje, że współczesne ataki supply chain coraz częściej uderzają bezpośrednio w mechanizmy automatyzacji DevOps. Masowe wstrzykiwanie złośliwych workflow do tysięcy repozytoriów zwiększa skalę zagrożenia, ponieważ kompromitacja pipeline’u otwiera drogę do przejęcia sekretów, tożsamości chmurowych i procesów publikacji.

Dla zespołów bezpieczeństwa oznacza to konieczność traktowania CI/CD jako krytycznej powierzchni ataku. Ochrona workflow, redukcja uprawnień, stosowanie krótkotrwałych poświadczeń oraz ścisła kontrola zmian w pipeline’ach powinny stać się standardem w nowoczesnym procesie wytwarzania oprogramowania.

Źródła

  1. https://thehackernews.com/2026/05/megalodon-github-attack-targets-5561.html
  2. https://safedep.io/megalodon-mass-github-repo-backdooring-ci-workflows
  3. https://docs.github.com/en/actions/how-tos/manage-workflow-runs/manually-run-a-workflow
  4. https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions?azure-portal=true
  5. https://docs.npmjs.com/trusted-publishers/

CISA dodaje exploity Langflow i Trend Micro Apex One do katalogu KEV

Cybersecurity news

Wprowadzenie do problemu / definicja

Agencja CISA rozszerzyła katalog Known Exploited Vulnerabilities o dwie podatności aktywnie wykorzystywane w rzeczywistych atakach: CVE-2025-34291 w Langflow oraz CVE-2026-34926 w Trend Micro Apex One. Samo umieszczenie luki w katalogu KEV oznacza, że zagrożenie zostało potwierdzone operacyjnie i powinno być traktowane jako priorytet w procesie zarządzania podatnościami.

Sprawa jest istotna, ponieważ dotyczy dwóch różnych klas technologii. Langflow funkcjonuje w szybko rosnącym obszarze narzędzi AI i automatyzacji workflow, natomiast Trend Micro Apex One należy do centralnych systemów ochrony endpointów, których kompromitacja może mieć konsekwencje dla całej organizacji.

W skrócie

  • CISA dodała do KEV podatności CVE-2025-34291 oraz CVE-2026-34926.
  • CVE-2025-34291 w Langflow może prowadzić do zdalnego wykonania kodu i przejęcia instancji.
  • CVE-2026-34926 w Trend Micro Apex One dotyczy obejścia ograniczeń z wykorzystaniem path traversal w środowiskach on-premise.
  • W przypadku Apex One skutkiem może być wstrzyknięcie złośliwego kodu dystrybuowanego następnie do agentów.
  • Dodanie obu luk do KEV oznacza konieczność pilnej remediacji i przeglądu ekspozycji środowiska.

Kontekst / historia

Katalog KEV pełni praktyczną rolę w priorytetyzacji podatności, które nie tylko istnieją, ale zostały już wykorzystane przez napastników. Dla zespołów bezpieczeństwa to ważny sygnał, że ryzyko nie jest hipotetyczne i może wymagać natychmiastowych działań naprawczych, nawet jeśli luka wcześniej była traktowana jako element standardowego backlogu patch managementu.

W przypadku Langflow problem był wcześniej opisywany jako połączenie błędów projektowych i konfiguracyjnych. Taki model zagrożenia jest szczególnie groźny w środowiskach AI, ponieważ platformy orkiestrujące przepływy pracy często przechowują tokeny API, dane integracyjne oraz konfiguracje łączące wiele usług w jednym miejscu.

Trend Micro Apex One reprezentuje inny scenariusz. Tu luka dotyczy wdrożeń lokalnych i wymaga wcześniejszego dostępu do serwera zarządzającego oraz odpowiednich uprawnień. Mimo wyższego progu wejścia skutki potencjalnej kompromitacji są bardzo poważne, ponieważ atak obejmuje system centralnie sterujący agentami bezpieczeństwa na stacjach końcowych.

Analiza techniczna

CVE-2025-34291 w Langflow nie sprowadza się do pojedynczego błędu, lecz do łańcucha podatności zwiększających wzajemnie swój wpływ. W opisywanym scenariuszu kluczową rolę odgrywa nadmiernie liberalna konfiguracja CORS, brak skutecznej ochrony CSRF oraz endpoint umożliwiający wykonanie kodu. Taka kombinacja pozwala doprowadzić do nieautoryzowanych żądań i wykorzystać logikę aplikacji do przejęcia instancji.

Z perspektywy technicznej szczególnie niebezpieczne jest to, że platformy AI często pełnią funkcję koncentratora integracji. Jeśli napastnik uzyska dostęp do środowiska Langflow, może potencjalnie przejąć nie tylko samą aplikację, ale również sekrety, konfiguracje workflow, poświadczenia do usług zewnętrznych i dostęp do kolejnych komponentów infrastruktury.

CVE-2026-34926 w Trend Micro Apex One została opisana jako podatność typu directory traversal w wersji on-premise. Według dostępnych informacji atak zakłada wcześniejsze uzyskanie dostępu do serwera oraz uprawnień administracyjnych. Następnie możliwa staje się modyfikacja kluczowych elementów wykorzystywanych przez serwer do dystrybucji komponentów i polityk, co może doprowadzić do rozesłania złośliwego kodu do agentów.

Ten model zagrożenia jest szczególnie groźny, ponieważ odwraca podstawową funkcję narzędzia bezpieczeństwa. Zamiast chronić stacje robocze i serwery, przejęta platforma zarządzająca może zostać wykorzystana jako zaufany kanał dostarczania ładunku do wielu hostów jednocześnie.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem exploitu w Langflow jest możliwość pełnego przejęcia instancji oraz kradzieży sekretów aplikacyjnych. W praktyce może to oznaczać nadużycie kluczy API, przejęcie kont usługowych, dostęp do danych użytkowników, a także dalszą penetrację środowisk chmurowych i systemów zintegrowanych z platformą AI.

W przypadku Apex One zagrożenie ma bardziej uprzywilejowany charakter, ale może objąć znacznie większy obszar infrastruktury. Naruszenie serwera zarządzającego agentami ochrony endpointów stwarza ryzyko szybkiej propagacji złośliwego kodu, utrzymania persystencji i ruchu bocznego z wykorzystaniem zaufanego komponentu działającego zwykle z wysokimi uprawnieniami.

Znaczenie operacyjne rośnie dodatkowo po dodaniu obu luk do KEV. To wyraźny sygnał, że organizacje powinny traktować je jako pilny priorytet remediacyjny, a nie element długoterminowego planu aktualizacji.

Rekomendacje

Organizacje korzystające z Langflow powinny zidentyfikować wszystkie wdrożone instancje, zweryfikować ich wersje oraz niezwłocznie zastosować dostępne poprawki. Równolegle warto przeanalizować konfigurację CORS, mechanizmy sesyjne i ochronę przed CSRF, a także ograniczyć ekspozycję interfejsów administracyjnych do sieci zaufanych.

W środowiskach, gdzie Langflow przechowuje tokeny i klucze dostępu do usług zewnętrznych, należy rozważyć natychmiastową rotację sekretów, jeśli istnieje choćby podejrzenie nieautoryzowanego dostępu. Dobrym krokiem jest również segmentacja sieci oraz ograniczenie możliwości wykonywania kodu wyłącznie do ściśle kontrolowanych scenariuszy.

W przypadku Trend Micro Apex One kluczowe znaczenie ma pilne wdrożenie poprawek producenta i ograniczenie dostępu do serwera zarządzającego. System nie powinien być wystawiony do internetu, a dostęp administracyjny powinien być chroniony dodatkowymi warstwami kontroli, takimi jak segmentacja, listy kontroli dostępu i silne uwierzytelnianie.

W obu przypadkach warto przeprowadzić działania huntingowe i przegląd logów pod kątem nietypowych żądań administracyjnych, zmian konfiguracji, nieautoryzowanego uruchamiania kodu oraz anomalii w komunikacji agentów i usług zależnych.

  • Zidentyfikować wszystkie podatne instancje i serwery.
  • Wdrożyć poprawki oraz środki kompensacyjne bez zbędnej zwłoki.
  • Ograniczyć ekspozycję interfejsów zarządzających.
  • Rotować sekrety i poświadczenia po potencjalnej kompromitacji.
  • Monitorować integralność konfiguracji oraz kanałów dystrybucji do agentów.

Podsumowanie

Dodanie CVE-2025-34291 i CVE-2026-34926 do katalogu KEV pokazuje, że aktywnie wykorzystywane podatności obejmują dziś zarówno nowoczesne platformy AI, jak i klasyczne systemy bezpieczeństwa zarządzane centralnie. W obu przypadkach skutki kompromitacji wykraczają poza pojedynczy host i mogą prowadzić do przejęcia sekretów, eskalacji dostępu oraz szerokiej dystrybucji złośliwego kodu.

Dla zespołów bezpieczeństwa to kolejny sygnał, że priorytetyzacja łatania musi obejmować nie tylko systemy brzegowe, lecz także aplikacje AI, narzędzia orkiestracji oraz platformy odpowiadające za ochronę endpointów w całej organizacji.

Źródła