Archiwa: LLM - Strona 9 z 11 - Security Bez Tabu

Tag: LLM

Skanowanie otwartych endpointów LLM: „How many states are there in the United States?” jako sygnał rozpoznania

Wprowadzenie do problemu / definicja luki

Wraz z upowszechnieniem wdrożeń LLM (lokalnych i chmurowych) rośnie liczba usług wystawianych na Internet „na szybko”: bez uwierzytelnienia, z błędną konfiguracją reverse proxy, z domyślnymi ustawieniami CORS albo z niekontrolowanym ruchem wychodzącym. To nie jest pojedyncza luka CVE, tylko klasa ryzyk: nieautoryzowana ekspozycja endpointów LLM oraz nadużycia wynikające z błędnych konfiguracji pośredników (proxy).

Sygnałem, że ktoś „szuka otwartych LLM”, mogą być pozornie banalne zapytania. SANS Internet Storm Center pokazał przypadek, w którym honeypot rejestrował powtarzające się requesty z promptem: „How many states are there in the United States?” – traktowane jako rozpoznanie (recon) w celu wykrycia dostępnych, niechronionych usług LLM.

W skrócie

  • Atakujący prowadzą systematyczną enumerację publicznie dostępnych endpointów LLM i źle skonfigurowanych proxy, używając „bezpiecznych” promptów do fingerprintingu modelu.
  • GreyNoise opisało kampanię, w której w 11 dni wygenerowano 80 469 sesji i sondowano 73+ endpointów (formaty kompatybilne z OpenAI oraz Google Gemini).
  • W praktyce ryzyko dotyczy m.in. wdrożeń lokalnych (np. Ollama), gdy ktoś celowo lub przypadkiem wystawi API na sieć/Internet bez warstwy uwierzytelnienia. Ollama domyślnie nasłuchuje na 127.0.0.1:11434, ale można to zmienić zmienną OLLAMA_HOST — co bywa początkiem problemów, jeśli zabraknie kontroli dostępu.

Kontekst / historia / powiązania

Wzorzec jest znany z innych usług: najpierw ciche mapowanie powierzchni ataku, potem dopiero eksploatacja (lub „monetyzacja” dostępu). W przypadku LLM „monetyzacja” bywa nietypowa:

  • użycie cudzej infrastruktury do generowania odpowiedzi (koszty),
  • dostęp do danych przesyłanych w promptach (tajemnice, PII, fragmenty kodu),
  • wykorzystanie modelu jako „silnika” do dalszych działań (np. automatyzacja phishingu, analiza danych, generowanie złośliwych treści – zależnie od polityk i zabezpieczeń).

GreyNoise zwraca uwagę na aspekt fingerprintingu bez wzbudzania alertów: zamiast agresywnych payloadów stosuje się neutralne pytania (w tym to o liczbę stanów USA), by potwierdzić, że endpoint żyje i jaki model/format API obsługuje.

Analiza techniczna / szczegóły luki

1) Jak wygląda rozpoznanie „na drzwiach” LLM

W logach honeypotów pojawiają się żądania HTTP przypominające typowe wywołania „chat/completions” lub endpointów kompatybilnych z OpenAI. W przykładzie z SANS widać request JSON zawierający pole prompt oraz charakterystyczny, powtarzalny tekst pytania, a także automatyzujący User-Agent (np. skaner).

To działa, bo:

  • wiele wdrożeń kopiuje „de facto standard” formatów API,
  • odpowiedź modelu (lub same błędy) pozwalają odróżnić implementacje,
  • prompt jest na tyle neutralny, że często omija proste reguły detekcji.

2) Co mówi telemetryka GreyNoise

GreyNoise opisuje kampanię enumeracyjną, w której testowano zarówno OpenAI-compatible API, jak i formaty Google Gemini, obejmując szerokie spektrum rodzin modeli. Kluczowe jest to, że zapytania były „niewinne”, a celem najpewniej było ustalenie co odpowiada i jakim modelem.

3) Dlaczego Ollama i podobne wdrożenia są wrażliwe na „przypadkową ekspozycję”

Ollama to częsty wybór do uruchamiania modeli lokalnie. Problem zaczyna się, gdy ktoś:

  • ustawia OLLAMA_HOST na adres dostępny w sieci,
  • publikuje port przez router/tunnel,
  • stawia reverse proxy „na szybko” bez autoryzacji.

Dokumentacja potwierdza, że domyślnie Ollama wiąże się z 127.0.0.1:11434 (czyli lokalnie), ale można ją wystawić na sieć przez zmianę bind address. Jednocześnie lokalny dostęp do API nie wymaga uwierzytelnienia — co jest OK dla localhost, ale ryzykowne po ekspozycji na zewnątrz.

Praktyczne konsekwencje / ryzyko

  1. Nieautoryzowane użycie zasobów i koszty
    Jeśli endpoint/proxy daje dostęp do płatnych usług albo kosztownej infrastruktury GPU, atakujący mogą „po cichu” generować obciążenie.
  2. Wyciek danych z promptów i kontekstu
    LLM często przetwarza dane wrażliwe (fragmenty kodu, logi, opisy incydentów). Przy błędnej konfiguracji kontroli dostępu ryzyko wycieku rośnie.
  3. DoS i degradacja jakości usługi
    OWASP wprost wskazuje „Model Denial of Service” jako kategorię ryzyka: modele można przeciążyć ruchem lub drogimi zapytaniami, powodując przestoje i koszty.
  4. Ryzyka łańcucha dostaw i integracji
    Gdy LLM ma „wtyczki”, akcje lub integracje, rośnie stawka: OWASP wymienia m.in. „Insecure Plugin Design” i „Excessive Agency” jako typowe problemy wdrożeń LLM.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań, które w praktyce najszybciej redukują ryzyko enumeracji i nadużyć:

Warstwa sieciowa i ekspozycja

  • Nie wystawiaj endpointów LLM bezpośrednio na Internet. Jeśli musisz, rób to przez reverse proxy z silnym uwierzytelnieniem i ograniczeniami.
  • Ogranicz dostęp po IP/VPN/Zero Trust (preferowane: dostęp tylko z sieci firmowej lub przez tunel z MFA).
  • Rate limiting i ochrona przed skanowaniem na warstwie proxy/WAF (limity per IP/ASN, detekcja burstów, blokady na nietypowe UA).

Uwierzytelnienie i autoryzacja

  • Traktuj LLM jak każdy krytyczny backend API: API key / mTLS / OIDC.
  • W przypadku wdrożeń lokalnych pamiętaj, że brak auth jest normalny dla localhost, ale po zmianie bind address to już poważna luka konfiguracyjna.

Monitoring i detekcja

  • Dodaj reguły SIEM/SOAR pod kątem powtarzalnych, „niewinnych” promptów używanych do fingerprintingu (np. pytania faktograficzne w dużej skali). GreyNoise pokazało, że takie prompty występują masowo.
  • Loguj: źródłowe IP, ścieżki endpointów, czasy odpowiedzi, kody błędów, rozmiary payloadów, nagłówki (w tym UA).

Higiena wdrożeniowa (LLM security baseline)

  • Oprzyj checklistę o OWASP Top 10 for LLM Applications: w praktyce najbardziej „natychmiastowe” są kontrola outputów (LLM02), ochrona przed DoS (LLM04), ochrona danych wrażliwych (LLM06) oraz ograniczenie agency/integracji (LLM08).

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

Enumeracja LLM ≠ klasyczne skanowanie CVE.
W tradycyjnym skanowaniu szuka się konkretnej podatności i wersji. Tutaj często chodzi o:

  • wykrycie „czy to w ogóle jest LLM”,
  • jaki format API obsługuje,
  • czy stoi za tym płatna usługa/proxy,
  • czy są jakiekolwiek bariery (auth, limity, filtracja).

Dlatego „bezpieczne” prompty są sprytne: pozwalają mapować cele bez generowania oczywistych sygnatur exploitów.

Podsumowanie / kluczowe wnioski

  • Powtarzalne, neutralne pytania (np. o liczbę stanów USA) mogą być realnym wskaźnikiem reconnaissance pod otwarte endpointy LLM.
  • Kampanie enumeracyjne są prowadzone na dużą skalę i obejmują wiele rodzin modeli oraz formatów API.
  • Największy błąd operacyjny to wystawienie API bez uwierzytelnienia (szczególnie po zmianie bind address lub przez źle skonfigurowane proxy).
  • Sensowna „minimum viable security” dla LLM to: brak publicznej ekspozycji, silny auth, limity, monitoring oraz checklista OWASP LLM Top 10.

Źródła / bibliografia

  • SANS Internet Storm Center (Didier Stevens), wpis dziennika o rekonesansie przez prompt „How many states…”. (SANS Internet Storm Center)
  • GreyNoise: Threat Actors Actively Targeting LLMs (opis kampanii enumeracyjnej i charakterystycznych promptów). (greynoise.io)
  • OWASP Foundation: Top 10 for Large Language Model Applications (kategorie ryzyk LLM). (owasp.org)
  • Ollama Docs: FAQ (domyślne bindowanie do localhost, ekspozycja przez OLLAMA_HOST, proxy). (docs.ollama.com)
  • Ollama Docs: API Authentication (brak auth lokalnie; znaczenie po ekspozycji). (docs.ollama.com)

Reprompt: jedno kliknięcie wystarczało, by przejąć sesję Microsoft Copilot i wyprowadzić dane

Wprowadzenie do problemu / definicja luki

„Reprompt” to opisany przez Varonis Threat Labs łańcuch ataku na Microsoft Copilot (wariant konsumencki: Copilot Personal), w którym napastnik mógł wstrzyknąć polecenie do Copilota przez legalny link i doprowadzić do cichej eksfiltracji danych po jednym kliknięciu. Kluczowy element: Copilot akceptował prompt przekazany w parametrze URL q i wykonywał go automatycznie po załadowaniu strony, co (w połączeniu z obejściami zabezpieczeń) umożliwiało działanie „w imieniu” zalogowanego użytkownika.

Microsoft załatał problem w aktualizacjach z 13 stycznia 2026 (Patch Tuesday), a według opisu nie ma potwierdzonych dowodów masowego wykorzystania „in the wild” w momencie publikacji.

W skrócie

  • Mechanizm wejścia: phishingowy (lub podsunięty innym kanałem) link do Copilota z ukrytym promptem w parametrze q.
  • Dlaczego to groźne: 1 klik, bez wtyczek/connectorów, a atak mógł utrzymywać sterowanie nawet po zamknięciu karty Copilota.
  • Trik na guardraile: tzw. double-request (polecenie wykonania tej samej akcji dwa razy) oraz chain-request (kolejne instrukcje pobierane z serwera atakującego).
  • Status: załatane przez Microsoft (Patch Tuesday 13.01.2026); Varonis podaje, że środowiska Microsoft 365 Copilot (enterprise) nie były objęte tym konkretnym scenariuszem.

Kontekst / historia / powiązania

Reprompt wpisuje się w szerszą klasę zagrożeń dla asystentów LLM: indirect prompt injection (pośrednie wstrzyknięcie poleceń), gdzie „instrukcje” dostarcza nie sam użytkownik, lecz dane z zewnątrz (np. link, treść strony, dokument). Microsoft wprost opisuje, że skutkiem takich ataków bywa m.in. eksfiltracja danych i wykonywanie niezamierzonych akcji z uprawnieniami użytkownika, dlatego promuje podejście „defense-in-depth” (m.in. izolowanie danych nieufnych, mechanizmy detekcji typu Prompt Shields, kontrola egress i governance).

Analiza techniczna / szczegóły luki

Varonis rozbił Reprompt na trzy kluczowe techniki, które razem tworzyły stabilny łańcuch eksfiltracji:

1) Parameter 2 Prompt (P2P) injection – q w URL

Copilot potrafił przyjąć prompt w parametrze q (np. copilot.microsoft.com/?q=<PROMPT>), a następnie automatycznie go wykonać po otwarciu strony. To „feature” UX-owy, ale jednocześnie gotowy wektor do nadużyć, bo ofiara widzi „legalny” link do usługi Microsoft.

2) Double-request technique – obejście guardrails przez „zrób to dwa razy”

Według opisu badaczy, zabezpieczenia Copilota (np. zasada „nie pobieraj URL bez uzasadnienia”, redakcja wrażliwych danych) w praktyce miały działać głównie dla pierwszego żądania. Badacze uzyskali obejście, każąc Copilotowi powtarzać akcję (wywołanie/fetch) dwukrotnie – w przykładzie część wrażliwa była usuwana w pierwszym podejściu, ale przechodziła w drugim.

3) Chain-request technique – sterowanie „z serwera” i eksfiltracja etapami

Najbardziej niebezpieczny element to „łańcuch” poleceń: po starcie z linku, Copilot był nakłaniany do pobrania kolejnych instrukcji z domeny atakującego (stage1 → stage2 → stage3…), a każda odpowiedź mogła być użyta do zbudowania następnego kroku. To utrudnia:

  • ocenę szkody przez ofiarę (pierwszy prompt nie ujawnia pełnej intencji),
  • detekcję po stronie klienta (bo „prawdziwe” polecenia przychodzą później),
  • ograniczenie ilości wykradanych informacji (ataker adaptuje pytania).

Co mogło wyciec?

W scenariuszach przytaczanych w opisie pojawiają się m.in. pamięć/konwersacje Copilota, kontekst konta i informacje osobiste (np. aktywność, lokalizacja, wątki rozmów), zależnie od tego, do czego Copilot ma dostęp w danym kontekście.

Praktyczne konsekwencje / ryzyko

Największe ryzyko operacyjne wynika z kombinacji: 1 klik + legalny link + „niewidoczna” kontynuacja ataku. W praktyce to:

  • phishing nowej generacji: użytkownik nie wpisuje promptu, nie instaluje wtyczek, nie „zezwala” jawnie — tylko otwiera URL.
  • wyciek danych trudny do odtworzenia: instrukcje mogą być dostarczane dopiero po rozpoczęciu sesji, więc analiza „co dokładnie poszło” jest trudna.
  • ryzyko reputacyjne i compliance (zwłaszcza jeśli w Copilocie lądują dane wrażliwe), bo prompt injection omija typowy model „użytkownik świadomie pyta”.

Rekomendacje operacyjne / co zrobić teraz

Dla organizacji (IT/SecOps)

  1. Wymuś aktualizacje: upewnij się, że aktualizacje z 13.01.2026 i kolejne są wdrożone na stacjach (Windows/Edge i komponenty Copilota).
  2. Higiena linków i szkolenia: dodaj do awareness prosty pattern: link do Copilota z długim ?q=... to sygnał ostrzegawczy (nawet jeśli domena jest prawdziwa).
  3. Kontrola egress / proxy: łańcuch ataku wymaga komunikacji z infrastrukturą atakera (pobieranie kolejnych instrukcji / „fetch URL”). Ograniczaj i monitoruj nietypowe połączenia do świeżych domen, szczególnie gdy inicjują je procesy przeglądarki w kontekście sesji Copilota.
  4. Warstwy ochrony dla prompt injection: jeśli używasz rozwiązań Microsoft, rozważ mechanizmy z rodziny „Prompt Shields” i podejście defense-in-depth (izolowanie danych nieufnych, polityki dostępu, audyt, DLP).

Dla użytkowników

  • Aktualizuj system i przeglądarkę, a do Copilota wchodź z własnego skrótu, nie z linków z wiadomości.
  • Jeśli Copilot otwiera się z automatycznie wypełnionym promptem, przeczytaj go przed wykonaniem (właśnie na tym żeruje ten wektor).

Różnice / porównania z innymi przypadkami

  • Reprompt (ten przypadek): „one-click” przez URL q, nacisk na utrzymanie kontroli po starcie i „prompt chaining” z serwera.
  • Klasa indirect prompt injection ogólnie: atakujący „przemyca instrukcje” w danych wejściowych, a skutkiem często jest data exfiltration (np. przez generowanie URL-i/znaczników, wywołania narzędzi, itp.). Microsoft opisuje to jako trudne do wyeliminowania i wymagające wielu warstw obrony.

Podsumowanie / kluczowe wnioski

Reprompt pokazał, że nawet „wygodne” funkcje typu prefill prompt z URL mogą stać się krytycznym wektorem, jeśli da się je połączyć z obejściem guardrails (double-request) i sterowaniem sekwencyjnym (chain-request). Atak był szczególnie niebezpieczny, bo minimalizował sygnały dla użytkownika i utrudniał detekcję po stronie endpointu. Z perspektywy bezpieczeństwa to kolejny argument, by traktować asystentów AI jak nową powierzchnię ataku, wymagającą polityk, monitoringu i kontroli przepływu danych — nie tylko „ustawień prywatności”.

Źródła / bibliografia

  1. BleepingComputer — opis ataku i wektora q (14.01.2026). (BleepingComputer)
  2. Varonis Threat Labs — analiza Reprompt (P2P, double-request, chain-request; aktualizacja 14.01.2026). (varonis.com)
  3. Microsoft MSRC — „How Microsoft defends against indirect prompt injection attacks” (29.07.2025) – kontekst i defense-in-depth. (Microsoft)
  4. Malwarebytes — potwierdzenie łatki w Patch Tuesday i kontekst ryzyka (15.01.2026). (Malwarebytes)
  5. SecurityWeek — podsumowanie technik i skutków (15.01.2026). (securityweek.com)

Hakerzy polują na źle skonfigurowane proxy, żeby „za darmo” korzystać z płatnych LLM (OpenAI, Anthropic, Gemini i inne)

Wprowadzenie do problemu / definicja luki

Wraz z boomem na GenAI, wiele firm stawia „bramki” (reverse proxy, API gateway, internal proxy) przed modelami językowymi — żeby ujednolicić dostęp, logować ruch, ukryć klucze API albo kierować zapytania do różnych dostawców. Problem zaczyna się wtedy, gdy takie proxy jest wystawione do internetu bez odpowiedniej kontroli dostępu (albo ma zbyt liberalną konfigurację routingu). W praktyce staje się otwartą furtką: każdy może wysyłać żądania, a rachunek i limity zużywa właściciel infrastruktury.

Na początku stycznia 2026 r. GreyNoise opisało kampanie, w których aktorzy (w tym prawdopodobnie „szarzy” researcherzy, ale też profesjonalny threat actor) masowo skanowali i testowali endpointy powiązane z LLM-ami, polując właśnie na takie błędy konfiguracyjne.

W skrócie

  • GreyNoise zarejestrowało 91 403 sesje ataków na swojej infrastrukturze honeypot (Ollama) między październikiem 2025 a styczniem 2026 i wyodrębniło dwie osobne kampanie.
  • Kampania #1: SSRF (server-side request forgery) — wymuszanie połączeń wychodzących z serwera ofiary (m.in. przez mechanizmy „model pull” i integracje webhook).
  • Kampania #2: enumeracja i fingerprinting — od 28 grudnia 2025 dwa IP metodycznie sprawdzały 73+ endpointy modeli, generując 80 469 sesji w 11 dni, testując formaty zgodne z OpenAI i Google Gemini.
  • Celem jest wykrycie źle zabezpieczonych proxy / bramek, które pozwalają uzyskać dostęp do komercyjnych API LLM (czyli realnie: ktoś inny płaci za tokeny).

Kontekst / historia / powiązania

Ten wektor nie jest „nowy” jako idea: źle skonfigurowane reverse proxy potrafi ujawnić dostęp do zasobów, które miały być wewnętrzne (np. inne hosty w sieci, metadane, usługi lokalne), a także bywa nadużywane jako „pośrednik” do wykonywania żądań w imieniu serwera. To klasyczny fundament pod SSRF i nadużycia routingu.

Nowością jest to, że LLM-y są kosztowym zasobem (tokeny, limity, budżety) oraz coraz częściej stoją za nimi automaty (agenty, workflow, funkcje), więc nawet „niewinne” zapytania testowe mogą być wstępem do:

  • kradzieży budżetu (token draining),
  • pivotu do systemów wewnętrznych (jeśli gateway ma dodatkowe integracje),
  • eskalacji do wycieku danych (jeśli proxy ma dostęp do RAG/źródeł).

Dodatkowo Cisco zwraca uwagę, że wiele wdrożeń LLM bywa publicznie wystawionych przez pośpiech, kopiowanie przykładów konfiguracji i brak twardych kontroli dostępu (na przykładzie serwerów LLM wykrywanych przez Shodan).

Analiza techniczna / szczegóły luki

1) Kampania SSRF: „zmuś serwer, żeby zadzwonił do mnie”

GreyNoise opisuje kampanię aktywną od października 2025 do stycznia 2026, w której atakujący próbowali potwierdzać SSRF poprzez OAST (out-of-band application security testing) i domeny callback. W praktyce chodzi o to, żeby serwer ofiary wykonał połączenie wychodzące do kontrolowanej infrastruktury — co potwierdza podatność.

W raporcie pojawiają się m.in.:

  • wykorzystywanie mechanizmu Ollama model pull do podkładania URL-i rejestru,
  • współwystępujące próby przez integracje webhook (np. parametry typu MediaUrl w kontekście SMS/MMS),
  • charakterystyka automatyzacji (fingerprinty JA4, wskazania na narzędzia w stylu Nuclei).

GreyNoise ocenia, że ta część wygląda jak aktywność „research/bug bounty”, ale skala i timing (pik w okresie świątecznym) sugerują „grey-hat pushing boundaries”.

2) Kampania enumeracyjna: „zbuduj listę otwartych bramek do płatnych modeli”

Druga kampania jest bardziej niepokojąca operacyjnie. Od 28 grudnia 2025 dwa adresy IP wykonywały metodyczne próby na 73+ endpointach modeli, testując formaty API kompatybilne z OpenAI i Gemini. W 11 dni zrobiły 80 469 sesji.

Co istotne, testy były „ciche” — proste prompt-y („hi”, puste wejście, pytania faktograficzne), żeby:

  • zidentyfikować, czy endpoint odpowiada,
  • sfingerprintować, jaki model stoi za proxy,
  • nie wywołać alarmów SOC/abuse detection.

GreyNoise wiąże tę infrastrukturę ze „znanymi” aktywnościami skanowania i eksploatacji CVE, co sugeruje, że enumeracja ma zasilić większy pipeline (najpierw mapa, potem nadużycie/eksploatacja).

Dlaczego proxy jest tu kluczowe?

W wielu organizacjach wygląda to tak:

  • reverse proxy/gateway ma ważny klucz API do OpenAI/Anthropic itp.,
  • na zewnątrz wystawia „własny” endpoint (często kompatybilny z OpenAI),
  • jeśli brakuje authN/authZ, ograniczeń tras lub izolacji tenantów, atakujący może używać tego endpointu jak „darmowej karty” do płatnego API.

To jest klasyczna konsekwencja złej konfiguracji reverse proxy: „proxy robi to, o co prosisz”, jeśli nie ma bezpiecznych guardrail’i.

Praktyczne konsekwencje / ryzyko

  1. Koszty i limity (token theft / budget drain)
    Najbardziej bezpośredni efekt: nieautoryzowane zapytania spalają tokeny, limity rate i budżety — często zanim ktoś zauważy.
  2. Ryzyko incydentu danych (jeśli gateway ma dostęp do RAG lub narzędzi)
    Samo „hello” nic nie kradnie. Ale jeśli ten sam endpoint ma dostęp do: wewnętrznych konektorów, retrieval, funkcji/agentów, logów rozmów — to rośnie ryzyko wycieku lub nadużyć (np. wymuszanie działań przez integracje).
  3. Sygnał, że jesteś „na liście”
    GreyNoise podkreśla, że tak duża enumeracja to inwestycja; mapowanie infrastruktury zwykle poprzedza realne nadużycie.
  4. Zgodność i reputacja
    Koszty to jedno, ale druga sprawa to audyt, raportowanie incydentów, ślady w logach i ryzyko, że twoje zasoby AI staną się „publicznym serwisem” bez twojej wiedzy.

Rekomendacje operacyjne / co zrobić teraz

Minimum bezpieczeństwa dla „AI gateway / LLM proxy”

  • Wymuś uwierzytelnianie (mTLS, OAuth2, signed JWT, API keys per klient/usługa) i autoryzację (policy per endpoint/model).
  • Nie wystawiaj kompatybilnych endpointów OpenAI „na świat” bez kontroli dostępu, nawet jeśli to „tylko test”.
  • Rate limiting + quota per klient/IP/token, osobno dla endpointów „model list / models” i „chat/completions”.

Twarde ograniczenia ruchu wychodzącego (SSRF)

  • Egress filtering: serwery LLM/proxy nie powinny móc łączyć się „gdziekolwiek w internet”.
  • Blokuj domeny OAST/callback na DNS (GreyNoise wskazuje wzorce .oast. jako istotne w kampanii SSRF).
  • Jeśli używasz Ollama/pull: ogranicz „model pulls” do zaufanych rejestrów.

Detekcja i monitoring

  • Alertuj na wzorce enumeracji: wiele endpointów modeli w krótkim czasie, nietypowe sekwencje „niewinnych promptów” i skok liczby sesji.
  • Monitoruj fingerprinty sieciowe, jeśli masz taką możliwość (GreyNoise opisuje użycie JA4 do identyfikacji automatyzacji).
  • Przejrzyj logi reverse proxy pod kątem:
    • nietypowych „OpenAI-compatible paths”,
    • prób listowania modeli,
    • powtarzalnych krótkich zapytań testowych.

Ramy kontrolne (żeby nie „zgubić” tego w backlogu)

W OWASP Top 10 dla aplikacji LLM temat nieautoryzowanego użycia, niewłaściwych kontroli oraz podatności wynikających z integracji i niebezpiecznych zachowań systemu przewija się wielokrotnie (np. ryzyka wokół nadużyć, DoS, ujawnień danych, supply chain i projektowania wtyczek/agentów). Traktuj te pozycje jako checklistę do przeglądu wdrożenia LLM.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

  • Wycieki kluczy API: klasyka (klucz w repo/logach). Tu jest subtelniej: klucz może być dobrze ukryty, ale proxy jest otwarte i działa jak publiczna bramka.
  • Publicznie wystawione serwery LLM (self-hosted): inny wariant problemu, ale podobna przyczyna — wdrożenie „na szybko”, bez kontroli dostępu i segmentacji (Cisco opisuje, jak takie ekspozycje można masowo wykrywać).
  • SSRF „klasyczne” vs SSRF w ekosystemie GenAI: mechanika ta sama, ale konsekwencje szersze, bo pipeline AI często ma integracje i automatyzacje, a koszty LLM są bezpośrednio mierzalne (tokeny).

Podsumowanie / kluczowe wnioski

  • Od końcówki grudnia 2025 widać metodyczną enumerację endpointów LLM, ukierunkowaną na wykrycie źle skonfigurowanych proxy, które mogą dać dostęp do płatnych modeli kosztem ofiary.
  • Równolegle działa kampania SSRF, gdzie celem jest potwierdzanie podatności i kanału egress (callback).
  • Największe ryzyko „tu i teraz” to: koszty, limity, oraz potencjalny pivot w głąb środowiska, jeśli bramka AI jest spięta z danymi i narzędziami.
  • Obrona nie wymaga magii: authN/authZ na bramce, rate limit, egress filtering, blokady OAST, monitoring wzorców enumeracji.

Źródła / bibliografia

  1. BleepingComputer – opis kampanii i obserwacji GreyNoise (9 stycznia 2026). (BleepingComputer)
  2. GreyNoise – „Threat Actors Actively Targeting LLMs” (8 stycznia 2026), metryki, kampanie, IOCs i rekomendacje obrony. (GreyNoise)
  3. ProjectDiscovery – seria o nadużyciach reverse proxy (kontekst bezpieczeństwa i skutki błędnej konfiguracji). (ProjectDiscovery)
  4. Cisco Security – studium wykrywania publicznie wystawionych serwerów LLM (Ollama) i ryzyk wynikających z ekspozycji. (Cisco Blogs)
  5. OWASP – Top 10 dla aplikacji LLM (ramy ryzyk i kontroli bezpieczeństwa dla wdrożeń GenAI). (OWASP Foundation)

ZombieAgent: jak „zombifikować” ChatGPT i wykradać dane z konektorów oraz pamięci

Wprowadzenie do problemu / definicja luki

ZombieAgent to pokazowy łańcuch ataków typu indirect prompt injection (pośrednia iniekcja promptów), który – według badań Radware – pozwalał przejąć sterowanie nad zachowaniem ChatGPT w scenariuszach „agentowych”: gdy model ma dostęp do narzędzi (np. przeglądania WWW), integracji/konektorów (np. poczta, dysk, repozytoria) i/lub mechanizmów pamięci długoterminowej. Efekt: wyciek danych z usług podłączonych do ChatGPT, możliwość propagacji (rozsyłania ładunku dalej) oraz utrwalenia (persistence) przez manipulację zasadami zapisywanymi w pamięci.

Kluczowe jest to, że w pośredniej iniekcji promptów „polecenia” atakującego nie przychodzą wprost od użytkownika, tylko są ukryte w treści, którą agent ma przetworzyć (e-mail, dokument, plik). Jeśli agent potraktuje tę treść jak instrukcję, zaczyna działać „dla atakującego”.

W skrócie

  • Atak bazuje na złośliwych e-mailach i/lub plikach, które zawierają instrukcje dla AI ukryte w treści.
  • Celem jest eksfiltracja danych (np. z inboxa i książki adresowej) oraz obejście wcześniejszych ograniczeń (m.in. zakazu modyfikowania URL).
  • W wariancie „persistence” atakujący dąży do zapisania reguł w pamięci długoterminowej, by agent wykonywał złośliwe działania w kolejnych rozmowach.
  • Radware raportował podatności wcześniej (ShadowLeak), a ZombieAgent pokazał „drugą rundę”: obejście poprawek; według doniesień luka była zgłoszona 26 września 2025 i załatana 16 grudnia 2025.

Kontekst / historia / powiązania

ZombieAgent jest rozwinięciem szerszego problemu: agentic AI zwiększa powierzchnię ataku, bo model nie tylko „pisze tekst”, ale czyta dane z systemów i wykonuje akcje. Radware wcześniej opisywał technikę ShadowLeak, w której model wyciekał dane przez dopisywanie ich do parametrów URL — co OpenAI miało ograniczyć m.in. przez blokadę modyfikowania linków.

ZombieAgent pokazuje, że nawet po wprowadzeniu takich guardrails można zbudować obejście, jeśli atakujący zmieni sposób „kodowania” danych i kanał wycieku.

Analiza techniczna / szczegóły luki

Radware opisał kilka scenariuszy, które łączy wspólny mianownik: agent dostaje do przetworzenia treść kontrolowaną przez atakującego i wykonuje ukryte instrukcje.

1) Eksfiltracja przez „pre-zbudowane” URL (obejście blokady modyfikacji linków)

Wg opisu, wcześniejsza obrona polegała na tym, że ChatGPT „nie może modyfikować dostarczonych URL” (np. dopisując wykradane dane jako parametry). ZombieAgent omija to, podając z góry przygotowaną listę URL-i odpowiadających literom/cyfrom/spacjom. Agent ma:

  1. odnaleźć w skrzynce ofiary wrażliwy fragment (np. token, adres, dane kontaktowe),
  2. „znormalizować” go,
  3. a potem „wyciekać” znak po znaku, wywołując odpowiedni URL dla kolejnych znaków.
    Ponieważ agent nie „modyfikuje” linku (tylko wybiera z listy), ograniczenie przestaje pomagać.

2) Złośliwy plik + kanały wycieku (serwer + renderowanie Markdown)

Drugi wektor to złośliwe instrukcje w pliku udostępnionym ChatGPT, które skłaniają agenta do eksfiltracji danych zarówno „po stronie usługi”, jak i przez mechanizmy renderowania (np. elementy w treści rozmowy).

3) Propagacja: atak „robi się sam” w ekosystemie e-mail

W wariancie propagacji agent najpierw pozyskuje z inboxa ostatnie adresy e-mail, a następnie atakujący rozsyła payload do kolejnych osób, zwiększając zasięg kampanii. To klasyczny „worm-like” efekt, tylko że paliwem są: konektory + automatyzacja pracy agenta.

4) Persistence przez pamięć długoterminową (Memory)

Najbardziej niepokojący element to „utrwalenie”: złośliwy plik ma instruować agenta, by dodał do pamięci trwałe reguły (np. priorytetyzowanie określonych kroków przed odpowiedzią). W opisie SecurityWeek: normalnie konektory i pamięć nie powinny działać razem w tym samym czacie, ale poprzez wstrzyknięte „reguły pamięci” agent może zawsze najpierw wykonać kroki atakującego (np. odczyt/wyciek), a dopiero potem rozmawiać z użytkownikiem.

Praktyczne konsekwencje / ryzyko

Najważniejsze ryzyka dla firm i użytkowników, jeśli podobne klasy błędów występują w agentach:

  • Wyciek danych z aplikacji podłączonych konektorami: poczta, dyski, narzędzia dev/PM (repozytoria, tickety), komunikatory — wszystko, co agent potrafi odczytać.
  • „Cloud-side exfiltration” i ślepe plamki detekcji: jeśli operacje dzieją się po stronie dostawcy usługi AI, tradycyjne zabezpieczenia perymetryczne/EDR/SWG mogą nie widzieć pełnego obrazu (w praktyce zależy od architektury integracji i logowania).
  • Utrwalony „insider”: pamięć długoterminowa jako mechanizm persistence to jakościowa zmiana — atak nie musi być jednorazowy, tylko może „żyć” w kolejnych sesjach.
  • Ryzyko łańcuchowe: propagacja przez e-mail i automatyzację może szybko przenosić problem na kolejne skrzynki/zespoły.

Rekomendacje operacyjne / co zrobić teraz

Poniżej praktyczny zestaw działań, które mają sens niezależnie od tego konkretnego PoC (bo celują w całą klasę indirect prompt injection dla agentów):

Szybkie „hardening” (dni)

  • Ogranicz konektory do minimum: odłącz e-mail i dyski od agentów tam, gdzie nie są krytyczne; stosuj zasadę najmniejszych uprawnień (tylko odczyt, tylko wybrane foldery/projekty).
  • Wyłącz lub ściśle kontroluj Memory w środowiskach firmowych (szczególnie dla kont uprzywilejowanych i zespołów obsługujących dane wrażliwe).
  • Wprowadź regułę: agent nie wykonuje akcji na podstawie treści z e-maili/plików bez walidacji (human-in-the-loop dla akcji i eksportów danych).
  • Allowlist dla otwierania linków / egress control: jeżeli agent ma narzędzie „open URL”, ogranicz domeny i blokuj nietypowe wzorce (np. masowe „odpytywanie” setek linków). (To dokładnie uderza w styl eksfiltracji „znak po znaku”).

Ochrona procesowa i monitorowanie (tygodnie)

  • Logowanie i audyt narzędzi agenta (co otworzył, co pobrał, jakie akcje wykonał w konektorach) + korelacja z DLP.
  • Segmentacja agentów: osobne tożsamości/instancje do zadań o różnym ryzyku (np. osobny agent do „czytania maili”, bez dostępu do repozytoriów i bez pamięci).
  • Testy bezpieczeństwa agentów: stałe „red teaming” prompt injection na realnych workflow (mail → podsumuj → wykonaj akcję). Radware podkreśla, że klasyczne guardrails bywają niewystarczające przeciw trwałym, pośrednim iniekcjom.

Wymagania wobec dostawcy (vendor / procurement)

  • Pytaj o separację „instrukcji” od „danych”, filtrowanie IPI, polityki pamięci, granice narzędzi oraz telemetrię (co klient może monitorować).
  • Weryfikuj timeline poprawek i komunikację podatności: w tym przypadku media opisywały zgłoszenie 26.09.2025 i łatę 16.12.2025.

Różnice / porównania z innymi przypadkami

  • ShadowLeak vs ZombieAgent: ShadowLeak (wg opisu mediów i Radware) eksfiltrował dane przez dopisywanie ich do URL (parametry). ZombieAgent omija to przez „słownik” predefiniowanych URL-i, czyli nie prosi modelu o modyfikację linku — tylko o wybór linku odpowiadającego znakowi.
  • Jednorazowy wyciek vs persistence: nowością w ZombieAgent jest mocny nacisk na utrwalenie przez pamięć i „reguły”, które wpływają na przyszłe zachowanie agenta.

Podsumowanie / kluczowe wnioski

ZombieAgent to ważny sygnał ostrzegawczy: im bardziej ChatGPT (i inne LLM) stają się agentami z narzędziami, tym mniej wystarcza klasyczne „prompt hardening”. Pośrednia iniekcja promptów w e-mailach i dokumentach jest szczególnie groźna, bo:

  • wygląda jak zwykła treść biznesowa,
  • może uruchamiać się w ramach normalnej pracy („podsumuj skrzynkę / przejrzyj plik”),
  • a w najgorszym wariancie może zostawić trwały ślad w pamięci agenta.

Jeśli w organizacji używacie konektorów i pamięci w narzędziach typu ChatGPT, potraktujcie ten temat jak nową klasę ryzyka operacyjnego (AI supply chain + data governance), a nie „ciekawostkę o jailbreakach”.

Źródła / bibliografia

  1. SecurityWeek — opis scenariuszy eksfiltracji, propagacji i persistence (ZombieAgent).
  2. Radware (blog Threat Intelligence) — streszczenie podatności, eksfiltracja z konektorów, pamięć, propagacja.
  3. Radware (Threat Advisory/Report) — kontekst „agentic economy”, indirect prompt injection, blind spots i persistence.
  4. SC Media/SCWorld — obejście guardrails z URL i wzmocnienia po stronie OpenAI.
  5. The Register — timeline zgłoszenia i łat (26.09.2025 → 16.12.2025) oraz odniesienie do ShadowLeak.

Ni8mare (CVE-2026-21858): krytyczna luka w n8n pozwala przejąć samodzielnie hostowane serwery automatyzacji

Wprowadzenie do problemu / definicja luki

Na początku stycznia 2026 r. ujawniono podatność „Ni8mare” w n8n — popularnej platformie do automatyzacji workflow (często wykorzystywanej też do orkiestracji integracji AI/LLM). Luka otrzymała maksymalny wynik CVSS 10.0 i została zarejestrowana jako CVE-2026-21858. W praktyce problem dotyczy głównie self-hosted instalacji n8n oraz scenariuszy, w których organizacje wystawiają na zewnątrz formularze/webhooki obsługujące pliki.

Klucz: to nie jest „kolejna drobna wpadka w parserze”. n8n bywa centralnym węzłem automatyzacji (API keys, tokeny OAuth, dostępy do baz, chmury, CI/CD), więc nawet pozornie „tylko” odczyt plików z hosta może kaskadowo skończyć się pełnym przejęciem środowiska.

W skrócie

  • Identyfikator: CVE-2026-21858 (Ni8mare), krytyczna podatność (CVSS 10.0).
  • Dotyczy: wersji n8n poniżej 1.121.0.
  • Istota problemu: „Content-Type confusion” w obsłudze webhooków/formularzy — brak właściwej walidacji typu żądania umożliwia kontrolę struktur opisujących pliki i w konsekwencji odczyt dowolnych plików z hosta w ramach podatnego workflow opartego o formularze.
  • Naprawa: aktualizacja do n8n 1.121.0+; oficjalnych obejść brak (tymczasowo: ograniczyć/wyłączyć publicznie dostępne webhooki/formy).

Kontekst / historia / powiązania

Z analizy Cyera wynika, że podatność została zgłoszona do n8n 9 listopada 2025, a wersja z poprawką została opublikowana 18 listopada 2025. CVE przypisano 6 stycznia 2026, a opis techniczny upubliczniono 7 stycznia 2026.

BleepingComputer zwraca uwagę na skalę potencjalnej ekspozycji (szacunki rzędu dziesiątek tysięcy instancji) oraz fakt, że n8n jest bardzo popularny w automatyzacjach związanych z AI (RAG, agenci, integracje).

Analiza techniczna / szczegóły luki

1) Gdzie zaczyna się problem: webhooki i parsowanie requestów

n8n przyjmuje dane wejściowe do workflow m.in. przez webhooki (w tym formularze). W uproszczeniu: to, jak n8n sparsuje body żądania, zależy od nagłówka Content-Type — inne ścieżki dla multipart/form-data (upload plików), inne dla pozostałych typów (np. JSON).

2) „Content-Type confusion”: kontrola req.body.files

Cyera opisuje scenariusz, w którym przy nieodpowiednim Content-Type uruchamia się „zwykły” parser body, a nie parser uploadu. Ponieważ wynik parsowania trafia do obiektu żądania, możliwe staje się nadpisanie struktur, które później są traktowane jak lista przesłanych plików (req.body.files). Jeśli w danym workflow logika obsługi formularza nie weryfikuje, że faktycznie przyszło multipart/form-data, to kolejne funkcje plikowe mogą zaufać tym danym.

3) Skutek techniczny: prymityw „arbitrary file read”

W opisie Cyera kluczowy jest moment, w którym komponent formularza wywołuje funkcje kopiujące pliki do magazynu (dysk/S3) na podstawie metadanych pliku — w tym ścieżki źródłowej. Jeśli atakujący kontroluje ten parametr, zamiast „prawdziwego uploadu” może zostać przetworzony lokalny plik z hosta, a jego treść trafia dalej do workflow (np. do bazy wiedzy/RAG, czatu, integracji).

W praktyce oznacza to, że podatne workflow oparte o formularze mogą stać się kanałem do wyciągania wrażliwych plików (konfiguracje, sekrety, pliki aplikacji). To dokładnie ten typ „małego błędu wejścia”, który w platformie automatyzacji często kończy się dużym incydentem.

Praktyczne konsekwencje / ryzyko

GitHub Advisory i NVD opisują CVE-2026-21858 jako możliwość nieautoryzowanego dostępu do plików w ramach określonych, form-based workflow, z ryzykiem dalszego kompromitowania zależnie od konfiguracji i sposobu użycia.

Z perspektywy obrony warto rozbić ryzyko na warstwy:

  • Wycieki sekretów i danych: jeżeli na hoście/volumenach są pliki konfiguracyjne, tokeny, klucze, dane integracji — odczyt plików może stać się wstępem do pivotu na inne systemy.
  • Przejęcie aplikacji n8n: BleepingComputer (na bazie ustaleń Cyera) wskazuje, że konsekwencje mogą obejmować także elementy eskalacji (np. nadużycia sesji) zależnie od środowiska i workflow.
  • Ryzyko downstream: n8n często ma „uprzywilejowane” integracje (CRM/ERP, chmura, CI/CD, bazy, narzędzia developerskie). Po przejęciu kontekstu automatyzacji atakujący może uderzyć dalej, już poza samą instancją n8n.

Rekomendacje operacyjne / co zrobić teraz

Poniżej lista działań, które realnie obniżają ryzyko — od „gaśnicy” po twarde zabezpieczenia:

  1. Natychmiastowa aktualizacja
  • Zaktualizuj do n8n 1.121.0 lub nowszej (to wersja wskazana jako zawierająca poprawkę).
  1. Tymczasowa redukcja powierzchni ataku (jeśli nie możesz patchować od razu)
  • Ogranicz lub wyłącz publicznie dostępne webhooki i endpointy formularzy do czasu aktualizacji.
  1. Przegląd workflow i ekspozycji
  • Zidentyfikuj workflow wykorzystujące Form / form-based webhooks (zwłaszcza te z uploadem plików lub logiką, która przekazuje pliki dalej: RAG/LLM, storage, e-mail, ticketing).
  • Sprawdź, czy te endpointy są wystawione do Internetu bez dodatkowej warstwy kontroli (reverse proxy, allowlist, WAF, auth).
  1. Rotacja sekretów i audyt dostępu
  • Jeśli instancja była publicznie dostępna i/lub podejrzewasz ekspozycję: rozważ rotację kluczy/tokenu integracji trzymanych w n8n, bo skutkiem CVE może być ich ujawnienie przez odczyt plików lub dane workflow.
  1. Długofalowo: zasady „n8n jako system uprzywilejowany”
  • Traktuj n8n jak narzędzie klasy „automation hub”: segmentacja sieci, minimalne uprawnienia integracji, ograniczenie egress/ingress, monitorowanie wywołań webhooków i anomalii w uruchamianiu workflow.

Różnice / porównania z innymi przypadkami

CSO Online zwraca uwagę, że ekosystem n8n notował też inne krytyczne problemy (w tym RCE) w ostatnim okresie, dlatego kluczowe jest utrzymywanie „latest available version” oraz skracanie okna ekspozycji między poprawką a wdrożeniem.

Na tym tle Ni8mare wyróżnia się tym, że startuje od wejścia zewnętrznego (formularze/webhook) i wykorzystuje błąd klasy „input validation / content-type handling”, który w aplikacjach integracyjnych bywa szczególnie groźny, bo łączy świat zewnętrzny z wewnętrznymi zasobami (pliki/sekrety/integracje).

Podsumowanie / kluczowe wnioski

  • CVE-2026-21858 (Ni8mare) to krytyczna podatność w n8n, która w podatnych workflow opartych o formularze może prowadzić do nieautoryzowanego dostępu do plików na hoście, a w praktyce — do poważniejszej kompromitacji zależnie od konfiguracji i tego, jak n8n jest używany w organizacji.
  • Najważniejsze działanie obronne jest proste: aktualizacja do 1.121.0+ oraz czasowe ograniczenie publicznej ekspozycji webhooków/form, jeśli patch nie jest natychmiast możliwy.
  • Warto potraktować tę lukę jako sygnał do „utwardzenia” n8n: minimalizacja ekspozycji, przegląd workflow, rotacja sekretów i monitoring, bo automatyzacja jest dziś jednym z najbardziej uprzywilejowanych punktów w środowiskach IT.

Źródła / bibliografia

  1. Cyera Research Labs — analiza „Ni8mare” i tło techniczne. (cyera.com)
  2. GitHub Security Advisory (n8n) — opis wpływu, wersje, mitigacje. (GitHub)
  3. NVD (NIST) — rekord CVE-2026-21858 i opis podatnych wersji. (NVD)
  4. BleepingComputer — kontekst, skala, streszczenie mechanizmu. (BleepingComputer)
  5. CSO Online — opis „Content-Type confusion” i mechaniki odczytu plików. (CSO Online)

Krytyczna luka w LangChain Core (CVE-2025-68664) – „LangGrinch” umożliwia wyciek sekretów i nadużycia deserializacji

Wprowadzenie do problemu / definicja luki

Pod koniec grudnia 2025 ujawniono krytyczną podatność w langchain-core (Python) – podstawowej bibliotece ekosystemu LangChain – która pozwala atakującemu „przemycić” spreparowaną strukturę danych do procesu serializacji/deserializacji i w efekcie wyciągać sekrety (np. zmienne środowiskowe) oraz inicjować niebezpieczne ścieżki wykonania w ramach obiektów frameworka. Luka otrzymała identyfikator CVE-2025-68664 i przydomek LangGrinch.

Równolegle opisano podobny problem w implementacji LangChain.js (CVE-2025-68665), dotyczący sposobu serializacji w JavaScript/TypeScript.

W skrócie

  • CVE-2025-68664 (Python / langchain-core): podatność typu serialization injection w dumps()/dumpd(), oceniona jako krytyczna (CVSS 9.3).
  • Mechanizm nadużycia opiera się o wewnętrzny znacznik "lc", który LangChain traktuje jako sygnał, że dane reprezentują „prawdziwy” obiekt frameworka, a nie zwykły słownik.
  • Najczęstszy wektor: pola odpowiedzi LLM (np. additional_kwargs, response_metadata) sterowane pośrednio przez prompt injection, a następnie serializowane i deserializowane w przepływach strumieniowych.
  • Poprawki: aktualizacja do langchain-core 0.3.81 lub 1.2.5 (w zależności od gałęzi).
  • Dodatkowo: analogiczna luka w LangChain.js (CVE-2025-68665, CVSS 8.6) – poprawione m.in. w @langchain/core 0.3.80 / 1.1.8 i langchain 0.3.37 / 1.2.3.

Kontekst / historia / powiązania

LangChain i langchain-core stały się fundamentem wielu wdrożeń „agentowych” (orchestracja narzędzi, pamięć, streaming, logowanie zdarzeń). Problem LangGrinch jest groźny nie dlatego, że dotyczy rzadkiego modułu, ale dlatego, że dotyka mechanizmu wymiany/utrwalania danych (serializacja), który bywa używany „w tle” w popularnych API i integracjach.

W praktyce to kolejny przykład klasycznej kategorii błędów (deserializacja danych niezaufanych), ale w nowym kontekście: LLM output jako dane wejściowe. Wiele zespołów nadal traktuje odpowiedź modelu jak „bezpieczny tekst”, podczas gdy jest to treść, którą przeciwnik może kształtować promptami, danymi w RAG, a czasem nawet treścią zewnętrznych źródeł.

Analiza techniczna / szczegóły luki

Na czym polega „serialization injection” w LangChain?

W LangChain istnieje wewnętrzny format, który opisuje obiekty frameworka jako struktury danych. Klucz lc jest częścią tego mechanizmu: sygnalizuje, że dana struktura ma być traktowana jak serializowany obiekt LangChain.

W CVE-2025-68664 problem polegał na tym, że funkcje dumps() i dumpd() nie „uciekały” (nie neutralizowały) słowników zawierających lc w dowolnych, swobodnych danych. Gdy taki wynik został później przepuszczony przez load()/loads(), wstrzyknięta struktura mogła zostać zinterpretowana jako legalny obiekt LangChain, a nie zwykłe dane użytkownika.

Co realnie umożliwia atak?

Z advisory wynika kilka praktycznych wektorów:

  • Ekstrakcja sekretów z env – historycznie ryzykowny wariant, bo wcześniejsze domyślne ustawienia pozwalały automatycznie pobierać sekrety ze zmiennych środowiskowych podczas deserializacji (secrets_from_env było domyślnie włączone).
  • Instancjonowanie klas w „zaufanych” przestrzeniach nazw (langchain_core, langchain, langchain_community) – nawet jeśli to nie jest „dowolna klasa z systemu”, nadal mogą istnieć konstruktory z efektami ubocznymi (połączenia sieciowe, operacje na plikach, itp.).
  • Powiązanie z prompt injection – ponieważ pola typu additional_kwargs/response_metadata mogą zostać ukształtowane przez atakującego (np. przez wymuszenie specyficznego JSON-a w odpowiedzi), a potem trafić do serializacji w strumieniowaniu.

Cyata opisuje też scenariusze, w których instancjonowane obiekty mogą powodować wyjściowe żądania sieciowe albo prowadzić do dalszych eskalacji, jeśli aplikacja po deserializacji wykona kolejne kroki „ufając” obiektom.

Co zmieniły poprawki (i dlaczego mogą „boleć”)?

W przypadku Pythona łatka nie tylko naprawia błąd escapowania, ale też wprowadza utwardzenie bezpieczeństwa:

  • domyślna allowlista (allowed_objects="core"),
  • secrets_from_env domyślnie False,
  • blokada szablonów Jinja2 przez init_validator (zmiana potencjalnie „breaking” dla części użytkowników).

Praktyczne konsekwencje / ryzyko

Największe ryzyka dla zespołów budujących aplikacje i agentów LLM:

  • Wyciek kluczy API (LLM provider, narzędzia, bazy wektorowe, systemy zewnętrzne), jeśli środowisko wykonawcze ma sekrety w zmiennych środowiskowych, a ścieżka deserializacji została osiągnięta.
  • Nieoczekiwane zachowanie agenta – atakujący może „dosztukować” struktury, które zmienią sposób działania łańcucha, logowania, pamięci, narzędzi lub dalszego generowania odpowiedzi (w praktyce: prompt injection + nadużycie serializacji).
  • Efekty uboczne w zaufanych klasach – nawet bez pełnego RCE, sam fakt inicjowania ruchu wychodzącego, odczytów plików czy nietypowych operacji może być bolesny (SSRF, exfil, kosztowe DoS).

Rekomendacje operacyjne / co zrobić teraz

  1. Zaktualizuj zależności natychmiast
    • Python: przejdź na langchain-core 0.3.81 albo 1.2.5 (zależnie od używanej linii).
    • JS: @langchain/core 0.3.80 / 1.1.8 oraz langchain 0.3.37 / 1.2.3.
  2. Załóż, że output LLM to dane niezaufane
    • Traktuj additional_kwargs, response_metadata, metadata jak payload z internetu.
    • Jeśli logujesz/serializujesz odpowiedzi modelu – wprowadź walidację i/lub filtrację (np. blokada klucza lc w danych swobodnych).
  3. Usuń automatyczne ładowanie sekretów z env przy deserializacji
    • Po łatkach domyślnie jest bezpieczniej, ale warto audytować kod: czy gdziekolwiek jawnie włączasz secrets_from_env / secretsFromEnv.
  4. Ogranicz deserializację do minimum
    • Jeśli musisz używać load()/loads(): trzymaj się allowlisty i nie deserializuj niczego, co może pochodzić od użytkownika/LLM/RAG/cache/hub bez walidacji.
  5. Sprawdź „wrażliwe” ścieżki z advisory
    • Python: szczególnie przypadki użycia streamingu i narzędzi, które wewnętrznie serializują zdarzenia (np. astream_events w wersji v1, Runnable.astream_log() i inne wskazane w advisory).
  6. Dodaj kontrolę w pipeline
    • SCA/Dependabot + blokada wdrożeń z podatnymi wersjami.
    • SBOM i alertowanie przy wykryciu langchain-core w podatnym zakresie.

Różnice / porównania z innymi przypadkami

  • Python (CVE-2025-68664): podatność w dumps()/dumpd() + twarde zmiany bezpieczeństwa w load()/loads() (allowlista, wyłączenie sekretów z env, blokada Jinja2).
  • JavaScript (CVE-2025-68665): podatność w Serializable.toJSON() / JSON.stringify() + deserializacja przez load(); hardening obejmuje m.in. jawne wyłączenie secretsFromEnv oraz limit głębokości (maxDepth) przeciw DoS.

W obu światach wspólny mianownik jest ten sam: framework myli dane użytkownika z danymi strukturalnymi (bo klucz lc ma specjalne znaczenie), a to tworzy „most” między prompt injection a klasycznymi kategoriami błędów bezpieczeństwa.

Podsumowanie / kluczowe wnioski

LangGrinch (CVE-2025-68664) to sygnał ostrzegawczy dla zespołów budujących agentów i aplikacje LLM: jeśli jakikolwiek fragment odpowiedzi modelu trafia do serializacji/deserializacji, to w praktyce traktujesz LLM jak niezaufanego nadawcę danych. Najważniejsze działania to szybka aktualizacja do wersji naprawionych, ograniczenie deserializacji, wyłączenie automatycznego ładowania sekretów z env i wprowadzenie allowlist / walidacji struktur.

Źródła / bibliografia

  1. The Hacker News – opis CVE-2025-68664 i CVE-2025-68665 oraz podatne/naprawione wersje (The Hacker News)
  2. GitHub Advisory (langchain-core, CVE-2025-68664 / GHSA-c67j-w6g6-q2cm) – wektory ataku, wpływ, zmiany hardening (GitHub)
  3. GitHub Advisory (LangChain.js, CVE-2025-68665 / GHSA-r399-636x-v7f6) – zakres npm, hardening load() (GitHub)
  4. Cyata Research – kontekst „LangGrinch”, scenariusze ryzyka w agentach (Cyata)

AI Kontra Pentesterzy – Lekcje Z Badania Stanford 2025

Dlaczego to ma znaczenie

Rosnące zdolności sztucznej inteligencji (AI) wywołują pytania o jej wpływ na bezpieczeństwo – zarówno pozytywny, jak i negatywny. Najnowsze raporty wskazują, że zaawansowane grupy atakujące (od cyberprzestępców po aktorów państwowych) już zaczynają wykorzystywać AI w operacjach ofensywnych. W odpowiedzi liderzy branży (np. OpenAI, Anthropic) uwzględniają ryzyko cyber w swoich zasadach bezpieczeństwa AI. Skoro napastnicy testują AI jako broń, obrońcy muszą zrozumieć, na co stać takie systemy – jak wypadają one na tle żywych pentesterów?

Czytaj dalej „AI Kontra Pentesterzy – Lekcje Z Badania Stanford 2025”