Badacze bezpieczeństwa ujawnili słabość w NVIDIA NemoClaw, która mogłaby pozwolić kontrolowanej przez atakującego stronie internetowej na uzyskanie nieuwierzytelnionego dostępu do lokalnie działającego serwera AI Ollama i potajemną zmianę sposobu działania jego modeli.
Lukę ujawnił Oasis Security, a dotyczy ona niektórych konfiguracji NemoClaw, które używają Ollama do lokalnego wnioskowania AI.
Atak nie wykorzystuje samego modelu językowego, lecz infrastrukturę, która go otacza. Łącząc wystawione API Ollama z techniką znaną jako DNS rebinding, złośliwa witryna może potencjalnie komunikować się z usługą AI działającą na komputerze ofiary.
Badacze wykazali, że taki dostęp można wykorzystać do zmodyfikowania szablonu czatu modelu i wstawienia ukrytych instrukcji kontrolowanych przez atakującego, które mogą wpływać na przyszłe rozmowy z AI.
Jest to szczególnie niepokojące w przypadku agentów AI, ponieważ złośliwe instrukcje mogą pozostawać poza widoczną częścią rozmowy i nadal wpływać na model w kolejnych sesjach.
Czym jest NVIDIA NemoClaw?
NemoClaw to otwartoźródłowy referencyjny stos NVIDIA do uruchamiania agentów AI w izolowanych środowiskach przy użyciu NVIDIA OpenShell.
Jedną z obsługiwanych opcji jest Ollama, popularna platforma, która pozwala uruchamiać duże modele językowe lokalnie, zamiast polegać wyłącznie na usługach AI działających w chmurze. Dokumentacja NVIDIA opisuje, jak NemoClaw może kierować żądania wnioskowania do serwera Ollama działającego na tym samym komputerze.
Uruchamianie AI lokalnie może zapewniać korzyści w zakresie prywatności, wydajności i kontroli.
Jednak sama lokalna usługa wnioskowania staje się ważną granicą bezpieczeństwa.
Badanie dotyczące NemoClaw pokazuje, co może się zdarzyć, gdy ta granica jest dostępna szerzej, niż się spodziewano.
Jak działa atak
Problem wynika z konfiguracji, w których Ollama jest powiązany z adresem: 0.0.0.0:11434
Powiązanie usługi z 0.0.0.0 oznacza, że nasłuchuje ona na wszystkich dostępnych interfejsach sieciowych, a nie tylko na lokalnym interfejsie pętli zwrotnej (loopback).
API Ollama na porcie 11434 domyślnie nie zapewnia konwencjonalnego uwierzytelniania.
Badacze stwierdzili, że taka konfiguracja mogła więc wystawić lokalny serwer modeli w sposób, który pozwalał docierać do niego żądaniom pochodzącym z przeglądarki.
Atak wykorzystuje następnie DNS rebinding.
W uproszczeniu:
- Ofiara odwiedza stronę kontrolowaną przez atakującego.
- Domena atakującego początkowo wskazuje na jego własny serwer WWW.
- Atakujący zmienia odpowiedź DNS tak, aby ta sama domena wskazywała na adres lokalny na komputerze ofiary.
- Przeglądarkę można wtedy oszukać, aby wysyłała żądania do lokalnie działającej usługi Ollama.
- Atakujący może wchodzić w interakcję z API Ollama bez konieczności podawania nazwy użytkownika ani hasła.
Technika ta wykorzystuje rozbieżność między tym, jak przeglądarka identyfikuje źródło (origin) witryny, a tym, na jaki adres w sieci ostatecznie wskazuje domena.
Według doniesień o badaniu Oasis cały łańcuch ataku zademonstrowano na podatnej konfiguracji NemoClaw.
Od dostępu z przeglądarki do zatrucia modelu AI
Uzyskanie dostępu do lokalnego API wnioskowania jest już poważne, ale badacze zademonstrowali bardziej trwały atak.
Korzystając z funkcji zarządzania modelami w Ollama, atakujący może zmodyfikować szablon czatu modelu.
Szablon czatu określa, w jaki sposób elementy takie jak:
- instrukcje systemowe
- prompty użytkownika
- wiadomości asystenta
są formatowane przed przekazaniem do modelu językowego.
Badacze pokazali, że atakujący może zmodyfikować ten szablon tak, aby po cichu dopisywać własne instrukcje do wiadomości systemowych.
Instrukcje te mogą następnie wpływać na kolejne rozmowy przetwarzane przez model.
Co ważne, nie jest to zatrucie wag leżącej u podstaw sieci neuronowej.
Atakujący zatruwa natomiast konfigurację wnioskowania modelu — a konkretnie szablon służący do konstruowania promptów.
To rozróżnienie ma znaczenie, ponieważ sam model może nadal wyglądać na legalny, podczas gdy jego zachowanie zostało zmienione przez ukrytą warstwę instrukcji.
Dlaczego trwałe instrukcje są niebezpieczne
Zwykły prompt injection zazwyczaj trafia do systemu AI jako część rozmowy, dokumentu lub strony internetowej, które są przez niego przetwarzane.
Ten atak jest inny.
Złośliwa instrukcja może stać się częścią trwałej konfiguracji modelu.
Według badaczy zatruty szablon czatu może stosować instrukcje kontrolowane przez atakującego w przyszłych rozmowach, nawet gdy agent AI dostarcza nowy, legalny prompt systemowy.
Aplikacje komunikujące się z Ollama mogą też nie mieć żadnej oczywistej wskazówki, że szablon został zmieniony.
Tworzy to problem integralności AI.
Przejęty agent może nadal wyglądać na działającego prawidłowo, podczas gdy jego decyzje lub odpowiedzi są kształtowane przez instrukcje, których użytkownik nie widzi.
Co mógłby zrobić atakujący?
Po uzyskaniu dostępu do wystawionego API Ollama badacze Oasis zgłosili możliwości obejmujące:
- wyliczanie lokalnie zainstalowanych modeli
- uruchamianie zadań wnioskowania z wykorzystaniem zasobów obliczeniowych ofiary
- przeglądanie informacji o modelach i szablonów
- modyfikowanie lub usuwanie modeli
- zmianę konfiguracji modelu
- wstawianie trwałych instrukcji do szablonów czatu
Rzeczywisty wpływ zatrucia modelu zależałby w dużej mierze od uprawnień, jakie ma dotknięty atakiem agent AI.
Izolowany chatbot bez żadnych możliwości zewnętrznych stwarza inne ryzyko niż autonomiczny agent, który ma dostęp do plików, narzędzi deweloperskich, API, poświadczeń lub innych systemów biznesowych.
To jedna z szerszych lekcji płynących z tego ujawnienia: przejęcie warstwy wnioskowania może pośrednio przejąć kontrolę nad zachowaniem agenta, który z niej korzysta.
Piaskownica nie rozwiązuje wszystkiego
NemoClaw wykorzystuje piaskownicę (sandbox) jako ważny mechanizm bezpieczeństwa wokół agentów AI.
Ale piaskownica i bezpieczeństwo serwera wnioskowania dotyczą różnych problemów.
Jeśli atakujący przejmie kontrolę nad modelem generującym instrukcje dla agenta, może być w stanie wpływać na działania, na które piaskownica legalnie zezwala.
Jak podsumowało Oasis Security, ochrona środowiska wokół agenta nie zwalnia z konieczności ochrony infrastruktury modelu, która napędza jego decyzje.
Ta zasada ma zastosowanie znacznie szerzej niż tylko do NemoClaw.
Organizacje wdrażające lokalne AI coraz częściej muszą traktować serwery modeli, API wnioskowania i warstwy orkiestracji agentów jako część swojego standardowego obwodu cyberbezpieczeństwa.
Które wersje NemoClaw są podatne?
Kwestia wersji wymaga pewnej ostrożności.
Pierwsze doniesienia nie wskazały numeru CVE ani jednego miarodajnego zakresu podatnych wersji dla każdej obsługiwanej platformy NemoClaw.
Szef badań w Oasis Security powiedział serwisowi The Hacker News, że NemoClaw v0.0.35 rozwiązał zgłoszony problem w systemach macOS i Linux, natomiast ścieżka wdrożenia dla Windows i WSL nie otrzymała na tamtym etapie równie pełnej poprawki.
Aktualna dokumentacja NVIDIA wskazuje, że w obsługiwanych konfiguracjach innych niż WSL NemoClaw utrzymuje Ollama pod adresem: 127.0.0.1:11434
i umieszcza przed nim zwrotny serwer proxy z uwierzytelnianiem tokenem na potrzeby łączności z piaskownicą. NVIDIA wyraźnie zaznacza, że ta ścieżka nie wystawia Ollama bez uwierzytelniania.
Dokumentacja bezpieczeństwa NVIDIA uwzględnia również ryzyko związane z backendem Ollama niepowiązanym z loopback, ponieważ bezpośredni dostęp do takiego backendu mógłby ominąć proxy z uwierzytelnianiem.
Administratorzy powinni więc ocenić swoje rzeczywiste powiązanie i topologię Ollama, zamiast polegać wyłącznie na numerze wersji NemoClaw.
Brak dowodów aktywnego wykorzystania
W chwili publicznego ujawnienia 25 sierpnia 2026 r. nie zgłoszono żadnych dowodów na to, że atakujący wykorzystują słabość NemoClaw w rzeczywistych atakach.
Dlatego, dopóki nie pojawią się nowe dowody, problem należy traktować jako wykazaną słabość zabezpieczeń, a nie aktywną kampanię wykorzystującą lukę.
To rozróżnienie jest ważne przy ocenie pilności i komunikowaniu ryzyka.
Co powinny zrobić organizacje
Organizacje korzystające z NemoClaw z lokalnym wnioskowaniem Ollama powinny już teraz przejrzeć swoją konfigurację.
✅ Utrzymuj Ollama na loopback
Jeśli to możliwe, Ollama powinien nasłuchiwać wyłącznie na: 127.0.0.1
a nie na 0.0.0.0.
API modelu przeznaczone wyłącznie do użytku lokalnego nie powinno być niepotrzebnie dostępne z innych interfejsów sieciowych.
✅ Używaj proxy z uwierzytelnianiem
Tam, gdzie NemoClaw obsługuje swoje uwierzytelniane proxy Ollama, organizacje powinny pozostawić tę ochronę włączoną i unikać konfiguracji, które pozwalają klientom ją omijać.
Obecna implementacja NVIDIA wykorzystuje proxy z bramką tokenową, utrzymując jednocześnie backend Ollama powiązany z loopback w obsługiwanych wdrożeniach innych niż WSL.
✅ Nie wystawiaj portu 11434
Administratorzy powinni upewnić się, że port TCP 11434 nie jest niepotrzebnie wystawiony na:
- sieć lokalną
- publiczne Wi-Fi
- firmowe sieci użytkowników
- internet
Mechanizmy kontroli na poziomie sieci powinny wzmacniać powiązanie lokalne.
✅ Sprawdzaj integralność modeli
Organizacje korzystające z lokalnych modeli AI powinny rozważyć monitorowanie czegoś więcej niż tylko plików modeli i ich skrótów.
Elementy konfiguracji, takie jak szablony czatu, mogą istotnie zmienić zachowanie modelu bez modyfikowania jego wag.
Nieoczekiwane zmiany szablonów, promptów systemowych lub definicji modeli należy więc traktować jako zdarzenia potencjalnie istotne dla bezpieczeństwa.
✅ Aktualizuj NemoClaw
Administratorzy powinni korzystać z aktualnego wydania NemoClaw i zapoznać się z najnowszymi wytycznymi wdrożeniowymi NVIDIA.
NVIDIA nadal wzmacnia obsługę lokalnego wnioskowania, w tym wprowadza kontrole mające zapobiegać nasłuchiwaniu backendów Ollama poza loopback w konfiguracjach chronionych przez jej lokalne proxy.
Szersze ostrzeżenie dla lokalnego AI
Ujawnienie luki w NemoClaw uwypukla pojawiające się wyzwanie w cyberbezpieczeństwie.
Organizacje często uważają lokalnie hostowany model AI za bezpieczniejszy, ponieważ dane nie muszą opuszczać urządzenia ani środowiska firmowego.
Ale lokalne nie oznacza automatycznie bezpieczne.
Lokalny serwer modeli nadal jest usługą sieciową.
Wymaga tych samych podstawowych zabezpieczeń co inna wrażliwa infrastruktura:
- uwierzytelniania
- izolacji sieciowej
- bezpiecznych ustawień domyślnych
- kontroli dostępu
- integralności konfiguracji
- monitorowania
- regularnych aktualizacji
Rosnące wykorzystanie autonomicznych agentów AI sprawia, że te mechanizmy kontroli są jeszcze ważniejsze.
Model AI nie zawsze jest już systemem, który po prostu generuje tekst. Może wpływać na tworzenie oprogramowania, uzyskiwać dostęp do informacji firmowych, komunikować się z systemami zewnętrznymi lub inicjować zautomatyzowane działania.
Ochrona integralności warstwy wnioskowania staje się więc częścią ochrony wszystkiego, co agent może robić.
Podsumowanie
Badanie dotyczące NVIDIA NemoClaw pokazuje, jak tradycyjna technika webowa, taka jak DNS rebinding, może nabrać nowego znaczenia po zastosowaniu jej wobec nowoczesnej infrastruktury AI.
Złośliwa strona internetowa nie musi kompromitować modelu od strony matematycznej. Jeśli może dotrzeć do nieuwierzytelnionej lokalnej usługi wnioskowania, zmiana konfiguracji otaczającej model może wystarczyć, by wpłynąć na jego przyszłe zachowanie.
Dla firm eksperymentujących z lokalnymi agentami AI powinno to być ważne przypomnienie, by badać infrastrukturę pod modelem — a nie tylko sam model.
Lokalną infrastrukturę AI trzeba traktować jak każdą inną usługę uprzywilejowaną. Izoluj API wnioskowania, uwierzytelniaj dostęp, chroń konfigurację modeli i nigdy nie zakładaj, że „AI na localhost” jest automatycznie bezpieczne.
