Wojciech Ciemski, Autor w serwisie Security Bez Tabu

Anthropic i Mythos: AI wykryło ponad 23 tys. potencjalnych luk w projektach open source

Wprowadzenie do problemu / definicja

Automatyczne wykrywanie podatności z wykorzystaniem modeli sztucznej inteligencji wchodzi na nowy poziom dojrzałości. Anthropic poinformował, że model Claude Mythos Preview zidentyfikował ponad 23 tysiące potencjalnych podatności w przeszło tysiącu projektów open source. To ważny sygnał dla całej branży, ponieważ pokazuje zarówno rosnącą skuteczność narzędzi AI w analizie kodu, jak i skalę problemów bezpieczeństwa obecnych w powszechnie używanych komponentach.

Znaczenie tej informacji wykracza poza pojedynczy eksperyment technologiczny. Projekty open source stanowią fundament nowoczesnych aplikacji, usług chmurowych i narzędzi deweloperskich, dlatego każda poprawa w tempie identyfikacji luk może istotnie wpłynąć na bezpieczeństwo całego łańcucha dostaw oprogramowania.

W skrócie

Anthropic podał, że Mythos wykrył ponad 23 tysiące potencjalnych podatności w ponad 1000 projektach OSS.
Spośród 1900 wyników poddanych zewnętrznej weryfikacji potwierdzono 1726 przypadków.
Ponad 1000 potwierdzonych problemów oceniono jako luki wysokiego lub krytycznego ryzyka.
Firma szacuje, że liczba potwierdzonych podatności wysokiego i krytycznego poziomu może sięgnąć około 3900, a docelowo nawet 6200.
Do tej pory zgłoszono dostawcom ponad 1100 niezweryfikowanych ustaleń, załatano 75 problemów wysokiej lub krytycznej wagi, a producenci opublikowali 65 biuletynów bezpieczeństwa.

Kontekst / historia

W ostatnich latach modele AI coraz częściej trafiają do procesów AppSec i vulnerability research. Narzędzia tego typu uzupełniają klasyczne metody, takie jak analiza statyczna, fuzzing, testy dynamiczne czy ręczne przeglądy kodu. Ich przewagą jest skala działania, ponieważ mogą analizować ogromne zbiory repozytoriów i szybciej wskazywać miejsca wymagające uwagi analityków.

Mythos Preview jest udostępniany wybranym organizacjom w ramach programu Project Glasswing. Kontrolowany model dostępu ma ograniczać ryzyko nadużyć, ponieważ technologia zdolna do szybkiego wyszukiwania podatności może wspierać nie tylko obronę, ale również działania ofensywne. To ważny element dyskusji o bezpieczeństwie modeli AI wykorzystywanych w cyberbezpieczeństwie.

Wyniki testów nie były jednak jednolite dla wszystkich projektów. W części dojrzałych repozytoriów open source liczba wykrytych problemów była relatywnie niewielka, co sugeruje, że skuteczność takich systemów zależy od jakości kodu, architektury aplikacji oraz dojrzałości procesu bezpieczeństwa prowadzonego przez maintainerów.

Analiza techniczna

Najważniejszy nie jest sam wolumen wykryć, lecz różnica między potencjalnym ustaleniem a podatnością realnie potwierdzoną. Systemy AI analizujące kod źródłowy zazwyczaj identyfikują wzorce mogące wskazywać na naruszenie założeń bezpieczeństwa, takie jak błędna walidacja danych wejściowych, ryzykowne operacje na pamięci, problemy z kontrolą uprawnień, nieprawidłowe granice zaufania czy niebezpieczne ścieżki wykonania.

Następnie takie ustalenia wymagają triage, korelacji oraz ręcznej lub zautomatyzowanej walidacji. W przypadku Mythos istotne jest to, że część wyników została zweryfikowana przez zewnętrzne firmy bezpieczeństwa. Ogranicza to typowy problem rozwiązań AI, czyli wysoki poziom fałszywych alarmów. Skoro z 1900 sprawdzonych przypadków potwierdzono 1726, to oznacza bardzo wysoką skuteczność w badanej próbce i realną wartość operacyjną dla zespołów bezpieczeństwa.

Anthropic zwrócił również uwagę, że liczba potwierdzonych poprawek pozostaje na razie ograniczona. Nie musi to oznaczać niskiej jakości zgłoszeń. W praktyce wiele spraw może nadal znajdować się w procesie odpowiedzialnego ujawniania, część błędów mogła zostać naprawiona bez szerokiego komunikatu, a część trafia do projektów z niewielkimi zasobami utrzymaniowymi. W ekosystemie open source to częsty problem, ponieważ krytyczne komponenty bywają rozwijane przez małe zespoły lub pojedynczych opiekunów.

Technologicznie narzędzia takie jak Mythos zmieniają ekonomikę wykrywania luk. Jeśli model potrafi masowo generować użyteczne hipotezy bezpieczeństwa, to próg wejścia do zaawansowanego researchu podatności maleje. Jednocześnie rośnie presja na dostawców oprogramowania, by szybciej klasyfikować zgłoszenia, priorytetyzować poprawki i automatyzować proces walidacji.

Konsekwencje / ryzyko

Najpoważniejsze konsekwencje dotyczą bezpieczeństwa łańcucha dostaw. Open source jest obecny w niemal każdym nowoczesnym środowisku IT, dlatego duża liczba luk wysokiego i krytycznego poziomu może przekładać się na ryzyko dla tysięcy organizacji jednocześnie. Problem nie ogranicza się więc do pojedynczych repozytoriów, lecz dotyczy całych ekosystemów zależności.

Drugie istotne ryzyko wynika z asymetrii między tempem wykrywania a tempem usuwania problemów. AI może znacząco przyspieszyć discovery, ale przygotowanie poprawki nadal wymaga pracy ludzi: potwierdzenia ustalenia, opracowania patcha, testów regresyjnych, publikacji nowej wersji i wdrożenia aktualizacji po stronie użytkowników. To prowadzi do narastania backlogu bezpieczeństwa.

Nie można też pominąć ryzyka ofensywnego. Narzędzia zdolne do masowej identyfikacji podatności mogą stać się akceleratorem dla aktorów zagrożeń. Nawet jeśli dostęp do konkretnego modelu jest kontrolowany, sam kierunek zmian jest jasny: zdolności ofensywne i defensywne będą rosły równolegle, a czas między wykryciem błędu a próbą jego wykorzystania może się skracać.

Dodatkowym wyzwaniem jest przeciążenie procesów operacyjnych. Jeżeli organizacje zaczną otrzymywać wielokrotnie więcej zgłoszeń niż dotąd, standardowe procedury CVE, PSIRT, patch management i zarządzania zależnościami mogą okazać się niewystarczające bez odpowiedniej automatyzacji i priorytetyzacji.

Rekomendacje

Organizacje korzystające z komponentów open source powinny potraktować ten trend jako wyraźny sygnał do wzmocnienia zarządzania ryzykiem w łańcuchu dostaw. Kluczowe znaczenie ma nie tylko szybkie wykrywanie problemów, ale przede wszystkim zdolność do ich sprawnej oceny i usuwania.

Utrzymuj aktualny SBOM oraz pełną ewidencję zależności bezpośrednich i pośrednich.
Automatyzuj monitorowanie biuletynów bezpieczeństwa i advisory dostawców.
Skracaj czas wdrażania poprawek poprzez testy aktualizacji w pipeline CI/CD.
Buduj proces triage oparty na ryzyku, z jasnymi kryteriami potwierdzania i eskalacji zgłoszeń.
Inwestuj w bezpieczny cykl wytwarzania, obejmujący przeglądy kodu, analizę statyczną i dynamiczną, fuzzing oraz kontrolę logiki autoryzacji.
Przygotuj mechanizmy ograniczające skutki opóźnionego łatania, takie jak segmentacja środowisk, minimalizacja uprawnień, WAF, RASP i detekcja prób wykorzystania nowych luk.

Podsumowanie

Dane przedstawione przez Anthropic sugerują, że AI staje się realnym mnożnikiem siły w obszarze vulnerability research. Ponad 23 tysiące potencjalnych wykryć w ponad 1000 projektach open source pokazuje zmianę skali, która może istotnie wpłynąć na procesy walidacji, ujawniania i łatania podatności.

Dla obrońców to jednocześnie szansa i wyzwanie. Z jednej strony możliwe jest szybsze odnajdywanie błędów w krytycznych komponentach, z drugiej bez dojrzałego zarządzania podatnościami, zależnościami i poprawkami nawet najbardziej zaawansowane mechanizmy wykrywania nie przełożą się na realne obniżenie ryzyka.

Źródła

FBI ostrzega przed Kali365: nowy phishing-as-a-service atakuje konta Microsoft 365

Wprowadzenie do problemu / definicja

Kali365 to platforma phishing-as-a-service zaprojektowana do przejmowania kont Microsoft 365 poprzez nadużywanie legalnego mechanizmu OAuth Device Code. W odróżnieniu od klasycznych kampanii phishingowych atak nie koncentruje się na kradzieży hasła, lecz na skłonieniu ofiary do zatwierdzenia kodu urządzenia na prawdziwej stronie logowania Microsoft.

Po zakończeniu procesu uwierzytelnienia napastnik uzyskuje ważny token sesyjny, który może zapewnić dostęp do poczty, aplikacji chmurowych oraz usług objętych pojedynczym logowaniem. To sprawia, że samo MFA nie zawsze wystarcza do zatrzymania tego typu operacji.

W skrócie

Federalne Biuro Śledcze ostrzegło przed Kali365 jako usługą wykorzystywaną do ataków na środowiska Microsoft 365 i Microsoft Entra. Narzędzie obniża próg wejścia dla cyberprzestępców, ponieważ dostarcza gotową infrastrukturę, automatyzację kampanii i elementy ułatwiające prowadzenie oszustw socjotechnicznych.

ataki wykorzystują mechanizm device code phishing,
platforma może przechwytywać tokeny i sesje bez kradzieży hasła,
Kali365 oferuje także tryb adversary-in-the-middle,
skutkiem może być pełny dostęp do kont Microsoft 365 oraz powiązanych usług SaaS.

Kontekst / historia

Device Authorization Grant powstał z myślą o urządzeniach, które mają ograniczone możliwości wprowadzania danych, takich jak telewizory smart, drukarki, systemy konferencyjne czy sprzęt IoT. Użytkownik otrzymuje krótki kod i wpisuje go na zaufanym portalu logowania, aby powiązać urządzenie z kontem.

Z czasem mechanizm ten zaczął być wykorzystywany przez przestępców. Kluczowy problem polega na tym, że ofiara loguje się na legalnej stronie i samodzielnie kończy proces MFA, przez co atak nie wygląda jak klasyczna próba wyłudzenia poświadczeń. W 2026 roku tego typu kampanie wyraźnie zyskały na znaczeniu, a Kali365 stało się przykładem komercjalizacji tego modelu działania.

Analiza techniczna

Model ataku jest prosty, ale skuteczny. Operator rozpoczyna proces autoryzacji urządzenia, generuje kod logowania, a następnie dostarcza go ofierze za pomocą wiadomości phishingowej lub innego komunikatu socjotechnicznego. Użytkownik trafia na prawdziwy proces logowania Microsoft, wpisuje kod i zatwierdza dostęp.

W efekcie platforma uzyskuje token dostępu powiązany z kontem użytkownika. Atakujący nie musi znać hasła ani przechwytywać jednorazowego kodu MFA, ponieważ z punktu widzenia systemu to użytkownik legalnie udzielił zgody na uwierzytelnienie.

Według opisywanych analiz Kali365 udostępnia funkcje charakterystyczne dla dojrzałych platform PhaaS. Obejmują one gotowe szablony kampanii, panele do śledzenia ofiar, automatyzację działań oraz elementy wspierane przez AI, które pomagają przygotowywać przynęty phishingowe. Model operacyjny przypomina strukturę usługową z administratorami, resellerami i afiliantami.

Drugim istotnym elementem jest funkcja określana jako „Cookie Link”, działająca w modelu adversary-in-the-middle. W takim scenariuszu ruch ofiary przechodzi przez infrastrukturę kontrolowaną przez napastnika, co umożliwia przechwycenie uwierzytelnionej sesji przeglądarkowej, tokenów i ciasteczek po zakończeniu logowania.

W zaobserwowanych przypadkach po przejęciu kont napastnicy uzyskiwali dostęp do skrzynek pocztowych, tworzyli złośliwe reguły wiadomości ukrywające aktywność i rejestrowali nowe urządzenia w środowisku ofiary. Takie działania zwiększają trwałość dostępu i utrudniają szybkie wykrycie incydentu.

Konsekwencje / ryzyko

Największe ryzyko wiąże się z błędnym założeniem, że wdrożenie MFA automatycznie chroni organizację przed wszystkimi formami phishingu. W przypadku nadużycia device code użytkownik przechodzi prawidłowy proces uwierzytelnienia, a napastnik otrzymuje legalny token sesyjny.

dostęp do poczty elektronicznej i poufnej korespondencji,
kompromitacja aplikacji chmurowych połączonych z SSO,
wyciek danych i dokumentów biznesowych,
wykorzystanie przejętego konta do dalszego phishingu,
ukrywanie śladów przez reguły skrzynki odbiorczej,
utrwalenie obecności dzięki rejestracji urządzeń i aktywnym sesjom.

Kali365 zwiększa skalę zagrożenia także dlatego, że upraszcza prowadzenie kampanii dla mniej doświadczonych operatorów. Gotowe zaplecze techniczne, automatyzacja i model usługowy sprawiają, że podobne ataki mogą być prowadzone szybciej i szerzej niż wcześniej.

Rekomendacje

Organizacje korzystające z Microsoft 365 i Entra powinny w pierwszej kolejności ocenić, czy przepływ uwierzytelniania device code jest im rzeczywiście potrzebny. Jeśli nie ma uzasadnienia biznesowego, warto go ograniczyć lub zablokować przy użyciu polityk dostępu warunkowego.

przeprowadzić audyt użycia mechanizmu device code w tenantach,
monitorować nietypowe logowania, wydania tokenów i nowe urządzenia,
analizować reguły skrzynek pocztowych pod kątem ukrywania wiadomości i przekierowań,
wymuszać Conditional Access oparty na ryzyku, stanie urządzenia i zaufanych lokalizacjach,
szkolić użytkowników, że legalna strona logowania nie zawsze oznacza bezpieczny proces,
wdrożyć procedury reagowania obejmujące unieważnianie tokenów, wylogowanie sesji, reset poświadczeń i przegląd zgód aplikacyjnych.

W przypadku podejrzenia incydentu należy zabezpieczyć wiadomości phishingowe, logi uwierzytelnień, informacje o nowych urządzeniach oraz artefakty związane z tokenami i sesjami. Szybka analiza tych danych może znacząco ograniczyć skutki naruszenia.

Podsumowanie

Kali365 pokazuje, że nowoczesny phishing coraz częściej nie polega na kradzieży haseł, lecz na nadużywaniu legalnych mechanizmów uwierzytelniania. Ataki wykorzystujące OAuth Device Code i przechwytywanie sesji skutecznie omijają ochronę opartą wyłącznie na MFA.

Dla organizacji oznacza to potrzebę wdrożenia warstwowego modelu bezpieczeństwa obejmującego kontrolę tożsamości, monitorowanie tokenów, polityki dostępu warunkowego, analizę sesji oraz regularną edukację użytkowników. Bez takiego podejścia ryzyko przejęcia kont w środowiskach Microsoft 365 będzie nadal rosło.

Źródła

Megalodon: zmasowany atak supply chain skaził tysiące repozytoriów GitHub

Wprowadzenie do problemu / definicja

Ataki typu supply chain coraz częściej wykraczają poza złośliwe paczki publikowane w rejestrach i uderzają bezpośrednio w proces tworzenia oprogramowania. Kampania Megalodon pokazuje, że przejęcie workflow CI/CD może stać się skutecznym sposobem na kradzież sekretów, tokenów i poświadczeń wykorzystywanych podczas budowania, testowania oraz wdrażania aplikacji.

W tym modelu napastnik nie musi od razu modyfikować logiki biznesowej projektu. Wystarczy dodać lub podmienić pliki automatyzacji, aby podczas uruchomienia pipeline’u doprowadzić do eksfiltracji wrażliwych danych i otworzyć sobie drogę do dalszej kompromitacji środowiska.

W skrócie

Megalodon to szeroko zakrojona kampania supply chain wymierzona w repozytoria GitHub. Według ustaleń badaczy złośliwe commity zawierające workflow GitHub Actions trafiły do ponad 5,5 tys. repozytoriów w bardzo krótkim czasie, a głównym celem operacji była kradzież sekretów z systemów CI/CD.

atak objął tysiące repozytoriów GitHub,
złośliwe zmiany dotyczyły plików workflow GitHub Actions,
celem była kradzież tokenów, kluczy i poświadczeń chmurowych,
w części przypadków skutkiem wtórnym mogła być publikacja skażonych wydań pakietów open source.

Kontekst / historia

Incydent został nagłośniony po wykryciu złośliwych wersji pakietu open source, których źródłem okazało się wcześniej skompromitowane repozytorium. To ważny sygnał ostrzegawczy dla całego ekosystemu, ponieważ pokazuje, że legalnie opublikowane wydanie może pochodzić z procesu build i release naruszonego na wcześniejszym etapie.

Z dostępnych informacji wynika, że złośliwe commity były generowane automatycznie i miały przypominać aktywność bota budującego. Taka metoda utrudnia szybką identyfikację anomalii, ponieważ zmiany w historii repozytorium mogą wyglądać jak rutynowe aktualizacje konfiguracji automatyzacji. Skala operacji sugeruje wysoki poziom automatyzacji oraz starannie przygotowaną infrastrukturę atakujących.

Kampania wpisuje się w szerszy trend przesuwania działań ofensywnych z poziomu klasycznego malware na warstwę procesu developerskiego. Coraz większą wartość dla napastników mają dziś nie tylko stacje robocze programistów, lecz także konta maintainerów, tokeny publikacyjne, workflow CI/CD i sekrety dostępne podczas uruchamiania pipeline’ów.

Analiza techniczna

Kluczowym elementem kampanii było osadzenie złośliwych definicji GitHub Actions w plikach workflow. Dzięki temu napastnik nie musiał wprowadzać oczywistego backdoora do kodu aplikacji. Wystarczyła modyfikacja katalogu odpowiedzialnego za automatyzację, aby po uruchomieniu pipeline’u dochodziło do przechwytywania i przesyłania wrażliwych danych z środowiska wykonawczego.

Badacze opisali dwa główne wzorce działania. Pierwszy polegał na dodaniu nowego workflow uruchamianego przy standardowych zdarzeniach, takich jak push lub pull request. Drugi wariant był bardziej podstępny i polegał na zastąpieniu istniejącego workflow zmodyfikowaną wersją z odpowiednio dobranymi triggerami, co pozwalało stworzyć uśpiony mechanizm możliwy do aktywacji później.

Istotną rolę odgrywał mechanizm workflow_dispatch, czyli ręczne lub wywoływane przez API uruchamianie workflow. Taki trigger może umożliwić aktywację złośliwego łańcucha wykonania po przejęciu odpowiednich tokenów. Z perspektywy obrony jest to szczególnie niebezpieczne, ponieważ kompromitacja może zostać rozszerzona także po zakończeniu początkowej fazy incydentu.

Zakres potencjalnie wykradanych danych był szeroki i obejmował m.in.:

zmienne środowiskowe CI,
tokeny GitHub i innych systemów CI/CD,
poświadczenia do AWS, GCP i Azure,
klucze prywatne SSH,
dane dostępowe do rejestrów kontenerów,
konfiguracje Docker i Kubernetes,
klucze API oraz connection stringi do baz danych.

To scenariusz szczególnie groźny, ponieważ sekrety dostępne w pipeline’ach często mają bardzo szerokie uprawnienia. W wielu organizacjach tokeny CI/CD pozwalają na publikację artefaktów, dostęp do repozytoriów prywatnych, wdrożenia produkcyjne oraz operacje na zasobach chmurowych.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem Megalodon nie jest samo dodanie złośliwego workflow, ale możliwość wtórnego wykorzystania przejętych sekretów. Jeżeli pipeline miał dostęp do środowisk produkcyjnych, rejestrów pakietów lub infrastruktury chmurowej, atakujący mógł rozciągnąć kompromitację daleko poza pojedyncze repozytorium.

przejęcie procesu wydawniczego i publikacja złośliwych wersji pakietów,
dostęp do prywatnych repozytoriów i kodu źródłowego,
kompromitacja obrazów kontenerów i artefaktów budowania,
lateral movement do usług chmurowych,
utrzymanie dostępu dzięki uśpionym workflow i pozostawionym tokenom,
naruszenie integralności łańcucha dostaw oprogramowania dla klientów końcowych.

Dla organizacji korzystających z open source oznacza to konieczność szerszego spojrzenia na bezpieczeństwo zależności. Nawet oficjalnie opublikowane wydanie pakietu może być efektem budowania ze skompromitowanego źródła, co podważa zaufanie do tradycyjnych wskaźników autentyczności release’ów.

Rekomendacje

Pliki workflow CI/CD powinny być traktowane jako zasoby wysokiego ryzyka i objęte takimi samymi mechanizmami kontroli jak kod produkcyjny. Ochrona samej aplikacji nie wystarcza, jeśli proces build i release pozostaje podatny na manipulację.

wymusić obowiązkowy przegląd zmian w plikach workflow przez wyznaczonych właścicieli,
zastosować CODEOWNERS dla katalogów odpowiedzialnych za pipeline’y,
ograniczyć uprawnienia domyślnego GITHUB_TOKEN do minimum,
przeprowadzić rotację wszystkich sekretów dostępnych w potencjalnie zainfekowanych workflow,
audytować historię commitów pod kątem zmian podszywających się pod boty,
monitorować użycie triggerów ręcznych i API uruchamiających workflow,
włączyć ochronę gałęzi, wymagane review i podpisywanie commitów,
ograniczyć liczbę sekretów eksportowanych do pipeline’ów,
stosować krótkotrwałe poświadczenia zamiast statycznych kluczy,
rozdzielić tożsamości używane do buildów, publikacji i wdrożeń.

Jeżeli istnieje podejrzenie ekspozycji, reakcja na incydent powinna wykraczać poza samo usunięcie złośliwych plików z repozytorium. Niezbędne są pełna inwentaryzacja sekretów, analiza logów GitHub Actions, przegląd opublikowanych artefaktów oraz weryfikacja, czy nie doszło do wtórnych wdrożeń lub publikacji.

Podsumowanie

Megalodon to przykład dojrzałego ataku na łańcuch dostaw, w którym głównym celem nie jest bezpośrednio aplikacja, lecz mechanizmy automatyzacji otaczające proces wytwarzania oprogramowania. Skala incydentu pokazuje, że workflow CI/CD stały się jednym z najważniejszych punktów nacisku dla współczesnych napastników.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że kontrola musi obejmować nie tylko kod źródłowy, ale również repozytoria, pipeline’y, tokeny automatyzacji i polityki dostępu do sekretów. Bezpieczeństwo procesu build i release jest dziś równie istotne jak bezpieczeństwo samej aplikacji.

Źródła

Anthropic może szykować publiczne wdrożenie Claude Mythos w Claude Code

Wprowadzenie do problemu / definicja

Anthropic może zbliżać się do kolejnego etapu udostępniania modelu Claude Mythos, określanego jako system o bardzo zaawansowanych zdolnościach w obszarze cyberbezpieczeństwa. To istotny temat dla branży, ponieważ nie chodzi wyłącznie o lepsze generowanie kodu, ale o model zdolny do wspierania złożonych działań defensywnych i potencjalnie również ofensywnych.

W praktyce oznacza to wejście w nową fazę rozwoju narzędzi AI dla bezpieczeństwa: systemów, które mogą jednocześnie przyspieszać wykrywanie podatności i zwiększać ryzyko ich automatycznego wykorzystywania. Tego typu rozwiązania wpisują się w kategorię technologii dual-use, czyli takich, które mogą służyć zarówno obrońcom, jak i atakującym.

W skrócie

Z publicznie ujawnionych informacji wynika, że model oznaczony jako claude-mythos-1-preview pojawił się czasowo w komponentach związanych z Claude Code oraz Claude Security. Wcześniejsze komunikaty Anthropic wskazywały, że Mythos oferuje istotnie zwiększone możliwości w zadaniach bezpieczeństwa i analizie kodu, ale jego szersze wdrożenie zostało ograniczone ze względu na wysokie ryzyko nadużyć.

Model ma koncentrować się na zadaniach związanych z bezpieczeństwem aplikacji i analizą kodu.
Anthropic sygnalizował obawy dotyczące potencjalnego wykorzystania technologii do działań szkodliwych.
Krótka obecność przełącznika aktywującego model może sugerować przygotowania do kontrolowanego wdrożenia.
Firma równolegle rozwija mechanizmy ograniczające nadużycia i inicjatywy wspierające wykrywanie podatności.

Kontekst / historia

Anthropic zaprezentował Claude Mythos w kwietniu 2026 roku jako model dostępny początkowo w ograniczonym podglądzie. Już wtedy podkreślano, że rozwiązanie znacząco przewyższa wcześniejsze modele firmy pod względem rozumowania nad kodem, autonomii działania i wykonywania zadań związanych z cyberbezpieczeństwem.

Jednocześnie producent zastrzegł, że tak zaawansowany model może wzmacniać zarówno zespoły obronne, jak i podmioty prowadzące działania ofensywne. W tle znajduje się szersza debata o roli generatywnej AI w bezpieczeństwie, szczególnie tam, gdzie narzędzia potrafią analizować kod, identyfikować luki i proponować dalsze kroki techniczne.

Sygnałem możliwego przejścia do szerszego testowania była obserwacja krótkotrwałej obecności funkcji związanych z Mythos w publicznie dostępnych interfejsach produktów z ekosystemu Claude. Może to wskazywać, że Anthropic rozwija warstwę zabezpieczeń pozwalającą na bardziej kontrolowane udostępnienie modelu.

Analiza techniczna

Najważniejszy element techniczny nie dotyczy samego pojawienia się nazwy modelu w interfejsie, ale klasy jego możliwości. Według dotychczasowych informacji Mythos został zaprojektowany jako model frontier o bardzo silnych kompetencjach w zakresie analizy kodu źródłowego, rozumowania o logice aplikacji, autonomicznego wykonywania zadań bezpieczeństwa oraz identyfikacji podatności.

Z operacyjnego punktu widzenia oznacza to system zdolny do pracy w wielu etapach: od zrozumienia repozytorium i kontekstu aplikacji, przez wykrycie potencjalnego błędu, aż po wygenerowanie scenariusza jego wykorzystania lub rekomendacji naprawczych. To wyraźnie odróżnia Mythos od klasycznych asystentów kodowania, które zwykle koncentrują się na uzupełnianiu kodu i prostym wsparciu programisty.

Istotnym elementem mają być również mechanizmy ochronne ograniczające ryzyko nadużyć. W praktyce takie zabezpieczenia mogą obejmować:

filtrowanie zapytań związanych z działaniami ofensywnymi,
ograniczanie dostępu do wybranych funkcji lub trybów pracy,
monitorowanie wykorzystania modelu i telemetrii,
segmentację dostępu zależnie od poziomu zaufania użytkownika,
kontrolę nad funkcjami autonomicznymi.

Dodatkowo Anthropic rozwija inicjatywy służące wykorzystaniu modelu do identyfikacji podatności w krytycznym oprogramowaniu w bardziej nadzorowanych warunkach. Taki tryb wdrażania pozwala oceniać skuteczność modelu przy jednoczesnym ograniczaniu ryzyka niekontrolowanego użycia.

Konsekwencje / ryzyko

Potencjalne skutki szerszego wdrożenia modelu tej klasy mogą być bardzo znaczące. Po stronie defensywnej organizacje mogą otrzymać narzędzie przyspieszające wykrywanie błędów wysokiego ryzyka, analizę kodu, priorytetyzację podatności i przygotowanie poprawek jeszcze przed wdrożeniem aplikacji do środowiska produkcyjnego.

Po stronie ofensywnej zagrożenie polega na obniżeniu bariery wejścia dla bardziej zaawansowanych technik ataku. Nawet jeśli model nie będzie generował kompletnych exploitów, samo wsparcie w analizie kodu, budowaniu hipotez o podatnościach i automatyzacji rekonesansu może zwiększać tempo działań przeciwnika.

Ryzyko należy rozpatrywać również systemowo. Jeżeli model rzeczywiście wykrywa bardzo dużą liczbę luk, organizacje mogą stanąć przed problemem gwałtownego wzrostu backlogu bezpieczeństwa. Samo wykrywanie podatności nie rozwiązuje problemu, jeśli procesy triage, walidacji, priorytetyzacji i łatania nie są wystarczająco dojrzałe.

Rekomendacje

Pojawienie się modeli takich jak Claude Mythos powinno skłonić organizacje do aktualizacji strategii AppSec oraz zasad AI governance. W praktyce warto rozważyć następujące działania:

wzmocnienie praktyk secure SDLC, w tym analizy kodu, skanowania zależności i testów bezpieczeństwa API,
przyspieszenie procesu klasyfikacji, walidacji i usuwania podatności,
budowanie odporności na ataki wspierane przez AI poprzez segmentację, hardening i zasadę najmniejszych uprawnień,
monitorowanie narzędzi AI używanych przez zespoły programistyczne oraz kontrolę przepływu danych do usług zewnętrznych,
opracowanie procedur dla scenariuszy masowego wykrywania podatności,
rozwijanie kompetencji zespołów blue team, AppSec i deweloperów w zakresie interpretacji wyników generowanych przez modele AI.

Podsumowanie

Claude Mythos może stać się jednym z najważniejszych i zarazem najbardziej wrażliwych przykładów rozwoju AI dla cyberbezpieczeństwa. Z jednej strony oferuje realną szansę na szybsze wykrywanie i usuwanie podatności, z drugiej niesie ryzyko przyspieszenia działań ofensywnych i dalszej automatyzacji eksploatacji luk.

Kluczowe znaczenie będzie miało nie tylko to, czy model trafi szerzej do produktów deweloperskich Anthropic, ale przede wszystkim to, czy producent zdoła skutecznie ograniczyć możliwość nadużyć i czy organizacje będą gotowe operacyjnie na nowy poziom skali pracy z podatnościami.

Źródła

Ghost CMS i CVE-2026-26980: krytyczna luka wykorzystana do przejęcia ponad 700 witryn w kampanii ClickFix

Wprowadzenie do problemu / definicja

CVE-2026-26980 to krytyczna podatność typu SQL injection w Ghost CMS, obejmująca interfejs Content API. Jej znaczenie wynika z faktu, że może zostać wykorzystana bez uwierzytelnienia do odczytu danych z bazy, a następnie do pozyskania klucza Admin API, co otwiera drogę do nieautoryzowanej modyfikacji treści publikowanych w serwisie.

W praktyce problem nie ogranicza się do naruszenia samego systemu zarządzania treścią. Przejęta witryna może zostać wykorzystana jako zaufany nośnik złośliwego kodu, służący do dalszych ataków na odwiedzających.

W skrócie

Badacze bezpieczeństwa opisali aktywną kampanię, w której cyberprzestępcy wykorzystują CVE-2026-26980 do przejmowania instancji Ghost CMS i osadzania złośliwego kodu JavaScript w artykułach oraz elementach stron. Celem operacji jest uruchamianie ataków ClickFix opartych na fałszywych komunikatach CAPTCHA i nakłanianiu użytkowników do ręcznego uruchamiania poleceń w systemie Windows.

Według opublikowanych informacji kampania objęła ponad 700 witryn z różnych sektorów, w tym edukacji, mediów, fintechu, SaaS i cyberbezpieczeństwa. Luka została załatana w wersji 6.19.1, ale nieaktualne lub niewłaściwie oczyszczone środowiska nadal mogą pozostawać zagrożone.

Kontekst / historia

Ghost CMS jest szeroko stosowany przez media, blogi technologiczne, organizacje eksperckie i firmy publikujące treści online. Z perspektywy napastników stanowi atrakcyjny cel, ponieważ kompromitacja jednej instancji pozwala nie tylko ingerować w publikacje, lecz także atakować użytkowników odwiedzających legalną i rozpoznawalną domenę.

Opisana kampania została wykryta na początku maja 2026 roku i miała charakter szeroko zakrojonego zatruwania witryn. Publiczne analizy wskazują, że część serwisów została skażona w krótkim czasie, co sugeruje zautomatyzowane skanowanie podatnych instancji oraz szybkie wykorzystanie luki po jej ujawnieniu.

To ważna zmiana w sposobie postrzegania ryzyka. W tym scenariuszu nie chodzi wyłącznie o wyciek danych z CMS, ale o przejęcie wiarygodnej platformy publikacyjnej i użycie jej jako etapu pośredniego w kampanii malware oraz socjotechniki.

Analiza techniczna

Podatność CVE-2026-26980 dotyczy Content API i umożliwia nieautoryzowany odczyt danych z bazy danych. Najpoważniejszym skutkiem jest możliwość uzyskania klucza Admin API, dzięki któremu atakujący może wywoływać funkcje administracyjne aplikacji i masowo modyfikować istniejące treści.

W analizowanych incydentach intruzi wykorzystywali przejęty Admin API do dopisywania złośliwych loaderów JavaScript do artykułów lub elementów stron. Kod ten pełnił rolę pierwszego etapu infekcji i pobierał właściwy ładunek z zewnętrznej infrastruktury. Taki model zapewnia napastnikom dużą elastyczność, ponieważ pozwala zmieniać końcowy payload bez ponownego naruszania każdej witryny osobno.

Kolejny etap obejmował filtrowanie ruchu i profilowanie odwiedzającego. Złośliwy skrypt zbierał informacje o przeglądarce oraz środowisku użytkownika, a następnie decydował, czy uruchomić dalszą fazę ataku. To klasyczny cloaking, którego celem jest ukrywanie faktycznego działania przed systemami analizy, crawlerami i narzędziami bezpieczeństwa.

Jeżeli użytkownik został uznany za wartościowy cel, strona prezentowała fałszywy ekran CAPTCHA osadzony w ramce. W rzeczywistości był to element kampanii ClickFix, zachęcający ofiarę do skopiowania i uruchomienia zakodowanego polecenia w oknie „Uruchom” systemu Windows. Dzięki temu wykonanie szkodliwego działania zostaje przeniesione na użytkownika, co pomaga ominąć część tradycyjnych mechanizmów ochronnych.

Dalszy łańcuch infekcji prowadził do pobrania archiwum ZIP, uruchomienia skryptu wsadowego, a następnie wykonania polecenia PowerShell pobierającego kolejne komponenty z serwera zdalnego. W zależności od wariantu wykorzystywano między innymi pliki DLL uruchamiane przez rundll32.exe lub ładunki JavaScript służące do osadzenia końcowego programu w systemie ofiary.

Konsekwencje / ryzyko

Ryzyko związane z CVE-2026-26980 obejmuje kilka warstw. Pierwsza to kompromitacja samej witryny, czyli nieautoryzowana zmiana treści, utrata integralności publikacji oraz możliwość osadzania złośliwego kodu. Druga dotyczy użytkowników końcowych, którzy mogą zostać nakłonieni do uruchomienia poleceń prowadzących do instalacji malware.

Trzeci poziom ma charakter reputacyjny i operacyjny. Zainfekowany serwis może zostać oznaczony jako niebezpieczny przez przeglądarki, systemy bezpieczeństwa i dostawców usług filtrujących ruch. Dla organizacji oznacza to ryzyko utraty zaufania odbiorców, partnerów i klientów, a w niektórych branżach również obowiązki związane z notyfikacją incydentu.

Atak jest szczególnie niebezpieczny również dlatego, że jego monetyzacja jest relatywnie prosta. Po przejęciu CMS napastnik może wykorzystać istniejący ruch witryny do kierowania części użytkowników do kolejnych etapów kampanii, bez konieczności natychmiastowego wykradania danych.

Rekomendacje

Podstawowym krokiem powinno być natychmiastowe zaktualizowanie Ghost CMS do wersji 6.19.1 lub nowszej. Jeżeli jednak istnieje podejrzenie wcześniejszej kompromitacji, sama aktualizacja nie jest wystarczająca, ponieważ klucze administracyjne i inne sekrety mogły już zostać przejęte.

zaktualizować Ghost CMS do bezpiecznej wersji,
obrócić wszystkie klucze API, tokeny, hasła i sekrety aplikacyjne,
przeprowadzić przegląd treści, motywów i szablonów pod kątem wstrzykniętego JavaScript,
sprawdzić logi aplikacyjne, reverse proxy, WAF i CDN pod kątem nietypowych wywołań API oraz masowych modyfikacji treści,
zweryfikować integralność bazy danych i opublikowanych wpisów,
przeszukać środowisko pod kątem wskaźników kompromitacji związanych z loaderami, cloakingiem i nietypowymi iframe,
wdrożyć monitoring zmian treści oraz alerty dla operacji wykonywanych przez Admin API,
poinformować użytkowników, jeśli istnieje ryzyko kontaktu ze złośliwą zawartością.

W dłuższej perspektywie warto ograniczyć ekspozycję interfejsów API, stosować WAF z regułami wykrywającymi SQL injection, monitorować integralność treści oraz regularnie skanować aplikacje webowe pod kątem podatności. Równie istotna jest edukacja użytkowników, ponieważ legalna witryna nie powinna wymagać uruchamiania poleceń systemowych w celu potwierdzenia, że odwiedzający jest człowiekiem.

Podsumowanie

CVE-2026-26980 pokazuje, jak groźne może być połączenie podatności aplikacyjnej z nadużyciem legalnych funkcji administracyjnych CMS. W tym przypadku skutkiem nie był jedynie incydent po stronie jednej witryny, ale masowa kampania zatruwania treści, wykorzystująca zaufane serwisy do prowadzenia ataków ClickFix i dalszej dystrybucji malware.

Dla administratorów Ghost CMS kluczowe są trzy działania: szybkie łatanie, pełna rotacja sekretów po incydencie oraz dokładna analiza integralności treści i logów. Organizacje, które ograniczą reakcję wyłącznie do aktualizacji systemu, mogą przeoczyć fakt, że napastnik uzyskał już trwały dostęp operacyjny do środowiska publikacyjnego.

Źródła

Ghost CMS CVE-2026-26980 Exploited to Hijack 700+ Sites for ClickFix Attacks — https://thehackernews.com/2026/05/ghost-cms-cve-2026-26980-exploited-to.html
Ghost Security Advisories — https://github.com/TryGhost/Ghost/security
Ghost Developer Documentation: Admin API — https://docs.ghost.org/admin-api
Ghost Developer Documentation: Content API — https://docs.ghost.org/content-api
GitHub Repository: TryGhost/Ghost — https://github.com/TryGhost/Ghost

Nie Sprzedaję Zgodności W Paczce. Po Co Są Szablony Dokumentacji NIS2 I ISO 27001?

Zacznijmy od rzeczy, którą warto powiedzieć od razu.

Jeżeli ktoś mówi Ci, że kupisz paczkę dokumentów i od tego momentu Twoja organizacja jest zgodna z NIS2 albo ISO 27001, to powinieneś bardzo uważać.

To tak nie działa.

Dokumenty same w sobie nie dają zgodności. Nie wdrażają zabezpieczeń. Nie robią analizy ryzyka. Nie testują kopii zapasowych. Nie szkolą zarządu. Nie obsługują incydentów. Nie podejmują decyzji za właścicieli procesów. Nie są też certyfikatem, audytem, opinią prawną ani indywidualnym wdrożeniem w konkretnej organizacji.

Czytaj dalej

CISA dodaje krytyczną lukę w Drupal Core do katalogu KEV po potwierdzonej aktywnej eksploatacji

Wprowadzenie do problemu / definicja

Amerykańska agencja CISA dodała podatność CVE-2026-9082 w Drupal Core do katalogu Known Exploited Vulnerabilities, czyli listy luk bezpieczeństwa aktywnie wykorzystywanych przez atakujących. Chodzi o krytyczny błąd typu SQL injection, który dotyczy instalacji Drupala korzystających z bazy PostgreSQL.

Wpisanie luki do katalogu KEV oznacza, że zagrożenie ma już charakter operacyjny, a nie wyłącznie teoretyczny. Dla administratorów, zespołów SOC i działów IT to wyraźny sygnał, że konieczne jest natychmiastowe działanie.

W skrócie

CVE-2026-9082 umożliwia nieautoryzowane wstrzykiwanie zapytań SQL za pomocą specjalnie przygotowanych żądań HTTP. Problem wynika z błędu w mechanizmie sanitizacji zapytań do bazy danych, co może prowadzić do ujawnienia informacji, eskalacji uprawnień, a w określonych scenariuszach także do dalszego przejęcia kontroli nad aplikacją.

Podatność dotyczy Drupal Core w środowiskach używających PostgreSQL.
Poprawka bezpieczeństwa została opublikowana 20 maja 2026 r.
Aktywność eksploatacyjna została zaobserwowana już w ciągu 48 godzin od publikacji łatki.
CISA wyznaczyła termin usunięcia podatności przez agencje federalne do 27 maja 2026 r.

Kontekst / historia

Drupal od lat pozostaje jednym z kluczowych systemów CMS wykorzystywanych przez administrację publiczną, media, sektor finansowy oraz organizacje obsługujące serwisy o wysokiej dostępności i dużej wartości danych. Z tego względu każda krytyczna luka w rdzeniu platformy szybko staje się celem zorganizowanych kampanii skanowania i prób przejęcia systemów.

W przypadku CVE-2026-9082 producent opublikował aktualizację bezpieczeństwa 20 maja 2026 r. Wkrótce potem pojawiły się informacje o aktywnych próbach wykorzystania podatności w środowisku rzeczywistym. Następnie CISA dopisała lukę do katalogu KEV, co zwykle oznacza wzrost priorytetu ryzyka w organizacjach publicznych i podmiotach infrastruktury krytycznej.

Z dostępnych informacji wynika, że w ciągu dwóch dni od ujawnienia problemu odnotowano ponad 15 tysięcy prób ataków wymierzonych w blisko 6 tysięcy serwisów działających w 65 krajach. Szczególnie często na celowniku znajdowały się podmioty z branży gamingowej i finansowej.

Analiza techniczna

Źródłem podatności jest błąd w warstwie API Drupala odpowiedzialnej za oczyszczanie i bezpieczne składanie zapytań SQL. W określonych warunkach mechanizm ochronny nie usuwa poprawnie niebezpiecznych danych wejściowych, co umożliwia przesłanie złośliwego żądania i wykonanie arbitralnych operacji na bazie danych.

Istotnym ograniczeniem, ale jednocześnie kluczowym warunkiem ryzyka, jest zależność od PostgreSQL. Oznacza to, że nie wszystkie wdrożenia Drupala są podatne, jednak organizacje korzystające z tej konfiguracji powinny traktować sprawę jako pilną. Atak nie wymaga wcześniejszego uwierzytelnienia, więc podatna instancja może zostać zaatakowana przez anonimowego użytkownika z internetu.

Skuteczna eksploatacja może obejmować kilka etapów. Na początku atakujący może wykorzystać lukę do odczytu danych z bazy, mapowania struktury tabel oraz pozyskiwania informacji o użytkownikach, sesjach i konfiguracji systemu. W bardziej zaawansowanych scenariuszach możliwa jest modyfikacja danych, przejęcie kont o wyższych uprawnieniach oraz wykorzystanie kompromitacji aplikacji jako punktu wyjścia do dalszych działań w infrastrukturze.

Pierwsza fala aktywności po publikacji poprawki miała charakter mieszany. Obejmowała zarówno masowe skanowanie internetu w celu identyfikacji podatnych hostów, jak i bardziej ukierunkowane próby walidacji podatności na konkretnych instancjach. Taki wzorzec jest typowy dla luk o wysokiej wartości ofensywnej.

Konsekwencje / ryzyko

Najważniejszą konsekwencją wpisania CVE-2026-9082 do katalogu KEV jest formalne potwierdzenie aktywnej eksploatacji. To zmienia klasyfikację problemu z podatności wymagającej aktualizacji na zagrożenie, które może już prowadzić do pełnoprawnych incydentów bezpieczeństwa.

Ryzyko dla organizacji obejmuje zarówno warstwę aplikacyjną, jak i potencjalne skutki operacyjne po stronie infrastruktury.

wyciek danych użytkowników i informacji aplikacyjnych,
przejęcie kont uprzywilejowanych,
manipulację treścią serwisu i ustawieniami CMS,
dalszy ruch boczny po kompromitacji hosta lub bazy danych,
wykorzystanie podatnej instancji jako punktu wejścia do kolejnych ataków.

Szczególnie zagrożone są organizacje utrzymujące publicznie dostępne portale o znaczeniu biznesowym, regulacyjnym lub reputacyjnym. Wysokie ryzyko dotyczy także środowisk, w których proces aktualizacji odbywa się z opóźnieniem lub monitoring aplikacyjny nie pozwala szybko wykrywać podejrzanych zapytań SQL.

Rekomendacje

Podstawowym działaniem obronnym jest natychmiastowe wdrożenie oficjalnych poprawek bezpieczeństwa dla Drupal Core. Organizacje korzystające z PostgreSQL powinny niezwłocznie zidentyfikować wszystkie instancje produkcyjne, testowe i zapomniane środowiska utrzymywane poza standardowym procesem zarządzania zmianą.

zidentyfikować wszystkie instancje Drupal Core działające z PostgreSQL,
niezwłocznie wdrożyć dostępne poprawki bezpieczeństwa,
przeanalizować logi HTTP, aplikacyjne i bazodanowe pod kątem nietypowych żądań,
zweryfikować, czy nie doszło do nieautoryzowanych zmian w kontach, rolach i konfiguracji,
sprawdzić integralność plików aplikacji oraz artefaktów wdrożeniowych,
uruchomić reguły detekcyjne w WAF, IDS i SIEM dla prób SQL injection,
ograniczyć ekspozycję interfejsów administracyjnych,
przygotować procedurę response w razie oznak wcześniejszej kompromitacji.

Warto przy tym założyć, że samo załatanie systemu może nie wystarczyć, jeśli podatność została już wykorzystana przed aktualizacją. W takiej sytuacji konieczne staje się przeprowadzenie analizy powłamaniowej, rotacja sekretów, przegląd kont uprzywilejowanych i ocena, czy w środowisku nie pozostawiono trwałych mechanizmów dostępu.

Podsumowanie

CVE-2026-9082 pokazuje, jak szybko krytyczna luka w popularnym systemie CMS może przejść od publikacji poprawki do masowej eksploatacji. Błąd SQL injection w Drupal Core, dotyczący instalacji opartych na PostgreSQL, został uznany przez CISA za aktywnie wykorzystywany i wpisany do katalogu KEV.

Dla administratorów i zespołów bezpieczeństwa oznacza to konieczność natychmiastowej reakcji: aktualizacji systemów, przeglądu logów, wdrożenia reguł detekcyjnych oraz sprawdzenia, czy środowisko nie zostało już naruszone. W praktyce jest to incydent wysokiego priorytetu, który należy obsłużyć tak samo poważnie jak każdą inną krytyczną podatność z potwierdzoną aktywną eksploatacją.

Źródła

Security Affairs — U.S. CISA adds a flaw in Drupal Core to its Known Exploited Vulnerabilities catalog — https://securityaffairs.com/192566/uncategorized/u-s-cisa-adds-a-flaw-in-drupal-core-to-its-known-exploited-vulnerabilities-catalog.html
CISA Known Exploited Vulnerabilities Catalog — https://www.cisa.gov/known-exploited-vulnerabilities-catalog
Drupal Security Advisory for CVE-2026-9082 — https://www.drupal.org
CVE Record for CVE-2026-9082 — https://www.cve.org
Imperva analysis of exploitation activity related to CVE-2026-9082 — https://www.imperva.com