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

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