Oasis Security разкри слабост в NVIDIA NemoClaw, която може да позволи на контролирана от атакуващ уеб страница да поеме неаутентифициран контрол над локалния Ollama екземпляр, обслужващ AI агент, и да засади скрити инструкции в самия модел.

Констатациите бяха споделени с The Hacker News преди публикуването им, като в доклада се посочва, че Oasis Security предварително е докладвала за тях на екипа за реагиране при инциденти с продуктовата сигурност (PSIRT) на NVIDIA.

Въпреки това уязвимостта не носи CVE идентификатор, няма посочен диапазон от засегнати версии, нито версия, в която е отстранена уязвимостта, така че оператор, изпълняващ NemoClaw, в момента не може да провери дали неговата инсталация е засегната. Към 25 август 2026 г. не се съобщава за експлоатация на уязвимостта.

NemoClaw е референтният стек с отворен код на NVIDIA за стартиране на агенти като OpenClaw в неговите изолирани среди OpenShell, а Ollama е една от поддържаните локални среди за извличане на изводи (inference backends).

Докладът описва как NemoClaw стартира Ollama с OLLAMA_HOST=0.0.0.0:11434, свързвайки сървъра на модела с всеки мрежов интерфейс, и посочва, че полученият достъп до API позволява на атакуващия да промени шаблона за чат на модела, така че скритите инструкции да се прилагат към всеки следващ разговор.

„Изолирането в пясъчник защитава крайната точка, но превземането на агента компрометира неговия достъп и инструменти“, се казва в доклада на Oasis Security.

Собствената документация за настройка на Ollama от NVIDIA и настоящият изходен код поставят това свързване на един специфичен път на платформата. Управлението на Ollama от NemoClaw се различава в зависимост от платформата:

  • Хостове, които не са базирани на WSL, поддържат Ollama на 127.0.0.1:11434 зад reverse proxy с токени на 0.0.0.0:11435, а първоначалното конфигуриране рестартира демон, който вече е свързан другаде, обратно към loopback интерфейса.
  • Docker Desktop на WSL пропуска проксито, тъй като контейнерът достига до loopback адреса на хоста чрез host.docker.internal.
  • Пътят на Ollama за Windows хост задава OLLAMA_HOST=0.0.0.0:11434, за да могат контейнерите на Docker Desktop да достигнат до демона, и не изисква автентификация на порт 11434.

Страницата за интеграция на NemoClaw в Ollama също съветва да се зададе OLLAMA_HOST=0.0.0.0 при изпълнение в WSL2 или контейнер, а свързването му към 0.0.0.0 и преди е идентифицирано като промяната, която излага екземплярите на Ollama извън локалната машина.

API на порт 11434 няма автентификация и разчита на два слоя междинен софтуер (middleware) за блокиране на заявки, произхождащи от браузъра. Когато адресът за свързване не е loopback, проверката на заглавката Host се пропуска изцяло. Слоят за споделяне на ресурси с различен произход (CORS) след това третира заявката като от същия произход (same-origin) и я разрешава, тъй като заглавките Origin и Host съдържат собствения домейн на киберпрестъпника. Това е в сила за страница, която атакуващият обслужва на порт 11434.

Пренасочването на системата за имена на домейни (DNS rebinding) преодолява тази бариера, като домейнът на атакуващия се разрешава първо до неговия собствен сървър, а след това до 127.0.0.1, докато браузърът продължава да третира заявките като заявки от същия произход.

В доклада не се посочва срещу кои браузъри или операционни системи е потвърдена веригата от атаки. Проверката на заглавките Host и Origin е стандартното решение за този клас атаки.

DNS rebinding атаката срещу API на Ollama е документирана. Ollama пусна корекция в сигурността във v0.1.29 на 14 март 2024 г., а NCC Group публикува препоръката като CVE-2024-28224 следващия месец. Този съвет препоръчва валидиране на заглавката Host от страна на сървъра, за да се разреши само набор от оторизирани стойности.

При достъпно API, злонамереният код на доклада записва променен Go шаблон чрез /api/create. Шаблонът контролира как структурираният масив от съобщения се рендира в чист текст, преди моделът да го обработи, а отровената версия добавя контролиран от атакуващия текст към всяко системно съобщение по време на генерирането на отговор.

Инструкциите, засадени по този начин, се запазват при следващите разговори и остават активни дори ако агентът предостави своя собствена системна подкана, според доклада.

„Клиентът не може да открие или предотврати това – шаблонът е свойство на ниво модел, невидимо за потребителите на API“, заявяват от Oasis Security.

The Hacker News прегледа хранилището на NemoClaw при коммит 17f0ca3b на 25 август и установи, че локалното прокси на Ollama отказва да стартира срещу бекенд, който не е свързан към loopback – поведение по подразбиране, въведено във v0.0.106 на 10 август. Проксито се затваря със специален код за състояние и извежда съобщение, че отказва да стартира, тъй като Ollama демон, достъпен на интерфейс, различен от loopback, заобикаля напълно проверката на токена на проксито.

Тази проверка може да бъде изключена чрез задаване на NEMOCLAW_OLLAMA_PROXY_SKIP_BIND_PROBE=1 и тя не блокира достъпа по подразбиране на хостове, където проверката за свързване не може да се изпълни.

Проверката се изпълнява и в самото прокси. NemoClaw не стартира това прокси на WSL пътищата, а конфигурацията на Windows хоста е една от тях. Следователно поведението по подразбиране във v0.0.106 не достига до пътя на платформата, където е зададено свързването към 0.0.0.0.

Същият преглед не установи проверка за цялост на шаблона за чат никъде в хранилището, като NemoClaw изпраща заявки към крайната точка /api/show на Ollama само за дължината на контекста на модела и декларираните възможности за извикване на инструменти.