Archiwa: LLM - Strona 10 z 20 - Security Bez Tabu

Krytyczna luka RCE w Flowise zwiększa ryzyko dla środowisk self-hosted po publikacji kodu exploitacji

Wprowadzenie do problemu / definicja

W świecie narzędzi opartych na sztucznej inteligencji rośnie liczba incydentów wynikających nie tylko z klasycznych błędów programistycznych, ale również z niebezpiecznych założeń projektowych. Taki charakter ma podatność CVE-2026-40933 w platformie Flowise, popularnym rozwiązaniu open source do budowy przepływów LLM i agentów AI.

Problem dotyczy zdalnego wykonania kodu (RCE) i może zostać wykorzystany poprzez import spreparowanego pliku chatflow. Publiczne udostępnienie kodu proof-of-concept dodatkowo zwiększa ryzyko, ponieważ ułatwia odtworzenie scenariusza ataku także mniej zaawansowanym technicznie napastnikom.

W skrócie

Podatność oznaczona jako CVE-2026-40933 otrzymała ocenę krytyczną i dotyczy mechanizmu integracji MCP w Flowise. Luka pozwala na uruchomienie dowolnych poleceń systemowych na serwerze po zaimportowaniu złośliwego chatflow zawierającego odpowiednio przygotowaną konfigurację.

Zagrożone są przede wszystkim instancje self-hosted.
Atak może zostać uruchomiony poprzez import złośliwego pliku JSON.
Wektor wykorzystuje obsługę MCP w trybie stdio.
Publiczny kod exploitacji zwiększa prawdopodobieństwo masowych prób nadużyć.
Według dostępnych informacji Flowise Cloud nie jest objęte tym samym scenariuszem ataku.

Kontekst / historia

Luka została ujawniona w szerszym kontekście problemów bezpieczeństwa związanych z ekosystemami AI korzystającymi z protokołu MCP. Flowise znalazł się w grupie produktów narażonych na tę klasę błędów ze względu na sposób obsługi niestandardowych narzędzi oraz serializacji poleceń wykonywanych przez adapter stdio.

Rosnąca popularność Flowise jako platformy do wizualnego budowania przepływów dla modeli językowych sprawia, że produkt staje się atrakcyjnym celem dla cyberprzestępców. Dodatkowym czynnikiem ryzyka jest publiczna dostępność technicznych szczegółów oraz kodu PoC, co skraca czas potrzebny na przygotowanie skutecznej kampanii ofensywnej.

Analiza techniczna

Istota podatności sprowadza się do niebezpiecznej obsługi konfiguracji MCP w trybie stdio. W podatnych wersjach Flowise wcześniejszych niż 3.1.0 możliwe było dodanie komponentu MCP i zdefiniowanie polecenia systemowego, które następnie mogło zostać wykonane przez host obsługujący aplikację.

Scenariusz ataku wykorzystuje legalną funkcjonalność programu. Napastnik przygotowuje złośliwy chatflow z osadzonym niestandardowym narzędziem MCP, eksportuje go do formatu JSON i przekazuje ofierze. Po imporcie backend podejmuje próbę enumeracji dostępnych akcji narzędzia. Jeżeli wykorzystywany jest transport stdio, ten etap może doprowadzić do uruchomienia wcześniej zdefiniowanej komendy systemowej.

To oznacza, że wykonanie złośliwego kodu nie musi następować dopiero po ręcznym uruchomieniu przepływu. W praktyce zagrożenie może materializować się już podczas importu lub otwarcia konfiguracji, co znacząco zwiększa skuteczność ataku i utrudnia użytkownikowi rozpoznanie momentu kompromitacji.

Publicznie dostępny kod PoC pokazuje możliwość uzyskania powłoki systemowej. W środowiskach kontenerowych skutki mogą być szczególnie dotkliwe, zwłaszcza gdy proces Flowise działa z szerokimi uprawnieniami lub jako root wewnątrz kontenera.

Konsekwencje / ryzyko

Najpoważniejszą konsekwencją jest możliwość wykonania dowolnego kodu z uprawnieniami procesu Flowise. To z kolei może prowadzić do pełnego przejęcia aplikacji, odczytu sekretów, kradzieży tokenów API, dostępu do baz danych oraz wykorzystania integracji z usługami chmurowymi i systemami biznesowymi.

Skala ryzyka jest wysoka, ponieważ atak może zostać ukryty w pozornie legalnym pliku importu i wykorzystuje natywne funkcje aplikacji. Dla zespołów bezpieczeństwa oznacza to większą trudność w detekcji oraz konieczność analizy zdarzeń, które na pierwszy rzut oka mogą wyglądać jak normalna aktywność administracyjna.

możliwość przejęcia serwera aplikacyjnego,
ekspozycja kluczy API i danych uwierzytelniających,
dostęp do połączonych baz danych i usług zewnętrznych,
ryzyko ruchu bocznego w infrastrukturze organizacji,
zwiększone prawdopodobieństwo automatyzacji ataków po publikacji PoC.

W wielu środowiskach produkcyjnych Flowise pełni rolę warstwy orkiestracyjnej pomiędzy modelami AI, źródłami danych, API i zasobami chmurowymi. Z tego względu skuteczna eksploatacja może wywołać konsekwencje wykraczające daleko poza samą aplikację.

Rekomendacje

Organizacje korzystające z Flowise w modelu self-hosted powinny potraktować tę podatność jako priorytet krytyczny. Najważniejszym krokiem jest niezwłoczne usunięcie podatnych wersji oraz ograniczenie powierzchni ataku związanej z mechanizmem MCP.

zaktualizować Flowise do wersji 3.1.0 lub nowszej,
wyłączyć albo ograniczyć obsługę stdio MCP tam, gdzie nie jest niezbędna,
zablokować import chatflow z niezweryfikowanych źródeł,
ograniczyć liczbę użytkowników mogących tworzyć i edytować przepływy,
stosować zasadę najmniejszych uprawnień dla procesu Flowise,
unikać uruchamiania aplikacji z uprawnieniami root,
odseparować aplikację od wrażliwych zasobów poprzez segmentację sieci,
monitorować logi pod kątem nietypowych importów i uruchomień procesów potomnych,
przeprowadzić rotację sekretów i poświadczeń w razie podejrzenia kompromitacji,
wdrożyć dodatkowe zabezpieczenia kontenerowe, takie jak seccomp, AppArmor, SELinux oraz ograniczenia capabilities.

Z perspektywy detekcji warto korelować zdarzenia importu konfiguracji z pojawieniem się nowych procesów systemowych, nietypowymi połączeniami sieciowymi oraz zmianami w konfiguracji narzędzi MCP. W zespołach SOC zasadna jest również budowa reguł wykrywających procesy uruchamiane z kontekstu Flowise.

Podsumowanie

CVE-2026-40933 pokazuje, że w narzędziach AI szczególnie niebezpieczne mogą być błędy wynikające z połączenia legalnej funkcjonalności z niekontrolowanym wykonaniem komend systemowych. Publikacja kodu exploitacji znacząco zwiększa prawdopodobieństwo realnych ataków na instancje self-hosted.

Dla organizacji korzystających z Flowise oznacza to konieczność natychmiastowej weryfikacji wersji oprogramowania, ograniczenia funkcji MCP, przeglądu uprawnień oraz analizy ewentualnych śladów wcześniejszej kompromitacji. Im większy dostęp aplikacji do danych, modeli i usług produkcyjnych, tym poważniejsze mogą być skutki udanego ataku.

Źródła

SecurityWeek – Exploit Code Published for Critical Flowise RCE Vulnerability — https://www.securityweek.com/exploit-code-published-for-critical-flowise-rce-vulnerability/
NVD – CVE-2026-40933 — https://nvd.nist.gov/vuln/detail/CVE-2026-40933
Flowise – GitHub Repository — https://github.com/FlowiseAI/Flowise
Obsidian Security – Technical analysis of Flowise MCP exploitation — https://www.obsidiansecurity.com/

Ataki z agentem LLM po luce Marimo CVE-2026-39987: nowy etap post-exploitation

Wprowadzenie do problemu / definicja

Badacze bezpieczeństwa opisali incydent, w którym po wykorzystaniu krytycznej luki w Marimo napastnik nie poprzestał na prostym uzyskaniu dostępu do systemu. Zamiast klasycznego zestawu sztywnych skryptów użyto agenta opartego na dużym modelu językowym, który wykonywał kolejne działania po kompromitacji w sposób adaptacyjny, reagując na wyniki komend i charakterystykę środowiska.

To istotna zmiana w krajobrazie zagrożeń. Agent LLM może działać jak półautonomiczny operator: rozpoznawać host, wyszukiwać sekrety, planować następne kroki i modyfikować przebieg ataku bez konieczności ręcznej interwencji na każdym etapie.

W skrócie

CVE-2026-39987 dotyczy nieuwierzytelnionego zdalnego wykonywania kodu w Marimo przez endpoint WebSocket /terminal/ws.
Podatność umożliwiała uzyskanie pełnej interaktywnej powłoki PTY bez logowania na wersjach wcześniejszych niż 0.23.0.
W zaobserwowanym ataku napastnik wydobył poświadczenia chmurowe, pobrał klucz SSH z AWS Secrets Manager, wykonał ruch lateralny i uzyskał dostęp do wewnętrznej bazy PostgreSQL.
Charakter poleceń wskazywał, że działania po kompromitacji mogły być realizowane przez agenta LLM.

Kontekst / historia

Marimo to reaktywny notebook Pythona wykorzystywany przez zespoły analityczne, inżynieryjne i deweloperskie. Tego typu narzędzia często działają blisko danych, środowisk testowych, sekretów aplikacyjnych oraz usług chmurowych, dlatego ich ekspozycja do internetu znacząco zwiększa powierzchnię ataku.

Po ujawnieniu CVE-2026-39987 okazało się, że problem wynikał z niewłaściwej kontroli autoryzacji dla terminalowego endpointu WebSocket. Luka została usunięta w wersji 0.23.0, ale publicznie dostępne, niezałatane instancje szybko stały się atrakcyjnym celem. Z perspektywy obrońców to kolejny przykład, że narzędzia AI i data science nie mogą być traktowane jako zasoby o niskim ryzyku tylko dlatego, że nie są systemami produkcyjnymi w klasycznym rozumieniu.

Analiza techniczna

Istota podatności sprowadzała się do tego, że endpoint /terminal/ws akceptował połączenia bez prawidłowej weryfikacji uwierzytelnienia. W praktyce umożliwiało to nieautoryzowanemu użytkownikowi uzyskanie interaktywnej powłoki systemowej, czyli bardzo silnego punktu wejścia do dalszej kompromitacji.

W opisanym scenariuszu atak rozpoczął się od przejęcia publicznie wystawionej instancji Marimo. Następnie napastnik przeszukał środowisko pod kątem poświadczeń, odnalazł dane dostępowe do usług chmurowych i użył ich do odczytu sekretu z AWS Secrets Manager. W kolejnym kroku pobrano prywatny klucz SSH, zestawiono krótkie sesje do kolejnych systemów i dotarto do segmentu infrastruktury zawierającego bazę PostgreSQL, z której wyeksfiltrowano dane.

Najbardziej niepokojące było jednak nie samo przejście przez kolejne etapy, ale sposób realizacji działań. Badacze zwrócili uwagę na kilka elementów sugerujących użycie agenta LLM: improwizowaną sekwencję poleceń zależną od bieżących wyników, obecność komentarza planistycznego, formułowanie komend w sposób uporządkowany i przyjazny przetwarzaniu maszynowemu oraz przekazywanie wyników poprzednich komend do kolejnych decyzji operacyjnych.

Taki model działania oznacza, że atakujący nie musi wcześniej znać dokładnej architektury środowiska ofiary. Wystarczy ogólna wiedza o systemach Linux, sposobach przechowywania sekretów, konwencjach administracyjnych i typowych narzędziach, aby agent po uzyskaniu powłoki samodzielnie eksplorował host i budował kolejne etapy łańcucha ataku.

Konsekwencje / ryzyko

Ryzyko związane z tym incydentem wykracza daleko poza pojedyncze RCE. Najpoważniejszym problemem jest skrócenie czasu od uzyskania dostępu do osiągnięcia realnego wpływu biznesowego. Jeżeli agent potrafi samodzielnie odnajdywać poświadczenia, pobierać sekrety, wykonywać ruch boczny i identyfikować wartościowe zasoby, okno czasowe na detekcję i reakcję staje się znacznie krótsze.

Dodatkowo agentyczne post-exploitation zwiększa odporność napastnika na błędy i nietypowe warunki środowiskowe. Klasyczny skrypt często zawodzi przy niestandardowych ścieżkach, innym układzie katalogów czy odmiennym schemacie systemu. Agent może natomiast analizować wyniki, korygować plan i próbować alternatywnych metod, co podnosi skuteczność operacji w zróżnicowanych środowiskach.

Dla organizacji oznacza to ryzyko przejęcia kont chmurowych, utraty kluczy SSH, kompromitacji baz danych, wycieku danych wrażliwych oraz dalszego rozprzestrzenienia się ataku na środowiska deweloperskie i produkcyjne. Szczególnie narażone są firmy, które dopuszczają bezpośrednią ekspozycję notebooków i pomocniczych usług inżynieryjnych do internetu.

Rekomendacje

Najważniejszym działaniem jest natychmiastowa aktualizacja Marimo do wersji 0.23.0 lub nowszej oraz pełna inwentaryzacja wszystkich instancji dostępnych z sieci publicznej. Dotyczy to także środowisk testowych, tymczasowych i tworzonych ad hoc przez zespoły analityczne.

Należy również założyć możliwość wcześniejszej kompromitacji każdego hosta działającego na podatnej wersji. W praktyce oznacza to konieczność rotacji kluczy API, poświadczeń AWS, kluczy SSH, haseł do baz danych oraz wszystkich tokenów zapisanych lokalnie lub dostępnych przez zmienne środowiskowe. Sama poprawka nie eliminuje skutków potencjalnego włamania.

Ograniczyć ekspozycję notebooków i narzędzi AI do internetu.
Wymusić silne uwierzytelnianie przez reverse proxy lub warstwę pośrednią.
Zminimalizować uprawnienia IAM i dostęp do menedżerów sekretów.
Wdrożyć segmentację sieci, aby hosty deweloperskie nie miały bezpośredniej ścieżki do bastionów, baz danych i paneli administracyjnych.
Monitorować nietypowe połączenia do terminalowych endpointów WebSocket oraz seryjne, krótkie sekwencje komend systemowych.
Analizować użycie AWS Secrets Manager i sesji SSH inicjowanych z nieoczekiwanych hostów.

Podsumowanie

Incydent związany z CVE-2026-39987 pokazuje, że nowoczesny post-exploitation coraz częściej przybiera formę agentyczną. Krytyczna luka w Marimo umożliwiła uzyskanie dostępu, ale prawdziwym sygnałem ostrzegawczym jest to, że po wejściu na host napastnik mógł szybko przejść do kradzieży sekretów, ruchu lateralnego i eksfiltracji danych przy wsparciu mechanizmu przypominającego autonomicznego operatora.

Dla zespołów bezpieczeństwa oznacza to potrzebę szybszego patchowania, mocniejszej segmentacji, ograniczania uprawnień oraz budowania detekcji ukierunkowanej nie tylko na sam exploit, lecz także na wzorce elastycznego, zautomatyzowanego działania po kompromitacji.

Źródła

GREYVIBE: rosyjskojęzyczna grupa wykorzystuje AI do cyberataków wymierzonych w Ukrainę

Wprowadzenie do problemu / definicja

GREYVIBE to nowo opisana grupa zagrożeń prowadząca operacje wymierzone w Ukrainę oraz podmioty powiązane z sektorem wojskowym, publicznym, cywilnym i biznesowym. Jej działalność wyróżnia łączenie klasycznych technik cyberwywiadowczych z wykorzystaniem narzędzi opartych na generatywnej sztucznej inteligencji, co pozwala szybciej przygotowywać infrastrukturę, przynęty socjotechniczne i komponenty złośliwego oprogramowania.

Z perspektywy obrońców jest to istotny sygnał zmiany w krajobrazie zagrożeń. Automatyzacja części procesu operacyjnego przez modele AI skraca czas potrzebny na tworzenie nowych wariantów malware i utrudnia wykrywanie kampanii wyłącznie na podstawie znanych sygnatur.

W skrócie

GREYVIBE prowadzi aktywne operacje co najmniej od sierpnia 2025 roku.
Grupa wykorzystuje spear phishing, fałszywe strony CAPTCHA, strony podszywające się pod ukraińskie podmioty oraz malware na Windows i Androida.
W arsenale aktora znalazły się m.in. PhantomRelay, LegionRelay i FallSpy.
Badacze wskazują, że modele AI i LLM wspierają rozwój elementów operacyjnych, obfuskację i przygotowanie infrastruktury.
Celem działań wydaje się przede wszystkim pozyskiwanie informacji wywiadowczych oraz utrzymywanie dostępu do środowisk ofiar.

Kontekst / historia

GREYVIBE wpisuje się w szerszy krajobraz operacji prowadzonych w interesie Federacji Rosyjskiej w kontekście wojny rosyjsko-ukraińskiej. Profil ofiar sugeruje ukierunkowanie na długotrwałe rozpoznanie i pozyskiwanie danych, a nie wyłącznie na destrukcję systemów czy szybki zysk finansowy.

Jednocześnie grupa nie sprawia wrażenia w pełni dojrzałego, jednolitego zespołu państwowego. Analitycy zwracają uwagę na błędy operacyjne, ślady testowych wersji malware oraz relacje z szerszym ekosystemem cyberprzestępczym. Taki model hybrydowy utrudnia jednoznaczną atrybucję i pokazuje, że granica między klasycznym APT a grupą przestępczą staje się coraz mniej wyraźna.

Analiza techniczna

GREYVIBE korzysta z kilku łańcuchów infekcji dostosowanych do rodzaju ofiary i wykorzystywanej platformy. W kampanii określanej jako PhantomMail stosowano wiadomości spear phishingowe zawierające odnośniki do archiwów ZIP lub RAR. Wewnątrz znajdował się loader JavaScript, który uruchamiał dokument-wabik i wdrażał komponent PhantomRelay. Ten pełnił rolę zdalnego trojana dostępowego opartego na PowerShell, umożliwiającego profilowanie hosta oraz wykonywanie poleceń systemowych.

Wariant PhantomClick bazował na stronach podszywających się pod legalne usługi i wykorzystywał mechanikę fałszywego CAPTCHA w stylu ClickFix. Ofiara była nakłaniana do samodzielnego uruchomienia poleceń, co prowadziło do wdrożenia kolejnego etapu infekcji. To przykład skutecznego połączenia socjotechniki z techniką living-off-the-land, ponieważ część działań wykonywano przy użyciu natywnych mechanizmów Windows.

Kampania PrincessClub wykorzystywała fałszywe strony ukraińskich klubów dla dorosłych. W zależności od urządzenia ofiara otrzymywała spyware FallSpy dla Androida albo malware PhantomRelayV1 i LegionRelay dla Windows. Późniejsze wersje stron zawierały też funkcję połączenia na żywo opartą na WebRTC, co mogło zwiększać wiarygodność przynęty i wspierać przechwytywanie audio lub wideo.

FallSpy został opisany jako spyware dla Androida nastawiony na pozyskiwanie wrażliwych danych z urządzenia. LegionRelay to z kolei lekki RAT oparty na PowerShell, obsługujący enumerację plików, eksfiltrację danych, wykonywanie zrzutów ekranu, kradzież danych z przeglądarek, pozyskiwanie informacji z komunikatorów oraz konfigurację dostępu RDP. PhantomRelayV1 rozwija te możliwości o mechanizmy trwałości, w tym niestandardowy watchdog.

W łańcuchu DroneLink atakujący wykorzystywali strony podszywające się pod fundacje charytatywne wspierające ukraińskie siły zbrojne. Celem było dostarczenie komponentów takich jak WireGuard i LegionRelay, co może wskazywać na próbę zestawienia trwałego kanału komunikacyjnego lub tunelowania ruchu po skutecznej kompromitacji.

Opisano również kampanię Nebo, w której próbka FallSpy imitowała rosyjskojęzyczny ekran logowania. Taki zabieg mógł służyć dezorientacji ofiar i budowaniu wrażenia pracy w wiarygodnym środowisku.

Najciekawszym aspektem technicznym pozostaje wykorzystanie AI do wspierania rozwoju operacji. Badacze wskazali, że generatywna sztuczna inteligencja mogła być używana do tworzenia grafik, rozwijania komponentów LegionRelay, przygotowywania loaderów i skryptów obfuskacyjnych, budowy zaplecza infrastrukturalnego oraz opracowywania komend wykorzystywanych po uzyskaniu dostępu. Jednocześnie analiza próbek ujawniła błędy projektowe i ślady niedojrzałości, co pokazuje, że przyspieszenie developmentu nie zawsze oznacza wysoką jakość operacyjną.

Konsekwencje / ryzyko

Działania GREYVIBE zwiększają presję na organizacje funkcjonujące w regionach objętych konfliktem oraz na podmioty współpracujące z administracją, wojskiem i sektorem pomocowym. Zagrożenie nie ogranicza się do utraty poufności danych. Obejmuje także długotrwałe rozpoznanie środowiska, kradzież danych uwierzytelniających, przejęcie komunikacji oraz wykorzystanie legalnych kanałów zdalnego dostępu do dalszej penetracji infrastruktury.

Szczególnie niebezpieczne jest łączenie wielu wektorów dostępu: phishingu, stron-wabików, infekcji mobilnych oraz komponentów PowerShell wdrażanych na stacjach roboczych. Taka wielowarstwowość zwiększa odporność kampanii na punktowe działania obronne i utrudnia pełne odtworzenie przebiegu incydentu.

Dodatkowym wyzwaniem jest rozwój malware wspomagany przez AI. Jeżeli aktor potrafi szybko przebudowywać loadery, skrypty i infrastrukturę, tradycyjne metody detekcji oparte na stałych sygnaturach mogą okazać się niewystarczające. Dla zespołów SOC oznacza to konieczność większego oparcia się na analizie zachowań, korelacji telemetrii i wykrywaniu anomalii.

Rekomendacje

Organizacje narażone na podobne kampanie powinny w pierwszej kolejności wzmocnić ochronę poczty i komunikacji użytkowników. W praktyce oznacza to rygorystyczne filtrowanie załączników i archiwów, sandboxing wiadomości oraz wdrożenie mechanizmów wykrywania phishingu ukierunkowanego.

W środowiskach Windows warto ograniczyć wykonywanie nieautoryzowanych skryptów PowerShell, monitorować uruchamianie interpreterów skryptowych oraz wykrywać nietypowe sekwencje poleceń kopiowanych przez użytkownika do okien dialogowych i terminali. Szkolenia z zakresu awareness powinny obejmować nie tylko klasyczne wiadomości phishingowe, ale także scenariusze fałszywych stron CAPTCHA i technik ClickFix.

Niezbędne jest również monitorowanie anomalii związanych z RDP, tworzeniem tuneli sieciowych, wykorzystaniem narzędzi zdalnego dostępu oraz próbami eksfiltracji danych z przeglądarek i komunikatorów. W przypadku urządzeń mobilnych należy egzekwować polityki MDM, ograniczać instalację aplikacji spoza zaufanych źródeł i analizować uprawnienia aplikacji pod kątem dostępu do wiadomości, mikrofonu, aparatu i pamięci urządzenia.

Budować reguły behawioralne dla uruchomień JavaScript z archiwów pobranych z internetu.
Monitorować nietypową aktywność PowerShell po otwarciu dokumentów lub stron phishingowych.
Wykrywać połączenia WebRTC inicjowane przez mało znane domeny.
Analizować nagłe tworzenie zdalnych kanałów administracyjnych i tuneli.
Łączyć telemetrię z hostów, poczty, proxy, EDR i urządzeń mobilnych.

Podsumowanie

GREYVIBE pokazuje, że współczesne operacje cyberwywiadowcze coraz częściej łączą klasyczne techniki infekcji z szybkim rozwojem komponentów wspomaganym przez sztuczną inteligencję. Grupa atakuje cele związane z Ukrainą, wykorzystuje zróżnicowane łańcuchy dostępu i działa na styku cyberprzestępczości oraz aktywności powiązanej z interesami państwowymi.

Dla obrońców najważniejszy wniosek jest praktyczny: sama znajomość nazw malware nie wystarcza. Skuteczna obrona wymaga monitorowania zachowań, ograniczania możliwości wykonywania skryptów, wzmacniania bezpieczeństwa urządzeń mobilnych oraz ciągłego dostosowywania detekcji do kampanii, które mogą dynamicznie zmieniać swoje artefakty techniczne dzięki użyciu AI.

Źródła

CERT-In zaleca łatanie krytycznych luk w systemach internetowych w 12 godzin

Wprowadzenie do problemu / definicja

Indyjski zespół reagowania na incydenty komputerowe CERT-In opublikował nowe wytyczne dotyczące ograniczania ekspozycji na podatności, które mogą być wykorzystywane w atakach wspieranych przez sztuczną inteligencję. Najważniejszym elementem dokumentu jest rekomendacja, aby krytyczne luki w systemach dostępnych z internetu były usuwane w ciągu 12 godzin od ich identyfikacji, o ile jest to operacyjnie możliwe.

To wyraźny sygnał, że tradycyjne modele zarządzania podatnościami przestają nadążać za tempem współczesnych kampanii ofensywnych. Rozwój modeli AI i LLM skraca czas potrzebny atakującym na analizę nowych błędów, przygotowanie exploitów i rozpoczęcie prób kompromitacji.

W skrócie

CERT-In chce skrócenia czasu reakcji na krytyczne podatności w systemach wystawionych do internetu do 12 godzin.
Powodem jest rosnące wykorzystanie AI do rekonesansu, analizy powierzchni ataku, phishingu i automatyzacji exploitacji.
Wytyczne promują ciągłą ocenę ryzyka, szybkie łatanie, architekturę Zero Trust i stosowanie środków kompensacyjnych.
Nowe podejście dotyczy nie tylko klasycznych systemów IT, ale również środowisk i komponentów AI.

Kontekst / historia

Presja na skracanie czasu reakcji na podatności nie jest nowym zjawiskiem, jednak w 2026 roku nabrała nowego znaczenia. CERT-In już wcześniej ostrzegał, że technologie AI o charakterze dual-use mogą zarówno obniżać próg wejścia dla mniej zaawansowanych napastników, jak i zwiększać skuteczność bardziej doświadczonych grup.

W praktyce nie chodzi już wyłącznie o szybsze wyszukiwanie błędów w kodzie czy analizę nowych wpisów CVE. Coraz większym problemem staje się automatyzacja całych łańcuchów ataku: od rozpoznania infrastruktury, przez identyfikację słabych punktów, po przygotowanie wiarygodnych wiadomości phishingowych i złośliwych komponentów.

Na tym tle klasyczny, tygodniowy cykl patch managementu może okazać się niewystarczający, szczególnie dla usług publicznie dostępnych, interfejsów API, środowisk chmurowych i systemów o wysokiej wartości biznesowej.

Analiza techniczna

Techniczny sens nowych wytycznych opiera się na założeniu, że cykl życia exploita ulega dalszej kompresji. Atakujący mogą dziś wykorzystywać AI do mapowania zasobów wystawionych do internetu, identyfikacji błędnych konfiguracji, analizy nowych podatności oraz szybkiego budowania proof-of-concept.

Do najważniejszych obszarów zastosowania AI po stronie ofensywnej należą:

rekonesans i analiza powierzchni ataku,
identyfikacja słabych tożsamości i niezabezpieczonych API,
automatyzacja przetwarzania informacji o podatnościach,
tworzenie treści phishingowych o wysokiej wiarygodności,
modyfikacja lub wspomaganie rozwoju złośliwego oprogramowania.

CERT-In zwraca też uwagę, że same systemy AI stają się atrakcyjnym celem. Wśród kluczowych zagrożeń wymieniane są prompt injection, wyciek danych, jailbreaking modeli, zatruwanie danych treningowych, kradzież modeli oraz kompromitacja pipeline’ów orkiestracji. Oznacza to, że bezpieczeństwo organizacji musi obejmować nie tylko serwery, stacje robocze i aplikacje, ale także modele, dane oraz warstwę integracyjną wykorzystywaną w procesach biznesowych.

Wytyczne różnicują również czasy remediacji. Najwyższy priorytet mają znane i aktywnie wykorzystywane podatności wpływające na systemy dostępne z internetu i infrastrukturę krytyczną. To właśnie dla nich rekomendowano 12-godzinne okno naprawcze, jeśli wdrożenie poprawki jest wykonalne.

Jeśli poprawka nie jest jeszcze dostępna, organizacja powinna wdrożyć środki kompensacyjne. Mogą one obejmować izolację systemu, ograniczenie dostępu, ochronę za pomocą WAF lub mechanizmów bezpieczeństwa API, wyłączenie podatnej funkcji oraz podniesienie poziomu monitoringu telemetrycznego i detekcyjnego.

Konsekwencje / ryzyko

Dla zespołów bezpieczeństwa i operacji IT nowe wytyczne oznaczają konieczność przebudowy procesu zarządzania podatnościami. Największym wyzwaniem będzie pogodzenie szybkości wdrożeń z zachowaniem kontroli zmian, zwłaszcza w złożonych środowiskach produkcyjnych i hybrydowych.

Spełnienie 12-godzinnego celu może wymagać:

pełnej widoczności aktywów i ich ekspozycji,
automatycznej priorytetyzacji podatności według ryzyka,
gotowych procedur emergency change,
stałej współpracy między SOC, IT, DevOps, zespołami chmurowymi i właścicielami aplikacji,
sprawnych testów regresji oraz procedur rollbacku.

Największe ryzyko dotyczy organizacji, które nadal utrzymują długie okna patchowania dla systemów internet-facing. To właśnie takie zasoby często stają się pierwszym punktem wejścia do środowiska poprzez zdalne wykonanie kodu, nadużycia API, przejęcie kont uprzywilejowanych, eskalację uprawnień lub ruch boczny po uzyskaniu dostępu.

Opóźnione łatanie może prowadzić do incydentów ransomware, kradzieży danych, zakłóceń ciągłości działania i problemów w łańcuchu dostaw. Dodatkowo AI zwiększa nie tylko skuteczność, ale również skalę ataków, co przekłada się na większą liczbę prób kompromitacji i szybszą adaptację kampanii do środowiska ofiary.

Rekomendacje

Organizacje powinny potraktować nowe wytyczne jako impuls do przejścia na model risk-based vulnerability management wspierany automatyzacją. W praktyce warto skupić się na kilku kluczowych działaniach.

Zidentyfikować wszystkie zasoby dostępne z internetu, w tym usługi chmurowe, API, panele administracyjne, VPN i komponenty zewnętrzne.
Wyodrębnić aktywa krytyczne biznesowo i przypisać im krótsze SLA naprawcze.
Zautomatyzować korelację danych z asset inventory, skanerów podatności, telemetryki SOC oraz informacji o aktywnej eksploatacji.
Wdrożyć procedury szybkiego patchingu dla zmian awaryjnych wraz z gotowymi scenariuszami testów i cofnięcia zmian.
Rozwijać architekturę Zero Trust oraz zasadę least privilege dla kont uprzywilejowanych i integracji API.
Wzmacniać zabezpieczenia warstwowe, takie jak segmentacja, EDR/XDR, WAF, ochrona API i monitoring tożsamości.
Rozszerzyć program bezpieczeństwa na komponenty AI, obejmując modele, dane, integracje i polityki dostępu.
W przypadku braku łatki natychmiast stosować compensating controls i formalnie dokumentować decyzje dotyczące ryzyka.

Dla dużych organizacji kluczowe będzie także silniejsze powiązanie patch managementu z cyber threat intelligence. Sama ocena CVSS może nie wystarczyć, jeśli dana podatność dotyczy systemu publicznie dostępnego i pojawiają się sygnały o jej aktywnym wykorzystywaniu.

Podsumowanie

Nowe wytyczne CERT-In dobrze pokazują, że w realiach ataków wspieranych przez AI czas reakcji staje się równie istotny jak jakość samych zabezpieczeń. Zalecenie 12-godzinnego łatania krytycznych luk w systemach dostępnych z internetu nie jest wyłącznie ambitnym celem operacyjnym, ale odpowiedzią na skracający się czas uzbrajania podatności przez napastników.

Dla organizacji oznacza to konieczność większej automatyzacji, lepszej widoczności aktywów i ściślejszej integracji bezpieczeństwa z operacjami IT. W środowisku, w którym przeciwnik działa szybciej dzięki AI, opóźnienia liczone w dniach mogą stać się realnym ryzykiem biznesowym.

Źródła

Mythos Nie Wystarczy. Lekcja Z Cloudflare.

Mythos jednak nie taki wspaniały?

Mythos Preview to jeden z tych tematów, przy których łatwo popaść w skrajności. Jedni widzą początek końca klasycznego pentestingu. Drudzy widzą głównie marketing, PR i kolejną falę zachwytu nad AI. Prawda jest mniej wygodna: Mythos jest wystarczająco mocny, żeby potraktować go bardzo poważnie, ale nie jest magicznym inżynierem bezpieczeństwa, którego można podpiąć do repozytorium i powiedzieć: „znajdź wszystko, co groźne”.

Czytaj dalej

AI zwiększa świadomość podatności, ale nie przełamuje problemu ich wykrywania

Wprowadzenie do problemu / definicja

Sztuczna inteligencja coraz mocniej wchodzi do obszaru cyberbezpieczeństwa, szczególnie tam, gdzie organizacje próbują szybciej identyfikować podatności, porządkować alerty i ustalać priorytety działań naprawczych. W praktyce oznacza to rosnące zainteresowanie narzędziami opartymi na modelach AI i LLM, które mają wspierać zespoły bezpieczeństwa w analizie ekspozycji i ocenie ryzyka.

Jednak mimo wysokich oczekiwań rynkowych obecny stan technologii pokazuje, że AI przede wszystkim poprawia widoczność problemu podatności i ułatwia pracę analityków, a nie stanowi jeszcze przełomu w samodzielnym wykrywaniu luk. To rozróżnienie ma kluczowe znaczenie dla organizacji planujących inwestycje w defensive AI.

W skrócie

AI pomaga lepiej rozumieć powierzchnię ataku i porządkować dane o podatnościach.
Wpływ obecnych narzędzi AI na samo wykrywanie podatności pozostaje ograniczony.
Największą wartość AI daje dziś w triage, korelacji danych i priorytetyzacji działań.
Organizacje nadal muszą opierać się na klasycznych metodach bezpieczeństwa i nadzorze ekspertów.
Wdrożenia AI hamują m.in. koszty, braki kompetencyjne i ograniczone zaufanie do autonomicznych decyzji modeli.

Kontekst / historia

W ciągu ostatnich kilkunastu miesięcy AI stała się jednym z najczęściej dyskutowanych tematów w branży bezpieczeństwa. Firmy i instytucje zaczęły testować modele generatywne nie tylko w centrach operacji bezpieczeństwa, lecz także w analizie kodu, klasyfikacji podatności, skanowaniu zasobów i korelacji telemetrii.

Równolegle pojawiła się silna narracja marketingowa sugerująca, że AI może znacząco zwiększyć skuteczność wykrywania luk i odciążyć przeciążone zespoły bezpieczeństwa. Bardziej ostrożne oceny przyniosły jednak analizy rynku oraz pilotaże prowadzone przez instytucje publiczne. Wnioski z takich działań wskazują, że wpływ AI na operacyjne wykrywanie podatności jest zauważalny głównie w obszarze analityki wspomagającej, ale nie daje jeszcze wyraźnej przewagi nad rozwiązaniami niewykorzystującymi AI.

W praktyce komercyjnej obraz wygląda podobnie. Organizacje są zainteresowane defensive AI, zwłaszcza tam, gdzie chodzi o detekcję, threat intelligence i priorytetyzację ryzyka, ale większość wdrożeń pozostaje na wczesnym etapie dojrzałości. AI częściej działa dziś jako warstwa wspierająca proces decyzyjny niż jako autonomiczny mechanizm odkrywania krytycznych błędów.

Analiza techniczna

Z technicznego punktu widzenia AI może wnosić realną wartość do zarządzania podatnościami na kilku poziomach. Przede wszystkim pomaga agregować i normalizować dane pochodzące z wielu źródeł, takich jak skanery bezpieczeństwa, systemy EDR, repozytoria kodu, bazy zasobów czy informacje o aktywnie wykorzystywanych lukach. Dzięki temu analitycy szybciej uzyskują spójny obraz sytuacji.

Drugim obszarem jest wzbogacanie kontekstu. Modele AI mogą wspierać klasyfikację zgłoszeń, uwzględniając krytyczność zasobu, ekspozycję internetową, znaczenie biznesowe systemu, zależności usługowe czy potencjalne ścieżki ruchu atakującego. W efekcie łatwiej ustalić, które podatności wymagają natychmiastowej reakcji, a które mogą zostać obsłużone w późniejszym terminie.

Trzeci poziom to interfejs i użyteczność. Modele językowe upraszczają wyszukiwanie informacji, generowanie podsumowań oraz przygotowywanie rekomendacji naprawczych w języku naturalnym. To szczególnie cenne w środowiskach, gdzie zespoły bezpieczeństwa pracują pod presją czasu i muszą analizować dużą liczbę sygnałów.

Problem zaczyna się wtedy, gdy od AI oczekuje się samodzielnego i niezawodnego wykrywania nowych lub trudnych do uchwycenia podatności. Takie zadanie wymaga nie tylko rozpoznawania wzorców, ale również rozumienia semantyki kodu, architektury aplikacji, stanów wykonania, konfiguracji środowiska i relacji między komponentami. Obecne modele dobrze radzą sobie z analizą opisową i wspieraniem interpretacji danych, ale gorzej z deterministycznym wskazywaniem realnie wykorzystywalnych błędów.

Dodatkowym ograniczeniem są znane problemy systemów AI, takie jak halucynacje, niestabilność odpowiedzi, zależność od jakości danych wejściowych oraz trudności z walidacją wyników. W programach zarządzania podatnościami może to prowadzić do błędnej priorytetyzacji, pomijania istotnych luk albo generowania nadmiarowych alertów o niskiej wartości operacyjnej.

Konsekwencje / ryzyko

Największym ryzykiem związanym z obecną falą wdrożeń AI są błędne oczekiwania. Jeśli organizacja uzna, że sztuczna inteligencja samodzielnie rozwiąże problem zarządzania podatnościami, może zaniedbać podstawy bezpieczeństwa, takie jak inwentaryzacja aktywów, skuteczny patch management, segmentacja sieci, ograniczanie ekspozycji internetowej czy właściwe mapowanie krytyczności systemów.

Istotnym problemem jest również nadmierne zaufanie do rekomendacji modelu. W środowisku złożonym biznesowo nieprawidłowa ocena priorytetów może spowodować, że naprawdę krytyczna luka pozostanie niezałatana, podczas gdy zespół skupi się na mniej istotnych zdarzeniach. Z kolei zbyt duża liczba fałszywych alarmów zwiększa koszty operacyjne i prowadzi do zmęczenia alertami.

Nie można też pomijać ryzyk wynikających z samego wdrażania AI. Obejmują one bezpieczeństwo danych przekazywanych do modelu, kontrolę uprawnień, odporność integracji, ryzyko ujawnienia informacji wrażliwych oraz zależność od zewnętrznych dostawców. W efekcie AI w cyberbezpieczeństwie tworzy jednocześnie nową wartość i nową powierzchnię ataku.

Rekomendacje

Najbardziej racjonalnym podejściem jest traktowanie AI jako elementu wspierającego program zarządzania podatnościami, a nie jako jego podstawowego filaru. Organizacje powinny wdrażać takie rozwiązania w jasno zdefiniowanych przypadkach użycia, gdzie łatwo zmierzyć korzyści operacyjne i utrzymać nadzór nad wynikami.

Wykorzystywać AI do triage alertów, korelacji danych i wzbogacania kontekstu podatności.
Weryfikować rekomendacje modelu przez analityków, szczególnie przy lukach krytycznych i systemach produkcyjnych.
Mierzyć skuteczność AI za pomocą tych samych wskaźników co inne technologie bezpieczeństwa, np. MTTR, udział false positives i pokrycie aktywów.
Utrzymywać klasyczne fundamenty bezpieczeństwa: patching, segmentację, hardening, testy aplikacyjne i kontrolę zależności w łańcuchu dostaw.
Objąć wdrożenia AI odpowiednim governance, w tym kontrolą danych wejściowych, audytem decyzji modelu i oceną ryzyka dostawców.

Dopiero takie połączenie pozwala wykorzystać zalety AI bez tworzenia fałszywego poczucia bezpieczeństwa. W obecnej fazie rozwoju technologii kluczowe pozostaje połączenie automatyzacji z eksperckim nadzorem człowieka.

Podsumowanie

AI realnie zwiększa świadomość podatności i pomaga zespołom bezpieczeństwa szybciej zrozumieć, co dzieje się w ich środowisku. To ważny postęp, zwłaszcza w dużych organizacjach, które muszą obsługiwać rozproszoną infrastrukturę oraz stale rosnącą liczbę sygnałów bezpieczeństwa.

Jednocześnie obecne narzędzia nie potwierdzają jeszcze, że sztuczna inteligencja jest w stanie autonomicznie i niezawodnie przełamać problem wykrywania podatności. Najbardziej dojrzałe podejście polega dziś na łączeniu AI z tradycyjnymi metodami bezpieczeństwa, kontrolą procesów i stałą walidacją wyników przez ekspertów.

Źródła

AI Raises Vulnerability Awareness, But Detection Impact Remains Limited — https://www.infosecurity-magazine.com/news/ai-raises-vulnerability-awareness/
Pilot for Artificial Intelligence Enabled Vulnerability Detection — https://www.cisa.gov/resources-tools/resources/pilot-artificial-intelligence-enabled-vulnerability-detection
Joint Guidance on Deploying AI Systems Securely — https://www.cisa.gov/news-events/alerts/2024/04/15/joint-guidance-deploying-ai-systems-securely
NSA Publishes Guidance for Strengthening AI System Security — https://www.nsa.gov/serve-from-netstorage/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3741371/nsa-publishes-guidance-for-strengthening-ai-system-security/index.html
AI adoption in security taking off amid budget, trust, and skill-based issues — https://www.csoonline.com/article/1307294/ai-adoption-in-security-taking-off-amid-budget-trust-and-skill-based-issues.html

Krytyczna luka w Ollama umożliwia zdalny wyciek pamięci procesu

Wprowadzenie do problemu / definicja

Wraz z rosnącą popularnością lokalnie uruchamianych modeli językowych bezpieczeństwo infrastruktury AI staje się równie ważne jak ochrona klasycznych aplikacji serwerowych. Najnowsze ustalenia badaczy wskazują na krytyczną podatność w Ollama, popularnym narzędziu do uruchamiania modeli LLM lokalnie oraz przez API.

Luka została oznaczona jako CVE-2026-7482 i dotyczy błędu odczytu poza zakresem pamięci procesu. W praktyce oznacza to, że zdalny, nieuwierzytelniony atakujący może doprowadzić do ujawnienia danych znajdujących się w pamięci usługi, jeśli instancja jest dostępna z sieci.

W skrócie

Podatność oznaczono jako CVE-2026-7482.
Poziom zagrożenia oceniono jako krytyczny, z wynikiem 9.1 w skali CVSS.
Problem dotyczy wersji Ollama wcześniejszych niż 0.17.1.
Atak wykorzystuje obsługę plików GGUF oraz endpoint /api/create.
Skutkiem może być wyciek danych z pamięci procesu, w tym sekretów i treści przetwarzanych przez model.

Kontekst / historia

Ollama zdobyła popularność jako rozwiązanie upraszczające lokalne uruchamianie modeli językowych bez konieczności korzystania z chmury publicznej. Z tego powodu narzędzie jest często używane w środowiskach deweloperskich, laboratoriach AI, wewnętrznych wdrożeniach firmowych oraz integracjach z agentami i systemami automatyzacji.

Wiele organizacji wystawia jednak interfejs API do sieci, aby przyspieszyć integrację z aplikacjami lub usługami pośredniczącymi. To właśnie taki model wdrożenia zwiększa ryzyko wykorzystania opisywanej luki, ponieważ podatność może zostać użyta bez logowania, jeśli usługa jest osiągalna z zewnątrz.

Znaczenie problemu wykracza poza zwykłą destabilizację procesu. W tym przypadku zagrożona jest poufność danych, a więc nie tylko konfiguracja hosta, ale również prompty systemowe, kontekst rozmów, odpowiedzi modeli, tokeny oraz informacje przetwarzane równolegle przez inne zadania.

Analiza techniczna

Źródłem podatności jest błąd typu out-of-bounds read w mechanizmie ładowania modeli GGUF oraz w ścieżce związanej z przetwarzaniem i kwantyzacją modelu. Aplikacja akceptuje plik GGUF dostarczony przez użytkownika, a następnie interpretuje metadane opisujące położenie i rozmiary tensorów.

Jeżeli te wartości zostaną celowo sfałszowane i wskażą obszary wykraczające poza rzeczywistą zawartość pliku, serwer może odczytać dane spoza przewidzianego bufora. Problem jest szczególnie groźny, ponieważ występuje w obszarze wykorzystującym operacje niskopoziomowe, co ogranicza ochronę typową dla bezpieczniejszych mechanizmów zarządzania pamięcią.

Scenariusz ataku jest relatywnie prosty. Napastnik dostarcza spreparowany plik GGUF do instancji Ollama, a następnie uruchamia proces tworzenia modelu przez endpoint /api/create. W wadliwej ścieżce przetwarzania aplikacja może wczytać fragmenty pamięci sterty i zapisać je do tworzonego artefaktu modelu, który następnie może zostać wyprowadzony poza środowisko ofiary.

To sprawia, że wyciek obejmuje potencjalnie nie tylko dane samego procesu, ale też informacje pochodzące z aktywnych sesji użytkowników, integracji narzędziowych i zewnętrznych komponentów podłączonych do serwera LLM. W środowiskach produkcyjnych skala takiego incydentu może być znacznie większa niż w typowych aplikacjach testowych.

Konsekwencje / ryzyko

Największym zagrożeniem jest utrata poufności. W pamięci procesu mogą znajdować się klucze API, tokeny dostępowe, zmienne środowiskowe, dane klientów, fragmenty kodu, treści dokumentów biznesowych oraz zapis konwersacji z modelem.

Ryzyko istotnie rośnie, gdy instancja Ollama jest publicznie dostępna albo udostępniona wewnętrznie bez segmentacji sieci i dodatkowej warstwy uwierzytelniania. W takich przypadkach pojedyncza luka może stać się punktem wejścia do szerszego incydentu obejmującego wiele aplikacji korzystających z tego samego backendu AI.

Szczególnie niebezpieczny jest też charakter eksfiltracyjny podatności. Organizacja może nie zauważyć ataku od razu, ponieważ nie musi on powodować awarii, zakłóceń usług ani innych wyraźnych objawów operacyjnych. W praktyce możliwy jest cichy wyciek danych poprzez utworzony artefakt modelu.

Rekomendacje

Najważniejszym krokiem jest niezwłoczna aktualizacja Ollama do wersji 0.17.1 lub nowszej, zawierającej poprawkę bezpieczeństwa. Sama aktualizacja nie powinna jednak być jedynym środkiem zaradczym, ponieważ duża część ryzyka wynika również z niewłaściwej ekspozycji usługi.

Ograniczyć dostęp do API wyłącznie do zaufanych segmentów sieci.
Ukryć usługę za firewallem, reverse proxy lub API gateway.
Wymusić uwierzytelnianie i autoryzację dla operacji administracyjnych oraz tworzenia modeli.
Zablokować import modeli i artefaktów z niezaufanych źródeł.
Monitorować użycie endpointów takich jak /api/create oraz operacje publikacji artefaktów.
Przeprowadzić audyt sekretów i zmiennych środowiskowych dostępnych dla procesu.
Ograniczyć uprawnienia procesu i uruchamiać usługę w możliwie odizolowanym środowisku.
Analizować logi pod kątem nietypowych operacji tworzenia modeli i połączeń wychodzących.

W środowiskach produkcyjnych warto również traktować serwery LLM jako systemy wysokiego ryzyka dla danych. Oznacza to potrzebę klasyfikacji przetwarzanych informacji, ograniczania czasu życia sekretów, separacji tenantów oraz kontroli przepływu danych pomiędzy użytkownikami, agentami i narzędziami.

Podsumowanie

CVE-2026-7482 pokazuje, że platformy AI uruchamiane lokalnie mogą zawierać klasyczne błędy bezpieczeństwa o bardzo poważnych skutkach biznesowych. W przypadku Ollama problem ma charakter krytyczny, ponieważ umożliwia zdalny i nieuwierzytelniony wyciek pamięci procesu poprzez spreparowany plik modelu i otwarty interfejs API.

Dla organizacji korzystających z lokalnych modeli językowych to wyraźny sygnał, że bezpieczeństwo warstwy inferencyjnej musi być oceniane tak samo rygorystycznie jak bezpieczeństwo aplikacji produkcyjnych. Szybkie wdrożenie poprawek, ograniczenie ekspozycji sieciowej i wzmocnienie kontroli dostępu powinny być w tym przypadku absolutnym priorytetem.

Źródła

The Hacker News — https://thehackernews.com/2026/05/ollama-out-of-bounds-read-vulnerability.html
CVE Record: CVE-2026-7482 — https://www.cve.org/CVERecord?id=CVE-2026-7482
Cyera Research — Bleeding Llama: Critical Unauthenticated Memory Leak in Ollama — https://www.cyera.com/research/bleeding-llama-critical-unauthenticated-memory-leak-in-ollama
Ollama Releases — https://github.com/ollama/ollama/releases